1 |
On Sat, October 22, 2011 3:52 pm, Konstantinos Margaritis wrote: |
2 |
> On 22 October 2011 16:17, Joop Boonen <joop.boonen@××××××.org> wrote: |
3 |
>> Hi all, |
4 |
>> |
5 |
>> Most of the (ARM) distros are currently working on or in the transition |
6 |
>> to |
7 |
>> hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any |
8 |
>> hardfp drivers yet. |
9 |
>> |
10 |
>> To be able to have a ARM hardfp compiled X Window desktop |
11 |
>> system/notebook |
12 |
>> with 3D support we need hardfp compiled drivers. |
13 |
>> |
14 |
>> I was thinking it might be more efficient is all Linux distro's work |
15 |
>> together to get these drivers as it's equally important for all distro |
16 |
>> that wants to move to a hardfp distro. |
17 |
>> |
18 |
>> What do you all think, who wants to work together to get full hardfp |
19 |
>> support for as most as possible ARM SOC GPUs? |
20 |
>> |
21 |
>> It would be great if we can in the end even have OSS drivers. |
22 |
> |
23 |
> Hi, |
24 |
> |
25 |
> Nvidia was the first to release hardfp drivers for tegra2 gpus for |
26 |
> armhf, and we also have working drivers for hardfloat for the |
27 |
> Freescale i.MX51 and i.MX53 gpus, which we use on our current and |
28 |
> upcoming products (Genesi Smarttop/Smartbooks). It took a lot of time |
29 |
> and effort on our side to push for that, and obviously not for |
30 |
> technical reasons -it was just a 5 minute recompile of a binary static |
31 |
> library. |
32 |
|
33 |
I can imagine. I understood that the MX51 has a AMD Z430 GPU. Which has |
34 |
been renamed to Adreno 200 (AMD Z430), as Qualcomm bought the handheld |
35 |
graphics unit from AMD. |
36 |
|
37 |
http://en.wikipedia.org/wiki/Imageon |
38 |
|
39 |
So you probably have to go through FreeScale that might need approval from |
40 |
Qualcomm to build a hardfp driver. |
41 |
|
42 |
I understood that in the ARM SOC world the SOC producer is responsible for |
43 |
the video driver, which is very different from the PC world where the |
44 |
designer is delivers the driver (NVidia/AMD/Intel). |
45 |
|
46 |
> But in the end it was worth it. We're getting 15-20% increase |
47 |
> in performance on average -sometimes more- in our GLES benchmarks, and |
48 |
> we're working to squeeze more performance out of that -I'm currently |
49 |
> working on neon-optimizations in the GLES1 backend, which may not be |
50 |
> current, but it's still used by some important and very much needed |
51 |
> applications (i.e. quake3 :). |
52 |
> |
53 |
> So, the list is short right now, but that is the least of our |
54 |
> problems. The real problem is getting all of the kernel gpu drivers |
55 |
> into a single (mainline?Linaro?) kernel tree. The vendors are very |
56 |
> resistant in releasing specs or source code, and the kernel guys are |
57 |
> equally -if not more- resistant in accepting half-open/half-closed |
58 |
> drivers into the kernel tree. |
59 |
|
60 |
I think this is de to GPL, that why they only allow open source modules |
61 |
for the kernel. That's also why the proprietary kernel modules for NVidia |
62 |
and AMD are not in the standard kernel. |
63 |
|
64 |
> It's going to be a long road, but I |
65 |
> think that eventually we're getting there, unless of course a miracle |
66 |
> happens and all vendors simultaneously opensource their drivers :) |
67 |
|
68 |
I hope it will happen soon. It feels the time when NVidia and ATI didn't |
69 |
build any (3D) drivers for Linux. This slows down Linux development a lot |
70 |
and it'll limit that hardware you'll be able to use Linux on. |
71 |
|
72 |
> |
73 |
> Regards |
74 |
> |
75 |
> Konstantinos |
76 |
> |
77 |
> _______________________________________________ |
78 |
> linaro-dev mailing list |
79 |
> linaro-dev@××××××××××××.org |
80 |
> http://lists.linaro.org/mailman/listinfo/linaro-dev |
81 |
> |
82 |
Regards, |
83 |
|
84 |
Joop. |