(09-14-2011, 12:30 AM)xstyla Wrote: where the hell the gs emulation is slow?! don't think so. I don't really see it. only big problem is the gs block memory and that format conversions and transfers or dependant sampling of textures.
Textures can be moved, be reinterpreted (cast) and be available only in low mipmap detail, for example.
The GS just has tons of ways to manipulate stuff in memory.
This requires a huge overhead in any typical texture cache design, as you have to update and handle all these (and more) cases whenever memory is accessed. This is so bad that in bad cases it may be faster to have no cache at all.
Then there's the 2 analogue outputs merging the GS can do.
This is simply not accessible on todays graphic cards / APIs so at best
we can try to emulate it. This is again slow and may get very complex.
Then there's the problem that games try to use the (real) GS efficiently, meaning they'll depend on the 48GB/s texture moving performance it offers.
Simply keeping those speeds up in emulation is going to be a major bottleneck.
I'm just writing about this from memory (Pseudonym and Gabest are the people knowing best about this) so it's likely that I'm leaving out even more problems here but yea, GS emulation will always be hard to do and it'll always be very demanding.