Announcement

Collapse
No announcement yet.

What You Need To Know About SPIR-V 1.0

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

  • #11
    Originally posted by erendorn View Post

    Sorry if I misinterpreted your post. I based my understanding on your conclusion ("Point, don't expect miracles and understand Vulkan wasn't meant to replace OpenGL and in there future probably new revisions of OpenGL will come simply because they server 2 different needs and markets"), which clearly talks about consumming the OpenGL API in applications, and not about providing an OpenGL API on a given platform.
    Your analogy was also very confusing, suggesting "using C as a high level language instead of Python", whereas Gufide is suggesting "Implementing a Python interpreter in C for platforms that don't have yet a working native Python interpreter, on the basis that C compilers will be availlable for more platforms so that python can be used as a high level language on these platforms".

    The fact that Mesa exists supports the claim that a decent part of OpenGL is not driver specific and can be implemented and shared on top of lower level stuff.
    Similarly, it supports the claim that non vendor supplied OpenGL implementations are needed.
    One issue in Mesa is that there was no common low level stuff to target. So Mesa currently only works with specific drivers. The question is, is Vulkan capable and low level enough to be considered as a valid backend in this case? This would certainly simplify the IR/GSLSL stuff, and enable more platforms (since Vulkan support is expected to be better and more widespread than full OpenGL and OpenCL and OpenWhatNot support).

    I'm not knowledgeable enough, but it isn't clear in your post that you are responding to that.
    Ok, let me try again is a more compact way

    1.) can vulkan be low level enough to write OpenGL on top of it? Not sure yet but should be doable(see it as TGSI 2.0 for practical purposes)
    2.) will it improve performance across vendors or OSes? No, realistically will probably be slower since is very likely will need very ugly(as terribly slow) hacks to comply to the specs
    3.) Ok, wouldn't make Mesa faster at least? No, quite a lot mesa code is actually needed to implement vulkan(can be done from scratch too tho, it will depend i guess) and gallium is close enough to vulkan to make it an act of insanity (mesa internals are lower level than vulkan btw)
    4.) Why OpenGL is slow then and all implementations are somehow different? because the algorithm and design are generic enough to be doable in any GPU but are not necessarily hardware side efficient but is broad enough to allow driver vendors to "Interpret" the spec implementation.
    5.) if OpenGL on top vulkan existed today, you think Vendors will use it? nope, simply because their implementation will always be more efficient for their hardware(even if it break the spec) and contain lots of "secret sauce"(benchmark optimiser, yeah everybody do this) and "Extra features"(that is a legal enough term for "vendor locking" aka GameWorks) that they will not ever will either release or allow publicly in any generic form(will trigger a legal sue hell thunder dome court crisis worldwide)
    6.) Ok, will it be better than current mesa at least? most likely barely or the same, simply because the implementation of mesa is not "slow(er)" is just strictly close to the specs and doesn't contain hardware/application micro optimisations(and the compiler side still need some work, this will apply to vulkan too probably)
    7.) Will be of any practical use this implementation? surprisingly yes, Kronos could use it as a generic SDK reference implementation(i doubt they would do so tho, is a massive lot amount of work)

    As a side note 2 corrections:

    1.) The OpenGL specification is driver agnostic(because is an specification), OpenGL driver is hardware specific and this is true for vulkan too. So in this sense Mesa provide libgl.so(OpenGL specification driver independent code) and the drivers(probably vulkan too) because again mesa is strict on the spec and serve several hardware providers, in the case of BLoBs they can micro optimise as much as they want all around

    2.) the expensive part of OpenGL is not actually related to the IR and conversions but is actually the safety and state handling of the static side and the compiler on the GLSL side, which is still slow with vulkan too btw, but vulkan put the compiler on user space so it doesn't matter anymore

    Comment


    • #12
      Originally posted by jrch2k8 View Post

      Ok, let me try again is a more compact way

      1.) can vulkan be low level enough to write OpenGL on top of it? Not sure yet but should be doable(see it as TGSI 2.0 for practical purposes)
      2.) will it improve performance across vendors or OSes? No, realistically will probably be slower since is very likely will need very ugly(as terribly slow) hacks to comply to the specs
      3.) Ok, wouldn't make Mesa faster at least? No, quite a lot mesa code is actually needed to implement vulkan(can be done from scratch too tho, it will depend i guess) and gallium is close enough to vulkan to make it an act of insanity (mesa internals are lower level than vulkan btw)
      4.) Why OpenGL is slow then and all implementations are somehow different? because the algorithm and design are generic enough to be doable in any GPU but are not necessarily hardware side efficient but is broad enough to allow driver vendors to "Interpret" the spec implementation.
      5.) if OpenGL on top vulkan existed today, you think Vendors will use it? nope, simply because their implementation will always be more efficient for their hardware(even if it break the spec) and contain lots of "secret sauce"(benchmark optimiser, yeah everybody do this) and "Extra features"(that is a legal enough term for "vendor locking" aka GameWorks) that they will not ever will either release or allow publicly in any generic form(will trigger a legal sue hell thunder dome court crisis worldwide)
      6.) Ok, will it be better than current mesa at least? most likely barely or the same, simply because the implementation of mesa is not "slow(er)" is just strictly close to the specs and doesn't contain hardware/application micro optimisations(and the compiler side still need some work, this will apply to vulkan too probably)
      7.) Will be of any practical use this implementation? surprisingly yes, Kronos could use it as a generic SDK reference implementation(i doubt they would do so tho, is a massive lot amount of work)

      As a side note 2 corrections:

      1.) The OpenGL specification is driver agnostic(because is an specification), OpenGL driver is hardware specific and this is true for vulkan too. So in this sense Mesa provide libgl.so(OpenGL specification driver independent code) and the drivers(probably vulkan too) because again mesa is strict on the spec and serve several hardware providers, in the case of BLoBs they can micro optimise as much as they want all around

      2.) the expensive part of OpenGL is not actually related to the IR and conversions but is actually the safety and state handling of the static side and the compiler on the GLSL side, which is still slow with vulkan too btw, but vulkan put the compiler on user space so it doesn't matter anymore
      ok clearer, thanks.

      Comment


      • #13
        Originally posted by erendorn View Post
        He is saying that OpenGL implementation itself could be built upon Vulkan, regardless of the underlying driver.
        I guess it is possible. Just like DX -> GL translations, etc. But what is the benefit? In case of DX to GL benefit was the ability to hook advanced game engine to GL without writing plenty of new code. But in this case it is lower level things and far more demanding. It is probably doable, but hard and takes resources. Gain isn't exactly obvious: these days we have opposite scenario where drivers have GL but no Vulkan so far. I can imagine it can be way to go for exposing GL on Vulkan-only driver, but it can turn out it can be better idea to use other layers (gallium, drm/kms & own custom stuff directly on top of it, etc).

        So only the vulkan implementation would be driver specific, but Vulkan is expected to be much easier to implement much less quirky driver side.
        So far pre-existing drivers had their own GL implementations. And I guess they are not going to be fond of idea to discard code and rewrite it from scratch without any reasonable gain. For new designs... hm, maybe, but there could be better ways to do it as well, depending on what devs want from low level layer. E.g. are you sure it would work better than using Galium or building on top of DRM/KMS directly?

        Basically, mesa (or something else) could do this and mecome driver independent.
        Uhm, I guess most driver-independent thing is stuff like llvmpipe. It works even without GPU at all. But there is some nasty catch...

        Comment

        Working...
        X