Announcement

Collapse
No announcement yet.

Vulkan 1.2.200 Released With Two New Extensions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    dark_sylinc
    Junior Member

  • dark_sylinc
    replied
    I forgot to mention something: VK_ARM_rasterization_order_attachment_access is not niche (but specific to TBDR GPUs, aka Mobile). And something I've been asking since day 0.

    It's nice to finally have it. Better late than never.

    Anyway, it's not an extension that dramatically changes how we make graphics through Vulkan (unlike OpenGL's era where vendor extensions that introduced shaders in the era of Fixed Function Pipeline was a total game changer), but it's more like a couple of lines of code to get access to GPU state I've always wanted to have to improve performance.

    Leave a comment:

  • dark_sylinc
    Junior Member

  • dark_sylinc
    replied
    Vulkan is reaching the point of OpenGL levels of fragmented extensions, except with a way more confusing versioning system. Can't wait for the Linux Vulkan drivers to fall behind the same way OpenGL did.
    Most of these extensions ARE implemented because the Linux drivers needed them (like this one for layers like Zink, or VK_VALVE_mutable_descriptor_type for emulating D3D12 on top of Vulkan). So I don't think so.

    Also it would be crazy to depend on VK_VALVE_mutable_descriptor_type because that extension basically is "whatever Proton needs", so any use outside that case could run into bugs.

    Also, these extensions are fairly specific for emulation layers. They're not meant to be used by most games or apps.
    Many of these extensions don't even make sense implementing them on Windows for example.

    The situtation with 2000-era OpenGL is different because developers would need a vendor extension to access basic state of the art GPU features while D3D9 was officially offering it out of the box.
    These Vulkan extensions instead are miscellaneous and niche.

    If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
    High/low level depends on where you're standing. For a microcode dev, even assembly language feels high level, let alone something like C. For a Python developer, C++ is already low level.

    Vulkan is very low level compared to D3D11 and GL, but it doesn't give direct access to the HW.
    Some parts were specifically left out because they're good defaults (e.g NDC range being [0; 1]) but turns out emulation layers need them (OpenGL uses the worse NDC range [-1; 1]).

    The same thing happened with Transform Feedback. It is terrible and nobody should be using it, so it was left out.
    But turns out you need it if you want to emulate OpenGL games that used it; and it is also useful for debugging (e.g. RenderDoc).
    Hence VK_EXT_transform_feedback was added.

    What we're seeing is just the result of tighter integration and coordination between drivers (Mesa with Intel & AMD) and user space SW (like Zinc or WINE/Proton) which is quite the opposite of the chaos that was in the 2000's and first half of 2010's.

    Leave a comment:

  • Daktyl198
    Senior Member

  • Daktyl198
    replied
    Vulkan is reaching the point of OpenGL levels of fragmented extensions, except with a way more confusing versioning system. Can't wait for the Linux Vulkan drivers to fall behind the same way OpenGL did.

    Leave a comment:

  • smitty3268
    Senior Member

  • smitty3268
    replied
    Originally posted by Rexerex View Post
    So those extensions don't implement any extra logic, only provide direct way to some underlying hardware circuit in graphics card that otherwise would be inaccessible?
    That certainly could be the case sometimes.

    I'm not completely sure exactly what this does, but from what I gather the driver programs the hardware to use certain coordinate ranges, and these ranges differ between GL and Vulkan (which matches what D3D expects). So Zink has to basically convert everything from one coordinate system that GL uses to another one the vulkan driver expects, which means everything is getting an extra calculation along the way. This extension will prevent that by making the vulkan driver (and hardware) expect the same ranges that the GL userspace in zink is providing.

    Take all that with a grain of salt, I'm not very familiar with that part of graphics systems.

    Leave a comment:

  • Quackdoc
    Senior Member

  • Quackdoc
    replied
    Originally posted by Rexerex View Post

    I think you totally misunderstand my question. If Vulkan is low level I imagine developers already has access to whatever graphic card is capable of. OpenGL implements extra abstraction layer of state machine over GPU so it is logical that if you want access some extra feature of GPU then it must be in OpenGL API.
    Nope, I didn't misunderstand. Again, think of vulkan as an ISA and and extensions the instructions. you still have to implement the instructions on the device. What an Graphics API does is act as a layer between some generic Graphics code, and the proprietary GPU code. Back the ISA analogy. you can add instructions to the set. but you still need the device to support it. so how do vulkan and gpus do this? Vulkan writes an extension. (Adds an instruction to the spec) that is either necessary, or optional. A gpu driver still needs to implement that extension. You cannot just program in that gpu's proprietary code, as it can differ even between gpus in the same family.

    As another analogy. think of OpenGL as C++, Vulkan as C (Or rust considering that it is still expanding), and GPU proprietary code as assembly. whiie you could in theory, program in GPU's proprietary code.

    Vulkan is a low level API, meaning it leaves a lot of work in the hands of the developer, but that doesn't mean you can just do what you want with the GPU's hardware, vulkan still needs to support it, and the GPU driver still needs to implement support.

    This should give you a general idea of how it works, obviously this isn't a great explanation, but the general idea stands.

    Leave a comment:

  • Rexerex
    Junior Member

  • Rexerex
    replied
    Originally posted by Quackdoc View Post

    Thats like asking if C is so low level, why does something need to be programmed in it. extensions are how VK work.
    I think you totally misunderstand my question. If Vulkan is low level I imagine developers already has access to whatever graphic card is capable of. OpenGL implements extra abstraction layer of state machine over GPU so it is logical that if you want access some extra feature of GPU then it must be in OpenGL API.

    Leave a comment:

  • Quackdoc
    Senior Member

  • Quackdoc
    replied
    Originally posted by Rexerex View Post
    If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
    Thats like asking if C is so low level, why does something need to be programmed in it. extensions are how VK work.

    Leave a comment:

  • Rexerex
    Junior Member

  • Rexerex
    replied
    Originally posted by smitty3268 View Post

    Emulating hardware in software will never be as fast as actually using the hardware feature directly.
    So those extensions don't implement any extra logic, only provide direct way to some underlying hardware circuit in graphics card that otherwise would be inaccessible?

    Leave a comment:

  • jacob
    Senior Member

  • jacob
    replied
    Originally posted by Rexerex View Post
    If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
    Because extensions are an integral part of the Vulkan design. It has always been the intention that all hardware-specific features would be implemented through extensions.

    Leave a comment:

  • skeevy420
    Senior Member

  • skeevy420
    replied
    Originally posted by Rexerex View Post
    If Vulkan is so low level why those things cannot be implemented efficiently without extensions?
    Because the default way Vulkan does depth range isn't efficient for OpenGL over Vulkan so that needed an efficiently implemented extension.

    Leave a comment:

Working...
X