Announcement

Collapse
No announcement yet.

Lightspark May Work Towards A Gallium3D State Tracker

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

  • #31
    I may be wrong on this, but isn't Gallium3D a different flavour of MESA? Why you consider it different to OpenGL?

    Comment


    • #32
      Originally posted by bridgman View Post
      .. and the video decode framework would require pretty much everything we do for 3D anyways (eg the ability to compile and run shaders, the ability to draw primitives, the ability to access memory etc...). Remember that it's the upper levels of Mesa, shared across all GPU hardware vendors, which deal with all of the GL specific nasties... and it's that common code which needs most of the work to support higher levels of GL.
      Correct me if I'm wrong but isn't that already done in Mesa? Memory Management was merged around 2.6.31, shader compilers are there and so on?

      Originally posted by bridgman View Post
      The proprietary drivers already have GL 4.x and OpenCL; video decode acceleration is WIP but is already working for some users. Mplayer supports GL output which doesn't normally have tearing issues unless you are running with a compositor, which I doubt you would want on an HTPC system.
      Well I have both ideological and practical problems with getting the proprietary driver to run. As for GL, on my current system(Intel i3 HD, Mobility Radeon 5850) it's actually slower than XV while making my Fan freak out more than Starcraft II on full in Windows.

      Originally posted by TemplarGR
      I may be wrong on this, but isn't Gallium3D a different flavour of MESA? Why you consider it different to OpenGL?
      Because OpenGL is a standardized API and Gallium3D a moving target implementation that seeks to implement all features a video card has?

      This question actually had me think about the problem more, and the more I do, the more this state tracker thing freaks me out.
      OpenGL was created to have a stable cross-platform 3D-API for developers to target. So let's say I'm a game developer. I write my game for OpenGL 3, and it works for a few years until changes to GCC/libc break it for everyone anyway.
      Now I can easily check whether the card of my user supports OGL3. Or at least I could till every driver vendor decided to implement whatever he wanted, randomly backporting features for OGL3 to cards that report 2.1 or even 1.5(yay Intel). Oh well, I'll check for the individual GL-extension then, checking for the existing 50+ Strings is a pain, but at least I can count on that... or at least I could, but now I've read about how some extensions are only half-working but report working state because that let's you run a few games on wine. And don't get started about Mesa's own extensions which are not part of the standard.
      With getting OGL to work being this much of russian roulette I understand why people would jump onto the state tracker bandwagon. But within a few years that environment will be fucked up too if everybody writes his own tracker.

      First of all Gallium3Ds API has been changing rapidly and according to Zack Rusin will continue to do so for another while. So not only will distros need to start packaging new Kernel/libdrm/Mesa-version as soon as the hit or else their state trackers will stop working, every API-change could easily break a ton of applications.
      Secondly people will start inter-dependencies between state-trackers, making the whole environment impossible to package and to maintain.
      Third and most important: Microsoft is currently shipping about 30 versions of DirectX 9,10 and 11 to every computer, because apps have started to hard-code dependencies onto for example the Juli 2009-version of DX11 and will only accept that. It's DLL-hell at it's fullest, forcing Microsoft to ensure that ALL of these work. Does Mesa really have the man-power to ensure Gallium API 0.8, 0.9, 0.91 and so on work at all times? And wasn't the reason OpenGL was standardized in the first place to prevent this mess?

      Comment


      • #33
        Originally posted by fabiank22 View Post
        Correct me if I'm wrong but isn't that already done in Mesa? Memory Management was merged around 2.6.31, shader compilers are there and so on?
        Sure, but all of the low level bits need to be changed for each new generation of hardware. That's where a lot of our developer time goes and that is presumably what you are saying we should stop in order to make time for video decode work.
        Test signature

        Comment


        • #34
          Originally posted by fabiank22 View Post
          Third and most important: Microsoft is currently shipping about 30 versions of DirectX 9,10 and 11 to every computer, because apps have started to hard-code dependencies onto for example the Juli 2009-version of DX11 and will only accept that. It's DLL-hell at it's fullest, forcing Microsoft to ensure that ALL of these work. Does Mesa really have the man-power to ensure Gallium API 0.8, 0.9, 0.91 and so on work at all times? And wasn't the reason OpenGL was standardized in the first place to prevent this mess?
          This is D3DX you are talking about and this is done on purpose because Microsoft didn't wish to maintain binary compatibility.

          Comment


          • #35
            Direct "something" 3D and OpenGL are overkill because it's like building a 24km high 1000000hp truck to travel from europe to the US through water, when you can also just use a boat.

            Serialisation goes like this:
            "Hey GPU! I'm a compositing WM"
            -"Hey GPU! I'm a movie decoder!"
            GPU: "I'm busy, OK?"

            And Gallium3D, as tech, own. No it's not finnished and (duh!) thus its API is not stable. But it will be. That's the point.

            Why do people use DX on Windows? Well why do you think, smartass? "Hey I'm a decoder app programmer. Can I have the nessecary sourcecode of Windows?" >.<

            Comment


            • #36
              Originally posted by V!NCENT View Post
              And Gallium3D, as tech, own. No it's not finnished and (duh!) thus its API is not stable. But it will be. That's the point.
              Yeah, it's unfinished, unstable and also not very well documented. You must be a real masochist to even consider targeting this API as an application developer.

              Comment


              • #37
                Originally posted by monraaf View Post
                Yeah, it's unfinished, unstable and also not very well documented. You must be a real masochist to even consider targeting this API as an application developer.
                What's the point of documenting the Gallium API when it's design isn't even finnished yet?

                Hell, what was the point of porting Quake to Linux in 1996?

                What was the point of developping Linux at all when HURD was being developped in 1990 and microkernels was supposed to be the state of the art in kernel design? Who the hell is going to develop for Linux? What company might possibly be interested in this crap?

                What is the point of starting a project at all? I mean it isn't usable from the very first moment you start working on it.

                Seriously you are all _IDIOTS_

                Comment


                • #38
                  Originally posted by V!NCENT View Post

                  And Gallium3D, as tech, own. No it's not finnished and (duh!) thus its API is not stable. But it will be. That's the point.
                  >.<
                  Troll on bro. Haters gonna hate...

                  I also love how you simply quote random strawman fanfiction, heck you even managed to get Hurd in there. Five thumbs up from me

                  Comment


                  • #39
                    Originally posted by fabiank22 View Post
                    Troll on bro. Haters gonna hate...

                    I also love how you simply quote random strawman fanfiction, heck you even managed to get Hurd in there. Five thumbs up from me
                    You must have never heared about the chaos theory, but that's OK; it's merely and indication for how fucking stupid you are.

                    BTW you'd all be crying like cry babies if Gallium3D was never created, simply because of the fact that you'd be stuck with a fixed pipeline solution from the stoneage.

                    Same goes for PulseAudio and D-bus; without it the best the Linux desktop was to pull of was surround sound and that'd be pretty much it. However ignoring that a great working audio card costs only 15 dollars max, you keep whining about the fact that it doesn't work, but then turn around to spend 250 dollars on an nVidia card because it all works so fucking great.

                    And now I am the troll. Tell that to AMD who moves towards Gallium3D. Maybe, instead of my sorry ass that you can lick you mutherfucker, they know better than you.

                    End of fucking story.

                    Comment


                    • #40
                      Maybe it's a foolish thing to ask, but did anybody actually bother to read the blogpost?
                      I got the impression that this is just a quick notation of an idea of one of the developers, looking for a less overkill way to get the drawing actions to the GPU.
                      Perhaps a Gallium state tracker isn't the best idea (the comments were quick to propose something like letting the cairo GL backend do the work); but it would be definitely easier than using openGL anyway.

                      But i guess the trolls here are up to something: with Gallium being the buzzword in open-source graphics, more developers are going to consider writing their own state trackers, custom-tailored to their needs.
                      My 2 cents: when the API has become relatively stable, why not let the people have their own state trackers? If this is easier to write (thus easier to maintain) than OGL or GL ES or RandomToolkitBackend, and works rasonably stable, it should be worth a try.

                      Comment

                      Working...
                      X