Announcement

Collapse
No announcement yet.

Radeon Driver Picks Up VBOs, OQ Support

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

  • BlackStar
    replied
    Originally posted by pvtcupcakes View Post
    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?
    Let's put it this way: I've yet to encounter a single Intel driver that manages to render anything more complex than "hello world" 3d graphics. Results range from buggy rendering to outright kernel crashes.

    In an interesting twist of fate, Intel's Linux drivers are ahead in OpenGL support compared to their Windows counterparts. On Windows you cannot even use features like FBOs or (shudders) PBuffers! It's not that the hardware is not capable, but that the drivers are severely lacking. Imagine Ati's OpenGL drivers 6 years ago - in a single word, "bad".

    Take a look at Google Earth's config files, it's an interesting glimpse in the world of 3d programming and how much 3d drivers suck outside of AMD and Nvidia. Last time I looked at it, they pretty much forced all Intel GPUs to use D3D rendering unconditionally (through some rather colorful comments).

    Regarding Urban Terror, chances are vertex shaders are evaluated on your CPU. Most Intel hardware is lacking hardware vertex shaders (only the last two generations have them and until the last one, it was often faster to run them on the CPU instead of the GPU).

    Leave a comment:


  • nanonyme
    replied
    Originally posted by Eosie View Post
    Not true. Loops with a constant number of iterations can be unrolled and so do branches.
    Wait, what? -funroll-loops all over again except this time with GPU's? Better tell all Gentoo users.
    Last edited by nanonyme; 08-17-2009, 03:55 PM.

    Leave a comment:


  • marek
    replied
    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.

    Leave a comment:


  • agd5f
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • pvtcupcakes
    replied
    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?

    Leave a comment:


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

    Leave a comment:


  • BlackStar
    replied
    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, 09:45 AM.

    Leave a comment:


  • osiris
    replied
    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).

    Leave a comment:


  • osiris
    replied
    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.

    Leave a comment:

Working...
X