On Sun, Apr 27, 2014 at 5:51 AM, Mohamed MEDIOUNI <mohamedmedioun...@gmail.com> wrote: > > Le 21 avr. 2014 13:16, "Rob Clark" <robdcl...@gmail.com> a écrit : >> >> On Sat, Apr 19, 2014 at 9:32 AM, Mohamed MEDIOUNI >> <mohamedmedioun...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
