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.
FWIW, I've sort of tried it out and it worked actually better than I thought it would (no second monitor at hand, simply included a virtual line with size 2560x1600 and allowed dri to initialize). glxgears worked just fine in a small window, but I thought bad things would happen if the size is increased beyond 2048 horizontally - instead it just seemed to chop off that extra bit (so with a window size of 2400 it would just render the left-most 352 pixels). So it seems it can live with a large pitch just fine, so you wouldn't need any of that incredibly clunky multi-buffer stuff. Just render to the same buffer twice. 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
