Firefox 4

[classicmanpro]

Now that Firefox 4 is out and knowing/hoping that it will probably be available as a binary package by the end of the week, I would like to ask the FF4 users/testers if 3D is available on *BSD?

After looking in the about:config entries, I've noticed something that seems to be related to the mesa libraries. Has anyone tried running 3D on FF4?

I've noticed that, on other platforms, WebGL is not enabled by default and I had to enable it via "webgl.force-enabled".

I also noticed that if I disable all the offline cache entries and enable only the memory cache it's Lightning FAST (about:config -> browser.cache.*).

Thank you.

[drhowarddrfine]

WebGL is enabled by default and I had thought WebGL was enabled on all the other browsers, too. IE9 does not and will not run WebGL cause it's not a modern browser.

I don't know what you mean when you ask if 3d runs.

[adamk]

3D acceleration is available on FreeBSD with the nvidia proprietary driver and various open source drivers (though the open source drivers are less capable than they are on Linux). Since I believe the webgl stuff on Linux requires either proprietary drivers or features only available when using KMS, I think that only the nvidia proprietary driver will be able to provide 3D acceleration for firefox4 on FreeBSD.

Neither NetBSD nor OpenBSD have 3D acceleration for nvidia cards, so they will not work in that situation. OpenBSD does have some support for GEM on intel GPUs, which might be enough to get 3D acceleration on FF4, but I have my doubts that's actually the case.

[BSDfan666]

I don't know if the port will be compiled with WebGL by default on OpenBSD, but as adamk said.. there is 3D support for Intel and ATI, but I don't know if it's suitable for that task.

Quite honestly the concept is weird anyway, I don't get why people keep using browsers for things they were never intended for.

[classicmanpro]

Here is one reason. 3D is really cool to play around with, check the tests on the right (the LAB section).

[classicmanpro]

I think I was right ... The norsemen added MesaLib as a dependency for Firefox 4.

[Oliver_H]

Originally Posted by adamk

3D acceleration is available on FreeBSD with the nvidia proprietary driver and various open source drivers (though the open source drivers are less capable than they are on Linux). Since I believe the webgl stuff on Linux requires either proprietary drivers or features only available when using KMS, I think that only the nvidia proprietary driver will be able to provide 3D acceleration for firefox4 on FreeBSD.

Neither NetBSD nor OpenBSD have 3D acceleration for nvidia cards, so they will not work in that situation. OpenBSD does have some support for GEM on intel GPUs, which might be enough to get 3D acceleration on FF4, but I have my doubts that's actually the case.

Free graphic drivers in Linux aren't more capable. They are sometimes slightly faster. WebGL stuff does work only together with nVidia proprietary drivers in Linux and in FreeBSD. If you want to try it, then you have to enforce it.

https://hacks.mozilla.org/2011/01/fi...comment-349829

http://hacks.mozilla.org/2010/09/hardware-acceleration/

Set via about:config layers.accelerate-all to true and verify it with about:support.

[adamk]

Originally Posted by Oliver_H

Free graphic drivers in Linux aren't more capable.

They absolutely are. KMS/GEM/TTM provide not only a speed boost, but allow for a larger number of supported OpenGL extensions.

Adam

[Oliver_H]

Do you know what KMS aka kernel mode setting really is? It's about setting screen res and depth. It's more a security-thing than something relevant for graphics. Guess why the OpenBSD guys are happy about it ;-)

TTM is a memory manager for graphic cards. And GEM is the new memory manager for graphic cards, replacing TTM.

GEM: http://keithp.com/blogs/gem_update/

So I really don't know what you're referring to ...

Maybe you're talking of Gallium3D, well ... that's a different story. But it's barely usable at the moment. Using Gallium3D requires working GEM in the OS. So yes, GEM is a necessity for the (near) future.

Finally there is no such thing as GEM/TTM/KMS, there is just a need for KMS and especially GEM.

[adamk]

Originally Posted by Oliver_H

Do you know what KMS aka kernel mode setting really is? It's about setting screen res and depth. It's more a security-thing than something relevant for graphics. Guess why the OpenBSD guys are happy about it ;-)

TTM is a memory manager for graphic cards. And GEM is the new memory manager for graphic cards, replacing TTM.

GEM: http://keithp.com/blogs/gem_update/

So I really don't know what you're referring to ...

Maybe you're talking of Gallium3D, well ... that's a different story. But it's barely usable at the moment. Using Gallium3D requires working GEM in the OS. So yes, GEM is a necessity for the (near) future.

Finally there is no such thing as GEM/TTM/KMS, there is just a need for KMS and especially GEM.

I know what they all are and I stand 100% behind my statements. KMS is needed for gallium3d, and gallium3d provides a larger number of of extensions and more capable drivers. Even without gallium3d, though, simply enabling KMS with an up-to-date version of the classic r600 drivers on Linux will provide OpenGL 2.1 support (vs 1.4, iirc, without KMS enabled) so, once again, the drivers are more capable on linux due to the presence of KMS.

Adam

EDIT: To clarify, the r600 mesa driver does report OpenGL 2.1 support in recent versions without using gallium3d. Despite this, opengl 2.1 only actually works properly when KMS is enabled.

Also GEM does not replace TTM. TTM is newer, in fact. GEM is the memory manager for intel GPUs. It is highly intel specific. TTM is the memory manager for radeon GPUs. TTM exposes the external GEM API. I'm not sure what nouveau uses.

[Oliver_H]

>Also GEM does not replace TTM. TTM is newer, in fact.

Wrong, GEM will replace TTM. It's a 'versus' thing- you know, in terms of competition and TTM is from VMware and as 'old' as Gallium3D (Thungsten Graphics acquired from Vmware).

But read yourself, just for the records: TTM is older, GEM is Intel's answer to TTM (bloat in their opinion, it's their _alternative_ to TTM):

http://lwn.net/Articles/283793/

>Even without gallium3d, though, simply enabling KMS with an up-to-date version of the classic r600 drivers on Linux will provide OpenGL 2.1 support (vs 1.4, iirc, without KMS enabled) so, once again, the drivers are more capable on linux due to the presence of KMS.

Once again tell me facts not fiction!

OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV620 95C2) 20090101 TCL
OpenGL version string: 1.5 Mesa 7.7.1

It's a Debian testing (maybe 2weeks behind bleeding edge) with kernel 2.6.38.1 ( I build my own kernels). I don't know which bleeding edge components you're using but I tried it in the mentioned Debian testing and a current Arch Linux with and without KMS ... no change. Yielding magic maybe?

>I know what they all are and I stand 100% behind my statements.

Even as they're wrong? Just one question: where the heck do you get your information? Phoronix maybe? That would explain something at least.

But apart from the graphics hogwash, there is at the moment no real disadvantage in using FreeBSD together with ATI (yeah, 2-3% performance in some applications).

As I said, there is a need for GEM and KMS and there is no need at all for TTM. We're talking of the (near) future, not a current state. Period.

[adamk]

So as far as the history of GEM and TTM, I admit that I was wrong. TTM predates GEM. That does not imply that GEM will replace TTM. I've seen no indication that the radeon driver developers plan on making that switch and seen plenty to indicate that they do not plan on making that switch. If you can show some solid evidence to the contrary, I will concede that point.

As for everything else you say... Well, that's just utter rubbish. Mesa 7.7.1 was released in March of 2010, just under a year ago. How is that 2 weeks away from bleeding edge?

This is two weeks away from bleeding edge:

OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV770 9442) 20090101  TCL
OpenGL version string: 2.1 Mesa 7.11-devel
OpenGL shading language version string: 1.20

Mesa has been able to do OpenGL 2.1 on the r600 driver since August of last year. Mind you, it still only works properly with KMS enabled.

So, now, where are you getting your information?

So, yes, I stand by my statements that the open source drivers on Linux are more capable than they are on FreeBSD. Both in general, and specifically when it comes to the topic of WebGL. Don't believe me?

HD4850 on Slackware -current:

http://picpaste.com/pics/webgl-linux_1.1301151644.png

And now on FreeBSD:

http://picpaste.com/pics/webgl-freebsd.1301151701.png

In both cases, I'm using the r600 driver from mesa git.

Oh, that error message reminds me of another big difference... IRQs (necessary for sync-to-vblank) do not work with the r600 driver on FreeBSD since they, too, require KMS.

Adam

EDIT:

And let's not forget that KMS is necessary to get even 2D acceleration on the most recent AMD and Intel GPUs. So, once again, the driver on linux is more capable than it is on FreeBSD.

2nd EDIT:

According to one of the primary radeon driver developers, when asked if there are plans on moving the driver to the GEM backend:

<glisse> adamk: no, GEM really only fit with igp gpu that don't have vram

Now, I admitted when I was wrong. Can you do the same?

Adam

[TerryP]

Originally Posted by adamk

IEven without gallium3d, though, simply enabling KMS with an up-to-date version of the classic r600 drivers on Linux will provide OpenGL 2.1 support (vs 1.4, iirc, without KMS enabled) so, once again, the drivers are more capable on linux due to the presence of KMS.

Considering that you can get OpenGL 3.3 off a decent r600 card and the most recent specification is for OpenGL 4.1, I think caring about any of that is a tad out moded from a practical perspective. The Open Source world lags much to far behind on this.


I'm in favour of anything that makes life easier on developing graphics drivers that work stably and doesn't leave "Everyone else" in the dirt. That requires unix systems and linux to use a similar enough way of doing things. Maybe that's because of my believes, dunno.


I have never seen viable 3D support just *work* outside of Ubuntu+nVidia blobs with any of my hardware. And I can remember when compiling an OpenGL 1.1 program without pain on FreeBSD would have been, politeness.

[adamk]

Originally Posted by TerryP

Considering that you can get OpenGL 3.3 off a decent r600 card and the most recent specification is for OpenGL 4.1, I think caring about any of that is a tad out moded from a practical perspective.

Considering there are a number of applications that have improved functionality when GLSL 1.2 is available, I (personally) wouldn't consider caring about the presence of OpenGL 2.1 outmoded.

The Open Source world lags much to far behind on this.

Agreed, but it's nice to have an open source option available to users who don't need the latest whiz-bang features available only via proprietary drivers.

Adam

[adamk]

Originally Posted by adamk

Now, I admitted when I was wrong. Can you do the same?

Guess not.

Adam