Originally posted by Korval:
Like what? What does D3D expose that OpenGL does not? If you’re talking about that one opcode (the name of it slips my mind), bear in mind that it takes 2 instruction slots in D3D, which is exactly what RC’s would take.
The cmp instruction equivalent in ps1.2 is not exposed in OpenGL register combiners.
Asgard, was there a particular problem you needed the GL equivalent to the cmp instruction for?
Asgard, was there a particular problem you needed the GL equivalent to the cmp instruction for?
Not really a particular problem. I just wanted to implement support for the cmp instruction in my DirectX pixel shader -> OpenGL reg combiners/texture shader translator that is part of my XEngine project (http://xengine.sourceforge.net).
It’s not really all that important. Just a nice-to-have feature.
That’s one of those things that I’d rather not have a special-purpose extension for. 
Well, I used to have a problem. IIRC, I tried to implement addition with 16-bit per channel precison. Mux was needed to handle carry, and without component-wise mux I could hardly fit all computations in 8 combiners. Anyway, I abandoned this area of research.
Originally posted by cass:
[b]
That’s one of those things that I’d rather not have a special-purpose extension for.
[/b]
In other words, the list of extensions isn’t going to be skyrocketing anymore.
Ah crap! that’s the measure I used to buy my card.
I didn’t say that either. 
There will still be extensions, but I think we’ve reached the end of the road for exciting variations on NV_register_combiners. New functionality will concentrate on extending the programming models in ARBvp and ARBfp and introducing new programming models as more units become programmable.
There will certainly be interesting features that will be vendor-specific, at least for a time. And, of course, some extensions will remain vendor- and/or hardware-specific.
Cass
Asgard, what’s about NVParse? I thought it can parse DirectX shaders.
NVparse can only parse pixel shader 1.1 like it is written in the doc.
Cheers
Arath
Korval, the register combiner’s mux instruction operates on the alpha component of the spare register, which means one comparison at a time. The pixel shader’s cmp instruction performs a four-component component-wise comparison. So, IMHO, you need at the very least 4 combiner stages to compare four components, whereas the pixel shader count two instructions. Maybe there’s a trick that allows the same operation to be performed in two combiner stages, and in that case I’d be very glad to know that trick !
Anyway, I think that cass answered my question indirectly.
Thanks cass !
Asgard, what’s about NVParse? I thought it can parse DirectX shaders.
Like Arath said, it only supports up to ps_1_1 and there are quite a few bugs in the ps_1_1 support of nvparse. Additionally, nvparse doesn’t perform all necessary semantic checks (if you look at my parser it is quite a bit more complicated than nvparse).
Therefore, I wrote my own translator quite a while back, but it’s not possible to support all ps_1_2 and ps_1_3 features with register combiners/texture shaders.
In particular:
Maybe I’ll implement the cmp instruction one day using multiple combiners. Also the last issue could probably be resolved by using an intermediate combiner. I don’t know why I didn’t do that when I wrote the translator…it’s been a while since then and I can’t remember all the details.
[This message has been edited by Asgard (edited 04-01-2003).]
Asgard, you’re right many thing stuff is not possible in openGL with rc/ts. But on the other hand, we can do double instructions in one stage (like double dotproduct) and we’ve got control on the final combiner. In fact, with the register combiners it’s like the pixel shader instruction for the XBOX. And as cass suggested, everyone should update to fragment program soon, but I still code for the GF3 owner (as I own a GF4 at this time).
Cheers,
Arath
Arath, register combiners are in a lot of ways more powerful than D3D shaders. Don’t get me wrong. I’m not complaining 
I just wanted to know if somebody knew how to implement the D3D cmp instruction with register combiners, because I thought I was too stupid to see how it could be done with 2 combiners (since that’s what the D3D docs imply). Now that I know that D3D uses functionality not exposed in the register combiners I can happily live with it…knowing that I wasn’t too stupid to see a solution with 2 combiners
fragment programs are not going to be widely supported before a while. Lots of ppl bought a GF3/4 or Radeon 8500 recently and won’t “upgrade” before one year or two (or even more).
Hi
there is the ATI_text_fragment_shader extension for thr R2xx chips.
Perhaps nVidia can make a {ARB|NV}_fragment_program based (program management …) extension with a text interface for NV2X (RC, TS) chips. It could be based on the nvparse syntax and add further hardware functionality (as the mentioned cmp instruction). IMO it would be useful for collaboration with fragment combiner programs and CG.
Bye
ScottManDeath
ScottManDeath, Just a side note - I’ve got the latest drivers for ATI Radeon 8500 and the ATI_text_fragment_shader extension is still not supported.
Originally posted by vincoof:
ScottManDeath, Just a side note - I’ve got the latest drivers for ATI Radeon 8500 and the ATI_text_fragment_shader extension is still not supported.
Hi
IIRC its only supported on the MAC. Perhaps someone should persuade the ATI && nVidia driver guys to provide Win32 & linux users with a proper text based extension for DX8 class hardware with ARB program management.
Bye
ScottManDeath
Perhaps someone should persuade the ATI && nVidia driver guys (…)
LOL, we had been trying hard to do so, for over a year, haven’t you noticed?