Firefox Developers Have Issues With Linux GPU Drivers Too

[monraaf]

actually, he made a valid point and testing in mesa mailing list confirms that: most (all?) open drivers pass almost all the tests but just crash ff randomly because of few other bugs.

Well the drivers support many cards from many families, not all are cards equally well supported. In fact Evergreen support in r600g has regressed so badly that it can't even run blender without locking up. I guess that's what you get when everybody hacking on it only test with the cards they have available (probably HD 4xxx series), sigh...

Anyway here's my experience with Firefox + WebGL + latest r600g:

http://img30.imageshack.us/i/2lc.mp4/

As you can see it's a little more serious than just Firefox crashing. So I can certainly understand why the Firefox devs have disabled WebGL for anything but NVidia blob.

WebGL demo from:

http://videos.mozilla.org/serv/mozhacks/flight-of-the-navigator/

[Thatguy]

i find it hard to believe that linux's 3d is hard to work with. even before linux had any decent video drivers, people still made 3d games. maybe not good ones, but they worked. if the ff devs are focusing explicitly on open source drivers and not proprietary, then really, they're idiots. open source video drivers are just about the worst open source products there are. besides, if they can get 3d working with proprietary drivers from other OSes, as i see it, that should mean that they only have a few things to tweak to make it work. they don't have to claim the entire 3d portion of the browser non-functional, they should just simply discourage using open source drivers temporarily. its better to have something than nothing.

even opera puts more dedication to their linux side than firefox has. i'm glad i'm an opera (and chrome) user.

Well, how hard is it to hit a moving target ? 3d code is massively complicated and the IL "intermediate layer" and the assembly compiler are effected by the ever evolving kernel changes.

should it be easy to write code for linux for good 3d performance, on paper yes. Is it viable for companys to chase the roving targets ? likely not. All of these GPU accelerated apps rely on a fiarly consisten API to function properly and becuase the linux API is highly flexiable and in a state of flux, its very hard to target properly.

With gallium drivers and the gallium IL and IL API comming along quickly, we might see a gpu accelerated browser.

People forget alot of the code in the nvidia and ati 3d drivers is likely microsoft code to begin with which is why we all get screwed in the end. New GPU's are very very dedicated to current Direct X standards from the hardware layers up to the drive IL language.

Its not a cut and dry problem.

[dfx.]

OpenSource drivers are good enough to play Quake 3, but not to show photos moving in circles?

Troll attempt failed. Try again later.

actually, he made a valid point and testing in mesa mailing list confirms that: most (all?) open drivers pass almost all the tests but just crash ff randomly because of few other bugs.

[transwarp]

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.

I'm not sure if I got my point across, so I'll spell it out more cleanly.

My understanding is that when a feature is under development, the driver is reporting that feature as available when the user program queries it. I think there should be one of two solutions (or both of them):

a. The feature is never reported as available using the standard API. A new standard or non-standard API is used to query the list of in-progress features. This would allow special programs to be used to test new features without impacting real applications.

b. The feature is not reported as available using the standard API until a standard or non-standard API call is made to inform the driver that it is in testing and evaluation mode. In-progress features are then reported as working. This allows normal applications to be used to test the driver with the feature, with only a small change or wrapper to the application.

The table you linked to has a lot of options, and I'm not sure the complexity of having more states than working/WIP/not working in the drivers and APIs themselves is worth the benefit it would bring. That is definitely the kind of knowledge that I think should be available programmaticly, though.

But talk is cheap, and I'm no X developer, so I may have no idea what I'm talking about.

[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.

[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.

[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.

[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/

[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.

[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.