A couple of questions have come up in my mind as I've been looking throught the DRM code. In radeon_sarea.h, there is this line: int crtc2_base; /* for pageflipping with CloneMode */
I've also noticed references to crtc2 in the xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon*
tree.
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, 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? Sorry if this is a simple question, I'm still trying to get my mind around how all this 3D stuff interacts.
The other issue is how to add additional cliprects to make 3D work for contexts larger than 2048x2048. Michel made this comment:
--------------------
AFAICS the cliprects are generated in the X server dri module, in DRIGetDrawableInfo(). A rough plan would be:
* dri module: add support for maximum cliprect size and position,
and split the cliprects in DRIGetDrawableInfo() if necessary
* radeon driver (or any driver simlarly, for that matter):
* if we're dealing with the new dri module (detected via
module version or presence/absence of new symbols), set
the maximum supported cliprect size and position, and
disable the DRI if the framebuffer size exceeds 4096 (or
whatever the correct limit will be) horizontally or
vertically
* otherwise, disable the DRI if the framebuffer size
exceeds 2048 horizontally or vertically.
Of course, I'd first hack in support for splitting the cliprects to verify that it actually works as intended.
----------------------------
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.
That's basically it. The cliprect list is a list of non-overlapping 2D rectangles that define the region of a window which can be rendered into. A fully visible window will have one cliprect which matches the window size.
I'm not sure I understand how this fits with the maximum size of the 3D context.
A rendering context has a maximum viewport size (GL_MAX_VIEWPORT) but the window/canvas can be larger. Remember, GL contexts and windows/drawables are distincly different things.
I assume each 3D context has some number of clip rects associated with it (at least one?).
A context doesn't have clip rects. Windows have cliprects.
> Does the cliprect define the 3D region?
It defines the 2D region of a window which it's legal to render into (i.e. the OpenGL "ownership" test).
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?
Where does 2048 come from? There's no window size limits that I'm aware of. There is a GL viewport size limit, as mentioned above.
I guess I can't quite see how all this is supposed to work together. Also what source files should I look in to mess with this? I apologizer if I'm getting the terms mixed up.
The DRI drivers query the cliprect list for a window with the XF86DRIGetDrawableInfo() function (defined in xc/lib/GL/dri/XF86dri.c)
-Brian
------------------------------------------------------- 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
