Radeon HD 7000 Series Will Bring New 3D Driver

[Drago]

... and compiler code is now out (minus the GCN-specific bits, of course)

Where....?

[agd5f]

Where....?

http://cgit.freedesktop.org/~tstellar/mesa/log/?h=r600g-llvm-shader

[Drago]

http://cgit.freedesktop.org/~tstella...0g-llvm-shader

Well, I thought this thread is for HD 7000 3D driver, not for openCL back-end. If it is not the case, then my bad and sorry for that.
There is no references in the this code for any chip >CHIP_CAYMAN.

[bridgman]

I thought it would have been obvious from the diagram



Seriously, I understand it's not obvious at all. If you look at the center-left of the diagram you'll see a little "you are here" guy with a few lines going off to the right and upper right. The line going off to the right is the common compiler work for OpenCL and GCN - at the end of that line there's another line going up into OpenCL work and a line going down into GCN work, with the internal name of the GPU family scribbled over in black. Going from memory, the line going up to OpenCL should be making the compiler code work with clover while the line going down to REDACTED should be adding the HW-specific ISA bits.

So... the compiler work is common to GCN and compute/OpenCL support, but the reason for releasing it now was more for people working on compute and that's what most of the mailing list comments talked about. We are not pushing out the GCN-specific HW programming bits yet but we are trying to push out the stack that GCN will use.

In most cases we are using Cayman for testing the stack changes since it is architecturally closest to GCN, however in the specific case of the compiler we want to support everything from Evergreen up since Evergreen is where the main HW features required for efficient OpenCL work arrived.

Clear as mud ?

[Drago]

As mud, yes
Now to summarize...the code Tom pushed is part of a compiler stack for OpenCL/compute. It has <=CHIP_CAYMAN for now, with CHIP_GCN landing after some time.
This will not replace any part of the Graphics pipeline. This code will integrate in mesa and is the back-end with front-end clover state tracker.
What about Graphics for GCN, e.g. graphics shader compiler?

[bridgman]

For GCN and up, this code + LLVM will more-or-less replace the shader compiler in r600g; at least that's our current thinking. The compiler will accept either TGSI or LLVM IR depending on whether the graphics or compute state tracker is running.

For graphics, the path will be :

[GLSL] >> (GLSL compiler) >> [glsl ir] >> (GLSL IR to TGSI converter) >> [tgsi] >> (new tgsi to llvm code) >> [llvm ir] >> (new llvm to ISA code) >> [gpu instructions]

..while for compute the path will be :

[OpenCL C99] >> (clover using clang/llvm) >> [llvm ir] >> (new llvm to ISA code) >> [gpu instructions].

Something like that anyways. There are a couple of points in the stack where LLVM runs some optimizing passes on the IR but I don't remember offhand where they are and need to get back to chopping firewood so am not looking at the code right now

square brackets for [data], parentheses for (processing)

[Drago]

Chipping firewood, really You are not living in a cabin in the woods, aren't you
This sounds like a plan. Do you know the work LunarGLASS has made to make LLVM graphics friendly. http://www.lunarg.com/3d-driver-deve...gy/lunarglass/
What do you think?

[Drago]

Also, is this code is the actual Catalyst OpenCL implementation with the obvious Tom's glue code for gallium3D.
What performance numbers to be expected? Any closer to Catalyst?

[bridgman]

Chipping firewood, really You are not living in a cabin in the woods, aren't you

Actually I *do* live in the woods (a red pine forest), the house design is basically a big cabin (albeit with a basement and a carport), and the floor plan was designed around a masonry heater that can keep the place cozy on all but the coldest days, so for all practical purposes "yes I live in a cabin in the woods".

My friends call it "the cabin" so I guess that makes it official. No TV, but I get deer in the front yard and wild turkeys in the back.

This sounds like a plan. Do you know the work LunarGLASS has made to make LLVM graphics friendly. http://www.lunarg.com/3d-driver-deve...gy/lunarglass/
What do you think?

It seemed pretty good to me -- essentially using two different levels of IR with standard code to optimize and convert between them, in order to help get around the "one size really doesn't fit all" problems we hit when trying to standardize on a single IR for all workloads and all hardware.

[Drago]

I always wanted to live like this. One day maybe...
What about the performance numbers?