Announcement

Collapse
No announcement yet.

Intel Is Preparing A Major Restructuring Of Their Graphics Driver

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

  • #21
    weren't newer Intel GPUs using firmwares? I hope this does not mean they pull the same trick the pulled with their wifi cards, where the "firmware" is the driver.

    Comment


    • #22
      I hope they'll keep the Linux driver Open Source.

      Comment


      • #23
        Originally posted by curaga View Post
        The Intel Linux team, or what was previously that, better keep a tight quality watch. Intel's Windows driver is pure shit, in such concentrations it will kill plants by overflowing them with nutrients. I'm really afraid of what will happen to the Linux driver's high quality when the Windows code starts getting in.
        That code is closed, how do you know that?

        Comment


        • #24
          Originally posted by Serafean View Post
          So does Apple's OpenGL stack. your point being?
          I'm giving them the benfit of the doubt as of now, but count me slightly worried...
          Originally posted by jf33 View Post
          Do you know any application that requires a 3.1+ compatibility profile? I don't. Also, wouldn't it be possible to use mesa for core profiles and the existing crappy Windows implementation for compatibility contexts?
          Well, if you use SDL and specify nothing you get a compatibility context. Windows-only OpenGL programs will probably do that a lot.
          Some programs have the core profile only activated with #ifdef __APPLE__. For example OSVR's rendering-manager still does: https://github.com/sensics/OSVR-Rend....cpp#L282-L287
          I've seen a todo somewhere in the code about that but I don't find it right now. Anyway, it seems that it's hardcoded that only APPLE gets a core context: OSVR-RenderManager/osvr/RenderKit/RenderMa...

          Comment


          • #25
            Originally posted by haagch View Post
            Well, if you use SDL and specify nothing you get a compatibility context. Windows-only OpenGL programs will probably do that a lot.
            Some programs have the core profile only activated with #ifdef __APPLE__. For example OSVR's rendering-manager still does: https://github.com/sensics/OSVR-Rend....cpp#L282-L287
            I've seen a todo somewhere in the code about that but I don't find it right now. Anyway, it seems that it's hardcoded that only APPLE gets a core context: OSVR-RenderManager/osvr/RenderKit/RenderMa...
            Wow, what an example of a clueless developer. Seriously, there is absolutely no reason to mix legacy OpenGL functions with modern OpenGL. Functions have been deprecated for a reason. Especially if you're doing such advanced stuff like VR rendering, then you *really* should get rid of all pre-3.1 functionality.

            But thanks for trying to convince him . And yes, although glEnable (and glDisable) is not deprecated by itself, it's no longer allowed to call it with GL_TEXTURE_2D as parameter.

            Comment


            • #26
              Let's hope this is not an announcement of the closing of their open driver effort. That would make me cry.

              Comment


              • #27
                I'd like to see them restructure their Cherry / Bay Trail Linux graphics (and audio) support. From none to some.

                Comment


                • #28
                  Originally posted by microcode View Post
                  Let's hope this is not an announcement of the closing of their open driver effort. That would make me cry.
                  Worse case, the LunarG ILO Gallium3D will probably get more attention.
                  Best case, we get a better open source driver.

                  Comment


                  • #29
                    they are not using gallium already. i wouldn't be surprised if they stop using mesa

                    Comment


                    • #30
                      Originally posted by Hi-Angel
                      That code is closed, how do you know that?
                      I wasn't speaking about code quality, but runtime quality. I know by having written opengl programs and having tried to run them on Windows machines with Intel GPUs. They fail in excruciating ways, I had several simple GL2 programs just muck up on Intel Windows, when they worked perfectly on every other OS and driver, including Intel Linux. 100% valid GL.

                      Comment

                      Working...
                      X