-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roland Scheidegger wrote: > I made some progress getting ATI_fragment_shader to work, so I've > uploaded some patches: > http://homepage.hispeed.ch/rscheidegger/dri_experimental/r200_fragshader.c > http://homepage.hispeed.ch/rscheidegger/dri_experimental/ati_fs_drm.diff > http://homepage.hispeed.ch/rscheidegger/dri_experimental/r200_ati_fs.diff > > This was initially all done by Dave Airlie, I've fixed it up a bit and > reverse-engeneered the coord routing (I hope...). > I'd be glad if someone could take a look at especially the drm > interaction and tell me if I'm on crack, otherwise I'd like to commit it > soon. The state aliasing gets a bit ugly IMHO, though nothing > unmanageable, that's why I'm asking. (some new atoms replace old ones > (tfactor, txfilter), but the afs atoms alias state from the pix atoms.) > > A quick view what's working and what isn't: > A simple hacked up multiarb demo using ati_fs instead works. Even
Another good test would be to modify progs/demos/pixeltexl to use ATI_fs instead of SGIS_pixel_texture. > changed so it does a dependant texture read it still looks like the same > as with fglrx. OTOH, a demo named t3 (have forgotten where I've found > it) doesn't quite work. Does t3 work with swrast? > There is presumably a bug with the global shader constants handling, > didn't have time to fix that yet (needs some core mesa changes again). > Also, binding a shader is probably going to be slow, as it is recompiled > each time. State handling is a bit problematic if ATI_fs is enabled, > maybe would need to refactor some code in r200_texstate.c. > There remains a question WRT to radeon 8500/9100, I have no idea if the > hang workaround would be needed on pass 1 too (and it's probably broken > on these chips, as the hang workaround looks like it will interfere with > ATI_fs). Is there a test to reliably reproduce the hang? I have an 8500LE, so I can test this patch for the hang. > Support for ATI_fs will be enabled automatically if texture_units is set > to 6 (there is simply no useful way to expose this with less units). > > And the REALLY important question: does doom3 run? :-) > Unfortunately, not quite. With hw tcl, it fails an assertion, though > this doesn't seem to be really related to ATI_fs, rather because doom3 > submits different vertices than with the arb path (as the crash is > doom.x86: r200_swtcl.c:103: r200SetVertexFormat: Assertion > `VB->AttribPtr[VERT_ATTRIB_POS] != ((void *)0)' failed.) Didn't look > into it (I hate that vertex stuff). > With tcl_mode=0, doom3 runs but it is very very dark. You can only see > direct light sources. Well this isn't any different than what it looks > like with swrast, so I'm not sure if the bug is in the driver specific > part or not. (as a side note, interstingly doom3 runs faster with ATI_fs > enabled - using fglrx or some other OS, the opposite is the case.) > > Roland > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDHwmcX1gOwKyEAw8RAg3wAJ9/MO+gY8Ayuyrj4pkYCWKAJpHxQwCfeTtY Si2xq6PluTLl5qSXvNJI7FE= =JhmY -----END PGP SIGNATURE----- ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
