R600 Open-Source Driver WIth GLSL, OpenGL 2.0

[bridgman]

Old mesa style only brings 50% of the fglrx speed. the opensource driver needs newstyle..... Galium3D+OpenGl3stage+LLVM compiler brings full speed! without galium3D+LLVM you'll never get the full speed.

I agree that it's likely to be the post-Gallium3D stack that sees most of the performance work, but be aware that "LLVM as shader compiler" hasn't really worked out so far. On the other hand, LLVM is turning out to be very useful for generating CPU code (eg running vertex shaders on the CPU for no-TCL parts or for CPU/GPU load-balancing) and for higher level operations like turning OpenCL into TGSI (ie LLVM running *above* the Gallium3D/TGSI API.

The main issue is that LLVM doesn't currently support VLIW hardware, and all of the Gallium3D-eligible ATI hardware is VLIW -- either 2-operation per instruction (3xx-5xx) or 5-operation per instruction (6xx and higher).

[bridgman]

The good news is that nha's shader compiler for 3xx-5xx is already quite a bit better than what we assumed when making our initial performance estimates for the open source driver. The compiler in the 6xx-7xx driver is not as sophisticated, but the 7xx parts in particular have a lot of shader power so I don't expect the shader compiler to be the bottleneck for another year or so.

The "low-hanging fruit" for performance will probably be (a) reducing the amount of state information sent with every command packet, (b) improving the degree to which the driver code and GPU can operate in parallel, and (c) doing a bit of profiling and fixing/optimizing anything which jumps out as taking much more time than it should.

[smitty3268]

The good news is that nha's shader compiler for 3xx-5xx is already quite a bit better than what we assumed when making our initial performance estimates for the open source driver. The compiler in the 6xx-7xx driver is not as sophisticated, but the 7xx parts in particular have a lot of shader power so I don't expect the shader compiler to be the bottleneck for another year or so.

The "low-hanging fruit" for performance will probably be (a) reducing the amount of state information sent with every command packet, (b) improving the degree to which the driver code and GPU can operate in parallel, and (c) doing a bit of profiling and fixing/optimizing anything which jumps out as taking much more time than it should.

Every now and then I get a sneaking suspicion that AMD has created a bridgman chat bot, with all the questions you seemingly answer over and over and over again. But then you come out with a good post like this and I'm reminded how awesome it is that AMD has you communicate with the community. I don't always agree, but hearing AMD's position is always interesting and in stark contrast to the wall of silence we get from nvidia.

I'm a little concerned about the r600 comiler, because last i saw on the mailing lists someone had come to the conclusion that it needed to be completely rewritten from the ground up and no one was volunteering or made it seem like that was going to happen. The argument was that the current compiler was vector-based and this guy thought it should be switched to a different architecture while that was still possible before it gets too difficult to fix.

[bridgman]

That was probably nha or MostAwesomeDude talking about rewriting the compiler, and I expect they are right about it needing a rewrite at some point. The current compiler is arguably more of a translator in the sense that it works on one IL instruction at a time, but even so I expect it will be fine for a year or two. Fortunately most of the IL instructions *are* vector operations, and those give a decent level of shader utilization even without combining multiple IL instructions into a single shader instruction word.

The current driver architecture should also allow a new compiler to plug in with relatively little effort -- if we get to the point where the driver architecture is becoming more tightly tied to the compiler internals then that should be a warning sign that it's time to get on with redesigning the compiler.

That said, there are relatively few shader-bound apps running on Linux today, even under Wine, so the current compiler will do the job for longer than most people expect. There are some DX9 games with relatively long shaders (50+ instructions per pixel) but even those tend to have a fairly high percentage of vector instructions. As long as that continues to be the case even an ideal shader compiler is likely to raise performance in shader-bound apps by no more than 30% over the current compiler in most cases.

A better shader compiler will definitely help with the low-end parts, but once you get up to the 8- or 10-SIMD parts (eg HD46xx or higher) the per-clock shader-to-pixel ratio is high enough that you're likely to be ROP- or memory-limited anyways. It's the 610, 620 and IGP parts that will be first to benefit from a better shader compiler, at least when running newer games.

[smitty3268]

quaridarium, not everyone is only interested in wine games. lots of people have an old laptop sitting around with an X1600 card in it, that they would like to use with some more basic 3D stuff but can't justify going out to buy a new laptop.

Also, a lot of the wine devs quotes about how they require nvidia extensions is because that's the driver they developed for - if they spent the time to do it, i'm sure they could get it running on the equivalent ati extensions, but no ones really going back to do that work because the hope is that they can just require GL3.2 and forget about older cards that never worked well anyway.

[barbarbaron]

AMD will soon deliver open graphics drivers, said Henri Richard just a few minutes ago, and the audience at the opening keynote of the Red Hat Summit broke into applause and cheers. Richard, AMD’s executive vice president of sales and marketing, promised: “I’m here to commit to you that it’s going to get done.” He also promised that AMD is “going to be very proactive in changing way we interface with the Linux community.”

The open sourcing of graphics drivers will indeed be good news, but it’s not a big surprise. After AMD acquired graphics driver maker ATI last year, an announcement that AMD would be opening up graphics drivers has been anticipated. The other shoe has dropped, and the folks at the Summit in San Diego are very happy. Now, the new question is “when?” Richard didn’t say.

MAY 9 2007 12:06PM GMT itknowledgeexchange.techtarget.com

http://itknowledgeexchange.techtarget.com/enterprise-linux/amd-will-deliver-open-graphics-drivers/

[agd5f]

2007 is when ATI restarted active involvement in open source graphics. I was hired in 2007.

[barbarbaron]

I was hired in 2007.

LOL who cares about your job?

[agd5f]

LOL who cares about your job?

Hired by AMD to work on open source graphics.

[Louise]

LOL who cares about your job?

@Michael: Can this user please be banned?