> On Thursday 02 June 2005 13:08, Boris Peterbarg wrote:
>> Aapo Tahkola wrote:
>> > I did some figuring on the CB_DPATH problem.
>> > After little testing it turns out that the lock up with
>> > progs/demos/isosurf goes away when the pacifier sequences are applied
>> to
>> > clearbuffer.
>> >
>> > Im starting to think that this sequence is needed whenever overwriting
>> > certain states rather than whenever 3d operation begins and ends.
>
> Perhaps. I don't think it's just the pacifier sequence, though. I've been
> running applications with RADEON_DEBUG=sync, which causes idle calls
> between cmdbuf calls, and I've been seeing lockups where the read pointer
> sits after the beginning of what cmdbuf emits and long before the first
> rendering commands.
I dont know if packet3 was issued before since I tweaked isosurf to dump
each frame portion of RADEON_DEBUG info into files using freopen.
But "DISCARD BUF" was really the only key difference in these logs.
> This indicates that at least one lockup is cause by
> one
> of the following:
> - intial pacifier sequence in r300_cp_cmdbuf
> - emission of cliprects or
Cliprects seem to be little off scale when compairing progs/samples/logo
against software rendering.
Perhaps near plane is negative ?
> - initial unchecked_state commands sent by the client
This is bad as you can see from first frame drawn by texwrap...
Sticking:
r300_setup_textures(ctx);
r300_setup_rs_unit(ctx);
r300SetupVertexShader(rmesa);
r300SetupPixelShader(rmesa);
or resethwstate to r300_run_vb_render should fix it.
--
Aapo Tahkola
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
