* rsx: Refactor vertex clip emit to avoid using f64 unnecessarily
- Fixes driver crash on intel
* vk: Add NVIDIA driver version check
- Warn if user has outdated drivers with known problems
- Handle typeless src and dst with aliased typeless format
- Optimize typeless transfers by only dealing with affected texels.
* Eliminates redundant dst->typeless transfer of full image (very expensive)
* Eliminates full src->typeless transfer of full image and replaces with only affected region
* Requires significantly smaller output buffers, saving on VRAM cost
- Fix special case where n=f making (f-n) = 0
- Dynamically update depth range by setting dirty bits
- Fix depth bounds when n=f and bounds test is disabled
- Some texture accesses require image compositing steps to assemble the requested image from existing subresources.
Handle all the common routines in a unified manner to avoid having one broken path (e.g mipmap gather not supporting bitcast operations)
- Currently this conversion is being done on the CPU to reuse as much code as possible.
The expectation is that this almost never happens, so there is not point in increasing maintenance burden by adding compute paths
- Tracks which kind of raster was done (Z-ordered vs linear) throughout the application.
- This allows to identify if data is in the expected format or not.
- Ensure incoming texture is large enough that the original one fits inside it to avoid back-and-forth succession.
- Make use of the resource manager to remove the obsolete textures to avoid holding on to the them which "leaks" VRAM.
The memory isn't leaking, it's just wasting space in temporary pool until renderer is closed.
- Do not write to the texture until previous draw call is completed using it.
- This is usually not much of a problem until blending operations come into play.
- This option was always enabled for NVIDIA cards, but it seems some games would benefit from the option on other GPUs as well.
- TODO: Hwtest to verify correct behavior and plan how to safely implement in hw
- The bytes in these values are based on the format according to hw tests
- G8B8 is unaffected as the first two bytes are already G8B8 for A8R8G8B8 standard layout (BGRA)
- A8B8G8R8 and its derivatives have words 0 and 2 exchanged.
