573720 - support mgl prefix for OSMesa, or make a gl prefixed build availble

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

This is really a standard thing, not something specific to Vlad's old Mesa build for Windows:

http://www.mesa3d.org/mangling.html

So mgl prefixes are here to stay.

Moreover, the fix is 1 line of code. And by checking the gl prefix first, we don't even slow things down for gl-prefixed users.

So what's the point NOT supporting this?

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Support mgl prefix

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

See recent post to the public_webgl list. Let's not make people stick to alpha4.

Comment 3

[Giles Thomas]

Hmm.  I've come around to Vlad's line of thought on this; even though mgl_ is a standard build target for Mesa, the real problem here is that binary copies of the Mesa DLL for Windows aren't readily available.  The only reason that there is an mgl_ prefixed binary available for Windows is because Vlad happened to build one and put it up on his blog.

I think it would be much better to provide a gl_ prefixed binary and make that widely available, and to keep Minefield as it is.  I tried building one myself, but the output of a default Mesa build using the current Microsoft Visual Studio Express doesn't seem to work.  It was about 400kb in size as compared to Vlad's one's 2.6Mb or so, so I assume that he'd done something to make it include more stuff...

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Then let's use this bug to track the task of making gl_ prefixed OSMesa available on Windows... updating the title.

My point is that since this is a standard option, we'll always eventually have users who built their own OSMesa with mgl_ prefix and will be disappointed that it doesn't work with firefox.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

And since supporting that is only 1 line of code, perhaps 100 bytes of resulting binary code, and zero performance/memory overhead for people who don't use it, I still don't understand why we don't support it.

Comment 6

[Giles Thomas]

Fair enough -- as a user, I just want to be able to run with software rendering, so as long as there's a DLL binary to use, it doesn't matter which prefixes it uses.  Whatever works best for you.

Hmmm.  That makes me wonder -- is there a case for building Mesa into Firefox for Windows?  I guess there's a potential licensing issue, but having a well-defined version sitting in C:\Program Files\Minefield would make config much easier for the average not-so-techie user.

Of course, if you're looking at using ANGLE as the underlying drawing API then it might all be irrelevant.

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #0)
> This is really a standard thing, not something specific to Vlad's old Mesa
> build for Windows:
> 
> http://www.mesa3d.org/mangling.html
> 
> So mgl prefixes are here to stay.
> 
> Moreover, the fix is 1 line of code. And by checking the gl prefix first, we
> don't even slow things down for gl-prefixed users.
> 
> So what's the point NOT supporting this?

Indeed, I have said that mesa name mangling is a standard compile option.  However, it is /not possible/ to build mesa with mangled symbol names easily on win32.  It takes a bunch of hacking of def files and other crap, because the default build is set up to generate normal gl* names.  The Linux vendors all ship osmesa with gl* names.  So the only reason there would be for supporting the mgl names is so that people can use the old broken version of OSMesa that I built a long time ago, which is not worth supporting; so this problem goes away if I or someone were to just rebuild a win32 mesa dll without the name mangling, because anyone who has the 'mgl' mangled names would have had to go out of their way to get one.

The cost of supporting it isn't super high, but there's no benefit to doing so.

Also, for building Mesa -- there isn't a license issue, but there is a pure code size issue.  Mesa is large, and it would probably double the Firefox download size.  What we can do though (and it's on the list) is to provide an addon-installable version that will come with the dll and set itself up, so users who want it can just install an addon and have things work.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 453043 [details] [diff] [review]
Support mgl prefix

I've got an OSMesa DLL (built stock, but with SSE2 turned on in compile flags) at http://people.mozilla.com/~vladimir/misc/OSMESA32.zip .  Works fine, but needs a patch to firefox.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: small fix to make osmesa work

Here's the small fix -- fixes two problems, one the WGL impl blindly calls ChoosePixelFormat even if it's not supported leading to a crash before we even decide that we can't create a WGL pbuffer.  Two, we need to use the lookup function before we just try to find the symbol in our process.. otherwise we end up finding some Win32 GL symbols and some Mesa GL symbols, leading to all sorts of confusion.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 453558 [details] [diff] [review]
small fix to make osmesa work

Oops, forgot to review this patch.

Comment 11

[Giles Thomas]

This sounds great!  Is there any way you'd suggest I could check it out?

I just tried to test it on my machine, using last night's build, but I'm not sure my test was conclusive -- I do have working OpenGL drivers here, and when I set webgl.software_render to "true" and point webgl.osmesalib at Vlad's new file, everything rendered OK -- but so quickly that I suspect it was still using hardware rendering.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Giles: (In reply to comment #11)
> This sounds great!  Is there any way you'd suggest I could check it out?

Apparently, Vlad hasn't pushed it yet, for if he had, he would have pasted here a link to the corresponding changeset.

> 
> I just tried to test it on my machine, using last night's build, but I'm not
> sure my test was conclusive -- I do have working OpenGL drivers here, and when
> I set webgl.software_render to "true" and point webgl.osmesalib at Vlad's new
> file, everything rendered OK -- but so quickly that I suspect it was still
> using hardware rendering.

If it were using OSMesa, you would see a message about that in the JS error console.

If you want to test it before Vlad pushes it, you have to check out mozilla sources, apply the patch, and build yourself.

Comment 13

[Giles Thomas]

Fair enough -- I'll just keep an eye on this ticket and try again when I've see a link to the changeset here implying that it's hit the nightly builds.

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

http://hg.mozilla.org/mozilla-central/rev/669f3a225e46