Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: Radeon Driver Picks Up VBOs, OQ Support

  1. #11
    Join Date
    Sep 2008
    Location
    Russia
    Posts
    24

    Default

    Good news. Looking forward for test results from Michael.

  2. #12
    Join Date
    Apr 2008
    Posts
    101

    Default

    also a compliment on the article to michael. afaik its the first time he provided useful links to the technical details

  3. #13
    Join Date
    Apr 2009
    Posts
    6

    Default

    Quote Originally Posted by BlackStar View Post
    Depends on your viewpoint, I guess. Personally, I consider anything less than OpenGL 2.1 + FBOs a "toy" - we are talking about 6 year old features here!

    (Not bashing the open-source drivers here, just saying I'd *really* love GLSL support so I Can finally drop the damned fixed-function codepath from my applications).
    R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.

  4. #14
    Join Date
    Apr 2009
    Posts
    6

    Default

    Quote Originally Posted by chelobaka View Post
    Good news. Looking forward for test results from Michael.
    Don't expect much. Only apps that feed GPU with much vertex data will benefit from vbo_clean branch merge, and as for occlusion queries on low end GPUs people may actually see performance drop (because app may have software and hardware OQ backends, and the SW-based one can be faster for slower GPUs - that's the case with sauerbraten game).

  5. #15
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,126

    Default

    Quote Originally Posted by osiris View Post
    R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.
    Loops are not necessary for a surprising number of algorithms: per-pixel lighting, shadow maps, parallax can all be implemented without loops. These represent a huge jump in quality over fixed function OpenGL, so they are certainly worth it (true, you *could* implement shadow maps and dot3 lighting without on fixed function hardware, but the implementation is not even funny).

    Other than that, I refuse to touch ARB_vertex/fragment programs (adding *yet* another codepath to my applications for obsolete hardware? No thanks!) If a GPU doesn't support GLSL I force it down the fixed-function pipeline and forget about it (which includes every Intel GPU currently in existence.)

    My point is that across-the-board GLSL support allows you to provide a unified and relatively clean rendering engine. Supporting the fixed function pipeline makes things much, *much* uglier.

    Edit: regarding VBOs, they are much easier to handle than client-side vertex arrays for a number of applications (esp. if you are using a GC). They also allow you to use a single codepath for basic geometry uploads, which is always a good thing.

    Speed will probably increase as the code matures.
    Last edited by BlackStar; 08-17-2009 at 09:45 AM.

  6. #16
    Join Date
    Feb 2008
    Posts
    88

    Default

    Just to put things into perspective: Nexuiz heavily uses GLSL, but not a single loop in GLSL.

  7. #17
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote Originally Posted by BlackStar View Post
    If a GPU doesn't support GLSL I force it down the fixed-function pipeline and forget about it (which includes every Intel GPU currently in existence.)
    Intel GPUs don't support GLSL?
    I have an X4500HD, and according to glxinfo it has OpenGL 2.1. I don't know a whole lot about OpenGL, but I do know that I am getting hardware acceleration on my Intel chip because it can run Urban Terror.
    Is it software based GLSL or something?

  8. #18
    Join Date
    Jul 2009
    Posts
    416

    Default

    And another quick question.
    When they refer to r300, does that include r400 and r500 like r600 can refer to rv770?

  9. #19
    Join Date
    Dec 2007
    Posts
    2,328

    Default

    Quote Originally Posted by pvtcupcakes View Post
    And another quick question.
    When they refer to r300, does that include r400 and r500 like r600 can refer to rv770?
    The r300 3D driver supports r3xx, r4xx, and r5xx chips. However, the r5xx hardware supports more advanced shader instructions like loops. So when GLSL support is added, r5xx chips will be able to do more things in hardware than r3xx/r4xx chips.

  10. #20
    Join Date
    Jan 2009
    Posts
    609

    Default

    Quote Originally Posted by osiris View Post
    R300 cards owners won't benefit (performance wise) from GLSL support actually, because R300 chips don't support loops and branches. While branches can be rewritten, if an app will try to use loops in GLSL programs the driver will just fallback to software. The best the R300 can do is ARB_vertex/fragment_program.
    Not true. Loops with a constant number of iterations can be unrolled and so do branches. Let's have a branch if(c){x=a;}else{x=b;}. This can be rewritten in GLSL as x=a*c+b*!c or simply x=mix(b,a,c). In other words, both code blocks should be evaluated and irrelevant results discarded if branching is not supported. This will still be much faster than software fallback. This is how proprietary drivers work and it's a must.

Posting Permissions

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