[Mesa-dev] Broadcom VideoCore IV

[Mohamed MEDIOUNI]

Le 14 mai 2014 21:02, "Mohamed MEDIOUNI" <mohamedmediouni91 at gmail.com> a
écrit :

>
> Le 29 avr. 2014 02:52, "Rob Clark" <robdclark at gmail.com> a écrit :
> >
> > On Sun, Apr 27, 2014 at 5:51 AM, Mohamed MEDIOUNI
> > <mohamedmediouni91 at gmail.com> wrote:
> > >
> > > Le 21 avr. 2014 13:16, "Rob Clark" <robdclark at gmail.com> a écrit :
> > >>
> > >> On Sat, Apr 19, 2014 at 9:32 AM, Mohamed MEDIOUNI
> > >> <mohamedmediouni91 at gmail.com> wrote:
> > >> > The VideoCore IV GPU has 14 cores:
> > >> >
> > >> > - 2 VPU Cores : Full-blown cores which run the ThreadX RTOS.
> > >> > There is an experimental LLVM port to it and also the VBCC C89
> > >> > compiler(which has'nt time support so classic benchmarks run
> > >> > indefinitely).
> > >> > The binary blob run on that.
> > >> > 5 GFlops
> > >> >
> > >> > - 12 QPU Cores : 3D cores officially documented by Broadcom and
> using a
> > >> > tile-mode rendering architecture.
> > >> > The full Android driver for that was open-sourced at the end of
> > >> > February.
> > >> >
> > >> > 24Gflops
> > >> >
> > >> > Questions:
> > >> >
> > >> > Can Gallium3D run with tile-mode rendering architecture ?
> > >>
> > >> yes, adreno (freedreno) is a tiler
> > >>
> > >> > Is it better using Mesa and  the Broadcom shader compiler ?
> > >>
> > >> Allegedly it may be easier to shoehorn in the blob compiler with a
> > >> mesa/dri driver vs mesa/gallium driver.  That probably shouldn't be
> > >> too much of a concern in the long run.  Overall I think a gallium
> > >> driver would be much easier to implement... gallium plus helpers
> > >> provide a lot to the driver writer.
> > >>
> > >> > Is it better using the VPU and an adapted LLVMpipe ?
> > >>
> > >> I guess you are talking about keeping the driver-on-videocore
> > >> approach?  That may have some advantages when it comes to handling
> > >> security (lack of mmu) on r-pi.  But other than that, I suspect
> > >> everything else will be easier to develop/debug on the arm side.  And
> > >> I suspect avoiding round trips to the coprocessor will help
> > >> performance in a lot of cases.
> > >>
> > >> so if you can figure out a way to deal with security aspect with arm
> > >> side driver, then I'd go for arm side gallium driver as my first
> > >> choice.
> > >>
> > > Have now some problems including :
> > >
> > > Need to run the programs as root or chmod 777 /dev/mem and chmod 777
> > > /dev/vc-mem
> > >
> >
> > yeah, that is a pretty good sign that you are doing something wrong.
> > Normally you need some kernel driver that is mediating access to the
> > hardware.  In fact no modern hardware is directly accessing hw
> > ioregion from userspace.  Normally userspace is constructing cmdstream
> > buffers passed down to kernel mode driver component which is what is
> > dealing with the actual hw
> >
> > BR,
> > -R
> I need that because of the MMU. Will experiment with uCLinux the next few
> days.
> But I will need  to finish the VideoCore LLVM backend before that.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140514/ae9baa3a/attachment.html>