On Thu, 2007-01-11 at 21:04 -0500, Phillip Ezolt wrote: > > First, the stipple pattern doesn't appear on the screen when X starts > up. As you may know, for radeon, this is done with DRI using indirect > buffers to draw the stipple. > > Oddly, the pattern never shows up on my screen AND the indirect > pointer (CP_IB_BASE) register is set to the value "000000000", so it > doesn't look like the CP is even executing the command.
Indeed. > I tried to avoid the whole "indirect buffer" issue, so on every call > to the indirect DRM ioctl, I issue the commands directly to the ring > buffer and return. (I just copied the values which X wrote to the > indirect buffer.) However, things still don't work correctly. Sounds like the CP isn't reading the commands you're writing. > 1) Could the CP be drawing this stuff, but putting it offscreen > somewhere? First of all, the CP itself doesn't draw anything. It's just a command processor that mostly converts command packets into sequences of register writes to the drawing engines. That said, it's theoretically possible that the CP is processing commands correctly, but the commands are incorrect such that the rendering goes offscreen. That's the next item: > 2) Could the command stream be wrong? That's unlikely. If the driver works correctly with DRI disabled, the CP commands it generates should be fine. > 4) Is there a simple command that I can issue to the CP to clear the > screen JUST to see if it is issuing any commands from the ring buffer > at all? You could do something along the lines of radeon_test_writeback: write to a scratch register via the CP and verify by reading the register directly. Actually, doing something like that from radeon_do_init_cp and returning an error if it fails might generally help to handle CP initialization issues more gracefully. > 1) The fglrx driver never sets the (RADEON_CP_RB_RPTR_ADDR) register. > If I read the register back when fglrx is running, it is set to "0". > > What does that register indicate? You can ignore scratch register writeback for now. You may want to load the radeon kernel module with no_wb=1 though to prevent the unlikely event that it intervenes with anything. > 1) The fglrx driver also never sets ANY of the the pciexpress > registers. (or any of the RADEON_AIC_*) Also, if I try to read the > PCI Express registers when fglrx is running, the values are all set to > zero. > > (Oddly, the PCIE index register: 0x00000030 is written to, but it is > never follwed by reads/write to 0x00000034... However, the > radeon_drv.h file also lists 0x00000030 as the bus control register, > so maybe it is using it as that. ) > > Is it possible that this card does use a GART? (Or is that crazy > talk..) It probably has to use some kind of GART, but apparently it's different from all the variants we support so far. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
