<div class="gmail_quote">Le 14 mai 2014 21:02, "Mohamed MEDIOUNI" <<a href="mailto:mohamedmediouni91@gmail.com">mohamedmediouni91@gmail.com</a>> a écrit : <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Le 29 avr. 2014 02:52, "Rob Clark" <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> a écrit : > > On Sun, Apr 27, 2014 at 5:51 AM, Mohamed MEDIOUNI > <<a href="mailto:mohamedmediouni91@gmail.com" target="_blank">mohamedmediouni91@gmail.com</a>> wrote: > > > > Le 21 avr. 2014 13:16, "Rob Clark" <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> a écrit : > >> > >> On Sat, Apr 19, 2014 at 9:32 AM, Mohamed MEDIOUNI > >> <<a href="mailto:mohamedmediouni91@gmail.com" target="_blank">mohamedmediouni91@gmail.com</a>> 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. </blockquote></div>