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

Reply via email to