On Sunday 14 August 2005 16:59, Roland Scheidegger wrote: > Those are quite stiff requirements though. None of the old chips support > all of that fully. Especially ARB_texture_env_combine (or even the EXT > variant) could be tricky. I'm not sure what parts of it Xegl really > needs, but on something like the plain rage 128 (can't even do "normal" > GL_BLEND in all cases) you could probably easily end up with software > fallbacks most of the time. Or, take a look at the voodoo3 driver, which > has the most strange tex combine setup ever (confusing as hell, set up > very unobvious, it's unclear to me though if the hardware capabilities > are really exposed that strange, if the driver is written in an odd way > or if glide acts as an obfuscation layer). It has fixed setups for BOTH > texture environments combined! Hard to tell if it would support > ARB_texture_env_combine somewhat reasonably, the driver at least > certainly would need a rewrite in that area at least if it indeed does. > > And, of course, some otherwise not too bad chips like the g200 can't > even do multitexturing :-(.
The voodoo really isn't that weird, glide's just a pain. It may not be able to do all of texture_env_combine in hardware, but it does (or, can) alpha blend on normal framebuffer writes (both CPU-driven and blit-driven), so if you separate out the math for the various Render operations you can multipass it. Likewise I'm fairly confident that you can do at least the simple masked blends even on 1TMU hardware if you have render-to-texture functionality. That's easy enough to do in EXA, you just create the surfaces you'll need ahead of time during PrepareComposite. Doing that from GL requires FBOs or similar. Granted this is harder than just multitexturing, which is probably why no one's tried to do it yet. - ajax
pgpxp8rwgRi2P.pgp
Description: PGP signature
