Firefox Developers Have Issues With Linux GPU Drivers Too

[kayosiii]

Wow, what a useless feature! But seriously, I'm gonna be interested in gpu acceleration only about the html5 videos, so until that actually is used on the net, this is really not a concern. Is there really anyone interested in having stupid 3d animations on his browser?!

Quite interested - I work for a company that does realtime 3d visualisations of constructions - we get a lot of clients requesting a web based solution. The main thing that stops us is that fact that everything that is not AMD/nVidia is horrible to develop for.

[89c51]

It's coming.

http://blog.johnford.info/linux-qt-b...g-generated-2/

nice to have

i read in the gentoo forums they had stoped development after one of the beta versions of ff4

now give us a e17 mozilla

[popper]

Is that GL ES itself or "the GL ES subset of GL" which was what the X devs recommended ?

well IF you step back and look at the Bigger picture (ARM Cortex using ES 2.X API,windows coming to ARM etc) it will be libGLESv2.so aka the OpenGL ES 2.X API from now on.

it would seem for every x86 Linux dev working on that, there are/will be masses more ARM Devs in all the embedded markets already using that ES 2.X API as their base rather than so called standard GL

as for the "the GL ES subset of GL", i wont argue the point, ill let ChrisT at the HP Palm developer centre make the point

http://developer.palm.com/distribution/viewtopic.php?f=70&t=5843&start=25

"ChrisT:This is just a matter of definition so it's a pretty pointless argument; but definition-wise; a subset is smaller or equal to the original set. In some ways, GL-ES is a super-set of GL as such it cannot be called a subset. Yes it was totally inspired by GL 2.0, but it has more than that."

"anaya2:from the Khronos Website...... It consists of well-defined subsets of desktop OpenGL...."

"ChrisT:Wow; what's pretty bad. You are right; they do claim this. But once again, if you look at the desktop emulations; it will be clear that it can't be a subset. Most likely a disconnect between marketing and the group. I'll bring it up to them and see what's up with that. Thanks for pointing that out. It's clear that this can't be the case merely considering that GLES has a fixed point interface which the desktop version does not have. Perhaps they meant this in terms of features and not so much API. In that case, yes the features are a subset of GL on the desktop. That would be an accurate statement.

As far as developers are concerned however; the API definitely isn't a subset and that imo makes developing for it somewhat painful. GL-4.0 may have remedied some of that; I have yet to look at what that spec looks like "

[popper]

Stupid one minute edit limit

I'm sure the developers are seeing other issues as well, but those are going to be more in the "both sides gotta agree on a core set of driver functionality to use, upper layers should use that functionality, and devs will make sure it works" department. I don't know if bugs are being filed against the drivers as problems are seen during browser development, but that would obviously help as well.

cant say for browser developers in x86 or even if ARM devs care for firefox devs inability to help out, but for ARM libGLESv2.so there are a few bug reports, one being directly related that recent

https://bugs.freedesktop.org/show_bug.cgi?id=32254

EGL+OpenGL API failed to work, that in turn came from the ARM devs

https://bugs.launchpad.net/glproxy/+bug/683993

Failed to run triangle for OpenGL backend with mesa7.9 egl driver

the ARM libGLESv2 devs are mostly happily using that to write apps now, since 2009 when libGLESv2 and related linux libs code etc arrived

http://www.powerdeveloper.org/forums/viewtopic.php?t=1841&postdays=0&postorder=asc&start=0

GL ES2 Render Pipeline Backend on EfikaMX

http://www.powerdeveloper.org/forums/viewtopic.php?p=12704

opengl es

"mvdhoning:Can you give some more info on the status of opengl es on the new efika?

What version will it be.
Will it work without x.
Will it be a precompiled kernel module?"

Matt Sealey (Neko):Tue Aug 25, 2009
* OpenGL ES2.0 and OpenVG 1.1
* Yes
* There is a precompiled kernel module and precompiled GL libraries."

so it seems if the firefox x86 devs have a problem finding a way to work better and smarter code with the x86/ARM driver devs, then they should perhaps step back a little and find a better way of working PDQ before libGLESv2 takes off in a massive end user devices way, but then im not even sure people want to use and port firefox code there anyway.

[bridgman]

as for the "the GL ES subset of GL", i wont argue the point, ill let ChrisT at the HP Palm developer centre make the point

http://developer.palm.com/distribution/viewtopic.php?f=70&t=5843&start=25

"ChrisT:This is just a matter of definition so it's a pretty pointless argument; but definition-wise; a subset is smaller or equal to the original set. In some ways, GL-ES is a super-set of GL as such it cannot be called a subset. Yes it was totally inspired by GL 2.0, but it has more than that."

I wasn't at XDS to nitpick over the wording being used, but I guess if you want to call in the lawyers then more appropriate wording would be "that portion of GL 2.0 which is also in GL ES 2.0", or "the subset of GL 2.0 which is in GL ES 2.0" or something like that. The important part is that apparently the GL 2.0 spec includes some things outside what DX9 hardware is necessarily able to do, while GL ES does not... and since there are a *lot* of DX9 GPUs out there being asked to run GL 2.0 that's fairly important.

[popper]

I wasn't at XDS to nitpick over the wording being used, but I guess if you want to call in the lawyers then more appropriate wording would be "that portion of GL 2.0 which is also in GL ES 2.0", or "the subset of GL 2.0 which is in GL ES 2.0" or something like that.

The important part is that apparently the GL 2.0 spec includes some things outside what DX9 hardware is necessarily able to do, while GL ES does not... and since there are a *lot* of DX9 GPUs out there being asked to run GL 2.0 that's fairly important.

sure that was Not my intent, but you know that someone reading Will try and nitpick, so i thought it was interesting info to include when they do.

indeed some (other than you) might say "that's fairly important", given you like to set a plan in motion and stick to it I.e the UVD review and the gallium posts etc.

id also say it's time to draw the line as a first step as of now, and write these missing GL ES v2 parts and concentrate on DX10.1 for now when time allows OC, and worry about DX9 GPUs later... but perhaps that's just me hoping Far More (x86/ARM) developers actually looking at MESA and perhaps coming to help out the core dev's if this DX10.1 commitment were set officially, the 'bigger picture' and all that.

[Danny]

I used GrafxBot about a month or two ago to test how my RS480 would perform using r300g for hardware acceleration on FF4. If I remember correctly, it conducted, I think, 775 tests which took quite a while (and heavy cpu usage!). Out of those 775 tests, atleast 20 or so couldn't be determined automatically as pass or fail and were potential test fails which I had to confirm manually. It involved comparing simple primitives to see if they were displayed, coloured appropriately or placed appropriately. Out of those 775 tests, it ultimately failed only two; hence it passed 773 / 775 tests. Now I don't know how complex these tests were; I'm not a dev unfortunately If they were only some sort of conformance tests, then 773 / 775 seems pretty good for me for r300g which was about a month ago. At that time, I looked for some config options to force hardware acceleration and test on FF4 but had no luck.

bjacob, i hope you might be able to provide more info on GrafxBot and what those results mean and compare with others (if any available)

More info on GrafxBot:
https://addons.mozilla.org/en-US/fir...don/grafx-bot/
http://jagriffin.wordpress.com/2010/...ing-grafx-bot/

[blindfrog]

Last couple of Catalyst releases have worked just fine with WebGL demos under Fedora 14 with both Firefox 4 and Chromium without any crashes. I don't know how resent "fglrx" drivers some of the devs are trying out but the new ones seems to work just fine.

[mgraesslin]

We really need some kind of extension/API mechanism with a bit more subtlety, ie a third "this is exposed but in development, so if you *can* work with a lower API level you should" state between "not exposed" and "exposed".

If there are runtime options to (for example) ignore GL ES even if it is exposed that would probably be a big help in the short term.

This would really help the KWin case. What about just having an environment variable, something like MESA_SAVE_EXTIONSIONS=1 which could be set by the app?

Concerning the KWin case we will also see some improvments in 4.7 through the GLES branch. We will add an option for the other to either use 1.x only or 2.x only, the 2.x code path (only GLES compatible code) will most likely be the default. Additionally I will try to get a testapp setup to decide whether 1.x, 2.x or GLES should be used.

[plonoma]

So would the real solution to have a non-standard way of signaling that the API is a WIP, rather than having it marked as working? Something like the -moz-rounded-corner CSS settings for Mozilla, or the matching ones for Webkit back when they were testing it out. That way, the only applications that see that a WIP feature are there are the ones that are specifically testing out that feature in that driver. Are there any cases where other applications would want to see WIP features as enabled? Once it does work, the driver reports it in the standard way, like -rounded-corners in modern CSS.

Am I totally off base with this?

That would indeed be very handy.
Something like the system used here:
http://www.x.org/wiki/RadeonFeature



"DONE" means that it is implemented and relatively bug-free.

"MOSTLY" means that it is implemented but has some known bugs.

"WIP" means that someone has started on the initial implementation.

"BIOS" means only if supported by your BIOS. No software support. Yet.

"N/A" means that the feature is not supported by the hardware.

"N/N" means that the feature will not be implemented, because a better alternative is or will be available.

"TODO" means that someone needs to write the code. The required knowledge to write the code may or may not be known. Please ask on #radeon if you want to get your feet wet on this.

"UNKNOWN" means that the current status of this item isn't known. You are free to update it if you know.