Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 54

Thread: AMD Radeon HD 7970 On Linux

  1. #31
    Join Date
    Sep 2009
    Posts
    318

    Default Thanks for the response.

    Quote Originally Posted by bridgman View Post
    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.

  2. #32
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,072

    Default

    Quote Originally Posted by wizard69 View Post
    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?

  3. #33
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    508

    Default

    Quote Originally Posted by curaga View Post
    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.

  4. #34
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    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.
    Last edited by bridgman; 12-24-2011 at 12:14 PM.

  5. #35
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,072

    Default

    Quote Originally Posted by Drago View Post
    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.

  6. #36
    Join Date
    Dec 2008
    Posts
    166

    Question code/specs?

    News?
    Anytime soon?

  7. #37
    Join Date
    Jan 2011
    Posts
    100

    Default

    Quote Originally Posted by Dolly8663 View Post
    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.

  8. #38
    Join Date
    Dec 2008
    Posts
    166

    Default

    Quote Originally Posted by Wilfred View Post
    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.

  9. #39
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

    Quote Originally Posted by sylware View Post
    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.

  10. #40
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,440

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •