Bug 5147

Summary: r300EmitWait emits a wait that's less strong than we want
Product: Mesa Reporter: Eric Anholt <eric>
Component: Drivers/DRI/r300Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: alexdeucher, z3ro.geek
Version: git   
Hardware: Other   
OS: FreeBSD   
Whiteboard:
i915 platform: i915 features:

Description Eric Anholt 2005-11-24 21:17:16 UTC
While looking into an issue that this report ended up being unrelated to, I
noticed that r300EmitWait handling is bad.  Assuming the r300 is like the
previous Radeons (which the limited specs, and the fact that it's the same
register and values as previous Radeons suggests), we need to be doing
_IDLECLEAN, not _IDLE.  The issue being that the caches for the different
pipelines are not coherent, so you need to flush when switching which one is
active.  I don't think there's any circumstance where we would want to do plain
_IDLE, so we should probably change it back to be like r200's interface to these
regs.  If this is an issue, it would manifest as small rendering glitches with
active texture uploading, most likely.
Comment 1 Oliver McFadden 2007-02-02 08:03:56 UTC
This has already been done in DRM commit 74ef13fd009b9e37956e4207d0a5ed92f4b5e39a (a merge commit) 
Comment 2 Alex Deucher 2007-02-15 22:41:13 UTC
(In reply to comment #1)
> This has already been done in DRM commit
> 74ef13fd009b9e37956e4207d0a5ed92f4b5e39a (a merge commit) 
> 

That doesn't look right to me.
Comment 3 Oliver McFadden 2007-02-15 22:55:10 UTC
It's possible there are still IDLE's that need to be replaced with IDLECLEAN somewhere... Maybe this could be the cause of some of the r300 lock up's.  Although it's kind of a fuzzy issue as to whether these are actual lock up's or not...  Anyway, someone with more r300 knowledge should probably take a look at this. 
Comment 4 Maciej Cencora 2009-06-07 17:46:58 UTC
Closing as fixed
Comment 5 Adam Jackson 2009-08-24 12:23:37 UTC
Mass version move, cvs -> git

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.