Announcement

Collapse
No announcement yet.

AMD's Open-Source Radeon Driver After Four Years

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

  • phoronix
    started a topic AMD's Open-Source Radeon Driver After Four Years

    AMD's Open-Source Radeon Driver After Four Years

    Phoronix: AMD's Open-Source Radeon Driver After Four Years

    While the BFS scheduler is getting ready to celebrate its second birthday, in just three weeks AMD's open-source Radeon graphics driver strategy for Linux will be turning four years old. It was on the 6th of September in 2007 that I exclusively broke the news to the world on AMD's open-source strategy, which has ended up being a game-changer in the Linux world. AMD continues to support open-source hardware enablement on their latest graphics processors and recently even hired more developers to work on the code and documentation. How far have they come though in four years?

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

  • Welsh Dwarf
    replied
    Could you please fix your links so that we can see what you're getting at.


    Oh, and, for all those wondering about GL3: the intel guys are pumping out patches at an almost alarming rate on the mailing list atm.

    Leave a comment:


  • curaga
    replied
    IIRC for nouveau it is only (mostly) the common gallium code that is missing for MSAA.

    Leave a comment:


  • bridgman
    replied
    Yep. IIRC most of the remaining work required is up in the common Mesa code.

    The Intel devs set up a detailed task list for getting to GL 3 and talked about it at XDC earlier in the week. There is a separate Phoronix article about their talk.

    Intel presentation : http://www.phoronix.com/scan.php?pag...item&px=OTkxMg

    Task list : http://dri.freedesktop.org/wiki/WorkQueue

    The list doesn't distinguish between work required in common Mesa code (which only has to be done once) and work required in the HW driver code (which has to be done once for each HW driver), but you can get a pretty good idea from looking at the individual tasks.

    MSAA is more or less independent and almost totally specific to driver HW. I don't *think* there is any common code required but not 100% sure.
    Last edited by bridgman; 09-18-2011, 10:32 AM.

    Leave a comment:


  • agd5f
    replied
    Originally posted by jonwil View Post
    Ok, so can someone tell me what is so hard about adding the missing features like GL3, MSAA etc into the open-source drivers?

    Lack of features in Mesa/Gallium3D/DRM/some other library the open drivers use? Lack of interest from the devs to support these features properly? Legal issues (similar to the legal issues that prevent AMD from releasing the specs for the hardware video decoding logic in the GPUs)
    Lack of manpower. Adding support for these features is a lot of work, but is progressing.

    Leave a comment:


  • jonwil
    replied
    Ok, so can someone tell me what is so hard about adding the missing features like GL3, MSAA etc into the open-source drivers?

    Lack of features in Mesa/Gallium3D/DRM/some other library the open drivers use? Lack of interest from the devs to support these features properly? Legal issues (similar to the legal issues that prevent AMD from releasing the specs for the hardware video decoding logic in the GPUs)

    Leave a comment:


  • V!NCENT
    replied
    Given that Mac OS X has shitty OpenGL performance and the FireGL on Linux is so damn shitty, one would think that AMD:
    1. Implements a co-working code path for an additional binary Digital Rights Management blob so it can work parallel with the Gallium driver;
    2. Puts Gallium3D onto Windows;
    3. Puts lots of devs onto the Gallium3D driver (as well as some on speed optimizing to keep up with nVidia on FireGL);
    4. Gives Apple a kickass Gallium oppertunity with the X.org codebase renewal;
    5. Dumps FireGL entirely when the time's ready.
    (6. delays Gallium3D work mostly when nVidia gets an edge, but on the long run starting with id's Rage, the graphics speed is no longer about raw speed but latency, since consoles dictate graphics mostly anyways)

    I'd say dump that horrible POS called FireGL and improve massively on the open source front so you can get quality drivers with huge benifits on all fronts.

    The time has come to dominate!

    Leave a comment:


  • BlackStar
    replied
    This is awesome. Thanks!

    Leave a comment:


  • curaga
    replied
    Originally posted by BlackStar View Post
    I am missing some secret sauce here. How does the stencil get written? Via GL_ARB_stencil_shader_export (is this even supported on Mesa? It requires GLSL 1.40!) And if yes, why doesn't the loss of early z-tests destroy performance?
    Via
    glClear(GL_STENCIL_BUFFER_BIT);
    glStencilFunc(GL_ALWAYS, 1, ~0);
    glStencilOp(GL_KEEP, GL_KEEP, GL_REPLACE);
    // pass 1 here
    Since pass 1 calls discard for non-edge pixels, the stencil is not marked for those. Early-Z isn't lost this way. This is quite a smart optimization, my jaw dropped too when I first saw it.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by curaga View Post
    Three passes, and only the first (edge detection) is executed for all pixels. The second and third pass are only executed for the edge-marked pixels (via the stencil), which brings a big speedup compared to running them on all pixels.
    I am missing some secret sauce here. How does the stencil get written? Via GL_ARB_stencil_shader_export (is this even supported on Mesa? It requires GLSL 1.40!) And if yes, why doesn't the loss of early z-tests destroy performance?

    The second pass is what makes it so much better in quality than many of the other implementations; instead of a constant blur, it depends on the type of aliasing. I recommend the fxaa vs mlaa article @ digitalfoundry, you can see how much more fxaa blurs.
    Thanks, will do.

    Edit: I missed the part where this is written in TGSI rather than GLSL. But still, the hardware limitations should be identical. Need to think about this some more.

    Leave a comment:

Working...
X