Announcement

Collapse
No announcement yet.

Zink Is Moving Closer To OpenGL 3.0 Support Over Vulkan

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

  • Zink Is Moving Closer To OpenGL 3.0 Support Over Vulkan

    Phoronix: Zink Is Moving Closer To OpenGL 3.0 Support Over Vulkan

    Zink was one of the Mesa/Gallium3D innovations that saw mainline status in 2019 for offering OpenGL support atop Vulkan hardware drivers. While an interesting approach, so far only the dated OpenGL 2.1 support has been exposed but the Collabora-led effort is closing in on OpenGL 3.0 capabilities...

    http://www.phoronix.com/scan.php?pag...-3.0-On-Vulkan

  • You-
    replied
    it would be interesting to see this added to mesamatrix.

    As for performance, I suspect the performance difference to be greater for the OpenGL1.x/2.x than later as those were generally mapped to fixed hardware functions and any intermediate layer would be slower than direct access. For Open GL3.x+, it will be interesting to see where they end up.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by Britoid View Post

    You're somehow implying each layer is adding some kind of performance overhead.

    They shouldn't add any, any performance slowdown is a bug.
    The vulkan layer has less context available to optimize things than the gallium layer does. Zink has that context, and will try to generate vulkan calls that are as optimized as possible, but it will never be entirely optimal the way that a native call directly to the hardware will be.

    At least not in all cases. For example, sometimes certain things are slow on certain hardware. A native OpenGL driver can go to great lengths to try to avoid such instructions on that hardware, while Zink is just generating standard Vulkan and won't know to avoid the slow calls. By doing the calls in Vulkan, it may explicitly require the vulkan driver to do the slow instructions, rather than allowing the driver options to choose some workaround that would end up being faster.
    Last edited by smitty3268; 01-05-2020, 10:26 PM.

    Leave a comment:


  • Britoid
    replied
    Originally posted by archsway View Post

    I'm not sure how OpenGL->Gallium3D->Vulkan->driver could be faster than OpenGL->Gallium3D->driver.
    You're somehow implying each layer is adding some kind of performance overhead.

    They shouldn't add any, any performance slowdown is a bug.

    Leave a comment:


  • betam4x
    replied
    Originally posted by log0 View Post

    Only if you don't mind having (in some cases massively) lower performance. Such layers will never be as fast as a native implementation.
    If DXVK is any indication, that is not necessarily the case. Depending on your hardware and software, DXVK on Linux/Wine can be faster than native DirectX 11 on Windows. Furthermore, DXVK on WINDOWS can be faster than DirectX 11. Alot of it comes down to the game, the ability to multi-thread, the core count of the CPU and number of execution cores on the GPU, the available vs used VRAM, etc.

    On my system I get around 20-30% faster performance on GTA V for instance, and several other titles either match or exceed (by small amounts) Windows/DX11 performance.

    EDIT: Though I do agree I don't see this project going very far unless they find a way to utilize threading to speed up OpenGL rendering.

    Leave a comment:


  • archsway
    replied
    Originally posted by geearf View Post

    Why would using Vulkan as intermediate API be inherently slower than using Gallium3D? Neither goes directly from OGL to native, and Vulkan is not higher level.
    I'm not sure how OpenGL->Gallium3D->Vulkan->driver could be faster than OpenGL->Gallium3D->driver.

    Leave a comment:


  • archsway
    replied
    Originally posted by Britoid View Post
    It'd be cool to see this eventually replace the OpenGL driver in Mesa.
    This is the OpenGL driver in Mesa, just with 10k lines of code for making Vulkan the backend.

    Leave a comment:


  • geearf
    replied
    Originally posted by log0 View Post

    Only if you don't mind having (in some cases massively) lower performance. Such layers will never be as fast as a native implementation.
    Why would using Vulkan as intermediate API be inherently slower than using Gallium3D? Neither goes directly from OGL to native, and Vulkan is not higher level.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by log0 View Post

    Only if you don't mind having (in some cases massively) lower performance. Such layers will never be as fast as a native implementation.
    Vulkan is pretty much as close to native as you can get for GPU's, its almost the equivalent for x86_64/32 for CPU's, the only thing lower would be GPU microcode.

    The whole point of Vulkan is it being a lower level driver that is portable amongst GPU's, the whole issue with the current situation is that API's like OpenGL/DirectX are very high level and don't give users that much control (they are also terrible when it comes to multithreading)
    Last edited by mdedetrich; 01-04-2020, 04:30 PM.

    Leave a comment:


  • Veto
    replied
    I guess the killer use case is virtualization. If the host exposes a virtual Vulkan hardware to the guest it can implement OpenGL and DirectX on top of that with Zink and DXVK. That would be much more versatile than e.g. the current Virgil approach.

    Leave a comment:

Working...
X