RPCS3 Forums
Alphakill - Printable Version

+- RPCS3 Forums (https://forums.rpcs3.net)
+-- Forum: Support & Issues (https://forums.rpcs3.net/forumdisplay.php?fid=17)
+--- Forum: Support (https://forums.rpcs3.net/forumdisplay.php?fid=18)
+--- Thread: Alphakill (/showthread.php?tid=174175)

Pages: 1 2 3 4


RE: Alphakill - vlj - 03-02-2016

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.



RE: Alphakill - Inue - 03-02-2016

(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.

Interesting if DX12 exposes only a subset then what about Vulkan because it only requires OpenGL 4.2 or are the majority of those hardware features in optional OpenGL vendor extensions? Does Vulkan have equivalent of https://www.opengl.org/registry/specs/NV/conservative_raster.txt
Regarding R/W textures are they supported by RSX? I know PS2's GS does and some Nvidia extension is needed to emulate that.

http://forums.pcsx2.net/Thread-Missing-Eyes



RE: Alphakill - vlj - 03-03-2016

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.



RE: Alphakill - Inue - 03-03-2016

(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.
How is ROV called in OpenGL and Vulkan is it shader interlock? https://www.opengl.org/registry/specs/ARB/fragment_shader_interlock.txt? I know there is https://www.opengl.org/registry/specs/INTEL/fragment_shader_ordering.txt
For programmable blending these extension can be used too
https://www.opengl.org/registry/specs/ARB/texture_barrier.txt
https://www.khronos.org/registry/gles/extensions/ARM/ARM_shader_framebuffer_fetch.txt
https://www.khronos.org/registry/gles/extensions/ARM/ARM_shader_framebuffer_fetch_depth_stencil.txt



RE: Alphakill - Inue - 03-16-2016

So now that Vulkan is merged how does it compare in the rendering features and performance to DX12 and OpenGL?