Bug 497427 - Black rectangles for resized PNG in Firefox
Black rectangles for resized PNG in Firefox
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-23 16:39 EDT by Pete Zaitcev
Modified: 2009-10-14 10:49 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-14 10:49:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg (37.74 KB, text/plain)
2009-04-24 12:39 EDT, Pete Zaitcev
no flags Details
Xorg.0.log (44.66 KB, text/plain)
2009-04-24 12:39 EDT, Pete Zaitcev
no flags Details
xorg.conf (956 bytes, text/plain)
2009-04-24 12:40 EDT, Pete Zaitcev
no flags Details
Unrelated: bizarre artefacts in Xvideo (610.79 KB, image/jpeg)
2009-04-29 13:35 EDT, Pete Zaitcev
no flags Details
a modified rs690 tx clamp patch that seems to work (2.76 KB, patch)
2009-04-30 08:58 EDT, Hin-Tak Leung
no flags Details | Diff
src rpm - xorg-x11-drv-ati-6.12.2-12a.fc10.src.rpm (986.88 KB, text/plain)
2009-05-07 09:04 EDT, Hin-Tak Leung
no flags Details
gromobir's dmesg output (34.46 KB, text/plain)
2009-09-12 14:13 EDT, Lukas Brausch
no flags Details

  None (edit)
Description Pete Zaitcev 2009-04-23 16:39:24 EDT
Description of problem:

Firefox displays a black rectangle for a resized PNG image.

Version-Release number of selected component (if applicable):

firefox-3.1-0.6.beta2.fc11.x86_64
xorg-x11-drv-ati-6.12.2-5.fc11.x86_64

How reproducible:

100% on the given configuration

Steps to Reproduce:
1. Find a reasonably sized PNG image
2. Launch Firefox, open the image
3. Size the Firefox window so that the PNG image is downscaled
  
Actual results:

Black rectangle

Expected results:

Scaled image

Additional info:

This happened before, coincidentially exactly one year back in April 2008.
Sadly, I cannot find a specific bug.

The xorg-x11-drv-ati was updated in order to fix bug 493068. Try not
to unfix it, because the lockups are much more important than mere black
rectangles for some resized images.
Comment 1 Pete Zaitcev 2009-04-23 16:43:49 EDT
Hmm, apparently it comes and goes for various reasons, on different hardware.
https://bugzilla.mozilla.org/show_bug.cgi?id=411831
Comment 2 Hin-Tak Leung 2009-04-23 21:00:26 EDT
Ha, I seems to be stalking somebody - was going to file a bug or add a comment in bug 493068 . The symptom I see is that some icons on facebook and youtube are black.

firefox-3.0.9-1.fc10.x86_64
xorg-x11-drv-ati-6.12.2-5.fc11.x86_64
Comment 3 Hin-Tak Leung 2009-04-23 21:03:42 EDT
(In reply to comment #1)
> Hmm, apparently it comes and goes for various reasons, on different hardware.
> https://bugzilla.mozilla.org/show_bug.cgi?id=411831  

But I am using KMS without xorg.conf, so is doing EXA, and confirmed in Xorg.0.log.
Comment 4 Matěj Cepl 2009-04-24 05:32:03 EDT
Could I get /var/log/Xorg.0.log, /var/log/dmesg, and /etc/X11/xorg.conf (if any exists) from both you attached to this bug as uncompressed separate attachments here, please?

Thank you
Comment 5 Dave Airlie 2009-04-24 08:21:09 EDT
please try the latest package from koji, hopefully it continues to fix the original problem and also fix the regression.
Comment 6 Pete Zaitcev 2009-04-24 12:39:18 EDT
Created attachment 341208 [details]
dmesg
Comment 7 Pete Zaitcev 2009-04-24 12:39:56 EDT
Created attachment 341209 [details]
Xorg.0.log
Comment 8 Pete Zaitcev 2009-04-24 12:40:39 EDT
Created attachment 341212 [details]
xorg.conf
Comment 9 Pete Zaitcev 2009-04-24 12:41:59 EDT
xorg-x11-drv-ati-6.12.2-6.fc11.x86_64 fails too (currently latest in Koji)
Comment 10 Pete Zaitcev 2009-04-24 12:44:28 EDT
I was wrong about PNG in particular. Resized JPEG fails too. It's just
the way Libpr0n draws to X server in such case. BTW, you can see them
being loaded gradually, but once complete the image goes black.
Comment 11 Hin-Tak Leung 2009-04-24 14:55:25 EDT
xvideo is also broken. Which xvinfo shows some adaptors, trying to run any of the media players (mplayer/gmplayer/totem) gives a green window, while the audio goes on.
Comment 12 Hin-Tak Leung 2009-04-24 16:05:08 EDT
thr xvideo issue is new to 6.12.2-6, and reverting to -5 gets it back.
Comment 13 Hin-Tak Leung 2009-04-27 17:21:35 EDT
I just wonder if anybody can say how long the png problem has been - is it related to the fix to bug 493068? The fix only clamps texture data, so that must mean the texture data buffer or something like that contains both (1) other data that shouldn't be there, (2) refers to locations that aren't really data (hence the fix). Either way, it seems that one needs to examine what is actually being passed around as texture.

I am a little disappointed that Dave had reverted the bug fix both in koji and upstream (I started looking at xf86-video-ati git a few days ago). While the firefox png resize bug is more visible, I myself value stability more than not being able to see *some* (resized) images; and it was the bug fix that drew me from radeonhd (which also is affected by a similiar bug, but less often) and so I am running a mod of 6.12.2-7 (which fixes xvideo-related issue) with with a slightly mod-version of the -5 patch.
Comment 14 Hin-Tak Leung 2009-04-28 05:35:18 EDT
Tried 6.12.2-8.fc11 new on koji a few hour ago - sorry to report that it is sh*t, but I appreciate the effort nonetheless, I really do. 

When it is installed on my system, the screen just go completely black except the mouse pointer when X/gdm starts. The mouse pointer is responsive on the black background and so is ctrl-alt-f2/f3/f4/f5/f6, although the virtual console shows *nothing* (not even pointer) whatsoever. At that point, at least one can do control-alt-del to reboot cleanly. There is no other symptom in the X log, other than just one line at the end: 
 (WW) xf86CloseConsole: VT_WAITACTIVE failed: Interrupted system call
(this is probably from the ctrl-alt-del)

FWIW, other than the typo (which upstream seems to confirm), I think the first chunk of the older patch should be like this, instead of just the last line - and this is what I am using; doesn't not help the png problem, but it feels correct:

+	    if (unit != 0 || !info->accel_state->need_src_tile_x || !info->accel_state->need_src_tile_y)
+		txfilter |= R300_TX_CLAMP_R(R300_TX_CLAMP_WRAP);
+	    else
+		txfilter |= R300_TX_CLAMP_R(R300_TX_CLAMP_CLAMP_GL);
+

I have the ati rs690 register guide, I just don't quite get the meaning of S,T,R, repeatnormal, repeatpad, etc. Is there an intro somewhere about the 3 co-ordinates and repeat* and texture more generally?
Comment 15 Hin-Tak Leung 2009-04-28 19:49:09 EDT
Tried 6.12.2-9.fc11: the resized png problem on firefox web pages is gone, but xvideo is now scaled wrongly. I'll attach the screenshot of mplayer playing a movie with "-vo x11" and "-vo xv" for illustration in the xv to Bug 497755 . (which probably should depend on bug 492685); but others can just trying playing some movie with "-vo x11" (without acceleration) and "-vo xv" (with xvideo) and compare.

I looked at the -8 to -9 code change and there is no change in the tx clamp patch, but in the kms gamma patch, so that's probably the reason for the blank screen. The clamp patch seems to cause xvideo to scale movie display wrongly. Hope this helps.
Comment 16 Hin-Tak Leung 2009-04-28 20:25:58 EDT
I tried scaling the wrong screenshot to match the right screenshot, and it looks like the wrong one is wrong in the horizontal direction by about 1.5 and in the vertical direction by about 3 (a little less, ~ 2.8) . i.e. if you have a correct screenshot at 1024 x 768, it is as if the code somehow scale it up to 1536 x 1536 then clip to get only the top left corner of the enlargement.
Comment 17 Pete Zaitcev 2009-04-29 13:31:56 EDT
Confirmed problem gone with 6.12.2-9.fc11 (required kernel 2.6.29.1-111.fc11).

Xvideo is bust indeed, but that probably needs a new bug.
Comment 18 Pete Zaitcev 2009-04-29 13:35:54 EDT
Created attachment 341797 [details]
Unrelated: bizarre artefacts in Xvideo

It's not just scaled so that the upper left corner is visible, but
also produces strange artefacts when overlayed with menus.
Anyway, needs its own bug.
Comment 19 Hin-Tak Leung 2009-04-29 23:23:50 EDT
(In reply to comment #17)
> Xvideo is bust indeed, but that probably needs a new bug.

There are already two xvideo-related reports... one from the initial acceleration change I think, and another for the -5/-6 change... now xvideo is broken in a different way :-).

The png and xvideo issue are related..., my own priority is (1) do not crash/hang, (2) xvideo, (3) resized graphics in firefox .

So until the hang fix, I was using redeonhd, because it hangs less often (and I also needed nomodeset to have xvideo/dri - see redeonhd bug list); now I am using the ati/radeon driver, but I prefer to stay with 6.12.2-7.fc11 for the rs690 clamp fix plus the rest from -9, because xvideo is more important to me than resized graphics. Ok, if all graphics are gone I'll reconsider - or use seamonkey - which doesn't seem to be affected. I can live without a small amount of (resized) images.
Comment 20 Hin-Tak Leung 2009-04-30 08:58:13 EDT
Created attachment 341919 [details]
a modified rs690 tx clamp patch that seems to work

This patch seems to get both png and xvideo to work - I don't know how/why, but please consider packaging it and/or committing up stream.

The way I came to it is this: we know the hang can be fixed by texture clamp; there are two ways of clamping (-5) and (-9), one breaks resized png and one breaks xvideo. (hmm, their breaking are both related to scaling - "resized" png breaks, and xvideo seems to be scaled to a wrong size then clipped?). But the patch itself modifies two files, one mostly to do with display, the only with video. So I took half of one patch and join it with the other half of the other patch.

I don't know why this works, but it does.
Comment 21 Hin-Tak Leung 2009-05-06 03:03:09 EDT
-12 still broken, with latest mesa/kernel/xserver.

kernel-2.6.29.2-129.fc11                      Wed 06 May 2009 07:43:51 BST
kernel-headers-2.6.29.2-129.fc11              Wed 06 May 2009 07:43:33 BST
kernel-devel-2.6.29.2-129.fc11                Wed 06 May 2009 07:39:50 BST
kernel-doc-2.6.29.2-129.fc11                  Wed 06 May 2009 07:37:31 BST
kernel-firmware-2.6.29.2-129.fc11             Wed 06 May 2009 07:36:48 BST
mesa-libGLU-7.5-0.14.fc11                     Wed 06 May 2009 07:29:33 BST
mesa-libGL-7.5-0.14.fc11                      Wed 06 May 2009 07:29:32 BST
mesa-libGLU-devel-7.5-0.14.fc11               Wed 06 May 2009 07:29:30 BST
mesa-libGL-devel-7.5-0.14.fc11                Wed 06 May 2009 07:29:24 BST
mesa-dri-drivers-7.5-0.14.fc11                Wed 06 May 2009 07:29:18 BST
mesa-libGLU-7.5-0.14.fc11                     Wed 06 May 2009 07:29:16 BST
mesa-libGL-7.5-0.14.fc11                      Wed 06 May 2009 07:29:14 BST
mesa-dri-drivers-7.5-0.14.fc11                Wed 06 May 2009 07:29:13 BST
xorg-x11-drv-ati-debuginfo-6.12.2-12.fc11     Wed 06 May 2009 07:15:40 BST
xorg-x11-drv-ati-6.12.2-12.fc11               Wed 06 May 2009 07:15:38 BST
xorg-x11-server-Xvfb-1.6.1-11.fc10            Wed 06 May 2009 07:13:29 BST
xorg-x11-server-Xorg-1.6.1-11.fc10            Wed 06 May 2009 07:13:22 BST
xorg-x11-server-devel-1.6.1-11.fc10           Wed 06 May 2009 07:13:12 BST
xorg-x11-server-debuginfo-1.6.1-11.fc10       Wed 06 May 2009 07:12:35 BST
xorg-x11-server-common-1.6.1-11.fc10          Wed 06 May 2009 07:12:18 BST
Comment 22 Hin-Tak Leung 2009-05-06 03:28:22 EDT
replacing the rs690 patch in -12 with my mod patch (comment 20) seems to work fine. Consider taking it? Please?
Comment 23 Pete Zaitcev 2009-05-06 14:49:53 EDT
I cannot install -12 on my Rawhide system: there's an ABI conflict with exa
module and X fails to start (rpm -i completes fine, so there's some missing
Requires: somewhere). I don't know where Hin-Tak gets the packages
listed in comment #21, they aren't in Koji (let alone Rawhide).
So I'm on 6.12.2-9 for now. There are no black rectangles.
Comment 24 Yanko Kaneti 2009-05-06 16:07:26 EDT
-12 requires newer X server, works for me with 
xorg-x11-server-Xorg-1.6.1-11.fc11
http://koji.fedoraproject.org/koji/buildinfo?buildID=100806
Comment 25 Hin-Tak Leung 2009-05-07 06:41:05 EDT
(In reply to comment #23)
> I cannot install -12 on my Rawhide system: there's an ABI conflict with exa
> module and X fails to start (rpm -i completes fine, so there's some missing
> Requires: somewhere). I don't know where Hin-Tak gets the packages
> listed in comment #21, they aren't in Koji (let alone Rawhide).
> So I'm on 6.12.2-9 for now. There are no black rectangles.  

The rest are from koji, but I did 

rpmbuild --rebuild http://kojipkgs.fedoraproject.org/packages/xorg-x11-server/1.6.1/11.fc11/src/xorg-x11-server-1.6.1-11.fc11.src.rpm

to put it on F10. It is as somebody else commented, due to additional dependencies, I need to do rpmbuild --rebuild the server, but the rest of F11 bits seems to go onto F10 quite happily. 

If you want to try out comment 20, what I did was to rpm -i the src rpm (which puts the bits under /root/rpmbuild/{SOURCES,SPECS}), replace the patch, then run rpm -bb xorg-x11-drv-ati.spec
Comment 26 Hin-Tak Leung 2009-05-07 09:04:38 EDT
Created attachment 342835 [details]
src rpm - xorg-x11-drv-ati-6.12.2-12a.fc10.src.rpm

Just -12 with the rs690 patch replaced with
https://bugzilla.redhat.com/attachment.cgi?id=341919 - this is a src rpm and you are supposed to run rpmbuild --rebuild to generate the x86/x86_64 rpms for install. so it is called -12a .

Hope this is useful to sombody else. you can compare src rpm contents by extract it all (in a new empty dir):

rpm2cpio src.rpm | cpio --extract -m
Comment 27 Hin-Tak Leung 2009-05-08 22:37:34 EDT
I wonder if Bug 499930 ( firefox tooltips corruption https://bugzilla.redhat.com/attachment.cgi?id=343194) 
and some font encoding issue ( https://bugzilla.redhat.com/attachment.cgi?id=342629 ) are related - the two kind of corruptions seems to be affected by setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 in opposite way - one is caused by it and the other is cured/worked-around by it, I think.
Comment 28 Bug Zapper 2009-06-09 10:29:29 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Hin-Tak Leung 2009-07-03 01:33:44 EDT
I put -18 from koji on, and the problem persists. just replacing the 690-hack patch with attachment 341919 [details] works. Also, there is a small bug with the acceleration code that has been around for a while, and this is the fix:


 --- xf86-video-ati-6.12.2/src/radeon_textured_videofuncs.c~	2009-05-23 06:48:26.000000000 +0100
+++ xf86-video-ati-6.12.2/src/radeon_textured_videofuncs.c	2009-05-26 10:59:18.000000000 +0100
@@ -1604,7 +1604,7 @@
 	    }
 	}
 
-	qwords = info->new_cs ? 8 : 6;
+	qwords = info->new_cs ? 7 : 6;
 	BEGIN_ACCEL(qwords);
 	OUT_ACCEL_REG(R300_TX_INVALTAGS, 0);
 	OUT_ACCEL_REG(R300_TX_ENABLE, txenable);

------------
the png black rectangles can be seen on youtube or facebook; the acceleration code bug is faily harmless - without the fix, it just pumps lots of warning messages about some number being 14 and not 16 into Xorg.0.log, if one plays movies with mplayer.
Comment 30 Pete Zaitcev 2009-07-07 19:40:55 EDT
I don't know about Hin-Tak's system, but I did not see the black rectangles
in a while (currently xorg-x11-drv-ati-6.12.2-19.fc12.x86_64).
Comment 31 Hin-Tak Leung 2009-07-07 22:17:58 EDT
(In reply to comment #30)
> I don't know about Hin-Tak's system, but I did not see the black rectangles
> in a while (currently xorg-x11-drv-ati-6.12.2-19.fc12.x86_64).  

As I said, -18.fc11 still show black rectangles. There is a solution to my problem - the patch I attached to replace the latest rs690 tx clamp D Airlie includes in -18.fc11 ; I just don't know why it works. (I looked at 19.fc12, but it requires the newer bleeding edge X server headers).

There are a couple of black rectangles at the front of youtube (as guest, no account required), and a lot on facebook (account required). 

if it helps, here is the relevant part of lspci -vvv:
-----------
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device ff1a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f0000000 (64-bit, prefetchable) [size=128M]
	Region 2: Memory at f8100000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at 9000 [size=256]
	Region 5: Memory at f8000000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable-
		Address: 0000000000000000  Data: 0000
	Kernel driver in use: radeon
	Kernel modules: radeon
----------------
Comment 32 Arturs Kapins 2009-07-14 07:51:38 EDT
I recently upgraded Fedora 10 to 11 and got black rectangles instead of scaled images.

Until accelration code for ATI driver gets fixed my workaround is to put in xorg.conf section "Device" section:
        Option      "RenderAccel" "off"

------------ package versions -----------------------
xorg-x11-drv-ati.i586.6.12.2-14.fc11
xorg-x11-drv-radeonhd.i586.1.2.5-2.8.20090411git.fc11
radeontool.i586.1.5-5.fc11

------------ lspci -vvv output -----------------------
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller])
	Subsystem: Dell Device 0230
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 19
	Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 2: Memory at fe9f0000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at ee00 [size=256]
	Region 5: Memory at fea00000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable-
		Address: 0000000000000000  Data: 0000
	Kernel driver in use: radeon
	Kernel modules: radeon
Comment 33 Arturs Kapins 2009-07-14 08:34:57 EDT
Quote from one old Radeon driver manpage: http://ftp.x.org/pub/X11R6.9.0/doc/html/radeon.4.html
Option "RenderAccel" "boolean"
    Enables or disables hardware Render acceleration. This driver does not support component alpha (subpixel) rendering. It is only supported on Radeon series up to and including 9200 (9500/9700 and newer unsupported). The default is to enable Render acceleration.

This bug manifests only on downscaled images and i guess it's about subpixel rendering hardware acceleration.
Comment 34 Jason 2009-08-12 14:30:06 EDT
(In reply to comment #29)
> I put -18 from koji on, and the problem persists. just replacing the 690-hack
> patch with attachment 341919 [details] works.

I wanted to add that this patch seems to have resolved my black resized image issues. Thanks for posting!

DPMS still doesn't turn off my lcd unless I use the nomodeset kernel option but then X is unstable and will lock up at certain (frequent) times if I make use of that.

Also I wanted to add that the problem with the X display becoming a completely garbled mess still persists. A good way to make this happen is to go to google maps and do some zooming in and zooming out with the mouse scroll wheel. 

-----------------------------------------------------------------------------
$lspci -v
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 028c
        Flags: bus master, fast devsel, latency 64, IRQ 18
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at f0100000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at 9000 [size=256]
        Kernel driver in use: radeon
        Kernel modules: radeon

$uname -r
2.6.29.6-217.2.3.fc11.x86_64
Comment 35 Michal Schmidt 2009-09-04 09:42:38 EDT
I'm still seeing this problem in fully updated F11, ATI RS690M. It's trivially reproducible by zooming out a web page containing images in Firefox.

Dave, several people had success with the clamping patch modified by Hin-Tak Leung. Could you comment on the patch?
Comment 36 Jason 2009-09-04 15:17:29 EDT
I should add that switching to the radeonhd driver solved all of my X issues with RS690M. (package: xorg-x11-drv-radeonhd)
Comment 37 Lukas Brausch 2009-09-12 14:13:44 EDT
Created attachment 360808 [details]
gromobir's dmesg output
Comment 38 Lukas Brausch 2009-09-12 14:14:52 EDT
This is still a problem on Fedora 11. Please check my dmesg output above and let me know if you need any more information.
Comment 39 Hin-Tak Leung 2009-09-17 07:01:16 EDT
I have modifed the clamp patch and see which values are shown in normal course of operation, so this is a typical usage:

   6926  VTX_OUT srcX > 1
   9148  VTX_OUT srcY > 1

 526144  VTX_OUT_MASK srcX > 1
     86  VTX_OUT_MASK srcX < 0
 556356  VTX_OUT_MASK srcY > 1
     84  VTX_OUT_MASK srcY < 0
   1500  VTX_OUT_MASK maskX > 1 
   1518  VTX_OUT_MASK maskY > 1

I think I have also seen  VTX_OUT srcX < 0 a few times; I am wondering about the maskX <0 and maskY < 0 case - is it possible to try these cases explicitly? (i.e. what kind of operation can exercise negative mask values for this code path?)
 
Also I wonder about signed negative zero at floating point - the specific code converts numbers from float to double-word before byte-outputing to the hardware. Presumably negative zeros are sent as negative zeros.

For those who wants to experiment, to build -18 with recent x-server/libdrm, most of a commit 'radeon: Fix DRI2BufferPtr to be DRI2Buffer2Ptr for xserver 1.6.' is needed.

I am mostly thinking that the RS690 doesn't like maskX/maskY negative, but I don't know how to make it happen...
Comment 40 Jérôme Glisse 2009-10-14 06:33:31 EDT
Did you try lastest fedora 12 (test livecd for instance) ? If so does it works properly with it ?
Comment 41 Yanko Kaneti 2009-10-14 06:43:11 EDT
I don't see this problem with rawhide, on the same hardware that has the problem with F11+updates
Comment 42 Michal Schmidt 2009-10-14 08:56:34 EDT
F12 works fine for me too, no black rectangles.
Comment 43 Jérôme Glisse 2009-10-14 10:49:32 EDT
Ok closing the bug.

Note You need to log in before you can comment on or make changes to this bug.