--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sat, 2003-07-12 at 00:24, Alex Deucher wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > > 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.
> 
> Sounds like bugs in the CRTC register handling, I suppose these only
> happen with page flipping enabled?

Yes this only happens when pageflipping is enabled.  swapping the order
of the crt2_base code in RADEONDoAdjustFrame() as you mention later
fixes the corruption on CRTC2 when you have pageflipping enabled and
you change modes, however, the framebuffer on crtc1 is still shifted a
few pixels to the left when you run an opengl app in clone mode.  side
by side modes work fine.  everything works fine with pageflipping
disabled.

One other issue, while I'm thinking of it, when you are using a side by
side mode in mergedfb, when the cursor is about 1/3 of the way across
crtc2, the cursor shows up on the far left side of crtc1, everywhere
else works fine.

> 
> 
> > > > 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).  
> 
> Hmm, can you try moving
> 
>       if (clone || info->IsSecondary) {
>           pSAREAPriv->crtc2_base = Base;
>       }
> 
> before
> 
>       if (pSAREAPriv->pfCurrentPage == 1) {
>           Base += info->backOffset;
>       }
> 
> ? Looks like the offset for page 1 gets added twice (here and in the
> DRM
> code above) for CRTC2.
> 

See comment above.

> 
> > > > 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?  
> 
> Theoretically no, in practice yes: as the maximum displacement of the
> scissor rectangle is equal to its maximum size (for Radeons), it
> doesn't
> make sense to make more than four cliprects out of one.
> 
> > 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?
> 
> That's what someone needs to find out. :) If that works, then the
> cliprect split trick should work as well.
> 

Alas, it doesn't work.  If run two apps side by side both display fine
up to 2048.  if you cross the 2048 boundry, the 3D window that crosses
it goes blank.  :(  looks like we may not be able to go above 2048 for
3D.


__________________________________
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

Reply via email to