This is an interesting topic, it has never occured to me to offload effects code onto a GPU. As an end-user this would be a very nice feature to have. With some of the effects, I can't even get pacman to run fullspeed with both artwork and advance effects. Would it make sense to use the new effects with other X11 modes like DGA, or does it have to be opengl only? I know Hans has recently been working on the effects code, I'd be interested to read what his thoughts are on this.
Regards, Chris On Tue, 14 Dec 2004 01:45:54 +0000, Matthew Earl <[EMAIL PROTECTED]> wrote: > Having recently acquired a suitably powerful graphics card, I thought > it would be fun to have MAME do the scale2x resize effect through a > fragment shader. It started off as an exercise to learn how to write > GPU programs, but I quickly realised implementing the scale2x > algorithm off the CPU could be a desirable feature in an emulator such > as MAME: > > - Allows the CPU to spend most of its time actually emulating hardware > - Takes advantage of advanced graphics cards functions which for the > most part are unused when scaling algorithms are performed on CPU. > > Fragment shaders could also be used to implement other effects such as > rgb effects (scanline, pixel triad, etc) and possibly HQ/LQ resize > algorithms. RGB effects should be trivial to code very efficiently. > There are potential stumbling blocks with implementing the HQ > algorithm, because of the constraints of fragment programs and my > inexperience with writing them. > > By applying multiple effects, or the same effect many times, the full > set of effects available in xmame could be implemented on the GPU with > only a handful of fragment programs. For example, scale4x with a > scanline effect could be implemented by applying the scale2x FP twice, > and then the scanline FP. > > My proof-of-concept implementation of the scale2x algorithm works on > the xmame-0.88 source on top of the existing opengl code. Modification > to the actual source code was minimal; all that was required was the > fragment program be loaded with the rest of opengl initialisation, and > a single call to glProgramLocalParameter4fARB made at render time, to > pass parameters to the program. I have uploaded the fragment program > here: > > http://users.ox.ac.uk/~newc2303/scale2x.fp > > To work correctly, regular opengl bilinear filtering must be disabled. > > Functionally, the effect exactly mimics the CPU implementation of the > algorithm. As far as speed is concerned, I get 90fps compared with > 60fps, on a run through half a level of mslug, on my 1.9GHz P4/Geforce > 6800 GT (I would be interested to know if there are any more precise > benchmarking methods that people use). > > To allow multiple shaders to be applied at the same time, the opengl > driver could be modified to render one pass per shader. The first pass > would be rendered as normal. The remaining passes would then take the > previous pass as a texture, and render it applied to a quad filling > the screen. > > The scale2x algorithm on its own may not be particularly useful as a > GPU implementation; people with hardware capable of running fragment > programs most likely have CPUs capable of running a MAME emulation and > a scale2x resize. However, I suspect there will be a lot of people > whose computers fall into the category of not being able to run > scale4x or HQ algorithms on the CPU in real time, but have a graphics > card suitable to allow it to be run on the GPU (I myself fall into > this category). > > I would be interested in hearing what other people think about this: > Developers and end users. Would it be worth my time continuing and > attempting to implement the HQ algorithm and other effects? Should I > set about implementing my changes to the opengl driver so that it > neatly merges with the rest of the code? Implementing this algorithm > such that the fragment programs are used when in GL mode, and the > current effects code when in any other mode, seems sensible, but might > be difficult for me to do as I have little experience with the xmame > source. It could also be the case that my propositions would require > xmame to be restructured a little; is it the case that currently > opengl mode itself is implemented as a filter? This approach would > probably be incompatible with my changes. > > Looking forward to hearing what people think, > > Matthew Earl > > _______________________________________________ > Xmame mailing list > [EMAIL PROTECTED] > http://toybox.twisted.org.uk/mailman/listinfo/xmame > _______________________________________________ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
