Eric Anholt wrote: > On Sun, 2007-07-22 at 23:38 +0200, Roland Scheidegger wrote: >> Chase Douglas wrote: >>> I am writing because I would like to work on adding support for 3D >>> acceleration at resolutions large enough for a dual monitor desktop. >>> Unfortunately, though I have experience writing some kernel drivers, I >>> have no experience with writing X drivers, and very little background >>> (although I did take a 3D programming course focused on the opengl >>> pipeline). >>> >>> The theory goes that one could create a framebuffer for each monitor and >>> iterate over the framebuffers when doing operations. >>> >>> How can I start working on this? I can read code fairly well, but I >>> don't know where to begin. I assume some code between the intel X driver >>> and the mesa driver will have to split a screen into two framebuffers >>> and tell the mesa driver of this fact. Other than that, I have no clue >>> where the API functions reside in the code. If anyone can point me to a >>> general set of functions and briefly what they do, I believe it would >>> help immensely. >> You don't necessarily need to split the framebuffer into two pieces, you >> could do this without modifying the ddx code (except from allowing it >> dri to initialize), if you use private render buffers. Sounds simpler to me. >> Theory goes like this with private buffers: >> If your 3d window size exceeds 2048 pixels (in any direction), you'd >> need to create 2 (I don't think resolutions which would require 4 are >> possible) private buffers to render to instead of 1 (and 2 depth buffers >> too). Then whenever you have something to draw, you just send it twice >> to the hardware, (with different buffers, viewport adjusted etc.). You'd >> need to modify quite a bit of code to make that work correctly though >> (from non-rendering stuff like read/drawpixels to swrast fallbacks) >> currently. >> Then at swapbuffer time you'd just blit the two buffers to the >> framebuffer (the blitter has no trouble supporting large resolutions >> AFAIK) instead of just one. >> (private buffers are implemented in the i915tex_privbuffers branch, if >> you'd want to experiment with that - shameless plug...) > > The problem for us is that on the hardware with this limitation, we > can't scan out from bigger than 2048 in the X direction either. But > solving the 3D side of things would be the hardest step I think. Oh. Thought it's only a 3d limitation. I've actually never really looked at how the intel driver manages dual-head configurations and/or large resolutions. If it uses a fake framebuffer and does scanout just from a (possibly even rotated) copy, this should still work I guess (might get a bit slow with yet another copy...), if it uses 2 buffers for all drawing in the first place this would need some work. But yes, either way should be relatively straightforward compared to what you need to do at the 3d side.
Roland ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
