http://bugs.freedesktop.org/show_bug.cgi?id=25884
--- Comment #26 from Alex Deucher <[email protected]> 2010-03-20 16:16:09 PST --- (In reply to comment #24) > The rv280's X server is also surviving xine-ui's on-screen display now with > the > revised patch, but it looks like the R200's command parser still has an issue > with IMMDs. (Whatever they are...) > > [drm:r100_cs_track_check] *ERROR* IMMD draw 14932 dwors but needs 18 dwords > [drm:r100_cs_track_check] *ERROR* VAP_VF_CNTL.NUM_VERTICES 3, VTX_SIZE 6 > [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! > [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer ! > [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! > [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer ! > [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! > [drm:r100_cs_packet_parse] *ERROR* Packet (0:3:14932) end after CS buffer > (9306) ! > [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! > > The "No buffer for z buffer" error is consistent with the RV350's results. > (The > rv280 is in a PC running vanilla 2.6.33.1.) > The problem is you need to re-emit all the previous 3D state (default state and state setup in the textured video functions) if you cross over into a new command buffer. I'm not sure of a clean way to handle this without some sort of state tracking. We should probably track the state like the mesa driver does and mark it as dirty when we flush so it can be re-emitted in the next command buffer. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
