Bug 4150 - BITBLT_MULTI does not pass (GL_ARB_texture_rectangle)
BITBLT_MULTI does not pass (GL_ARB_texture_rectangle)
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300
unspecified
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-19 23:09 UTC by Ryan O'Hara
Modified: 2006-02-20 13:40 UTC (History)
1 user (show)

See Also:


Attachments
testcase (3.24 KB, text/plain)
2005-08-19 23:12 UTC, Ryan O'Hara
Details
my xorg.conf (14.48 KB, text/plain)
2005-08-19 23:46 UTC, Emil Jacobs
Details
drm side of the proposed fix (975 bytes, patch)
2005-08-21 11:24 UTC, Aapo Tahkola
Details | Splinter Review
r300 driver side of the proposed fix (2.27 KB, patch)
2005-08-21 11:28 UTC, Aapo Tahkola
Details | Splinter Review
Whops... :) (701 bytes, patch)
2005-08-21 11:39 UTC, Aapo Tahkola
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan O'Hara 2005-08-19 23:09:15 UTC
Cairo using the GLX glitz backend locks X. This has been confirmed by another user.

Cairo 0.9.2
Glitz 0.4.4
Radeon 9500 Pro
cvs drm as of 8/19
Comment 1 Ryan O'Hara 2005-08-19 23:12:27 UTC
Created attachment 2940 [details]
testcase

cairo glitz backend testcase hardlocks r300
Comment 2 Emil Jacobs 2005-08-19 23:21:54 UTC
Confirmed by me :)
Setup: 
distro: Gentoo
cairo 0.9.2-r1
glitz 0.4.4
cvs drm/mesa/xorg of 8/19
Comment 3 Emil Jacobs 2005-08-19 23:46:44 UTC
Created attachment 2941 [details]
my xorg.conf
Comment 4 Aapo Tahkola 2005-08-21 11:24:58 UTC
Created attachment 2966 [details] [review]
drm side of the proposed fix

Is bitblt secure?
Comment 5 Aapo Tahkola 2005-08-21 11:28:48 UTC
Created attachment 2967 [details] [review]
r300 driver side of the proposed fix
Comment 6 Stephane Marchesin 2005-08-21 11:34:31 UTC
(In reply to comment #4)
> Created an attachment (id=2966) [edit]
> drm side of the proposed fix
> 
> Is bitblt secure?

Not as-is. But it's a type3 packet so that's already handled by
radeon_check_and_fixup_packet3.
Comment 7 Aapo Tahkola 2005-08-21 11:39:53 UTC
Created attachment 2968 [details] [review]
Whops... :)
Comment 8 Ryan O'Hara 2005-08-21 16:44:36 UTC
I can confirm that the r300 driver patch works.
Comment 9 Vladimir Dergachev 2005-08-21 17:44:11 UTC
(In reply to comment #4) 
> Created an attachment (id=2966) [edit] 
> drm side of the proposed fix 
>  
> Is bitblt secure? 
 
I don't think so - it could be used to view system memory,  
so a check is needed. 
Comment 10 Ryan O'Hara 2005-08-21 17:45:37 UTC
I may have spoken a little too soon. Now instead of an immediate hard lock after
some time the machine locks.
Comment 11 Michel Dänzer 2005-08-21 18:46:25 UTC
(In reply to comment #9)
> (In reply to comment #4) 
> >  
> > Is bitblt secure? 
>  
> I don't think so - it could be used to view system memory,  
> so a check is needed. 

See comment #6.
Comment 12 Vladimir Dergachev 2005-08-21 20:49:07 UTC
(In reply to comment #11) 
> (In reply to comment #9) 
> > (In reply to comment #4)  
> > >   
> > > Is bitblt secure?  
> >   
> > I don't think so - it could be used to view system memory,   
> > so a check is needed.  
>  
> See comment #6. 
 
Thing is the patch switches BITBLT to use a r300 raw packet, so this would 
bypass usual radeon checks. 
 
I am not certain why this patch affects things at all, as I would have expected 
packets inherited from radeon driver to work fine - certainly Xserver should 
use BITBLT quite often. Perhaps, there is some subtle issue that I am missing ? 
 
 
Comment 13 Aapo Tahkola 2005-08-23 12:49:18 UTC
(In reply to comment #12)
> (In reply to comment #11) 
> > (In reply to comment #9) 
> > > (In reply to comment #4)  
> > > >   
> > > > Is bitblt secure?  
> > >   
> > > I don't think so - it could be used to view system memory,   
> > > so a check is needed.  
> >  
> > See comment #6. 
>  
> Thing is the patch switches BITBLT to use a r300 raw packet, so this would 
> bypass usual radeon checks. 

Usual readeon checks arent used for r300 as far as I can see.
Looking at radeon_check_and_fixup_packet3, it seems to me like LOAD_VBPNTR would
go trough it without any checks.

>  
> I am not certain why this patch affects things at all, as I would have expected 
> packets inherited from radeon driver to work fine - certainly Xserver should 
> use BITBLT quite often. Perhaps, there is some subtle issue that I am missing ? 

Remember that xorg uses indirect buffers.
Comment 14 Aapo Tahkola 2005-08-30 10:17:22 UTC
(In reply to comment #10)
> I may have spoken a little too soon. Now instead of an immediate hard lock after
> some time the machine locks.

Is this always reproducible?
If so r300 based gpus might work better with page flipping or without buffer swaps.
Also you should be able to workaround this "bug" by starting with atis drivers
before using r300 driver.
Comment 15 Ryan O'Hara 2005-09-29 19:45:36 UTC
This is reproducible although I'm no longer sure it is directly related to cairo
(or anything opengl).  If I load the drm.ko and radeon.ko modules, after a
while, I get the freeze. Enabling page flipping didn't seem to solve the issue.

I'm not sure if the following backtrace is useful but here it is anyway:
gdb) bt
#0  0xffffe410 in ?? ()
#1  0xbfe964f8 in ?? ()
#2  0x00000000 in ?? ()
#3  0x00006444 in ?? ()
#4  0xb7d69539 in ioctl () from /lib/libc.so.6
#5  0x080dbbb6 in xf86ioctl ()
#6  0xb7f76828 in drmCommandNone () from /usr/lib/xorg/modules/linux/libdrm.so
#7  0xb7977943 in RADEONWaitForIdleCP ()
   from /usr/lib/xorg/modules/drivers/radeon_drv.so
#8  0xb7799afc in XAAInit () from /usr/lib/xorg/modules/libxaa.so
#9  0x080f6edf in miInitializeBackingStore ()
#10 0x0810d446 in miSpriteInitialize ()
#11 0x080825e6 in DoGetImage ()
#12 0x08082896 in ProcGetImage ()
#13 0x0808594b in Dispatch ()
#14 0x0806dddc in main ()

I'll try to provide further information if necessary.

(Sorry for the late response as this is the first time I've had access since
Hurricane Katrina)
Comment 16 Danny Kukawka 2005-11-08 10:36:45 UTC
Comment on attachment 2940 [details]
testcase

wrong file?!
Comment 17 Aapo Tahkola 2005-11-08 11:22:21 UTC
(In reply to comment #16)
> (From update of attachment 2940 [details] [edit])
> wrong file?!

It seems to me like this would be the infamous r300 lock case.
Im going to disable r300 support to avoid confusion with stable and not stable
chips.

As far as the bitblt part goes, r300_cmdbuf.c needs to be converted to pass
along drm_file_t so that we can call radeon_check_and_fixup_packet3(...).
Comment 18 Aapo Tahkola 2006-02-21 08:40:33 UTC
Fixed in DRM CVS thanks to Dave Airlie.
File in another bug about the r300 chip instability if you wish.