Announcement

Collapse
No announcement yet.

When the radeon driver is moved to dri2&gallium3d, will older cards use it?

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

  • When the radeon driver is moved to dri2&gallium3d, will older cards use it?

    So what I gather so far from around here is that with the next X.Org release(7.5), DRI2 will be out, and sometime after that, Gallium3D will be used instead of Mesa.
    What I want to know is, will all cards(R100 and above) be able to use the new software?
    For example, I have an X1650 Pro, and an X1250, I'm sure these will be moved. But, I also have an older Radeon 9200 SE with my older PC that's still good for light gaming and such, will it be able to use Gallium3D and DRI2?
    I wasn't sure because mainly I read somewhere that Gallium3D had problems being implemented for older cards..


    Thanks!

  • #2
    I don't think there is any reason why DRI2 couldn't be used all the way back to R100. I don't think there is anything inherent in either DRI2 or Dave's memory manager work that would limit use with older Radeon parts, although I would rather hear that from Dave than from me

    The catch with Gallium is that it is designed for GPUs which have both programmable pixel and vertex shaders, ie DX9 parts (R3xx) and up. The idea is that everything above Gallium is written in, or translated to a standard intermediate language (TGSI) and then the Gallium driver performs the final translation from TGSI to GPU-specific instructions.

    The question is whether it is practical to run TGSI on older GPUs. The Nouveau devs feel it should work OK, and we will need to find out as well since some of our IGP parts do not have vertex shader hardware (eg the RS400/480 and RS600/690). We can get pretty decent performance running the vertex shaders on the CPU so we will need to use a mix of hardware drivers for pixel shader plus Softpipe for vertex shader. The same model could presumably be used for vertex shading with pre-DX9 GPUs.

    The remaining question is whether it will be practical to execute TGSI pixel shaders on DX7 or DX8 hardware. There the chances seem better. Nobody knows for sure but I expect a bunch of smart people will try to make it work.
    Test signature

    Comment


    • #3
      Originally posted by bridgman View Post
      I don't think there is any reason why DRI2 couldn't be used all the way back to R100. I don't think there is anything inherent in either DRI2 or Dave's memory manager work that would limit use with older Radeon parts, although I would rather hear that from Dave than from me

      The catch with Gallium is that it is designed for GPUs which have both programmable pixel and vertex shaders, ie DX9 parts (R3xx) and up. The idea is that everything above Gallium is written in, or translated to a standard intermediate language (TGSI) and then the Gallium driver performs the final translation from TGSI to GPU-specific instructions.

      The question is whether it is practical to run TGSI on older GPUs. The Nouveau devs feel it should work OK, and we will need to find out as well since some of our IGP parts do not have vertex shader hardware (eg the RS400/480 and RS600/690). We can get pretty decent performance running the vertex shaders on the CPU so we will need to use a mix of hardware drivers for pixel shader plus Softpipe for vertex shader. The same model could presumably be used for vertex shading with pre-DX9 GPUs.

      The remaining question is whether it will be practical to execute TGSI pixel shaders on DX7 or DX8 hardware. There the chances seem better. Nobody knows for sure but I expect a bunch of smart people will try to make it work.
      So DRI2 is for sure, but Gallium3D on a card like my 9200 is a maybe?

      But wouldn't that mean that future releases of Xorg would use a mixture of Gallium3D and mesa?
      Last edited by Extreme Coder; 27 August 2008, 09:41 PM.

      Comment


      • #4
        I think so. I wouldn't say DRI2 is "for sure" but "very probably". I wish I could find a word to use for "maybe" that isn't quite so positive.

        Strictly speaking Gallium3D is a new driver architecture, and Mesa is being modified to use the Gallium driver model instead of the current Mesa driver model, but AFAIK the OpenGL driver will still be "Mesa", just a newer version of it.

        Not sure what the plan is (if any) to support a mix of old and new cards in the same system. In that case running Gallium on both might be attractive even if the Gallium-based driver didn't run as fast on the old chip as pre-Gallium Mesa did.

        I should mention that even the current 3D driver stack is at the point where features can be implemented on R3xx and up but not on the older GPUs. There is a good chance that the current Mesa driver will evolve to the point where it already does everything your older card can handle, in which case there may not be much benefit going to a Gallium-based driver anyways.

        Anyways, it's a good question. Something for Michael to ask about at XDS
        Test signature

        Comment


        • #5
          Originally posted by bridgman View Post
          I think so. I wouldn't say DRI2 is "for sure" but "very probably". I wish I could find a word to use for "maybe" that isn't quite so positive.

          Strictly speaking Gallium3D is a new driver architecture, and Mesa is being modified to use the Gallium driver model instead of the current Mesa driver model, but AFAIK the OpenGL driver will still be "Mesa", just a newer version of it.

          Not sure what the plan is (if any) to support a mix of old and new cards in the same system. In that case running Gallium on both might be attractive even if the Gallium-based driver didn't run as fast on the old chip as pre-Gallium Mesa did.

          I should mention that even the current 3D driver stack is at the point where features can be implemented on R3xx and up but not on the older GPUs. There is a good chance that the current Mesa driver will evolve to the point where it already does everything your older card can handle, in which case there may not be much benefit going to a Gallium-based driver anyways.

          Anyways, it's a good question. Something for Michael to ask about at XDS
          Thanks for your explanation! It's always very handy to have someone like you from ATi at this forum
          So I think R300 and up will use Gallium, or something similar to that?
          Sometimes I feel the 3D stack for my Radeon 9200 is sometimes incomplete, but only slightly :P (But it's way better than any Intel 3d driver for sure ) I just hope that sometime soon any loose ends or missing GL extensions will be implemented.

          Comment


          • #6
            Based on above info, the it might be good to have pre-R300 and post-R300 (including R300) driver separated, because this seems as a clean cut between two distinct implementations on different HW architecture.

            Only if radeonhd driver can be back ported to support R300/R420 HW together with R520/R600/R700 to be purely based on Gallium3D arch, and radeon driver solely works for Mach/R100/R200 using whatever traditional rendering architecture, this separation seems natural and nice....

            Comment


            • #7
              Just to clarify, DRI2 and gallium are orthogonal. Once we have a unified memory manager we'll get DRI2. Gallium is just an interface in mesa for making it easier to write drivers. It's still a fair amount work to port drivers to the interface. Gallium requires a pixel shader, but provides a sw vertex shader as it was originally designed around Intel GPUs with no vertex shader. As for pre-shader hw, gallium would need updates to deal with that sort of hardware. It'd be a fair amount of work.

              Comment


              • #8
                Pre-R300 chips definitely do not fit into the current Gallium architecture. After all, you'd end up doing OpenGL fixed function -> pixel shader -> fixed function, and that's just going to suck until a lot of work is put into it. Personally, I feel that would be a waste of developer time.

                On the other hand, it may be possible to extend the Gallium interface so that in place of a TGSI pixel shader we could also provide an ATI_fragment_shader (or something like it) pixel shader. That would allow us to go forward with a unified driver even for pre-R300 hardware.

                Of course in the end, it's a question of how much time the people who care can devote to the task.

                Comment


                • #9
                  Given the way architecturally that Gallium3d is designed, it probably doesn't make much sense to use it for older hardware. Software HT&L for older cards without vertex shaders would have a huge performance hit for rather dubious benefit given how complete the current drivers for those cards.

                  Comment

                  Working...
                  X