(03-02-2016, 02:11 AM)vlj Wrote: You're confusing read/write buffer with raster ordered view which is a dx12 features (used to synchronise pixel shader execution on the same pixel to implement correct transparency).

Read/write buffer refers to the synchronisation of data between rsx emulation thread and the rest of the emulator. There is often an option in emulator like "frame buffer location" or efb potion in dolphin.

On PC the gpu is drawing things in memory which is separate from the application memory. However on console this is not the case and the gpu is able to draw anywhere in memory, and cell is able to read rsx memory (albeit slowly).
This means that for accurate emulation rpcs3 would have to issues a lot of image transfer from opaque gpu memory to visible memory and this is obviously costly (no game would run at more than a single digit fps).
Read/write toggles allows to bypass such copies. Since almost every rsx produced data are never used by cell this doesn't break a lots of game at the moment.

On the other hand Vulkan might (but that's completely optional and depends on the driver) support a feature that is likely to help rsx memory management corner case : linear tiling for render target and sampled texture. Dx12 doesn't support this at all (actually dx12 is only exposing the common subset of feature that a Vulkan capable card can support) and it's quite difficult to work around.

(03-03-2016, 01:31 AM)vlj Wrote: There is no vendor specific extension for Vulkan right now (well actually there's nv_glsl_shader but it's not exposing an hw feature, it's rather a port simplification things).
However Vulkan can query for some device specific feature like available memory type, queue, format tiling support,... And the app is responsible for not using a feature if not present (opengl mandated the driver to emulate it on the other hand). See http://vulkan.gpuinfo.org/listfeatures.php
I don't know if conservative raster is exposed by Vulkan, I didn't find something related atm.

I don't understand what is called rw texture in the link you gave. Image load and store are part of opengl since 4.2. It allows to write to image which is a texture without sampler bound to it. I think it's still possible to sample a texture bound as an image but I never tried. It would involve carefully synchronisation though.

BTW as a loosely related note : Nvidia Rov (rastered ordered view) are exposed as a feature enabling fast programmable blending/order independent transparency but in fact programmable blending and order independent transparency requires a way to write several concurrent pixel shader output coming from a single pixel. Dx11 and opengl 4.0 introduced a synchronisation primitive, atomic counters, which allows that and that's why there are dx11 demo featuring order independent transparency.
Unfortunately Nvidia and Intel gpu atomic counters support are slow (I mean, really slow) so Intel introduced PixelSync which is more less a mutex on pixel. Nvidia followed the same idea with the raster ordered view feature and got it standardized in dx12.
But on Radeon atomic counter are fast enough to enable their usage in order independent transparency scenario and even more complex ones. So while they don't support rov they can still support programmable blending.
Of course both atomic counter and rov incur an overhead over "vanilla" pixel shader execution.