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.

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.

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.

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.

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.

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.

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

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.

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?

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?

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.