AMD Radeon HD 7970 On Linux

[wizard69]

Don't know but I'll ask around.



We pushed code for "multiple ring support" a couple of months ago :

http://www.phoronix.com/scan.php?pag...tem&px=MTAwNzg

A number of things will use that code in the future, but one of them is allowing compute operations to go through a separate command queue from graphics operations so that the hardware can flip between tasks at a fairly fine-grained level. The multiple ring support started with Cayman but GCN is the first generation where I expect we will really use it.

My understanding of SI is thin but I thought or maybe I was hoping that compute threads could run independent of the graphical workload on one or more of the "cores". Much like a process might run on a separate i86 core.

Correct, I can't answer

Thought so! By the way does SI generate 32 or 64 bit addresses?

We are trying to get all the invasive changes (multiple rings, memory management etc..) pushed out in time for the merge window. Hopefully the remaining changes for GCN will be specific to new HW, but I don't think we have discussed getting them in post-merge yet.

BTW from this point on I'm probably going to switch from talking about GCN to talking about SI (the first generation of GCN parts), partly because it's one less letter (I'm big into efficiency) and partly because that's the terminology we use internally and I'm getting tired of typing SI, backpacing over it and typing GCN instead.

I know there is a lot of whining here about slow Linux support but waiting for a more polished support package isn't a bad idea. Better to merge in after 3.3 than to have buggy support.

By the way give everybody on the GCN team a slap on the back for me. This looks like a major accomplishment and the first product looks to be very impressive as a generation one implementation.

[curaga]

Thought so! By the way does SI generate 32 or 64 bit addresses?

The IOMMU link says 64-bit.

@bridgman:

Thanks, that's what I was worried about, increased attack surface. Previously you'd need to commandeer the driver, now you can just write a "normal" program.

Could you elaborate a bit more on the page tables, how are they set up to allow "legal" access? Will the gpu programs have malloc(ON_VRAM) and malloc(ON_RAM), or will all memory need to be specifically passed from cpu-space?

[Drago]

The IOMMU link says 64-bit.

@bridgman:

Thanks, that's what I was worried about, increased attack surface. Previously you'd need to commandeer the driver, now you can just write a "normal" program.

Could you elaborate a bit more on the page tables, how are they set up to allow "legal" access? Will the gpu programs have malloc(ON_VRAM) and malloc(ON_RAM), or will all memory need to be specifically passed from cpu-space?

Frankly, I don't know why GPU shader program would have to do memory allocation. As I understand it, it can do memory address calculations(indexing, v-tables, etc.) with in memory allocated from the driver. SI will just assure that you don't address outside this dedicated region.

[bridgman]

There may be some cases (eg recursion) where memory allocation from within a shader program could be useful, but AFAIK this round of changes doesn't go there. For now my understanding is that the memory manager works pretty much the way it did before, only rather than patching command buffers with physical addresses the page tables are used to map valid accesses through to the correct locations and either block accesses to other addresses or map them onto a dummy page (not sure which).

I'm not sure what address space the GPU uses under the new scheme; hopefully will get a chance to look through the code over the holidays.

[curaga]

Frankly, I don't know why GPU shader program would have to do memory allocation. As I understand it, it can do memory address calculations(indexing, v-tables, etc.) with in memory allocated from the driver. SI will just assure that you don't address outside this dedicated region.

With the official push as an "equal co-processor" it becomes possible and in some cases desirable to run something entirely (or almost entirely) there.

This is compute though, not graphics.

[sylware]

News?
Anytime soon?

[Wilfred]

Graphic card information and programming are revealed six months prior to launch, according to anandtech. Does than mean, that we could already be having working opensource driver? Why it is not the fact?

bridgman already answered that question in another thread. Not so much information with the level of detail required for driver development is released.
Also since several programmers already work on free linux drivers full time, I don't think it can get done that much faster.

[sylware]

bridgman already answered that question in another thread. Not so much information with the level of detail required for driver development is released.
Also since several programmers already work on free linux drivers full time, I don't think it can get done that much faster.

Well since now HD 7970 is out, we can expect specs/code very soon, the time to tidy all the things up I guess.

[bridgman]

News? Anytime soon?

Next on the list should be the memory management code I mentioned a couple of pages ago. That is highest priority because it's kind of invasive so it needs to go in around a merge window. Once that code is upstream the remaining bits are much more specific to GCN chips.

Earliest for the next drop would be first week of Jan; that's when people start coming back from vacations and reading their emails again.

[bridgman]

Alex pushed the memory management (VM) patches to the dri-devel list last night.