![]() ZeroGS can only do a limited amount of work-arounds before compatibility starts dropping, so the only other option is to try to multithread the GS. The GS also has two different contexts which makes things twice as difficult. The GS doesn't suffer from such bottlenecks. In modern GPUs, it is advantageous to group as much geometry as possible in one draw call. This kills almost all caching techniques used by modern games because the GS and PC GPUs have very different performance bottlenecks. The GS plugin has to draw geometry in the same order as it was received. This unfortunately is not possible with Pcsx2 and the GS plugin. GPU optimization talks usually appear in every Game Developers Conference and there are many papers on them on the net, so there is a lot more to the story than written here.Īll this means is that single-threaded applications really need to design their GPU algorithms well to see fast frame rates. What kills games isn't sending geometry down the graphics pipeline, but it is when render targets are switched, render targets are used as textures in the next draw call, textures are locked, and when render targets are transferred from GPU memory to CPU memory (in the last case, the CPU not only goes to lunch, but has dinner also). The biggest challenge when designing games and hardcore applications that need to use the GPU to its full potential is to make sure that graphics driver stalls are minimal at all costs. The CPU just writes to the FIFO and the GPU just reads from it, this makes all the difference in terms of keeping the GPU active while the CPU isn't and vise versa. They also take advantage of FIFOs (first in first out buffers). They usually cache render state changes, shader changes, and texture changes up until actual geometry is rendered. Graphics drivers and libraries are aware of this and try as little as possible to communicate with the graphics card. During these stalls, the CPU basically goes to lunch until the GPU is ready. It isn't that the GS plugin itself does a lot of computation on the CPU, but the fact that it needs to communicate with the graphics card means that unnecessary stalls will occur in the graphics driver as the GPU and CPU are synchronized. It was apparent early on the project that the GS plugin was going to be a big bottleneck during 3D scenes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |