Announcement

Collapse
No announcement yet.

Radeon HD 7000 Series Will Bring New 3D Driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • blackshard
    replied
    Originally posted by Darkfire Fox View Post
    ...isn't that exactly what I said?

    (well, minus the VLIW5 part)
    Well actually you were right, there will be some VLIW5 parts too (Brazos 2.0).

    Leave a comment:


  • airlied
    replied
    Originally posted by 89c51 View Post
    that only stands for the lower parts of the stack right??

    i mean the state trackers are (or supposed to be) HW independent.
    They are in theory, in practice you still have to design them around an abstraction of hardware interfaces. You also have to test and prove each state tracker on each pipe driver, just because it builds doesn't in any way means its useful or runs.

    Dave.

    Leave a comment:


  • 89c51
    replied
    Originally posted by airlied View Post
    I think you've misunderstood what gallium is, it isn't magic, it can't take a driver written for one set of hardware and make it work on a completely different hardware platform. Now all gallium drivers essentially share the same interface structure and framework and as such the fastest way to write one is to duplicate an existing one, remove stuff that doesn't apply and fill in the blanks.

    gallium architecture avoids some duplicated code between drivers, not ever last possible single line of it.

    Dave.
    that only stands for the lower parts of the stack right??

    i mean the state trackers are (or supposed to be) HW independent.

    Leave a comment:


  • airlied
    replied
    Originally posted by DanT View Post
    Hallo,
    I just woul like to ask about gallium drivers development efficiency. The gallium is known to bring many advantages in much more efficient coding, compared to "classic" mesa drivers (avoiding code duplicity and so on, as usually claimed).

    From the article it sounds to me, however, that the new driver, in fact, duplicates some amount of code from r600g. Could someone explain which parts of driver are "duplicated" from r600g (and why)?

    Thank you very much for the explanation. Best regards
    Dan T.
    I think you've misunderstood what gallium is, it isn't magic, it can't take a driver written for one set of hardware and make it work on a completely different hardware platform. Now all gallium drivers essentially share the same interface structure and framework and as such the fastest way to write one is to duplicate an existing one, remove stuff that doesn't apply and fill in the blanks.

    gallium architecture avoids some duplicated code between drivers, not ever last possible single line of it.

    Dave.

    Leave a comment:


  • DanT
    replied
    Gallim drivers development - code sharing

    Hallo,
    I just woul like to ask about gallium drivers development efficiency. The gallium is known to bring many advantages in much more efficient coding, compared to "classic" mesa drivers (avoiding code duplicity and so on, as usually claimed).

    From the article it sounds to me, however, that the new driver, in fact, duplicates some amount of code from r600g. Could someone explain which parts of driver are "duplicated" from r600g (and why)?

    Thank you very much for the explanation. Best regards
    Dan T.

    Leave a comment:


  • bridgman
    replied
    Originally posted by gigaplex View Post
    I was under the impression that GCN was MIMD rather than SIMD. Is that not accurate?
    Depends on who you ask, I guess. Current chips have multiple SIMDs each capable of executing a different program on a different set of data elements (although in most cases they run multiple instances of a small number of programs), so if that's all you require to call something MIMD then I guess both current and future architectures are MIMD.

    GPUs are often classed as "multithreaded SIMD" rather than MIMD because of nuances in connectivity and data sharing. Each new generation of GPUs improves data sharing capabilities and efficiencies so I guess at some point they will start getting called MIMD by enough researchers to "make it official". Not sure where that point is though...

    Originally posted by whitecat View Post
    Does this new driver stack will be developed "internally" by AMD or in a "open" manner (I mean a git repo during the development).
    As agd5f said, the bits specific to new hardware will be developed internally until we arrange and receive approval to release them, which I wouldn't expect to happen until after launch, then the rest of the work will happen in the open.

    The new stack should be architecturally similar to the current stack, and in the areas where it's different (multiple ring support, memory management, compiler so far) we're planning to push those bits out early, once they move from ideas to at least semi-working code. Multiple ring support was pushed out a month or two ago, while the memory mgmt and compiler code are getting fairly close.

    We discussed the memory management and compiler plans a bit at XDC, so the core ideas are already "out there". Current thinking is that we should be able to share some shader compiler work between graphics on GCN and clover on existing hardware plus GCN.

    Originally posted by whitecat View Post
    If I remember, r600g was mainly created by Red Hat guys?
    600g is a bit of a special case in the sense that there was no new hardware info involved, but rather implementing a new driver using programming information which was already released and being used in the "classic" r600 driver, so it was not subject to the usual embargo issues related to new hardware info before launch.
    Last edited by bridgman; 09 December 2011, 01:32 AM.

    Leave a comment:


  • agd5f
    replied
    It will all be public once we are able to release the initial code.

    Leave a comment:


  • gigaplex
    replied
    Originally posted by bridgman View Post
    Just a reminder, current and GCN architectures are both SIMD -- it's just that current GPUs are VLIW SIMD while GCN is non-VLIW SIMD :



    See slide 19

    Maybe we need to introduce a new NPLIW architecture (Not Particularly Long Instruction Word) to avoid confusion
    I was under the impression that GCN was MIMD rather than SIMD. Is that not accurate?

    Leave a comment:


  • whitecat
    replied
    Does this new driver stack will be developed "internally" by AMD or in a "open" manner (I mean a git repo during the development). If I remember, r600g was mainly created by Red Hat guys?

    Leave a comment:


  • smitty3268
    replied
    Any VLIW5 chips are likely just rebadged from older generations, and not new

    The switch away from VLIW4 means that any shader compiler would be radically different, which is why i suspected they might start a new driver. All the compute features might impact that as well.

    Leave a comment:

Working...
X