On Wednesday 04 January 2006 06:52, martin wrote: > I'm glad to hear that :) > > now would it be possible to move the graphics rendering from X11 methods to > XV methods ? is my assumption right that i should just write an > minimalistic extra glx with callbacks to Xv methods to make it possible ? > or is the mesa api deeply stuck in the X11 method calls ?
If you're trying to accelerate software GL, Xv is totally the wrong way to go. Xv is only useful for getting YUV->RGB colorspace conversion and scaling done on the hardware instead of in software. There are two ways you can use Mesa in a pure software configuration. The first is to build libGL as a software renderer, which is what the non-dri make targets will do. We'll call this "Xlib mode". In this mode Mesa fakes the GLX protocol internally, rendering to an XImage that is pushed to the server periodically via XShmPutImage. All rendering is done on the client side in host memory. The other way is to use indirect GLX; ie, build libGL to emit GLX protocol (which all the dri make targets do) and push GLX protocol to the server, which then handles the rasterisation. We'll call this "GLX mode". This is usually slower right now for cards with DRI enabled, because in order to get some rather uninteresting correctness bits correct, the depth buffer _has_ to be located in video RAM, and CPU read access to video RAM is slow. However for non-DRI setups, this is approximately the same performance as Xlib mode. GLX mode is occasionally less featureful than Xlib mode, because not all the features Mesa supports have their GLX protocol implemented. GLX mode is also a rather aggressive thing to ask the server to do, such that X interactivity suffers a bit. One potentially interesting method of partially accelerating GL - for cards where we know very little about the 3d engine - would be to implement a "stub" DRI driver that's only smart enough to do DMA uploads to the card. You'd do all your rasterisation in software in host memory and then DMA the result up to the card on glXSwapBuffers. This might or might not be a win. There's incremental stages past this too, eg the 3dfx cards have an alpha combiner that can be activated even for CPU-driven writes to VRAM, so you could potentially rasterise in software directly to the card, letting the card handle the alpha combination, and then do a card-to-card blit on SwapBuffers. I suspect the effort would be better spent reverse-engineering the card's 3d engine though. - ajax
pgptTCTVpdZgG.pgp
Description: PGP signature
