Announcement

Collapse
No announcement yet.

Port fglrx openGL stack to Gallium3D

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

  • bridgman
    replied
    Yeah, I don't see how this would work either. We already have a hardware layer abstraction that supports OpenGL 4.0, OpenCL etc., and have years of performance tuning invested in it. As marek said, the kernel and xorg APIs are probably always going to be a lot more stable than the Gallium3D API, for the simple reason that new userspace APIs are going to come along more often than the kernel and/or X see major design changes.

    I'm not sure how having a second state tracker (fglrx + mesa) would help either.

    In many ways running the fglrx 3D userspace driver over the open source kernel driver would be less work *and* more useful. Even that would be a *lot* of work, however, since the memory management abstractions are quite different.

    I guess the key point here is that the *current* Gallium3D implementation (and API) is probably going to need significant changes before it can support GL 4.0 and OpenCL. That doesn't mean it's not still a Good Thing, just that it's not likely to be the free (or at least cheap) lunch you might hope for.

    Leave a comment:


  • marek
    replied
    Originally posted by cobalt View Post
    With OSS ATI drivers moving to the Gallium3D architecture in the medium/long term, could the fglrx openGL/openCL stack be ported over to become a Gallium3D state tracker and released as a BLOB?
    I don't see how this could ever work. The Gallium3D driver interface is a pretty fast moving beast, with API changes every week (one was just 15 hours ago), that means everything proprietary relying on this interface would need to be fixed too so that it works with the latest version. A non-blob might work though.

    A much better plan would be to replace Gallium3D with the fglrx driver stack entirely, but that's just as crazy as the former idea.

    Leave a comment:


  • sandain
    replied
    Originally posted by cobalt View Post
    You have what I mean backwards, port the openGL part to G3D and drop the hardware specific part. So the new graphics stack would have fglrx openGL state tracker and OSS G3D driver
    G3D already has a functional OpenGL 2.x state tracker, and will hopefully soon have OpenGL 3.x and OpenCL 1.0 state trackers. What is missing, assuming you are using a r600|r700|evergreen variant, is the G3D hardware driver. I am under the impression that this work has already started, but is living in a separate branch that is not ready for end users. If you are however using a r300|r400|r500 variant, the hardware driver sits in the mainline code, and is maturing rapidly.

    AMD has stated multiple times on these forums that they have no intention of releasing the source code for FGLRX due to legal issues related to DRM. They have also stated that they have no intention of releasing a binary hardware driver for G3D, preferring a FOSS solution instead.

    If you are using a r600|r700|evergreen based card, your best bet is to use either FGLRX, or the classic Mesa driver for your 3D needs. FGLRX now supports OpenGL 3.3/4.0 if you want the most out of your card. The classic Mesa driver only supports OpenGL 2.0, but is an excellent option if you require a FOSS solution.

    If you are using a r300|r400|r500 based card, your best bet is to use either the classic Mesa driver or the G3D driver. Both of these drivers are fairly mature, and should provide the majority of the features that you will need. If you are running a supported kernel and xorg, you can try running the last version of FGLRX that supported these chips, 9.3.

    Leave a comment:


  • cobalt
    replied
    Fglrx already uses a framework similar to G3D internally. They wouldn't gain much from switching over. They could re-use G3Ds state trackers... but they already have their own, so why replace them?
    You have what I mean backwards, port the openGL part to G3D and drop the hardware specific part. So the new graphics stack would have fglrx openGL state tracker and OSS G3D driver

    Fglrx already uses a framework similar to G3D internally
    If they already use something similar to G3D to separate the cross-platform code, then I could see that as being an issue as it would interfere with the Windows and OSX drivers. Having G3D drivers across all platforms would be really cool but I doubt AMD would have the much of a reason to do it in the foreseeable future.

    But I doubt that's going to happen soon, G3D isn't mature enough yet
    Im thinking at least a year or two down the line considering the current G3D drivers are still quite early in development anyway

    Besides, G3D doesn't magically solve the problem of kernel and xorg ABIs
    If the fglrx devs were only working on the state tracker they would only have to deal with the G3D ABI.

    There's quite a few people at AMD that know way more about their drivers, their customers and their markets than we do. If it would solve their problems, they'd already be doing it
    Didn't mean to come across as arrogant or anything, your entirely correct in what you say. I'm just curious from a hypothetical perspective if the above approach would be feasible.

    Leave a comment:


  • rohcQaH
    replied
    Fglrx already uses a framework similar to G3D internally. They wouldn't gain much from switching over. They could re-use G3Ds state trackers... but they already have their own, so why replace them?

    Switching to G3D might make sense if AMD could use G3D for both their linux and their windows drivers. But I doubt that's going to happen soon, G3D isn't mature enough yet. But even if it was, I'm sceptical that the initial costs would ever pay off.

    Besides, G3D doesn't magically solve the problem of kernel and xorg ABIs.


    There's quite a few people at AMD that know way more about their drivers, their customers and their markets than we do. If it would solve their problems, they'd already be doing it

    Leave a comment:

Working...
X