Re: R300 pixel shader
I've been doing quite a bit of work towards getting rid of the EASY_PFS_INSTR and co. macros. My aim is to have a function similar to i915's i915_emit_arith, that will handle swizzling/negation transparently. If all goes to plan, I should have something that works okay in the next couple of days. r300 doesn't support arbitrary swizzling in fragment programs like it does for vertex programs. Unsupported swizzles need to be done in multiple instructions. As for the SRC0A in FPI0, The W component is replicated into the XYZ registers somehow, but I'm not exactly sure what components W gets copied into. Cheers, Ben Skeggs. Jerome Glisse wrote: Hi, I was playing with pixel shader, trying to improve support of texenv co... But i didn't success to find a way to do swizzle. If i ask for SRC0A in FPI0 is the A component replicated ? Anyone so far played with all that ? By the way i take a quick look to i915 code, and like Keith said maybe (i think he says something about that in a previous mail :)) we could have something generic enought for graphics cards with pixel shader ? Thus having less code to debug do... best, Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] pixel shader
Hi Nicolai, I committed a modification of pretty_print_command_stream.tcl that decodes most of PFS_INSTR* registers. It still prints the actual value written - as a last value after equals sign. So, I am hoping that even if this messed up your disassembler it is easy to fix - I am not that proficient in Python to venture modifying your code :) Also, r300_demo now have headers for both vertex shader and pixel shader. Lastly, I think it would be useful to have an assembler for vertex shaders and pixel shaders that does the job similar to those DirectX functions that translate textual description into coded on (I also believe that OpenGL 2.0 should have something like this as well). What are your thoughts about this ? thank you ! Vladimir Dergachev --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] pixel shader
On Sunday 19 September 2004 03:53, Vladimir Dergachev wrote: Hi Nicolai, I committed a modification of pretty_print_command_stream.tcl that decodes most of PFS_INSTR* registers. It still prints the actual value written - as a last value after equals sign. So, I am hoping that even if this messed up your disassembler it is easy to fix - I am not that proficient in Python to venture modifying your code :) Also, r300_demo now have headers for both vertex shader and pixel shader. It did mess up the disassembler which uses a simple regex to catch the data, but it's an easy fix. Lastly, I think it would be useful to have an assembler for vertex shaders and pixel shaders that does the job similar to those DirectX functions that translate textual description into coded on (I also believe that OpenGL 2.0 should have something like this as well). Doesn't Mesa already support ARB_vertex_program and ARB_fragment_program? I think it would be best to add R300 programs as an additional backend for the already existing infrastructure, though I have no idea how flexible the existing code is - I haven't looked at it in detail. cu, Nicolai pgpPA5WoUzFsG.pgp Description: PGP signature
Re: [R300] pixel shader
Lastly, I think it would be useful to have an assembler for vertex shaders and pixel shaders that does the job similar to those DirectX functions that translate textual description into coded on (I also believe that OpenGL 2.0 should have something like this as well). Doesn't Mesa already support ARB_vertex_program and ARB_fragment_program? I think it would be best to add R300 programs as an additional backend for the already existing infrastructure, though I have no idea how flexible the existing code is - I haven't looked at it in detail. Yes, you are correct ! I did not know this was implemented already. Does anyone on the list has any advice on how to use it ? thank you ! Vladimir Dergachev cu, Nicolai --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
