request/suggestion to work together to get hardfp/OSS ARM GPU drivers and/or to get documentation

Joop Boonen joop.boonen at boonen.org
Sun Oct 23 08:40:51 UTC 2011


On Sat, October 22, 2011 3:52 pm, Konstantinos Margaritis wrote:
> On 22 October 2011 16:17, Joop Boonen <joop.boonen at boonen.org> wrote:
>> Hi all,
>>
>> Most of the (ARM) distros are currently working on or in the transition
>> to
>> hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any
>> hardfp drivers yet.
>>
>> To be able to have a ARM hardfp compiled X Window desktop
>> system/notebook
>> with 3D support we need hardfp compiled drivers.
>>
>> I was thinking it might be more efficient is all Linux distro's work
>> together to get these drivers as it's equally important for all distro
>> that wants to move to a hardfp distro.
>>
>> What do you all think, who wants to work together to get full hardfp
>> support for as most as possible ARM SOC GPUs?
>>
>> It would be great if we can in the end even have OSS drivers.
>
> Hi,
>
> Nvidia was the first to release hardfp drivers for tegra2 gpus for
> armhf, and we also have working drivers for hardfloat for the
> Freescale i.MX51 and i.MX53 gpus, which we use on our current and
> upcoming products (Genesi Smarttop/Smartbooks). It took a lot of time
> and effort on our side to push for that, and obviously not for
> technical reasons -it was just a 5 minute recompile of a binary static
> library.

I can imagine. I understood that the MX51 has a AMD Z430 GPU. Which has
been renamed to Adreno 200 (AMD Z430), as Qualcomm bought the handheld
graphics unit from AMD.

http://en.wikipedia.org/wiki/Imageon

So you probably have to go through FreeScale that might need approval from
Qualcomm to build a hardfp driver.

I understood that in the ARM SOC world the SOC producer is responsible for
the video driver, which is very different from the PC world where the
designer is delivers the driver (NVidia/AMD/Intel).

> But in the end it was worth it. We're getting 15-20% increase
> in performance on average -sometimes more- in our GLES benchmarks, and
> we're working to squeeze more performance out of that -I'm currently
> working on neon-optimizations in the GLES1 backend, which may not be
> current, but it's still used by some important and very much needed
> applications (i.e. quake3 :).
>
> So, the list is short right now, but that is the least of our
> problems. The real problem is getting all of the kernel gpu drivers
> into a single (mainline?Linaro?) kernel tree. The vendors are very
> resistant in releasing specs or source code, and the kernel guys are
> equally -if not more- resistant in accepting half-open/half-closed
> drivers into the kernel tree.

I think this is de to GPL, that why they only allow open source modules
for the kernel. That's also why the proprietary kernel modules for NVidia
and AMD are not in the standard kernel.

> It's going to be a long road, but I
> think that eventually we're getting there, unless of course a miracle
> happens and all vendors simultaneously opensource their drivers :)

I hope it will happen soon. It feels the time when NVidia and ATI didn't
build any (3D) drivers for Linux. This slows down Linux development a lot
and it'll limit that hardware you'll be able to use Linux on.

>
> Regards
>
> Konstantinos
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
Regards,

Joop.




More information about the Ubuntu-server-arm mailing list