Announcement

Collapse
No announcement yet.

RADV Vulkan Driver Finally Adds VK_KHR_synchronization2 Support

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

  • coder
    replied
    Originally posted by oiaohm View Post
    Lets take GPU with like GPUDirect storage as in directly able to request data from a NVME/harddrive. So you ask for a descriptor it might be stored in the NVME instead of the GPU VRAM. Of course there is going to be major performance difference between something stored on the NVME/harddrive vs VRAM.
    Can you point to any sort of API reference which says it's even possible to do specifically that, or are you just making shit up?

    It seems to me that GPUDirect is just about enabling DMA transfers between GPU and storage - not actually putting GPU runtime state in nonvolatile memory on the NVMe drive. If you know differently, let's see some proof.

    Originally posted by oiaohm View Post
    https://www.nextplatform.com/2021/09...ory-hierarchy/
    CXL memory where it could possible to have multi CXL devices in system provide memory to the GPU.
    A memory hierarchy doesn't mean the memory will all be accessed in exactly the same way. Even when using directly-connected NVDIMMs, you don't treat them as if they're just more DRAM. Optane is the best NVDIMM tech we currently have, yet it's still an order of magnitude slower and has multiple orders of magnitude worse endurance than DRAM. If you blindly treated them like DRAM, system performance would crater and you'd be replacing the NVDIMMs of a system like every couple weeks.

    Originally posted by oiaohm View Post
    3) going forwards totally vram less GPU items will be possible. As in all ram provide by CXL modules and of course the system could have many CXL modules.
    That will never happen. GPUs are incredibly bandwidth-hungry. Even CXL 2.0 is down by an order of magnitude from what the latest GPU-like accelerators are getting from their HBM configurations. The point of CXL memory devices is to have a large pool of shared memory, but not to completely replace locally-attached DRAM.

    Originally posted by oiaohm View Post
    cl333r the reality is going forward memory has got a lot more complicated so its no longer just allocate tiny field you have to have enough structure to say where you really want that tiny field allocated as there are way more options where a GPU in future could be allocating that tiny field.
    I'm pretty sure what actually changed is that OpenGL tried to hide the details of GPUs' NUMA from the programmer, whereas Vulkan took a different approach of just exposing all the gory complexity for the programmer to manage.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by cl333r View Post
    Not an advanced user, I just completed "the vulkan tutorial" a few times and by far the worst thing I found about Vulkan is the over-engineered descriptor API. I was constantly asking myself - why is such a tiny field of GPU programming (descriptors take up very little memory) so overly complicated in Vulkan?

    PS: The descriptor = uniforms in OpenGL.
    Because it is more complex than it first appears.

    Practical guide to vulkan graphics programming

    A descriptor set allocation will typically be allocated in a section of GPU VRAM.
    You see this kind of statement in documentation around descriptors. But this is a rabbit hole statement. Descriptors take up very little memory is true. What makes it tricky is the typically be allocated in section of GPU VRAM that is not understood.

    Lets take GPU with like GPUDirect storage as in directly able to request data from a NVME/harddrive. So you ask for a descriptor it might be stored in the NVME instead of the GPU VRAM. Of course there is going to be major performance difference between something stored on the NVME/harddrive vs VRAM.

    There is more than just this either.
    The system world would have been a simpler place if InfiniBand had fulfilled its original promise as a universal fabric interconnect for linking all

    CXL memory where it could possible to have multi CXL devices in system provide memory to the GPU.

    Yes it use to be system ram and vram and that was it .
    Going forwards.
    1) we have system memory that may or may not be one piece. This is the NUMA problem
    2) We have vram that inside a GPU may not be a single allocation system. So a gpu that has like 2 descriptor sets because it has two completely different memory management units. Yes now NUMA problem inside gpu cards. Yes we had this problem a long time ago with multi GPU on single card but we never fixed that problem with opengl back then.
    3) going forwards totally vram less GPU items will be possible. As in all ram provide by CXL modules and of course the system could have many CXL modules.

    cl333r the reality is going forward memory has got a lot more complicated so its no longer just allocate tiny field you have to have enough structure to say where you really want that tiny field allocated as there are way more options where a GPU in future could be allocating that tiny field.

    Leave a comment:


  • cl333r
    replied
    Not an advanced user, I just completed "the vulkan tutorial" a few times and by far the worst thing I found about Vulkan is the over-engineered descriptor API. I was constantly asking myself - why is such a tiny field of GPU programming (descriptors take up very little memory) so overly complicated in Vulkan?


    PS: The descriptor = uniforms in OpenGL.

    Leave a comment:


  • FireBurn
    replied
    Finally? Making is sound like some urgent thing that's been delayed forever

    Leave a comment:


  • RADV Vulkan Driver Finally Adds VK_KHR_synchronization2 Support

    Phoronix: RADV Vulkan Driver Finally Adds VK_KHR_synchronization2 Support

    The Mesa Radeon Vulkan driver "RADV" has added support for the prominent VK_KHR_synchronization2 extension introduced earlier this year...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Working...
X