Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Intel Talks About Their GPU Drivers, Wayland, Etc

  1. #11
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by eugeni_dodonov View Post
    I'd say because the current drivers, which are not based on Gallium, just work, and are being very actively developed, so there is not much point of switching to gallium just for the sake of switching to it .
    Thanks for your work and for answering, yet..

    Quote Originally Posted by smitty3268 View Post
    It's an extra layer in between the 2 layers they have written themselves. They have less control over it.
    But don't Intel invent their own directx, their own opengl, their own operating system yet?
    The question is important because they are tearing the every spirit of opensource development.

    They are making yet another graphics stack, like building own house on top of others. While the action is good, the effect on neighborhood is pretty disastrous.
    They are destroying gallium with each progress of own driver. If they don't need gallium, why won't they come up with points why gallium is bad, what should be changed about it (both organisationary or technically).

    Opensource is about cooperation - open code is only a requirement for it. When cooperation takes place(I didn't write complete acknowledgement, but cooperation), each company technology is boosted by synergy.
    Right now Intel' policy of ignorance poisons cooperation for sake of faster development - it would unavoidably cripple progress of others at some time in future.

    Quote Originally Posted by smitty3268 View Post
    They want to put all the shared code into their GLSL compiler, and have all the drivers hook directly into it. The fact that they've written all this code themselves is one of the main selling points for them.
    You don't sell open code, you sell your skills as professional and your ability to finish project (unavoidably with others).
    What is the reason for them to pick ignorance route ?, they sell chips, designs and licenses - not their open driver.

    Quote Originally Posted by smitty3268 View Post
    If they hooked into Gallium, they would have to work with other people's shared code there, and have another layer in between their driver specific code and GLSL compiler. They can't simply alter Gallium to fit their needs, because it's maintained by other people and organizations. If you've followed the Mesa mailing list, you'd see that they feel perfectly free to alter their GLSL compiler code in ways which cripple other drivers - something that wouldn't fly in gallium.
    This is not problem of Intel, it is a problem of Gallium's organization. Someone who actually sees them, is the right entity to step in and report them - as in first step in solving bug.
    As example: if Intel is not following the policy, or if *other people* do not follow the policy - they should be handled as special case and their variations should be placed in side-branches.
    If the deviation becomes so different (in functionality) as to be seen as collection of patches - RFC should be rised as of overtaking this modification as default against the current, rethinking the approach of the project (as in integrating the two version together) or, in rare case, starting a spin off(fork) - in case the difference due to the goals of each one results in complete different code.
    The disadvantages of synergistic cooperative development will be covered by absence of bugs, regressions, integration problems (Intel APU with AMD card, or VMWare machine - as example).

    Quote Originally Posted by smitty3268 View Post
    Plus, they don't really have a major manpower issue like the other drivers do, which means that one of Gallium's biggest benefits isn't as important to them as it is to other drivers.
    Why should be 100 vs 5 development faster, than 105(2) one?
    Copypasting code doesn't solve integration, inter-cooperation, redundancy and debugging issues.
    The idea of Gallium is that of cooperative development, no?

  2. #12
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by crazycheese View Post
    They are making yet another graphics stack, like building own house on top of others. While the action is good, the effect on neighborhood is pretty disastrous.
    I have to say that this is over-dramatizing things. There is much more "common Mesa code" than "common Gallium3D code" and the Intel devs have been good about (a) enhancing that code (eg new GLSL compiler) and (b) making sure the new code worked for other drivers, not just their own hardware.

    There are some downsides to not exposing a Gallium3D API (the obvious one being that you can't share "X acceleration over Gallium3D" code across HW vendors without it) but I think those are relatively small in the grand scheme of things.

    Quote Originally Posted by crazycheese View Post
    They are destroying gallium with each progress of own driver. If they don't need gallium, why won't they come up with points why gallium is bad, what should be changed about it (both organisationary or technically).
    This all happened a few years ago, and IIRC most people agreed with the issues they raised. My recollection was that most of the concerns were related to TGSI rather than the Gallium3D API, but the two do go together unless you want to define a new hybrid API. The Intel devs feel that GLSL IR is a better representation for passing to the HW drivers than TGSI or Mesa IR and I don't think anyone disagrees with that for graphics; the discussion is more around how big the benefits are, how well GLSL IR will work for compute, and whether it's worth changing IRs at this point. The answer to the last question seems to be a definitive "yes", although it's much less clear what the new IR should be.

    LLVM IR is on the table along with TGSI, GLSL IR, and the LunarGLASS framework built over LLVM IR which lets more of the HW-specific nasties be handled by common code than by HW-specific drivers. If you want to nitpick you could argue that we are going "off the reservation" as well by looking at LLVM IR rather than TGSI, but we're all "doing what we think is best" and discussing the pros and cons so that if there *is* a single solution we have a good chance of finding it.

    When we discussed this at XDC I think it's fair to say the consensus was "we don't know enough to pick one yet, let's try a few more things and see what works best". My guess is that once the IR discussions settle down you'll see some kind of hybrid "Gallium3D API plus whatever IR wins" become the standard for everyone.
    Last edited by bridgman; 12-03-2011 at 12:47 PM.

  3. #13
    Join Date
    Jun 2010
    Posts
    243

    Default

    Quote Originally Posted by bridgman View Post
    This all happened a few years ago, and IIRC most people agreed with the issues they raised. My recollection was that most of the concerns were related to TGSI rather than the Gallium3D API, but the two do go together unless you want to define a new hybrid API. The Intel devs feel that GLSL IR is a better representation for passing to the HW drivers than TGSI or Mesa IR and I don't think anyone disagrees with that for graphics; the discussion is more around how big the benefits are, how well GLSL IR will work for compute, and whether it's worth changing IRs at this point. The answer to the last question seems to be a definitive "yes", although it's much less clear what the new IR should be.

    LLVM IR is on the table along with TGSI, GLSL IR, and the LunarGLASS framework built over LLVM IR which lets more of the HW-specific nasties be handled by common code than by HW-specific drivers. If you want to nitpick you could argue that we are going "off the reservation" as well by looking at LLVM IR rather than TGSI, but we're all "doing what we think is best" and discussing the pros and cons so that if there *is* a single solution we have a good chance of finding it.

    When we discussed this at XDC I think it's fair to say the consensus was "we don't know enough to pick one yet, let's try a few more things and see what works best". My guess is that once the IR discussions settle down you'll see some kind of hybrid "Gallium3D API plus whatever IR wins" become the standard for everyone.
    Maybe Intel could openly say that they'll switch to Gallium if it's converted to use GLSL IR, instead of TGSI. I'm not a developer or graphics expert, but would it be a lot more work to maintain GLSL IR instead of TGSI after the initial upfront work is done to support it on other hardware? In other words, Would it take much extra work to create new drivers with it, like for new generations of hardware?

  4. #14
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by Prescience500 View Post
    Maybe Intel could openly say that they'll switch to Gallium if it's converted to use GLSL IR, instead of TGSI.
    The problem is that AFAIK there is no agreement from other driver teams to standardize on GLSL IR either, and in the very short term nobody (a) has time to drop everything else and work instead on establishing a common IR, or (b) sees standardizing IR as a particularly high priority anyways. I expect that by next XDC everyone will be in better shape to discuss standardizing IR -- right now we're all "in learning mode" to a certain extent.

    Quote Originally Posted by Prescience500 View Post
    I'm not a developer or graphics expert, but would it be a lot more work to maintain GLSL IR instead of TGSI after the initial upfront work is done to support it on other hardware? In other words, Would it take much extra work to create new drivers with it, like for new generations of hardware?
    The current stack essentially does that today. AFAIK the new GLSL compiler in Mesa generates GLSL IR no matter what HW driver is being used. The GLSL IR is then :

    - used directly by the latest Intel drivers (not sure if this is happening yet but AFAIK it's still the plan)

    - converted to Mesa IR for classic Mesa drivers other than the ones which directly use GLSL IR

    - converted to TGSI for Gallium3D drivers

    This obviously adds a tiny bit of overhead but since it only affects the initial compilation of GLSL shader source code it doesn't really affect application performance.

  5. #15
    Join Date
    Jun 2010
    Posts
    243

    Default

    Quote Originally Posted by bridgman View Post
    The problem is that AFAIK there is no agreement from other driver teams to standardize on GLSL IR either, and in the very short term nobody (a) has time to drop everything else and work instead on establishing a common IR, or (b) sees standardizing IR as a particularly high priority anyways. I expect that by next XDC everyone will be in better shape to discuss standardizing IR -- right now we're all "in learning mode" to a certain extent.
    That's what I gathered from what you said previously. I merely meant that they could "announce" it, not actually begin work on it. On the other hand, if it's not known exactly how it would be done or if there might be a better, 3rd alternative, then I guess waiting might be a better option. Still, as an enthusiast, it's nice to be able to follow developments and know all the latest stuff. Why else would people like myself follow Phoronix and it's forums?

  6. #16
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    I guess the question is what benefit would come from such an announcement ? I don't think any of the driver developers are particularly troubled by Intel staying with the classic HW driver API for now since Mesa supports both classic HW driver and Gallium3D HW driver APIs pretty painlessly.

    I don't think there is much being "lost" by the use of different APIs at this point. A year from now that might not be the case, as other state trackers start to mature, but by then I think everyone should be in better shape to discuss whether IRs (and hence driver APIs) can be standardized for both compute and graphics.

    We have had a number of internal discussions about IR options; we certainly aren't ready to say "hey we should all standardize on XYZ". We were able to build a consensus on what we we should try first, but that's about it. In other words, I don't believe that any of the driver teams know what they would ask the other driver teams to standardize on even if they *could* wave a magic wand and have everyone agree immediately.
    Last edited by bridgman; 12-04-2011 at 09:35 PM.

Posting Permissions

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