Tear-Free Acceleration For ATI EXA, Xv

[TechMage89]

Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

We do get 3d now and later. Now it works. Later it will work better.

Also, reagarding the point of radeonhd, it's more compact and clean, as well as faster. The ati driver has a lot of legacy code for older chips and doesn't do the (faster) native modesetting for new ones. This should all be less relevant when KMS arrives, because the 2d accel/TexturedVideo of the two drivers is pretty much the same.

[Extreme Coder]

Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

We do get 3d now and later. Now it works. Later it will work better.

Well, AFAIK, OpenGL 2 comes with Gallium.

[TechMage89]

Well, AFAIK, OpenGL 2 comes with Gallium.

Only because the devs don't think it's worth the effort to continue to pour effort into advancing a depreciated driver framework (well technically Gallium isn't a framework, but I'm not sure what exactly to call it)

[duby229]

Uhm, DRI has been working fine for me for about a month now. Gallium isn't in any way essential to 3d working. It's just an easier (and potentially more flexible) way of making DRI drivers. Mesa 7.1 has now been released, so the Xserver 1.5 should be released shortly.

We do get 3d now and later. Now it works. Later it will work better.

Also, reagarding the point of radeonhd, it's more compact and clean, as well as faster. The ati driver has a lot of legacy code for older chips and doesn't do the (faster) native modesetting for new ones. This should all be less relevant when KMS arrives, because the 2d accel/TexturedVideo of the two drivers is pretty much the same.

How about working on making it stable so that those of us who dont know that voodoo you do can take advantage of it as well....

And what exactly has native modesetting done? Dalay after delay, it;s over a year now with no progress, and and has been dropped in favor of the same kind of modesetting that radeon already does...

Once modesetting is moved into the kernel and radeonhd is using radeons acceleration code what then will have been the point? I guess I just dont understand the religion...

[TechMage89]

AtomBIOS-based modesetting is very good for basic support (and I think it's stupid that the radeonhd driver didn't take advantage of it earlier) but AtomBIOS has errata/doesn't work that well on some hardware. Native modesetting is also faster (there is a noticeable difference how fast X takes to start up between radeon and radeonhd).

The code will very shortly be stable. With Xorg 7.4, 3d should work fine up through r500.

RadeonHD already has the acceleration code from radeon. KMS will have its own modesetting code, from what I understand, it will use atombios, but I don't think that rules out using native modesetting code for some cards later on.

[duby229]

AtomBIOS-based modesetting is very good for basic support (and I think it's stupid that the radeonhd driver didn't take advantage of it earlier) but AtomBIOS has errata/doesn't work that well on some hardware. Native modesetting is also faster (there is a noticeable difference how fast X takes to start up between radeon and radeonhd).

The code will very shortly be stable. With Xorg 7.4, 3d should work fine up through r500.

RadeonHD already has the acceleration code from radeon. KMS will have its own modesetting code, from what I understand, it will use atombios, but I don't think that rules out using native modesetting code for some cards later on.

Like I said, I guess I just dont understand the religion.

If KMS could support native modesetting down the line somewhere then why did radeonhd waste time on it? If it already uses radeons acceleration code then why did they waste even more time on that?

The way I see it is that so far radeonhd offers --nothing-- that radeon doesnt already offer in a more complete and stable package, right now. And never will. Same thing with fglrx. The problem with radeon is that it isnt complete or stable enough. But it --could-- be. If everybody would just stop working against each other and consolidate on a common goal working together and sharing resources.

radeonhd and fglrx both need to be scrapped and the folks working on the linux portion of both these drivers need to put there attention towards radeon right now while the opportunity still exists. The window is closing, it wont be available much longer. If ATi lets this golden nugget slip by, they probably wont catch up ever again.

[Extreme Coder]

Like I said, I guess I just dont understand the religion.

If KMS could support native modesetting down the line somewhere then why did radeonhd waste time on it? If it already uses radeons acceleration code then why did they waste even more time on that?

The way I see it is that so far radeonhd offers --nothing-- that radeon doesnt already offer in a more complete and stable package, right now. And never will. Same thing with fglrx. The problem with radeon is that it isnt complete or stable enough. But it --could-- be. If everybody would just stop working against each other and consolidate on a common goal working together and sharing resources.

radeonhd and fglrx both need to be scrapped and the folks working on the linux portion of both these drivers need to put there attention towards radeon right now while the opportunity still exists. The window is closing, it wont be available much longer. If ATi lets this golden nugget slip by, they probably wont catch up ever again.

What chance are you talking about that later on won't exist?

[duby229]

What chance are you talking about that later on won't exist?

ATi has no real competition right now... nvidia doesnt have an x86 chip, so once fusion hits the market, nvidia will be relying solely on discreet products to get by.. And Intel doesnt have anything compelling on the graphics side.

However this is only a short term condition.... The rumormill has it that nvidia is working on designing an architecture that will be compatible with X86 on the front end, which puts them back in the game... And Intel will have Larrabee...

The only thing nVidia needs is a top end CPU, and the only thing Intel needs is a top end GPU, and they are both working on exactly those things.....

[TechMage89]

Duby, you're being a bit abrasive and also unrealisitc. Radeon and radeonhd are *very* similar drivers. Very little effort is being duplicated at this poing and a lot of code is being shared. RadeonHD is arguably the better driver since the inclusion of ATOMBios, which enables it to do modesetting natively for cards that it knows about, and with ATOMBios for everything else. Also, the acceleration code for r600+ is totally different from anything prior, so including in radeon would be rather impractical.

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer. ATI can't very well release code that contains IP that isn't theirs, so open-sourcing fglrx isn't practical either. Fglrx will always have a place, but hopefully a more marginal one as the open-source driver improves.

[grantek]

Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer.

Maybe for the current generation of cards, but that won't be true forever. As open-source developers come up with graphics/memory management/etc. optimisations, a technology base will develop that will feed from and into other graphics drivers, ideas will be shared, and performance will increase exponentially. By that point, closed-source developers will be re-implementing some ideas from the open-source community (or straight-out stealing code if they dare), and future hardware will be developed with [then-]exisiting technology in mind. If companies like AMD are bringing out technologies like Fusion, they need to support it out of the box on open OSes, so they'll need to continue commissioning open drivers, which will also drive the closed-source driver closer the open one(s).

At least that's the way I'd like it to happen. There's currently a lot of value in fglrx, and there will be for a while, but I'd gladly take a substantial performance hit for an open driver - I already am taking a minor performance hit running Windows games on Wine/Cedega anyway