--- Michel Dänzer <[EMAIL PROTECTED]> wrote: > > The comments regarding this code are a bit sparce and seem to imply > > that the support was added for clone mode. Mergedfb works > similarly to > > clone mode, however there are some differences; for instance if you > > have two heads side by side. 3D seems to work pretty well in > mergedfb > > mode, but there are a few little issues, > > Can you elaborate on these?
They are mentioned here: http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=276 but I'll elaborate. If you are running in mergedfb clone mode, and start an opengl app, the framebuffer on crtc1 shifts to the left a few pixels, as such the cursor does line up properly with where it should be. crtc2 is fine. closing the app and switching a away from the mode and then back fixes the shift. The other issue is that if you place a 3D app right between the two heads so half is on one head and half is on the other and then switch modes, crtc2 flickers badly and shows corruption almost like the sync is off. moving the app to one head or the other and switching modes then switching back again seems to fix it. > > > and I'm wondering if they need to be considered in the drm code > > (possibly for pageflipping). this snippet here seems like it might > > > need updating (radeon_state.c): > > > > RADEON_WAIT_UNTIL_3D_IDLE(); > > OUT_RING_REG( RADEON_CRTC_OFFSET, ( ( sarea->frame.y * > > dev_priv->front_pitch > > + sarea->frame.x > > * ( dev_priv->color_fmt - 2 ) ) & ~7 ) > > + offset ); > > OUT_RING_REG( RADEON_CRTC2_OFFSET, > dev_priv->sarea_priv->crtc2_base > > + offset ); > > > > ADVANCE_RING(); > > > > Should crtc2 take into account the sarea stuff that crtc1 does? > > No, dev_priv->sarea_priv->crtc2_base is supposed to take the CRTC2 > frame > position into account. The X server driver must set it correctly in > MergedFB mode, should be easy looking at the clone code. > > OK. I just checked for mergedfb and that does get set correctly in RADEONDoAdjustFrame() (same as clone mode). > > The other issue is how to add additional cliprects to make 3D work > for > > contexts larger than 2048x2048. Michel made this comment: - snip - > > > > what exactly is a cliprect? I've read over the FAQ and the source > and > > it seems to define a clipping region if you have overlapping > windows. > > In X terminology, a cliprect is a rectangular area which is visible. > This translates pretty well into the chip scissor registers. The DRM > basically does in pseudo-code: > > foreach ( cliprect ) { > write cliprect coordinates into scissor registers; > flush primitives; > } > Ok. > > I'm not sure I understand how this fits with the maximum size of > the 3D > > context. > > The scissor registers seem to be the limiting factor as they only > take > 12 bits for each dimension of size and position of the rectangle. so is there a limit to the number of cliprects you could use extend the size of a 3D window? I'm trying to understand how this would work. with the driver as it is now, if you create a single 3D window greater than 2048 in either dimension, it will only display up to 2048. now, again with the driver as it is now, if you displayed two 3D windows with a total size of greater then 2048 in one dimension would/should it work? like this for example? ------------------------------------------------- ---------------------- --------------------- | <- 2000 -> | | <- 2000 -> | | | | | ---------------------- --------------------- -------------------------------------------------- So can there be multiple 3D windows as long as the cliprect for each window is 2048 or less in any dimension? or does the total length of all cliprects have to be 2048 or less? I assume the former. > > > I assume each 3D context has some number of clip rects > > associated with it (at least one?). > > Exactly, in fact this is true for every window. > > > Does the cliprect define the 3D region? so basically, the code > would > > have to check the size of the 3D region requested and if it was > wider > > or taller than 2048, it would allocate an additional cliprect? > > Exactly. > Would this make rendering the 3D substantially more complicated since there are now more than one cliprects to consider for a single 3D window? how do cliprects interact with the overall 3D rendering for that window? Are cliprects just like a viewport into the output of the 3D engine (to put it simply)? > > I guess I can't quite see how all this is supposed to work > together. > > I know the feeling. :) You seem to be on the right track though. > > > Also what source files should I look in to mess with this? > > As I said above, I believe DRIGetDrawableInfo() in > programs/Xserver/GL/dri/dri.c to be the place. I'll take a look. Thanks for your help, Alex __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
