[Mesa-dev] Broadcom VideoCore IV

[Rob Clark]

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