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. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
