Dieter Nützel wrote:
Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive:

On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote:

[ Following up to the dri-devel mailing list, we aren't really
using the sf.net bug tracker anymore but rather the kernel and
XFree86 bugzillas ]

On Mon, 2004-02-09 at 04:55, SourceForge.net wrote:

I just ported the latest CVS drm-kernel code into the 2.6.2
vanilla kernel.

Do you have a patch for us to look at?

Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #.


Does the same problem occur if you just build the DRM from DRI
CVS?

It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under
2.6.


I use only 2.6.x. There is No problem with DRI CVS (DRM).

But some apps hang the graphics card (hard).

UT2003 Citadel after some (<= 3) seconds. But _very_ smooth with S3TC
and Roland's hardware TCL patch.
That's not good. There is nothing (both in the S3TC patch as well as in the changed lighting code) which could make lockups disappear. Using compressed textures shouldn't change anything (except the textures are smaller so less texture swapping is needed which might mean there are more free dma buffers available). The lighting changes did avoid some TCL fallback with materials between begin/end (and it looks like the fallback doesn't always work correctly, though I don't think it causes lockups), but in the latest patch (submitted to cvs yesterday) it's back in (as removing it wasn't correct and sometimes caused obvious rendering errors, it still awaits a proper fix). The patch still avoids a tcl fallback when using two-sided materials, but that really shouldn't have caused lockups...
Meaning if the lockups have disappeared in UT2003, they are likely to reappear somewhere else.
That said, I just tried to reproduce the lockups, but I can't even get ut2003 (demo 2206) to start here, it crashes even before the nvidia logo appears (seems to segfault and then be stuck waiting for a signal, killall -9 will just get rid of it fine). I can only hope it's not caused by the lighting changes I've commited yesterday (though I've no idea how these changes could cause that) - maybe some of the experimental code I've got here causes it.


Roland


------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to