Announcement

Collapse
No announcement yet.

LLVMpipe Gallium3D Now Exposes GLSL 3.30

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

  • LLVMpipe Gallium3D Now Exposes GLSL 3.30

    Phoronix: LLVMpipe Gallium3D Now Exposes GLSL 3.30

    The LLVMpipe driver that provides software-accelerated OpenGL support over Gallium3D now has GLSL 3.30 support where previously only version 1.40 of the GL Shading Language was exposed...

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

  • #2
    Meanwhile, Sandybridge is stuck at 1.40

    Comment


    • #3
      Originally posted by Krejzi View Post
      Meanwhile, Sandybridge is stuck at 1.40
      Intel OTC devs said they won't implement anything newer than 3.1 for Sandy Bridge, but it's technically possible.

      Windows drivers for Sandy Bridge also only support OpenGL 3.1.

      Comment


      • #4
        Originally posted by Krejzi View Post
        Meanwhile, Sandybridge is stuck at 1.40
        Get coding. The driver is open source, documentation is available. Yeah, I know, graphics driver development is hard. But hey, I have Ironlake, that driver is even less complete than the Sandy Bridge one.

        @_SXX_: Do you have a link to where Intel devs said this? All I'm aware of is Paul Berry saying he probably won't work on geometry shaders for SB, but would be willing to help if someone else tackled it: http://lists.freedesktop.org/archive...er/046150.html

        Comment


        • #5
          Great but I'd be curious to know why the non-LLVM backend is still stuck with 1.5

          Comment


          • #6
            yeah

            Originally posted by Krejzi View Post
            Meanwhile, Sandybridge is stuck at 1.40
            its stupid decision but ok, next time i will remember this type of decisions by intel devs

            Comment


            • #7
              Originally posted by Gusar View Post
              Get coding. The driver is open source, documentation is available. Yeah, I know, graphics driver development is hard. But hey, I have Ironlake, that driver is even less complete than the Sandy Bridge one.
              Oh gosh, how can I thank you for your helpful suggestion? here's a tip for you:
              Get mining, get an Earth map and find gold, if you mine enough you'll find gold and become a billionaire. HTH

              Comment


              • #8
                At least you'd have some reasonable expectation of getting something useful if you wrote code, without worrying about getting taxed when you exchanged it for your currency of choice. And in this case you have prior art and experience that's willing to help, whereas if you went mining you likely wouldn't have the tools, experience, or knowledge to do the job, and nobody to help.

                You'd be better off mining for quartz anyway, imho.

                Comment


                • #9
                  OpenGL coding is a nightmare due to the vast diversity of availability of extensions, which is somewhat understandable, but it's hard to find a good technical explanation for why each version of GLSL breaks with previous versions. If you want to write a properly portable OpenGL application, you basically need to rewrite every shader in various versions of GLSL -- there's no difference in features, just in syntax. Sure, newer versions are nicer and cleaner, but the cost of this urge to streamline is huge headaches for us devs.

                  OpenGL is the best option we have for crossplatform graphics development, but I can't say I love it.

                  Comment


                  • #10
                    Originally posted by Gusar View Post
                    @_SXX_: Do you have a link to where Intel devs said this? All I'm aware of is Paul Berry saying he probably won't work on geometry shaders for SB, but would be willing to help if someone else tackled it: http://lists.freedesktop.org/archive...er/046150.html
                    I consider this statement as fact that Intel devs won't implement those on their own.

                    Comment


                    • #11
                      Originally posted by mark45 View Post
                      Oh gosh, how can I thank you for your helpful suggestion? here's a tip for you:
                      Get mining, get an Earth map and find gold, if you mine enough you'll find gold and become a billionaire. HTH
                      You're incorrectly inferring I was attempting a suggestion and was soliciting thanks for my supposedly brilliant contribution. I wasn't. I was just stating the obvious. So the joke's on you.

                      But let's look at the situation realistically - what will you gain if geometry shaders get implemented for SB? It's not like SB is powerful enough to actually run the things that rely on geometry shaders. You get prettier glxinfo output, and can maybe marvel at some demo running at low fps, and that's that. So I find posts like rikkinho's beyond silly.

                      Comment


                      • #12
                        Originally posted by _SXX_ View Post
                        I consider this statement as fact that Intel devs won't implement those on their own.
                        Yes it can be interpreted that way, but it's very different from "Intel OTC devs said they won't implement anything newer than 3.1 for Sandy Bridge". The thing is, 3.1+ extensions already are implemented on SB.
                        You're doing the same as those who were saying "Nvidia said they will never support Optimus on Linux", when what they actually said was "We currently do not have plans to support display on Optimus systems where the display is connected to the Intel hardware" (emphasis mine).

                        Comment


                        • #13
                          OpenGL 4

                          Hopefully we'll see OpenGL 4 soon.

                          Comment


                          • #14
                            Originally posted by Gusar View Post
                            You're doing the same as those who were saying "Nvidia said they will never support Optimus on Linux", when what they actually said was "We currently do not have plans to support display on Optimus systems where the display is connected to the Intel hardware" (emphasis mine).
                            i don't really care what they said if feature I need not supported or broken. There is no GL_ARB_compatibility support in Mesa so applications that require OpenGL 3.3 won't work out of box on Sandy Bridge even if those don't need geometry shaders and this is sad.

                            Comment


                            • #15
                              Originally posted by emblemparade View Post
                              OpenGL coding is a nightmare due to the vast diversity of availability of extensions, which is somewhat understandable, but it's hard to find a good technical explanation for why each version of GLSL breaks with previous versions. If you want to write a properly portable OpenGL application, you basically need to rewrite every shader in various versions of GLSL -- there's no difference in features, just in syntax. Sure, newer versions are nicer and cleaner, but the cost of this urge to streamline is huge headaches for us devs.

                              OpenGL is the best option we have for crossplatform graphics development, but I can't say I love it.
                              What is lowest common denominator?

                              If your shaders work with mere syntax changes, you should've written them in the earlier version in the first place.

                              Comment

                              Working...
                              X