Announcement

Collapse
No announcement yet.

Radeon HD 7000 Series Open-Source Still A Mess

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

  • phoronix
    started a topic Radeon HD 7000 Series Open-Source Still A Mess

    Radeon HD 7000 Series Open-Source Still A Mess

    Phoronix: Radeon HD 7000 Series Open-Source Still A Mess

    It's been nearly one year since AMD began rolling out their Radeon HD 7000 "Southern Islands" graphics cards and while there is AMD Catalyst Linux driver support, the open-source driver support for this latest-generation AMD graphics hardware is still a disappointing mess...

    http://www.phoronix.com/vr.php?view=MTIzNDQ

  • entropy
    replied
    Originally posted by agd5f View Post
    I wouldn't worry too much about the fixed function stuff. Most if not all modern hardware from the last 10 years or so requires shaders and emulates the fixed function features via shaders. This site has some good introductory information on legacy-free OpenGL:
    http://openglbook.com/
    Thanks!

    Leave a comment:


  • agd5f
    replied
    Originally posted by entropy View Post
    I'm just reading the current edition of the SuperBible. It doesn't cover the fixed-function pipeline.
    But I guess it's not worth the time also learning all the "legacy" stuff?
    I wouldn't worry too much about the fixed function stuff. Most if not all modern hardware from the last 10 years or so requires shaders and emulates the fixed function features via shaders. This site has some good introductory information on legacy-free OpenGL:
    http://openglbook.com/

    Leave a comment:


  • entropy
    replied
    Originally posted by marek View Post
    I can tell you from my experience that all you need to know is OpenGL and GLSL and you need to know them really well.
    I'm just reading the current edition of the SuperBible. It doesn't cover the fixed-function pipeline.
    But I guess it's not worth the time also learning all the "legacy" stuff?

    Leave a comment:


  • entropy
    replied
    Originally posted by bridgman View Post
    IMO the solution is to find the right level of detail. I think everyone agrees that documenting where to find the code and how to build/install it is worth doing, so the question is whether documenting one or two more levels of detail would help and where we reach the point of diminishing returns. I suspect we reach that point quite early, ie that the optimal point would be maybe 5-10 pages *total* of well-written design docco divided across the major component projects (eg a page or two for stack-level plus a page or two for each major component) and kept ruthlessly up to date.

    That would be enough to let potential developers get a lot further into the code quickly, and hopefully enough that they can start tinkering and asking good questions (where "good" in this case means "other developers feel that answering the questions is a good use of their time").
    That sounds good to me. Is this something on your mind "only" or has that been discussed already with the right people willing to do this work?

    What's also missing, IMHO, is a glossary. Or does it exist already and I didn't find it? It may sound trivial but having things like "stride"* explained in a few words,
    might turn out valuable for beginners and non-native speakers of english. I guess this is a rather static thing and mostly new entries need to be added.

    [*] Maybe not the perfect example but you might get the idea.

    Leave a comment:


  • Tyler_K
    replied
    Originally posted by bridgman View Post
    Originally posted by Hamish Wilson View Post
    I am interested in the word "we're" in your statement. What exactly is your involvement with the driver?
    Other than the shader compiler Michel pretty much wrote radeonsi. Everyone helped with testing and debugging the driver but MrCooper (that's just his IRC handle BTW) drew the short straw for initial SI userspace support.
    LOL, glad to see that someone else was thrown for a loop too..I thought it was Alan Coopersmith (Oracle) at first ... did a search through his old posts for hints/clues and was left just unclear and wondering. Mystery solved

    Leave a comment:


  • marek
    replied
    Originally posted by gamerk2 View Post
    For one, you don't learn OGL to make game rendering engines. More often, its for working on some CAD program.
    This is interesting. I've met tens of people in person who had learned OpenGL through game development (and some later got a job in the industry). I have never met anyone who had learned it through CAD.

    Originally posted by gamerk2 View Post
    Secondly, writing hardware drivers is a totally different beast then working within the confines of some stand alone program.
    I would beg to differ. It's mostly software development like anything else. You don't always have to mess with hardware at the lowest level. Some core Mesa developers don't even know the hardware and they've done an amazing job.

    Leave a comment:


  • bridgman
    replied
    Tom and others have been doing a lot of work on enabling the new LLVM-based shader compiler for r6xx through NI hardware, so if that works out OK then there's probably no need for anything else.

    I haven't discussed it with Jerome, but I imagine he is torn between hoping the LLVM stack succeeds so he doesn't have to write a new shader compiler and hoping it fails so he does have a good excuse to write a new shader compiler

    Leave a comment:


  • curaga
    replied
    Originally posted by bridgman View Post
    the "final" design he had been working on, not the initial "write this so we can get the rest of the stack running" code that runs today.
    Any news on that, BTW?

    Leave a comment:


  • gamerk2
    replied
    Originally posted by marek View Post
    I think anyone who can write a decent game rendering engine (that's why you learned OpenGL in the first place, right?) has already enough knowledge to write GPU drivers.
    I laughed when I read this. A lot.

    For one, you don't learn OGL to make game rendering engines. More often, its for working on some CAD program.

    Secondly, writing hardware drivers is a totally different beast then working within the confines of some stand alone program. I've worked on systems where you have to send some I/O directly to the H/W. In this realm, we CARE that it takes some switch inside the H/W some amount of time to fully settle, and this drives how the S/W is developed. We care that it might take x amount of time to access some data if its located in RAM. And so on. To an application developer, all this is invisible, because its all handled for you driver side.

    Leave a comment:

Working...
X