Announcement

Collapse
No announcement yet.

A Glide State Tracker For Gallium3D Is Talked About

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

  • A Glide State Tracker For Gallium3D Is Talked About

    Phoronix: A Glide State Tracker For Gallium3D Is Talked About

    A student developer has written to the Mesa3D development mailing list about creating a Gallium3D state tracker for the Glide API. Yes, the 3Dfx that hasn't been used in more than a decade...

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

  • #2
    Waste of an article

    What a waste of an article. Brian Paul already replied to point out that the fixed-function Glide API doesn't map well at all to the shader-based Gallium. The discussion is pretty much over by now.

    Comment


    • #3
      Apart from Glide worth being implemented or not (probably the later) mesa devs could make a list of small "easy" projects (if there is such a thing in graphic development) for people looking in to getting involved in mesa/G3D/state trackers/etc.

      Comment


      • #4
        Originally posted by Plombo View Post
        What a waste of an article. Brian Paul already replied to point out that the fixed-function Glide API doesn't map well at all to the shader-based Gallium. The discussion is pretty much over by now.
        I agree. This is not news.

        Comment


        • #5
          So how exactly do gallium drivers support older opengl versions?... in any case a gallium based driver would be better than an opengl wrapper.

          Comment


          • #6
            Originally posted by cb88 View Post
            So how exactly do gallium drivers support older opengl versions?... in any case a gallium based driver would be better than an opengl wrapper.
            Strictly speaking there is no problem implementing a fixed-function API in a Gallium3D-based state tracker as long as the API can be translated into shader-based draw operations (which is probably the case for Glide) - the problem is more with running on fixed-function *hardware*.

            I don't remember if the proposal was to run Glide on new HW (which should be OK) or to run on 3DFX HW (which would be really problematic).

            Comment


            • #7
              Originally posted by bridgman View Post
              Strictly speaking there is no problem implementing a fixed-function API in a Gallium3D-based state tracker as long as the API can be translated into shader-based draw operations (which is probably the case for Glide) - the problem is more with running on fixed-function *hardware*.

              I don't remember if the proposal was to run Glide on new HW (which should be OK) or to run on 3DFX HW (which would be really problematic).
              It looks like the student was proposing to allow newer gallium-capable hardware to run Glide Apps natively. He points out that there may not actually have been any Glide-based Linux Apps, but that Gallium is capable of running on Windows as well, so it might be useful there.

              Of course, I'm pretty sure that many Glide apps were also 16-bit, which wouldn't execute too well on a modern OS without emulation of some sorts anyway. The Glide-OpenGL wrappers that we already have are probably as good as they need to get anyway.

              He was mostly looking to get familiar with the Gallium API as a capstone project for his Bachelor's degree, not necessarily to resurrect the Glide API as a viable GPU programming API. He also asks for alternative projects if anyone has any that they can think of.

              Comment


              • #8
                would it even be a bad thing to resurrect glide?

                Comment


                • #9
                  Also, why would be there any need to run it natively? Every app that used Glide should run faster than what it was deemed possible when designed/developed, even with a wrapper.

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    Strictly speaking there is no problem implementing a fixed-function API in a Gallium3D-based state tracker as long as the API can be translated into shader-based draw operations (which is probably the case for Glide) - the problem is more with running on fixed-function *hardware*.

                    I don't remember if the proposal was to run Glide on new HW (which should be OK) or to run on 3DFX HW (which would be really problematic).
                    It was to run it on new hardware. Brian's point was not that it wouldn't be possible; it was that the fixed-function Glide was not a good match for the shader-based Gallium3D.

                    Comment


                    • #11
                      Why stopping this to happen???

                      I think that this guy should start with the project despite what some "Big Bosses" say. It whould be nice to have glide implemented natively, and in turn, dll wrappers for wine in order to not lose lot of old good games. I guess this guy should go his way, no matter what other people say.

                      Comment


                      • #12
                        Originally posted by sebastianlacuesta View Post
                        I think that this guy should start with the project despite what some "Big Bosses" say. It whould be nice to have glide implemented natively, and in turn, dll wrappers for wine in order to not lose lot of old good games. I guess this guy should go his way, no matter what other people say.
                        Why? It would require a lot of duplicated work to implement another fixed-function API using Gallium3D. Using an OpenGL wrapper would be easier and more sensible - it's not like the old games using Glide wouldn't still run at full speed.

                        But from reading the original email, the potential author's main objective seems to be learning to use Gallium, not to implement Glide.

                        Comment

                        Working...
                        X