Announcement

Collapse
No announcement yet.

Intel Is Getting Very Close To OpenGL 4.0/4.1/4.2 Mesa Support

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

  • Intel Is Getting Very Close To OpenGL 4.0/4.1/4.2 Mesa Support

    Phoronix: Intel Is Getting Very Close To OpenGL 4.0/4.1/4.2 Mesa Support

    As brought up in the discussion following yesterday's article about Intel adding BPTC support to their Mesa driver, several Phoronix readers are filled with happiness over Mesa nearly support not just for the OpenGL 4.0 specification but also OpenGL 4.1 and 4.2 aren't far out of reach...

    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
    AMD ARE YOU LISTENING

    Comment


    • #3
      Also its worth pointing out extensions nobody work on (at least for long enough to update those docs):

      4.0
      ARB_shader_subroutine

      4.1
      ARB_vertex_attrib_64bit

      4.2
      Empty

      And that is even better news, as that mean that people really work toward 4.0/4.1/4.2, and not only one lowest hanging fruites.

      Comment


      • #4
        Yeah i wanna hear somethnig about main ones , the hard to implement ones if you like ... GL_ARB_shader_subroutine, GL_ARB_tessellation_shader and GLSL 4.0 .

        Advertising OpenGL 4.0 support is anywhere near without those .

        Of course every code counts, bptc is good to have
        Last edited by dungeon; 23 July 2014, 11:03 AM.

        Comment


        • #5
          Originally posted by dungeon View Post
          GL_ARB_shader_subroutine, GL_ARB_tessellation_shader and GLSL 4.0 .
          Yeap, and these will probably take quite a bit longer. So I'm not sure if the article name "getting very close to OpenGL 4.0" is very accurate...

          Comment


          • #6
            Originally posted by GreatEmerald View Post
            Yeap, and these will probably take quite a bit longer. So I'm not sure if the article name "getting very close to OpenGL 4.0" is very accurate...
            I still see little point in celebrating. Intel GPUs are too slow for most OpenGL 4.x games. A real gamer would buy NVIDIA. There are not much options as AMD also totally fails with their open source plans. I've tried Radeons every now and then and typically the drivers hang the machine during the first 15 minutes of testing.

            Comment


            • #7
              Originally posted by GreatEmerald View Post
              Yeap, and these will probably take quite a bit longer. So I'm not sure if the article name "getting very close to OpenGL 4.0" is very accurate...
              They're still a long way off if GLSL 4.x takes as long as GLSL 3.x

              Comment


              • #8
                Well, the only place where nvc0 is behind intel is its lack of ARB_shader_atomic_counters (which are actually missing in gallium as a whole). This should not be difficult to implement, but is also not incredibly useful without some of the other direct-to-buffer extensions like ARB_shader_image_load_store and ARB_shader_storage_buffer_object. [And the ARB_clear_texture extension was _just_ checked in, but it should also not be too hard to add support for.]

                For those who are looking for a bit of a status update on various GL4.0 things:

                - ARB_gpu_shader5 is 95% done on nvc0 and intel -- the last piece missing is dynamic sampler referencing (and also intel apparently has issues with the multi-stream streamout stuff)
                - ARB_tessellation_shader is like 20% done -- there are patches from Fabian Bieler which do a bunch of the initial work, but there are a lot of holes. I've done a gallium implementation on top of them and nvc0 passes a few of the piglit tests. The core work will be picked up by ChrisF after he's done with gs5.
                - ARB_gpu_shader_fp64 is like 80% done for softpipe and nvc0 -- Dave Airlie has patches in a branch for core and softpipe, I have patches in a branch for nvc0.
                - ARB_shader_subroutine is 0% done (at least publicly) -- I believe someone at Intel said they may look at it, but nothing firm.

                GLSL 4.00 isn't really a thing btw -- it doesn't add anything on top of, say, GLSL 1.50... it's just the collection of extensions that enable the various functionality.

                And as always, if you want to find out what extensions a particular piece of hardware supports (for a released Mesa version):

                Comment


                • #9
                  Originally posted by caligula View Post
                  I still see little point in celebrating. Intel GPUs are too slow for most OpenGL 4.x games. A real gamer would buy NVIDIA. There are not much options as AMD also totally fails with their open source plans. I've tried Radeons every now and then and typically the drivers hang the machine during the first 15 minutes of testing.
                  what OS are you using and which card? i have a radeon HD 4850X2, 4250, 7700 and Kabini APU and i had never seen a system hang since 3.8 kernel

                  and OpenGL is used for a lot more than just games, don't be an ass

                  BtW radeonSI driver is actually pretty close to intel support for GL 4+

                  Comment


                  • #10
                    @89c51
                    AMD, from what I heard, isn't that far behind. Neither is nouveau. With intel doing most of the mesa work, all the AMD devs have to do is add support for it in their drivers. That being said...

                    @Caligula
                    Intel is indirectly speeding up the development for other companies. Sure it might not really be in their interest since their hardware isn't going to get very far, but as long as they're willing to pitch in I'd say let them.

                    @DanL
                    A good chunk of OGL 4.x was already completed when OGL 3.3 was released. I don't suspect it'll take as long as we think it will. I get the impression OGL 3.x features were a bit more complex, too, though I could be wrong.

                    Comment

                    Working...
                    X