Maybe there somebody answer me... I have some questions about GS emulation. At first it's interesting to know how exactly GS emulation happend. Is there translation of GS draw calls and functions to some of OGL or it's more primary low-level hardware emulation. Is there fast EDRAM emulation issue or especially page buffers issue? it's huge amounts of bandwidth, but the render of frame go thru multiple passes so maybe do render in less passes could solve these problem, anyway how it's work? And what parts of GS pipeline could be ported to Compute shaders or OpenCL, maybe filtering, blending, it's even harder to do rasterisation on wide gpu simd blocks. Great thanks to all who's answer me
Sorry for my English, but I hope it's better than your Russian
You ask over compilcated question. There is EEuser and GSuser manuals for PS2, look at GIF transfers -- it's a way EE communicated with video, so we have a giftransfer functions that emulate this flow. We have 4Mb "videomemory" in emulator that allow to share textures and data between EE and GS thread. So when GS plugin collect all data needed to draw a scene, we just do it. It's not to easy, because graphic data of GS has different concept than OGL.
The most troublesome part is texture cashing -- PS2 dos not give exact place of memory for texture, and data stored in squeezed way. Sometimes 4Mb texture of PS2 could be used as 3-4 normal textures, and algorithm is not 100% successful (see Baldur gates or Star Wars: Force Unleashed). Even more, target handling could be overcomplicated because of manual erratas. And ZZogl use shaders at every possibility that allow parallel execution. For example PS2 have a wonderful trick to obtain a mosaic patterns (such as sky, floor, walls) -- it allow to place a minitexture on surface according to bitmask. At ogl we have no equvalent tricks at all, so we maintain a shader program for this.
So I do not see where OpenCL could be used, simply shaders is more than enough.
Quote:I WISH WE COULD JUST TARE APART A REAL PS2 GET THE SOFTWARE INSIDE IT AND PUT IT IN A PROGRAM!
Software is nothing, most troublesome part is hardware that do a real job here.
what about Sonic Unleashed,i see that some shaders are missing.I saw in the real game that parts are glowing(i think its texture highlighting).Like in the map of the world and The Sonic Model even at AA 16 the shaders are not shown.
but still this is a emulator.but is it possible to make the emulator suck more cpu and ram so i can have better fps. I really want it like that.Get a console said SEGA.Yeah right....
Quote:so we have a giftransfer functions that emulate this flow
Is it necessary emulate exactly 4 Mb of videomem? it's much transfers between cpu mem-->gpu mem, is there opportunity to hold all content of EE RAM in videomem to avoid texture streaming?
Quote:So I do not see where OpenCL could be used, simply shaders is more than enough
But as you say it's bandwidth limited too, so aren't OpenCL model of shared threads can help save some of it
Quote:what about Sonic Unleashed,i see that some shaders are missing
As i know all PS2 shaders execute in VU0 and VU1 vector units inside Emotion Engine, not in GS, so maybe it's emulator itself problem, but water shaders in FFXII and GOWII work fine
Quote:Is it necessary emulate exactly 4 Mb of videomem? it's much transfers between cpu mem-->gpu mem, is there opportunity to hold all content of EE RAM in videomem to avoid texture streaming?
Yes, of course. It's static pool of memory in PC memory -- stay here all of the time. And it is shared between EE thread and GS thread, no transfer is needed. Usuall PS2 games trick is to use all 4Mb memory to handle several textures at once (PS2 games authors use almost every dirty trick to gain 60FPS). But! PS2 textures stored in squeezed way, it means, that pixel storage order is not trivial. It's allow fastest way to read subtexture (as linear pool of data, in unsqueezed storgae X*Y texture contain Y pieces of 4*X bytes -- read this is slower than one continues 4*X*Y block of memory). So we MUST translate texture, at least when we resolving (put texture back in EE thread). Also pixel stored in non-trivial way (well, most used storage modes is CLUT -- with palletes). So we got a texture from EE thread (no time for this -- it's in PC memory at this time), decoding colors (if needed -- this part could be redone for better performance), unsqueeze (on shaders). If we need resolve it we store resulted one in new PC memory. Also we handle texture cache, which is the most slowest part now.
