Page 1 of 2 12 LastLast
Results 1 to 10 of 45

Thread: R600 Gallium3D Getting Close On OpenGL 3.3 Support

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,456

    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
    442

    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,755

    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,187

    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
    599

    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,755

    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
    599

    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
    Jun 2011
    Posts
    315

    Default

    Quote Originally Posted by Ericg View Post
    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)
    I would disagree..
    Ever since 3.0, from my perspective, the kernel went to hell in a handbasket...

    Around 3.0 is where the kernel platform drivers broke my wireless in my 7 year old HP laptop which was working perfectly fine for 6 years until then.. I've had to blacklist the HP platform driver to fix it.
    They tell me to test the latest kernels (3.5 head, 3.6 head, etc.), but these kernels lock the system hard on the same laptop, so they won't even boot. The only solution that works perfectly is kernel 3.2 in Debian Wheezy and on top of that, I have to blacklist the HP platform drivers. If I do that, the system is rock solid stable and the wireless works flawlessly. it's also works flawlessly on 2.6* and 2.4* kernels since forever..

    Then I bought a new laptop.. Turns out Kernel 3.2 that works perfectly on my other laptop, in Debian Wheezy, randomly locks up hard when running iceweasel/firefox on this new laptop. In fact, it seems to be a common occurance for people with mobile Ivy Bridge processors and intel graphics. I'm so lucky that the 3.5 head and 3.6 head kernels actually boot in this new laptop (although they don't on my other), and not only that, but it fixes the lock ups.. Why haven't the fixes in 3.5/3.6 been backported to 3.2 stable? I have no f-ing clue. Apparently the kernel team is leaving it to the poor folks at Debian to find these crash fixes in the mess of the 3.5/3.6 kernels and backport them in the hopes of making a stable kernel themselves because the kernel team isn't providing a stable 3.X release (yet!).. IMO, it feels like the kernel is a horrible mess right now. I've got 2 laptops that require very specific kernel versions (that are different!!!) to function at all, which means to me that the whole 3.X series is terribly unstable.
    Last edited by Sidicas; 01-13-2013 at 10:23 PM.

  9. #9
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    124

    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 would be apprehensive about quickening the release process. Doing a release takes a fair amount of work---developers shift focus from adding features or optimizations to stabilization. That may mean fixing the inevitable regressions, or other bugs that have popped up, or just finalizing and polishing things they've worked on. This is a good thing, but it sort of puts forward progress on hold.

    In my limited experience with working with the kernel and X server, it seems like the kernel process almost necessitates a person whose entire job is managing releases, merge windows, and so on. This makes sense for a huge project like the kernel, but it seems a high cost for us. A similar issue we have is stable branch maintenance---I know Ian has spent a huge amount of time on that, and could spend even more. (Recently, Andreas stepped up to manage that, which has been extremely helpful. We're very grateful!)

    Piglit tests are definitely a huge help in mitigating regressions, but they're by no means foolproof---there are still huge gaps in our test coverage. Also, we don't yet have a system set up where we're running those tests on every platform, so they mostly get run on developers' machines. (We should fix that.) I've definitely fixed a number of 965GM crashers right before release that somehow no one had noticed. And especially these days, breaking people's 3D drivers can be pretty painful. I know distros are really concerned about that (and rightly so).

    I do agree with Marek---Mesa master tends to be fairly stable and works most of the time. Breakage does happen, but it's usually caught and corrected fairly quickly. I think for advanced users who enjoy being on the bleeding edge and want the latest and greatest, using Mesa master is a decent option. It's reasonably easy to do these days, and we definitely appreciate the additional testing and feedback. But not everybody wants to be on the bleeding edge.

    That said, it's very likely that we'll continue evolving the release process. Maybe we'll move to a shorter release cycle in the future. We'll have to wait and see :)

  10. #10

    Default

    One would hope though that an exception could be made, just this once if OpenGL3.3 support can be had so that either the coming window is pushed back to include it or a special release that adds only that is put out in the interim for the distros to pick up so we aren't waiting till the 2014 releases before we see it.

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
  •