NVIDIA's List Of Known Wayland Issues From SLI To VDPAU, VR & More

[oiaohm]

Here it is stated that vulkan is based on explicit syncronization.
https://lwn.net/Articles/814587/

https://themaister.net/blog/2019/08/14/yet-another-blog-explaining-vulkan-synchronization/

Implicit memory ordering – semaphores and fences

Semaphores and fences are quite similar things in Vulkan, but serve a different purpose. Semaphores facilitate GPU <-> GPU synchronization across Vulkan queues, and fences facilitate GPU -> CPU synchronization.

These objects are signaled as part of a vkQueueSubmit. However, one very important thing to note about semaphores and fences is how they interact with memory. To signal a semaphore or fence, all previously submitted commands to the queue must complete. If this were a regular pipeline barrier, we would have srcStageMask = ALL_COMMANDS_BIT. However, we also get a full memory barrier, in the sense that all pending writes are made available. Essentially, srcAccessMask = MEMORY_WRITE_BIT.

https://www.khronos.org/blog/underst...ynchronization In long is at Khronos.

The reality is Vulkan has both explicit syncronization. and implicit syncronization.

Note that one of the Vulkan implicit syncs is called fences guess what dma_fence in the Linux kernel on dmabuf lines up with.

Basically that write-up you are point to is in fact faulty not based on what is in the Vulkan specification. Yes Vulkan you are meant to have both implicit sync and explicit sync and able to use what one suites the problem best.

Vulkan is "Implicit and explicit sync together" and that is what need to be implemented for vulkan to work to specification. A pure explicit sync only graphical stack is not 100% Vulkan compatible. Do note the writeup lwn you were point to suggested at the end doing implicit and explicit sync together. It was not saying you could do explicit sync only as Nvidia developers are attempting to push.

Yes Ekstrand had miss in the spec of Vulkan that is valid to use implicit sync if developer of program wants to.

[MorrisS.]

https://themaister.net/blog/2019/08/14/yet-another-blog-explaining-vulkan-synchronization/

https://www.khronos.org/blog/underst...ynchronization In long is at Khronos.

The reality is Vulkan has both explicit syncronization. and implicit syncronization.

Note that one of the Vulkan implicit syncs is called fences guess what dma_fence in the Linux kernel on dmabuf lines up with.

Basically that write-up you are point to is in fact faulty not based on what is in the Vulkan specification. Yes Vulkan you are meant to have both implicit sync and explicit sync and able to use what one suites the problem best.

Vulkan is "Implicit and explicit sync together" and that is what need to be implemented for vulkan to work to specification. A pure explicit sync only graphical stack is not 100% Vulkan compatible. Do note the writeup lwn you were point to suggested at the end doing implicit and explicit sync together. It was not saying you could do explicit sync only as Nvidia developers are attempting to push.

Yes Ekstrand had miss in the spec of Vulkan that is valid to use implicit sync if developer of program wants to.

Thanks, So this means that a vulkan compositor supporting Wayland should guarantee enhanced compatibility among several kind of graphical hardware providing higher performance too because Vulkan is characterized by greater flexibility.

[oiaohm]

Thanks, So this means that a vulkan compositor supporting Wayland should guarantee enhanced compatibility among several kind of graphical hardware providing higher performance too because Vulkan is characterized by greater flexibility.

The reality is no. The reason why vulkan cannot work on some hardware is that the hardware does not support explicit sync.

This is the catch. Hardware that is explicit sync it possible if the developer of that hardware cooperates with the OS kernel developers in some form to have implicit sync done on top of explicit sync. Hardware that is implicit sync only you cannot do explicit sync on to of it just will not work.

Vulkan compositor will have enhanced features but more restricted compatibility with platforms. Yes some of your arm board GPUs are still implicit sync only in particular areas.

Remember arm boards you have the fun one that the graphical out and the GPU part processing openg/egll/vulkan effects are from two different vendors. KMS being implicit sync does match up to what the majority of the bit in control of output is in arm soc chips.

[MorrisS.]

The reality is no. The reason why vulkan cannot work on some hardware is that the hardware does not support explicit sync.

This is the catch. Hardware that is explicit sync it possible if the developer of that hardware cooperates with the OS kernel developers in some form to have implicit sync done on top of explicit sync. Hardware that is implicit sync only you cannot do explicit sync on to of it just will not work.

Vulkan compositor will have enhanced features but more restricted compatibility with platforms. Yes some of your arm board GPUs are still implicit sync only in particular areas.

Remember arm boards you have the fun one that the graphical out and the GPU part processing openg/egll/vulkan effects are from two different vendors. KMS being implicit sync does match up to what the majority of the bit in control of output is in arm soc chips.

Which hardware does not currently support expplicit sync? You stated that vulkan supports both the syncronizations.... so if explicit sync is not supported, implicit sync intervenes.

[oiaohm]

Which hardware does not currently support expplicit sync? You stated that vulkan supports both the syncronizations.... so if explicit sync is not supported, implicit sync intervenes.

If a GPU does not have explicit sync vulkan is not supported on it. This is why Vulkan cannot be implemented on really old GPUs and a lot of different embedded GPus cannot be used for vulkan because their memory design does not allow explicit sync and it operates under pure implicit sync. This is also why some arm soc chip GPU are only opengl with no vulkan.

But there is a worst case.

https://www.asrockrack.com/general/productdetail.asp?Model=M2_VGA#Specifications

This above is real in production video card. Zero Vulkan support, Zero opengl hardware support. Implicit sync only, 2d acceleration only. Silicon motion gpu in one of the common items you find in embedded platforms (soc chips) directly connect to output.

So yes there is implicit sync only hardware still around. Yes there is hardware where you have to cpu render opengl/vulkan because that hardware does not support opengl or vulkan and when you hit that hardware has implicit sync for the kernel mode setting stuff as it is implicit sync in the hardware as well.

But even with explicit sync hardware the CPU side also need implicit sync. Implicit sync implemented on top of explicit sync in the kernel allows the kernel to check something is in sync before switching to the application to get better cpu scheduler allocation of time.

So there are two implicit sync here.
1) Hardware forced implicit sync where the hardware you are using only has implicit sync and this hardware is still being made today.
2)Implicit sync implemented in kernel to allow waiting for sync application not wasting context switches and CPU the same reason why we have a futex for other stuff.

Fun part here is Nvidia under windows does not have to implement implicit sync in kernel space because Microsoft does that so Nvidia just have to provide a explicit sync interface and then Microsoft codes up there dx11/dx12 in kernel space implicit sync wrapper driver. Linux there is not a generic kernel space wrapper to go from explicit sync to implicit sync a few have suggested creating one.

Implicit sync is forced basically in two different ways.
1) we have hardware that is implicit sync only.
2) Getting the best CPU utilisation there are many cases where implicit sync fits better.

Of course we have futex locking that is really halfway between implicit sync and explicit sync in it function. So futex gets good CPU utilisation due to the wait being able to be done like implicit and high performance like explicit sync because of a lock is not contended you can take it straight away without a kernel call or waiting.

Something like a futex design has advantages. Lets say you have implicit sync only hardware and instead of vulkan explicit sync it was done futex style. You could just have on that hardware that the sync always responds as contended so the application will call the kernel wait function and function implicit sync. Now if the hardware is explicit sync if the sync is ready application gets a performance boost of not having to perform a kernel syscall.

Futex design gives you something halfway between implicit sync and explicit sync. And it something that can truly work with either.

The one major reason for Nvidia to push for everything to be explicit sync only means they will not have to work cooperatively in kernel space development.

[MorrisS.]

If a GPU does not have explicit sync vulkan is not supported on it. This is why Vulkan cannot be implemented on really old GPUs and a lot of different embedded GPus cannot be used for vulkan because their memory design does not allow explicit sync and it operates under pure implicit sync. This is also why some arm soc chip GPU are only opengl with no vulkan.

But there is a worst case.
https://www.asrockrack.com/general/p...Specifications
This above is real in production video card. Zero Vulkan support, Zero opengl hardware support. Implicit sync only, 2d acceleration only. Silicon motion gpu in one of the common items you find in embedded platforms (soc chips) directly connect to output.

So yes there is implicit sync only hardware still around. Yes there is hardware where you have to cpu render opengl/vulkan because that hardware does not support opengl or vulkan and when you hit that hardware has implicit sync for the kernel mode setting stuff as it is implicit sync in the hardware as well.

But even with explicit sync hardware the CPU side also need implicit sync. Implicit sync implemented on top of explicit sync in the kernel allows the kernel to check something is in sync before switching to the application to get better cpu scheduler allocation of time.

So there are two implicit sync here.
1) Hardware forced implicit sync where the hardware you are using only has implicit sync and this hardware is still being made today.
2)Implicit sync implemented in kernel to allow waiting for sync application not wasting context switches and CPU the same reason why we have a futex for other stuff.

Fun part here is Nvidia under windows does not have to implement implicit sync in kernel space because Microsoft does that so Nvidia just have to provide a explicit sync interface and then Microsoft codes up there dx11/dx12 in kernel space implicit sync wrapper driver. Linux there is not a generic kernel space wrapper to go from explicit sync to implicit sync a few have suggested creating one.

Implicit sync is forced basically in two different ways.
1) we have hardware that is implicit sync only.
2) Getting the best CPU utilisation there are many cases where implicit sync fits better.

Of course we have futex locking that is really halfway between implicit sync and explicit sync in it function. So futex gets good CPU utilisation due to the wait being able to be done like implicit and high performance like explicit sync because of a lock is not contended you can take it straight away without a kernel call or waiting.

Something like a futex design has advantages. Lets say you have implicit sync only hardware and instead of vulkan explicit sync it was done futex style. You could just have on that hardware that the sync always responds as contended so the application will call the kernel wait function and function implicit sync. Now if the hardware is explicit sync if the sync is ready application gets a performance boost of not having to perform a kernel syscall.

Futex design gives you something halfway between implicit sync and explicit sync. And it something that can truly work with either.

The one major reason for Nvidia to push for everything to be explicit sync only means they will not have to work cooperatively in kernel space development.

ok consider that GTK4 has introduced hardware acceleration I don't know about Qt). Based on what you claim it is necessary to divide legacy software for legacy hardware from modern software for modern hardware, otherwise modern hardware is penalized. The Os installation mechanism has to make a diagnose on hardware before the Os is installed proceeding for the choice between the two alternatives. A bit like when Ubuntu installation checks if an NVidia card is used in order to prevent the graphical environment from applying Wayland stack.

[oiaohm]

ok consider that GTK4 has introduced hardware acceleration I don't know about Qt). Based on what you claim it is necessary to divide legacy software for legacy hardware from modern software for modern hardware, otherwise modern hardware is penalized. The Os installation mechanism has to make a diagnose on hardware before the Os is installed proceeding for the choice between the two alternatives. A bit like when Ubuntu installation checks if NVidia card is used in order to prevent the graphical environment from applying Wayland stack.

That idea does not work long term. GTK4 hardware acceleration https://blogs.gnome.org/chergert/202...-ngl-renderer/ Yes they are keeping opengl backend. https://doc.qt.io/qt-6/windows-graphics.html same with Qt.

Divide between legacy and modern hardware is not exactly possible. Do note the m.2 graphics card I pointed to

https://www.anandtech.com/show/13677/innodisk-launches-m2-graphics-card-with-4k-output

There are quite a few different makers of them. Yes some of them have hdmi and displayport out. These are advanced GPU they are not exactly legacy either. Turns out implicit sync need a simple memory management unit in the GPU. Yes that simple memory management unit uses less silicon.

This is really the split between cheapest GPUs you can buy and the more expensive ones with implicit sync vs explicit sync GPU. Problem is it is valid for you to have a M2 simple gpu in you system and be rendering on a more complex gpu. Yes using PRIME to sync between the two.

Opengl applications that function on implicit sync is not going away either. Its not really possible to draw a clean line between modern and legacy. Because you might have modern hardware but you still will want to run legacy software. Yes people who have legacy hardware will want to be running modern software. This is why the toolkits for GTK and Qt have multi backends so applications can adapt when run.

You did not think that you could have legacy design GPU being a cheep one and a modern design GPU in the same system.

That one where Ubuntu has to disable Wayland stack when it detects Nvidia is more sign of Nvidia failure to provide features. Of course Ubuntu does not mention the different Nvidia X11 2d rendering issues basically this is picking the least broken with Nvidia and Ubuntu not fully working.

Horrible as it sounds we need a solution that you can have old gpus, modern cheap/simple gpus and modern more expensive and more complex gpus in the same system without having problems. Multi stacks is not a option here this is why there is so much push back against Nvidia explicit only idea.

[arQon]

QUOTE=oiaohm;n1327227]Opengl applications that function on implicit sync is not going away either.[/QUOTE]

True, but the number of those *ever* written, let alone still running, is probably small emough to count on one hand.

[oiaohm]

True, but the number of those *ever* written, let alone still running, is probably small emough to count on one hand.

You must have a very big hand as there is over 1000 games valve still sells on steam in that camp. But its the simpler games people don't benchmark much.

So it little more common of a corner case than one would think.