R600 Open-Source Driver WIth GLSL, OpenGL 2.0

[rvdboom]

Some people seem to have some difficulties understanding that the whole X infrastructure has been largely rehauled these last years and I guess it's kind of a moving target for drivers devs.
The choice of supporting OSS drivers by AMD has allowed them also to work on the Mesa 3D Stack, improving the whole infrastructure for everyone. I guess AMD could have decided just to concentrate their development effort to the binary blob and like Nvidia, only just provide their OpenGL stack as binary only, completely replacing the OSS one, and I suppose, in that case, that they could have continued to support older cards, not having to pay people to write OSS software.
I appreciate the fact that they decided to do otherwise and to help improve the whole OSS graphic stack.
I also appreciate AMD devs presence on this forum : it's very nice to have inside news. :-)

[marek]

If you own 3xx-5xx hardware (you have X1950 ?) you should get familiar with building and running the Gallium3D driver - it's not ready for general use yet but it's making good progress and already has GLSL and GL 2.1 enabled. At minimum you should be monitoring the progress but it wouldn't hurt to try it out periodically. You'll need a new kernel with KMS enabled, don't remember if you are already running KMS.

The Gallium3D driver certainly has its flaws but it's getting to the point where it might be usable for some games. Compiz works for some time and even with some advanced effects it's completely stable and smooth. xmoto and openarena are playable, neverball too if you get lucky, nexuiz would work too if some non-driver-related bugs were fixed. There is a lot of work going on in Gallium3D that some features may stop or start working from time to time.

The hopefully complete TODO list for r300g can be found here in the Gallium section:
http://dri.freedesktop.org/wiki/R300ToDo
It's frequently updated so you might get a pretty accurate idea about the current state. 2 or 3 features from that list are performance improvements. If we implemented them, the performance will get back on top.

~ Marek

[barbarbaron]

@Marek: Thanks for the info.

[pedepy]

bridgman, 8 months *is* a lifetime; linux doesn't update once every 2 to 3 years like OS X or Windows does .. most distros are a rolling update model; and alot of work on other elements like my wireless driver or what not are dependent on using the latest kernels. keeping me from updating my kernel is really restrictive in linux.

that said, i'm sort of in the impression (and correct me if im wrong, though i hope not to be), that alot of basic structural work is being done in the drivers and that sooner or later things will sort of reach 'critical mass' and we'll see a jump in features and performance that should be bring it alot closer to what the closed source alternative (or lack thereof) offers.

[Ant P.]

@Michael: Can this user please be banned?

If not that, I say an apology for his rudeness is required.

[bridgman]

that said, i'm sort of in the impression (and correct me if im wrong, though i hope not to be), that alot of basic structural work is being done in the drivers and that sooner or later things will sort of reach 'critical mass' and we'll see a jump in features and performance that should be bring it alot closer to what the closed source alternative (or lack thereof) offers.

Yep, the drivers advanced to the limit of the then-current framework pretty quickly, and most of the work in the last year has been implementing and transitioning to new framework bits - KMS, GEM/TTM, DRI2, and Gallium3D.

The big success of the last year has been making the new framework run "not much worse than the old one" and distros (other than Fedora) are not going to be picking it up until the spring releases, but it appears that most of the real hard work has been done.

[bridgman]

yes...... i realy wrote that only in Wine point of view....
in wine you are lost on an non OpenGl3.2 amd card.

for nativ games.. yes nice....

but..... be sure in the next future time we will have some gread openGL3 only game engines... save a lot of CPU you can play a hardcore game with an monster grafic card on an 1ghz single core CPU.... thats the future of openGL3 engines..

but yes thats the future

So here's something to think about...

I haven't looked at all of the 3.2 extensions related to DX/OGL interoperability, but the ones I did look at have been supported by the hardware since pretty much the dawn of time. agd5f already added support for one or two of them IIRC.

So... as long as Wine checks for specific extensions rather than saying "Can I haz 3.2 ?" there's a decent chance those extensions will be available on older hardware as well.

[BlackStar]

ok nice try again!.......

this works for 'DirectX9b' because OpenGL2.1 is neear by 9B!


this will never work for DirectX9C shader3 +'vertex texturing''texture sampling in vertex shaders'

Because a X1950XTX do not support "texture sampling in vertex shaders"

But vertex texturing is on the minimum feature set of wine!

Good thing that virtually no SM3 game requires vertex texture fetching. This functionality only became mainstream with SM4/DX10 and all such cards support VTF.

In other words, I fail to see what you are trying to say with this example.

[barbarbaron]

not everyone is only interested in wine games.

+1

I'm not expecting to have ass kicking dx9c performance from my gpu in wine too, nor do I care about it. I think the important thing here is to have more game companies port their titles to linux environment. Or a reason for companies like Loki Games to port older titles. And that reason is proper driver support. Mac and linux users combined, opengl graphics stack only people are %10 of all computer users worldwide. It is a good portion to base a business on but something is preventing it.

Despite their opensource evangelism AMD doesn't do much to make this happen and it makes me think AMD is actually hindering the efforts by giving sorta support in both their closed source and opensource drivers. If there weren't people like Corbin Simpson and Marek Olsak (who are independent developers and do most of the gallium3d r300g work now) we would be doomed in gallium3d too -or wouldn't be doomed -. An excerpt from a phoronix.com article:

Contrary to earlier reports stating that the forthcoming id Tech 5 engine from id Software would likely not be ported to Linux due to the involved work, cost, and lackluster Linux graphics drivers (according to John Carmack), it looks like we will end up seeing this next-generation game engine running with Linux.

Carmack is talking about AMD/ATI drivers there.

@Bridgman:

The "specified capabilities" are only specified for Windows (read the box)

From an AMD Linux guy? It doesn't make sense.

I'm not trying to glorify nVidia's binary blob linux support here, but there is an inevitable rule in everything: It has to work first to make a difference.

[bridgman]

Seriously, any approach which requires hardware from one vendor to behave exactly the same as hardware from another vendor is not going to work long term. If this is true then it's something that will need to change in Wine.

The Wine devs have said multiple times that there is no NVidia-specific code in Wine -- this sounds pretty NVidia-specific to me. Not saying you're wrong, but there is a disconnect there that would be good to get clarified.