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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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

                    Working...
                    X