ATI R600/700 OSS 3D Driver Reaches Gears Milestone

[Kjella]

Based on my own experience confirming all the legendary "fglrx sucks!" ranting of many others including you (which makes it very unlikely to dramatically change until open drivers reach usable state), I believe the majority of the anti-blob rationale has been validated by long-term practical experience of it's users, so I'll rather stick with the vendor who actively supports FOSS driver development even if it doesn't seem to be worth the trouble at the moment than sacrificing means for the sake of the end and getting forever stuck with any form of blob as a result.

My experience with fglrx is outdated, but it's anti-fglrx rationale not anti-blob. I like tinkering with my machine but not in the tear-my-hair-out sense that fglrx brought me to. My rationale is this, by using an open source operating system and applications I promote open source in general even if not in everything.

To take a little religious analogy, I think it's more effective to go out and make everybody a little religious than to become some hermit monk of pure OSS dedication. The attitude that closed source always sucks is a bad one, because there's many good blobs. Windows XP is a good blob. OS X is a good blob. The nVidia driver is a good blob. It just so happens that fglrx was not a good blob last I checked.

By all means, you should do what you believe in. But the number of people who'd buy AMD based on paper specs and 3D drivers that don't even do glxgears is extremely few, it'd never make sense to go this far and no further. The question is how big the pie is and what share they can get when they do deliver good open source drivers. And right now I have no problems recommending Linux/nVidia to make that pie bigger...

[nanonyme]

But the number of people who'd buy AMD based on paper specs and 3D drivers that don't even do glxgears is extremely few, it'd never make sense to go this far and no further.

Which is probably the very reason why AMD/ATi decided not to stop with giving out the specs and three of their developers are doing in the effort of giving us working classic Mesa r600 drivers. They're gotten a great bulk of the big work done, now there's some big issues, bug fixes and classic r600 should start reaching parity with classic r300 which I think is a very impressive show from AMD/ATi; it shows they do care about Linux users a great lot.
Ps. The bug I talked about isn't a glxgears bug; the driver can run glxgears itself just fine, it's moving a window on top of an OpenGL window that causes corruption.

[energyman]

well, I bought my hd3870 because AMD started to give out specs. And one of my linux using friends did the same. In fact, he is using the open source drivers because he does not need 3d.

[lbcoder]

...there's many good blobs. Windows XP is a good blob.

No it isn't.

OS X is a good blob.

The parts that are open source are, the other parts (the blob parts) are useless goofy apple junk more focused on looking cute than actually DOING ANYTHING.

The nVidia driver is a good blob.

I suppose that it depends on your definition of good... in this case, better than the open source driver, but STILL CRAP. I have two machines with nvidia and I refuse to update either the OS (due to requiring updated drivers) or the just the drivers themselves (since every time I do something breaks).

It just so happens that fglrx was not a good blob last I checked.

They work fine for me. I haven't experienced any regressions and they at least seem to function.

[Kano]

I have a script that can update Nvidia drivers just fine. No big deal to do so and current drivers work for me. I could go back too with the script. What distro do you use?

[Loris]

Ehm...

r6xx/r7xx compiz!

[Xheyther]

Interesting

By the way, what are memcpy ? And what were the enhancement necessary to achieve this ? Just to know where they are in the way to full linux ati graphic stack.

[Loris]

Interesting

By the way, what are memcpy ? And what were the enhancement necessary to achieve this ? Just to know where they are in the way to full linux ati graphic stack.

memcpy is a function used to copy a contiguous segment of memory from one place to another. It is a generic function that uses the CPU to do the actual copy.

In his post, agd5f just tells that this DRM and Mesa couple works, and can (and will) be optimized. The accelerated memory copying will be implemented by means of GPU instructions, so to free the CPU from the burden.

This is a great milestone, thank you to all the developers and the people that are permitting this.

[bridgman]

Interesting

By the way, what are memcpy ? And what were the enhancement necessary to achieve this ? Just to know where they are in the way to full linux ati graphic stack.

The commit was the one labled "r600: fix R600SetTexOffset", second from the top right now but probably further down the list by the time you read this :

http://cgit.freedesktop.org/mesa/mesa/log/

Right now the driver draws things pretty quickly, but the GLSwapBuffers command that moves the image from the "back buffer" (where it's drawn) to the "front buffer" (on screen) is done on the CPU (memcpy) so is very slow, over a second per frame. The GPU can do the same copy perhaps 1000x as fast, so replacing this particular use of memcpy with HW acceleration makes the difference between being mind-bogglingly slow and being pretty good.

[Xheyther]

Thank a lot for your answer you two. If I can continue to ask questions, I wonder why memcpy is that slow and copy from back to front buffer with the gpu is that fast...

I guess this is due to kernel protection mechanism and difficulties to access the GPU memory from the CPU...