Page 1 of 5 123 ... LastLast
Results 1 to 10 of 45

Thread: R600 Gallium3D Getting Close On OpenGL 3.3 Support

  1. #1
    Join Date
    Jan 2007
    Posts
    15,641

    Default R600 Gallium3D Getting Close On OpenGL 3.3 Support

    Phoronix: R600 Gallium3D Getting Close On OpenGL 3.3 Support

    The open-source AMD "R600g" Gallium3D driver is slowly but surely closing in on OpenGL 3.3 support for this open-source Linux graphics driver that supports from the Radeon HD 2000 through Radeon HD 6000 GPUs...

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

  2. #2
    Join Date
    Jul 2010
    Posts
    449

    Default

    I find it exciting that we now have two open source drivers with OpenGL 3.1 support (particularly as neither is far from OpenGL 3.3).

    Intel pushed up the last two version numbers so it would be nice if the bump to 10.0 could be a result of both AMD and Intel drivers.

  3. #3
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,935

    Default

    What are the odds of moving Mesa to the kernel's release style? Tag release --> Two week merge window --> 1 RC a week, with say a minimum of 5 RC's, that puts us at 7 weeks. Tag release. Pattern starts again.

    I get the benefit of a nice steady 6month release schedule but something like the graphics stack-- like the kernel, I feel like needs to be a little more rapid release. This way if a feature isn't quite ready, its not a big deal to just release a month and a half or 2months later. The piglit tests help to ensure we don't regress and break things so its not even an argument of "Rapid release means rapid breakage!"

    Any input from Kayden? Airlied? Marek?

  4. #4
    Join Date
    Oct 2007
    Posts
    1,323

    Default

    Quote Originally Posted by Ericg View Post
    What are the odds of moving Mesa to the kernel's release style?
    IIRC, VMWare has a lot to do with mesa's release style and they like it the way it is.

  5. #5
    Join Date
    Jan 2009
    Posts
    630

    Default

    Quote Originally Posted by Ericg View Post
    What are the odds of moving Mesa to the kernel's release style? Tag release --> Two week merge window --> 1 RC a week, with say a minimum of 5 RC's, that puts us at 7 weeks. Tag release. Pattern starts again.

    I get the benefit of a nice steady 6month release schedule but something like the graphics stack-- like the kernel, I feel like needs to be a little more rapid release. This way if a feature isn't quite ready, its not a big deal to just release a month and a half or 2months later. The piglit tests help to ensure we don't regress and break things so its not even an argument of "Rapid release means rapid breakage!"

    Any input from Kayden? Airlied? Marek?
    I don't like the kernel release model and I don't think it would suit Mesa. Mesa is usually fairly stable even during heavy development and new features are being usually developed in separate feature branches, which are then reviewed, rebased, and merged. I think the current Mesa release model is probably the best we can have.

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,935

    Default

    Quote Originally Posted by marek View Post
    I don't like the kernel release model and I don't think it would suit Mesa. Mesa is usually fairly stable even during heavy development and new features are being usually developed in separate feature branches, which are then reviewed, rebased, and merged. I think the current Mesa release model is probably the best we can have.
    Okay, hence why I asked for your three's input specifically haha. Just out of curiousity, what is it that you don't like about the kernel's release style? Things seem fairly stable even during RC's (im running 3.8rc3 right now, before I ran rc1)

  7. #7
    Join Date
    Jan 2009
    Posts
    630

    Default

    A too-long stabilization period is the main issue. After the merge window, you have to wait 2.5 months before your code is released. If you miss it, you have to wait half a year (and it's rotting in some private branch for 3 months before Linus pulls it), which means waiting at least 3/4 of a year before distributions release it.

  8. #8
    Join Date
    Jan 2010
    Posts
    368

    Default

    So what's the status of geometry shaders support? This is obviously a big and hard feature, but there's already some proof of concept code done, as far as I know. Is anyone working on it?

  9. #9
    Join Date
    Jun 2010
    Posts
    172

    Default

    You can hardly say r600 is getting close to OpenGL 3.3 support when a *minor* detail called GLSL 1.5 is missing from 3.2, when GLSL is the most essential part of the specification.

  10. #10
    Join Date
    Jan 2009
    Posts
    630

    Default

    Quote Originally Posted by efikkan View Post
    You can hardly say r600 is getting close to OpenGL 3.3 support when a *minor* detail called GLSL 1.5 is missing from 3.2, when GLSL is the most essential part of the specification.
    GLSL 1.5 is mostly just a combination of the extensions mentioned in the TODO list below it and most of them are DONE.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •