We tried enabling OpenGL on Linux, and discovered that most Linux drivers are so disastrously buggy (think “crash the X server at the drop of a hat, and paint incorrectly the rest of the time” buggy) that we had to disable it for now. Heck, we’re even disabling WebGL for most Linux drivers, last I checked…
If your drivers are decent (some of the closed-source ones can be, nouveau can be sometimes), you do get something akin to Direct2D on Linux through XRender, though. So while you don’t get compositing acceleration, you do get faster canvas drawing and the like. drawImage, for example, can be much faster on Linux than on Mac. But only if you manage to find a driver and X version that happens to not suck…
We do plan to put more work into the Linux end of this, look for workarounds for the various bugs, etc. But we could really use some help from Xorg and distros and the like here…
This is somewhat embarrassing for the Linux community. Anyone know anyone who can help?
The Radeon OSS drivers post on the Phoronix.com forums, and are very helpful…
DDD
I wonder what kind of OpenGL firefox uses that makes it a problem on most drivers where a lot of other GL applications or games don’t have so much problems (I’m not saying they’re exempt of problems). Hell, I haven’t seen a GL application crash on me, yet firefox crashed when I forced enabling webgl.
>Heck, we’re even disabling WebGL for most Linux drivers, last I checked…
Yes, but that’s because your WebGL implementation is buggy.
When I run: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
with the latest Firefox on my Radeon R600, it crashes almost immediately.
Chromium on the other hand finishes most tests without any problem on
the same hardware…
Maybe this is because GLES v2 requires a minimum of 8 texture units,
whereas the R600 has only 4. But on Chromium you can switch from EGL to
GLX with –use-gl=desktop. I don’t know if a similar switch is possible
with Firefox.
What’s embarrassing?
Chris Jones: the fact that it works fine on Windows and OS X, but not on Linux.
(And I should make it clear I count myself as a member of that community.)
Gerv
To octoploid : no crashes for me.
Results: (5249 of 5315 passed, 3 timed out)
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20100101 Minefield/4.0b10pre
Linux fredo-arch 2.6.37-ARCH #1 SMP PREEMPT Fri Jan 7 17:32:33 CET 2011 x86_64 AMD Athlon(tm) II X2 215 Processor AuthenticAMD GNU/Linux
[fred@fredo-arch objdir-fx]$ yaourt -Si nvidia
Dépôt : testing
Nom : nvidia
Version : 260.19.29-2
webgl.enabled_for_all_sites;true
webgl.force_osmesa;false
webgl.mochitest_native_gl;false
webgl.osmesalib;
webgl.shader_validator;true
webgl.verbose;false
“Open source drivers” community is a joke. Not only they don’t implement OpenGL properly, the performance is so poor and bad you can’t even use it. And they have the gall to criticise Nvidia for providing working Linux drivers with proper OpenGL support, high performance, VDPAU hardware decoding support, OpenCL support.
http://www.phoronix.com/data/img/results/nvidia_nouveau_q111/5.png
To FredBezies:
Yes, Firefox should print a warning when the graphic card
does not have enough texture units, instead of just crashing.
But the best thing would be a WebGL implementation based on GLX.
With this even “older” cards would run just fine most of the time.
To Driver:
It’s just lack of man-power (developers, developers, …).
But you’re right: When the open source drivers will be ready,
the cards will be obsolete…
@Octoploid: That might hold true for nVidia cards, where the reverse-engineering required for nouveau means that it tends to lack support for recent hardware. Intel graphics work before the hardware even gets released to the public, and ATI seems fairly close behind these days.
@gerv: I can’t speak to the quality of nouveau or ATI, but Intel at least seems rock-solid stable. You might look into the texture-units issue mentioned in other comments. If you have more-or-less reproducible crashes on Intel, contact Keith Packard. For ATI, try Alex Deucher.
Can Firefox use OpenGL optionally at runtime, or do you have to make the decision at build time? If the former, how can I try it to see if it works on my hardware?
To Anonymous2:
Try:
MOZ_GLX_IGNORE_BLACKLIST=1 firefox
Let me add here my 0.02 € as a bug triager on the Red Hat bugzilla for both MoFo and Xorg components. I think that the biggest mistaken assumption in both this and bug 624390 is that the problematic cases could be separated by drivers. My experience from observing many thousand Xorg bugs over the last couple of years is that the algorithm is much more complicated … it is more about combination of driver, particular chipset, kernel version and sometimes even monitor. E.g., I have here notebook with intel chipset and open source intel driver and both the Flight of the Navigator and WebGL Aquarium (from http://blog.vlad1.com/2010/12/21/webgl-in-firefox-4-beta-8/) work just fine. I am certain that for somebody else with different intel chipset this might be quite crashy experience. I believe that the summary from my experience is that Mozilla sholdn’t even try to maintain such white-/black-list, because it is just overwhelming, and probably best left to the Xorg distribution maintainers.
Hey, this is opensource. Publish test cases, and tell fanboys that Linux will suck until they are fixed
And then fanboys will bugger developers until they fix it!
@octoploid
20100101? =P
I get almost the same results here with the same about:config settings as you listed.
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20110108 Firefox/4.0b9pre
Results: (5217 of 5452 passed, 3 timed out)
OpenGL renderer string: GeForce 7600 GS/PCI/SSE2
OpenGL version string: 2.1.2 NVIDIA 260.19.29
Linux 2.6.37-gentoo #2 SMP PREEMPT Sat Jan 8 21:18:15 CET 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ GNU/Linux
I’m go to Linux
Well, the Mesa/DRM/X.Org developers working on those drivers could help if asked …
Answering many comments at once:
@ Gervase: for layers acceleration, the other main reason why it’s not accelerated by default (regardless of drivers) is also that currently this doesn’t interact well with XRender acceleration. If you want, that’s our fault. The news here is that we are also blacklisting drivers, which also affects WebGL. But we are not blacklisting everything. The NVIDIA proprietary driver is already accelerated.
To force-enable layers acceleration go to about:config and set layers.acceleration.force-enabled to true.
To ignore the driver blacklist, define the MOZ_GLX_IGNORE_BLACKLIST env variable.
@ Gervase again: I would have appreciated a bit *less* blog/news coverage on this, I’m spending more time than I would like replying to comments everywhere…
@ Octoploid “that’s because your WebGL implementation is buggy, Chrome doesn’t crash with the same drivers” — that’s a baseless statement. Just because Chrome doesn’t crash with the same drivers doesn’t mean that our crash isn’t a driver crash. We implement things differently so we hit a different set of crashes. The Chrome devs are getting WebGL crashes too, that’s why they temporarily disabled WebGL by default to see how it affects their crashiness. (We don’t have to do this kind of things thanks to crash-stats
@ Matej: yes we know that many factors need to be considered here. However, right now, for the FF 4.0 release, we don’t have time to implement a very complex logic here. Checking for the NVIDIA driver already allows us to safely whitelist it, that’s better than nothing. Looking forward to whitelisting more stuff as soon as possible, and yes that will involve refining the whitelisting logic a lot.
@ Fulano and daniels: I’m about to write to a Xorg mailing list, with test cases. There are great testcases out there, for example: defined MOZ_GLX_IGNORE_BLACKLIST env variable, run firefox, and go to:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
To be clear: the NVIDIA proprietary driver is already whitelisted, and we’re working on whitelisting other drivers/setups ASAP.
Uh, daniels is Daniel Stone, an X.org guy. Ben Kero already bugged me, as well; I’m trying to track down bz so we can discuss this.
Thankyou for being clear, Benoit. Now be verbose and link to the relevant bugs :)
@ Corbin: bkero and MostAwesomeDude have had the great idea of joining the #gfx IRC channel at mozilla, so we’ve had a productive talk. I gave them steps to reproduce (webgl conformance test suite…) and they can reproduce. This conversation will most likely continue on the xorg-devel mailing list now.
@ mardeg: for example:
https://bugzilla.mozilla.org/show_bug.cgi?id=616416
https://bugzilla.mozilla.org/show_bug.cgi?id=589546
you could also run a query on crash-stats.mozilla.com
Gerv, it’s not clear to me that GL “works” in Windows drivers either, necessarily. There are reasons beyond the validation stuff that we’re using ANGLE with a d3d backend on Windows to implement WebGL. As I understand, correctness issues with Windows GL implementations were some of those reasons.
Things do pretty much work on Mac; having the OS vendor explicitly support GL and having a limited set of video hardware, all known to the OS vendor, to support, makes things like having non-buggy drivers much simpler, though.
Linux could help by freezing linux driver APIs. The lack of a solid target for manufacturers to target is, AFAIK, a huge reason why Linux drivers SUCK!
But that’s ok, manufacturers just have to give up their entire intellectual property and Linus and co will write drivers for them! Oh but wait, that hasn’t worked either (see Radeon example). Oh but NDAs are the answer aren’t they? But Linux has got that thing that makes it into a rotating cube … oh yeah, most of the time it doesn’t work!
Linus is wasting a lot of resources, causing a lot of grief and making an embarrassment of Linux with his moving target driver API. It’s time someone stood up the dictator!
@pd. That’s- nice AFAIK rant. To put it in perspective though, 3D in Linux is implemented in a project called MESA, not the Kernel (which only provides a route to the hardware), and isn’t controlled by Linus at all. Don’t let stuff like facts get in you way, though…
@ Boris: I actually have some issues with GL drivers on Mac:
Bug 593867 – crash [@WebGLContext::ValidateProgram] in NVIDIA driver on Mac
and Mac OSX 10.5 has serious enough issues that we’re still considering blacklisting it for WebGL (giving whole-system lockups in the presence of heavy shaders, and test failures that made me disable the WebGL mochitest on 10.5, …).
That could be related to the fact that Apple writes their own OpenGL drivers rather than using manufacturer-provided drivers.
It’s true that the situation on Windows is generally worse (leading to us using Direct3D instead via ANGLE) but there’s one exception though: if I had to name the best OpenGL driver of all cards and platforms, I’d say it’s the NVIDIA driver on Windows.
I tried using MOZ_GLX_IGNORE_BLACKLIST=1 , and enabling WebGL, but I still get messages in the javascript console saying “WebGL: Can’t get a usable WebGL context”. How can I get Firefox to tell me *why* it can’t get a usable WebGL context?
Hello,
Is there a convenient place to report test results for graphics hardware? I’d like to help with webgl on linux, if I can.
I’ve run the graphxbot plugin & sent my kronos conformance test data in the option section, along with my lspci & uname info. Doesn’t look like graphxbot does webgl tests, though.
Also, strangely, some pages (mine, specifically) crash when using software rendering via osmesalib (but the kronos demos run OK, if slowly), like so:
firefox-bin: program/ir_to_mesa.cpp:2187: prog_src_register mesa_src_reg_from_ir_src_reg(ir_to_mesa_src_reg): Assertion `reg.index
Stu: this is definitely not the place :-) If you have a crash to report, a bug report is the place. If it’s just test performance data, I believe Grafxbot is the right way.