Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=6637          
     
           Summary: r200 tcl flickering problems revisited
           Product: Mesa
           Version: CVS
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Drivers/DRI/r200
        AssignedTo: dri-devel@lists.sourceforge.net
        ReportedBy: [EMAIL PROTECTED]


The r200 driver (and IIRC to a lesser degree radeon too) used to have tcl
problems which often resulted in heavy flickering. This was solved somewhat a
long time ago by submitting the state atoms in a "proven by trial-and-error"
fixed ordering, though noone really knew why this would be necessary (nor
obviously what the order of the atoms should be). More recent investigations
however showed that fglrx does emit writes to 0x2284 before it writes to the
R200_SE_VAP_CNTL reg (and in turn it seems to emit the R200_SE_VAP_CNTL reg
quite often too), and (sometimes) before emitting tcl vector state. In fact, the
r300 driver indeed does that too. So I tried writing to that reg before any
access to the tcl vector state (same as what r300 driver does). This indeed
fixed all flickering problems even with an old user-space driver which didn't
have a fixed ordering of the state atoms (Mesa 5.0.2).
I'd be happy to really fix that, but even after some discussion on irc I
couldn't figure out WHEN this register in fact needs to be emitted. Emitting it
every time vector tcl space is accessed might be both overkill (accessed quite
frequently, could potentially hurt performance) and insufficient (what about tcl
scalar state, other vap regs). Currently without that patch there still are some
slight flickering problems sometimes (I can see them with a rv250 and nwn when
hyperz is active). I'm not sure the drm is the right place to do this (simpler
to patch, but maybe the drm can't really know when to emit it).
btw if you're wondering this doesn't seem to fix the lockups/crashes which seem
to be related to tcl - I've seen some of those drmRadeonIrqWait: -16 recently
too both with and without that patch, though only once every few hours of heavy 
use.
So I'd be happy if someone had some insight on when that reg should really be
emitted.          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to