If anything, the new G13G seems roughly on par with a GTX 1050, but may be usable for so much more with the right programming. Perhaps the missing functionality that MoltenVK requires may be implemented this way without as much of a performance hit as the Intel Macs would have taken from doing main to/from GPU data shuffling? May be interesting to revisit this some day and see how things look with the new SoC GPUs, since they use unified memory, and support things like computing ray tracing paths in shaders in a single pass, something which is probably not relevant to this, but an example of what can be done with compute shaders. Without aliasing of heap contents, memory would have to be allocated for every used size and format combination, but arbitrary allocation in heaps lets us reuse the memory backing render targets and simply create views of it with different sizes and formats. Resource aliasing is great for render targets since they're transient on the Xbox 360 due to EDRAM. However, games don't necessarily use all those 512 megabytes for textures and vertex buffers, so it's better to allocate that buffer in smaller parts. I'm using a 512 MB buffer to emulate physical memory layout for texture untiling/tiling and vertex fetch because it increases performance (no need to maintain vertex caches) and accuracy (allows for weird render to texture cases, including horizontal predicated tiling). They are optional, but definitely help reduce video memory usage. Regarding the memory-saving features: I was talking about my Direct3D 12 renderer rewrite, but this applies to Vulkan as well. Xenos clear render targets by drawing a large rectangle, however, only 3 vertices are submitted, so we need to reconstruct another one in a geometry shader from the 3 vertices we have, after the vertex shader is done.

Xenia 360 emulator for mac