Re: r200 and ATI_fragment_shader
On Wed, Sep 07, 2005 at 01:29:30PM -0600, Brian Paul wrote: | The basic idea of GL_SGIS_pixel_texture and the pixeltex.c demo is | that each RGB value sent to glDrawPixels is converted into an STR | texture coordinate. The texture is sampled with those coordinates and | the resulting colors get drawn where glDrawPixels would normally put | them. | | It's a kind of primordial dependent texture lookup. Mainly intended for colorspace transformations, if I remember correctly. Allen --- 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
Re: r200 and ATI_fragment_shader
Roland Scheidegger wrote: Ian Romanick wrote: Another good test would be to modify progs/demos/pixeltexl to use ATI_fs instead of SGIS_pixel_texture. Sounds actually not that easy. Or maybe I just don't understand the spec there very well. The basic idea of GL_SGIS_pixel_texture and the pixeltex.c demo is that each RGB value sent to glDrawPixels is converted into an STR texture coordinate. The texture is sampled with those coordinates and the resulting colors get drawn where glDrawPixels would normally put them. It's a kind of primordial dependent texture lookup. -Brian --- 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
Re: r200 and ATI_fragment_shader
Ian Romanick wrote: Another good test would be to modify progs/demos/pixeltexl to use ATI_fs instead of SGIS_pixel_texture. Sounds actually not that easy. Or maybe I just don't understand the spec there very well. Does t3 work with swrast? With the version in cvs, no. With my version, yes :-) Just found the error. But anyway, this now works in hardware too. Still no luck with doom3 with swrast (though actually I think it does not exactly look as with hw, though the complete dark surroundings are identical). > Is there a test to reliably reproduce the hang? I have an 8500LE, so > I can test this patch for the hang. > Not sure if it was possible to reliably reproduce it. Maybe a good idea would be to just do the same as the current code does, but in both passes (though I suspect the chances that you're only exactly using tex unit 0 and no other units is pretty slim if you use a shader). 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
Re: r200 and ATI_fragment_shader
-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
Re: r200 and ATI_fragment_shader
Roland Scheidegger wrote: A quick view what's working and what isn't: A simple hacked up multiarb demo using ati_fs instead works. Even 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. I've uploaded a newer version, some initialization bugs fixed, some passcord projected swizzling bug probably fixed (never saw code which would use that), and some lerp parameter order fixed - this one fixes the t3 demo. Still no luck with doom3 :-(. 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
Re: r200 and ATI_fragment_shader
Roland Scheidegger wrote: Michel Dänzer wrote: On Wed, 2005-09-07 at 01:52 +0200, Roland Scheidegger wrote: 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). Are these really related? My understanding is that texture_units is about the number of 'traditional' GL texture units exposed, and that this is tunable because it has an impact on the maximum texture size advertised. I don't see why that should affect shaders in any way. Because ATI_fs does only replace tex env. Thus, you still need to "traditionally" enable texturing on the units you want to use (the spec isn't very obvious about it, but all demos I've seen and doom3 really do it). There is no way you can enable texturing on a unit with a higher number than traditionally exposed (well at least with mesa, but everything else would be a hack I suppose). Have to correct myself, you're right in theory, number of fragment registers need not be the same as number of texture units supported (though if it's lower, you wouldn't be able to sample from that unit (could still use the coord set) but if it's higher there shouldn't be a problem). The code in core mesa doesn't test for that correctly I guess. However, I think it's safe to say that from all the apps out there using ATI_fs, none will bother to test for the number of texture units supported (at least all the demos I've seen didn't), all will just assume 6, so imho it's useless to advertize it with less than 6 texture units, all you'd get would be errors (not to mention I'd need to correct the code :-)). 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
Re: r200 and ATI_fragment_shader
Michel Dänzer wrote: On Wed, 2005-09-07 at 01:52 +0200, Roland Scheidegger wrote: 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). Are these really related? My understanding is that texture_units is about the number of 'traditional' GL texture units exposed, and that this is tunable because it has an impact on the maximum texture size advertised. I don't see why that should affect shaders in any way. Because ATI_fs does only replace tex env. Thus, you still need to "traditionally" enable texturing on the units you want to use (the spec isn't very obvious about it, but all demos I've seen and doom3 really do it). There is no way you can enable texturing on a unit with a higher number than traditionally exposed (well at least with mesa, but everything else would be a hack I suppose). 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
Re: r200 and ATI_fragment_shader
> > > > 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). > > Are these really related? My understanding is that texture_units is > about the number of 'traditional' GL texture units exposed, and that > this is tunable because it has an impact on the maximum texture size > advertised. I don't see why that should affect shaders in any way. Well I suppose you can error out the user if you don't have 6 units and they try to use more than they have in the shader... so it probably doesn't need to be connected to it... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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
Re: r200 and ATI_fragment_shader
On Wed, 2005-09-07 at 01:52 +0200, Roland Scheidegger wrote: > > 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). Are these really related? My understanding is that texture_units is about the number of 'traditional' GL texture units exposed, and that this is tunable because it has an impact on the maximum texture size advertised. I don't see why that should affect shaders in any way. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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
Re: r200 and ATI_fragment_shader
Philipp Klaus Krause wrote: Dave Airlie schrieb: Just to update, I've looked at the fragment shader stuff and the documentation I have isn't enough to implement the spec, we only have access to the second stage registers (PP_CNTL - states second or only pass registers) Is it enough to implement GL_ARB_texture_crossbar? Definitively. No additional information at all should be needed to implement it. The reason it's not implemented is the that the r200 does not have any "spare" register in the fragment pipeline. It has only 6, which can be used both as inputs and outputs. But you need to make sure you don't overwrite a register value which you got from texture sampling if you might need it again later on, which would easily happen with a trivial implementation of crossbar. It would be easy to add with the default enabled 4 or 2 tmus, but not quite so trivial for all 6. I think Ian was working on this some time ago. Roland --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 and ATI_fragment_shader
Dave Airlie schrieb: Just to update, I've looked at the fragment shader stuff and the documentation I have isn't enough to implement the spec, we only have access to the second stage registers (PP_CNTL - states second or only pass registers) Is it enough to implement GL_ARB_texture_crossbar? Philipp --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
