Sorry your browser is not supported!

My friend and myself are trying to do cool a water effect such as in Morrowind. We both have GF4 cards so its not a hardware issue. Now that Nvidia have released CG we can't find any old assembly shader files. I found a water file for version PS 1.4(is this version supported by DBPro?) but that wont load into DBPro. We cant find any programs so we can write version 1.0 files and see what they look like or do we just edit them in notepad and see what happens when we apply it to an object in DBPro. If we are totally on the wrong track please advise. As I see it until CG is supported, Pixel and Vertex shaders are to be kept away from unless someone really knows what they are doing or has the time for trial and error programming. Any help would be greatly appreciated.

Ive got the PS 1.4 shader available if anyone wants to try it.

I thought DBPro didn't support PS 1.4. Sorry

Well since it needs DX8.1 i would have thought it would. Anyway I tried using shaders from rendermonkey and some of the simple ones worked, there was a water shader available there too.

edit them in notepad


pixel shader (save as something like .pshader)


i mean all this will do is take the first texture, and multiply it by the second one similar to the Multiply Blend within Paintshop or Photoshop.
i have a full selection of the commands and for what formats they work in if you need them ... but nVidia should have the full list as they've created these things

[edit-]
lol i know i've edited this a few times ... not changed much but the remarks - i'm just bein anal about them don't worry not changing any code, just loosk bloody messy to me

@Elemenop

Your problem isn't DBPro it's your hardware. To my knowledge, no Nvidia hardware supports pixel shader 1.4, not even their most recent cards. The Only hardware that I know of that supports ps 1.4 is made by ATI. Don't ask me why but Nvidia just doesn't like ps 1.4.

Neophyte... Pixel & Vertex Shaders are fully supported in all thier cards
ATi havn't made ANY Shaders, they've added support for them and not even hardware support at that.

Pixel & Vertex Shaders are nVidia's baby derived from Real-Time MultiTexture Blending Techniques and setup to originally be used within OpenGL 1.1 with nVidia GeForce Based hardware... OpenGL 1.3,1.4 & 1.5 are completely nVidia's (nothing to do with SGI, which i think has confused alot of people to why some of the functions are setup differently)

DirectX has only been supporting Shaders in DirectX 8.1 (one packaged with WinXP) because it was considered that GeForce Based cards were main stream enough ... however even then they lasped the used of certain types of pixel and vertex shader and gave very limited support - and it is more likely the reason they're not able to use ps.1.4 is that they've no doubt not set it up right.

That aside even if non of that was true, they said they got the Shader from nVidia.com (probably the Dev website) ... why would nVidia have unsupported Shader Samples on thier website?

well the code provided works, interesingly but works (^_^)

@Raven



Huh? http://mirror.ati.com/developer/indexsc.html



I thought pixel and vertex shaders drew their inspiration from Pixar's Renderman Shading Language? When Opengl 1.1 came out the hardware wasn't capable of using pixel and vertex shaders. Shaders, at least the hardware implementation, are a relatively new thing. OpenGl has been around since 1992 so i find it hard to believe Pixel and Vertex shaders were setup to used with OpenGl 1.1.



What? First off, OpenGL 1.5 doesn't exist. The latest implementation of OpenGL is 1.4. Secondly, I have no idea what you mean by 1.3,1.4 being completely Nvidia's. If this site http://www.opengl.org/developers/about/overview.htmlis to believed at all:



Do you mean extenstions to the OpenGl language? If so then yes Nvidia has many extentensions that it supports that are not part of the core OpenGl specification but so does every graphics company. Heck, it is even encouraged. Is that what you mean?



Not true. They were first introduced in Directx 8. For proof just check the what's new section of the directx 8.1 sdk where it says:


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dx8_c/directx_cpp/Intro/DX8WhatsNew.asp



You may be right on this one. Directx hasn't been all that consistent with regards to compatiablity over the years.



Elemenop never said he got it from the Nvidia dev site he just said that he found it. In fact in the previous sentence he stated that he couldn't find any old assembly shader files.


Don't get me wrong Raven I don't have anything against you, but I'm basing my knowledge that its his hardware and not DBPro on the fact that I have a GeForce 4 ti 4200 myself and the latest ps version that i can use is 1.3. I know because i used the PIXEL SHADER EXIST command and found out for myself. I am also pretty positive that Nvidia doesn't support ps 1.4 because I have The Cg Tutorial and there is no reference whatsoever of the ps 1.4 profile or how to compile to it. I'm also sure that ps 1.4 is an ATI thing because of this: http://mirror.ati.com/developer/SIGGRAPH02/ATIHardwareShading_2002_Chapter3.pdf

yes but most pixel shaders that are really out there on the net are written like



yes for all intensive purposes this is a Pixel Shader... however what most don't understand is that it is encapsulated within C++ PixelShader function

believe me they've had shaders around longer than you'd think - just not in the capacity they're within now ... all vertex and pixel shaders are anyways are assembly functions which edit within the memory directly either objects or textures with layered effects. This is just Multi-Layer Textureing, however in a much faster form, and with hardware specifically setup to achieve these tasks even faster it means you can create some pretty complex effects that only programs like Photoshop would be able to achieve however within a much quicker space of time allowing them to become realtime effects.

OpenGL 1.3 -> all the updates in it are for nVidia cards written by nVidia
OpenGL 1.4 -> enhanced updates by nVidia for the new GeForce3/4 enhancements
OpenGL 1.5 -> purely for the FX generation and still in Beta

all the major updates have been from nVidia for nVidia within the concecutive OpenGL's ... this is why everyone still uses OpenGL 1.2, because everything over it basically is only for nVidia Cards - there are also other updates for OpenGL Workstation Cards, but as generally the Joe public never has FireGL's or WildCats or Quadro cards etc... the improvements in that area can be quite safely looked over, and most actually wrap the nVidia functions to thier own cards in thier drivers.

i mean its an open source like Linux yes, but doesn't stop one company updating it ... the fact that these WILL become standard effects in most other cards over the next few years this is why its released.
you'll find that Mesa released thier new drivers specifically to allow older cards to use these new functionality within OpenGL 1.3+

next the fact that Pixel & Vertex Shaders were in DirectX 8 was a pure joke in itself, they never worked ... no matter what hardware you had, and if by some miricle you did finally get them to work - then you're as good as screwed because they ran so slowly you might as well just do the shaders to old fashion way like id did in Quake3!

i have a full library of howto structure and develop Pixel/Vertex Shaders 1.1,1.2,1.3,1.4,2.0,3.0,2.0sw,3.0sw

as for the 1.4 being ATi, have you seen the extensions within 1.4? its just pathetic ... to be honest i'd rather skip it and use 2.0 with a GeForce based card. That aside, perhaps they did design it - but i know for a fact that if they're cards support it, then it isn't Hardware based but Driver based. Because unlike the GeForce 3,4 Ti, Fx cards ... the Radeons don't have a Shader Level to thier GPU - they have the floating point co-processor, but no Shader Processor - this would mean they're running them one the hardware the exact same way as Microsoft's Rasteriser does and nVidia's NV30 Emulator does, but just calculating this using the speed currently available or by switching to the processor.

even still though, GeForce cards WILL run all the pixel and vertex shader formats - this i also know first hand as i've tested this with most of my cards under DirectX 8.2 and DirectX 9.0

its good you've done your research, but ATi have very little to do with Shaders - and an even smaller compatibility with them. A huge part of DirectX9 was to add this functionality to ATi Radeon based cards - which it has done with Software Shaders, but it isn't the same. And until ATi pull thier finger out and make a card with a Shader Processor, or add another section in addition to the FPU then they'll just trail.

if you go by exactly what is out there rather than the people who are using the hardware then you'll find that the ATi Radeons are some mirical card capable of astounding speed at a great cost with hundreds of features.
When the fact of the matter is that a Radoen 9700 barely keeps up with a GeForce4 Ti 4200 at factory defualt speed (let alone overclocked) ... you add to this the fact that the GeForce AGP Pipeline is setup better than the Radeons allow more information to be passed at greater speeds, which means if you're a lucki bugger who has am AGP 8x with atleast 512Mb Ram then the Radeon will each the GeForce's dust...

you then add to this the fact that nVidia are constantly improving their OpenGL and DirectX Drivers (most cards have gained around 10-25% speed increase from thier base drivers within the last year), plus they are capable of handling more shaders and more complex shaders much more easily without even touching the main GPU or CPU ... this gives them another speed boost.
people wonder why they don't perform much greater in the 3DMarks 2003, but really the fact of the matter is that 3D Mark uses DirectX (which is designed to enhance the speed of the Radeons) they're also using universal rather than hardware specific shaders in those tests... and on base operations its all upto raw speed of the Processors and FPU - which GeForce and Radeons until the FX have been roughly equal.

you ever wonder why Radeons are so much cheaper than the GeForce counterparts? the reasons are obvious - but diehard Radeon fans just don't want to admit that they're surfing in nVidia's wake and they're not looking like they'll catch up. put the 5000 against the NV30 and its a true joke - no matter how much people have tried to praise it, and state how small the speed and feature gap is - the fact of the matter is that the 5000 is 10% slower than the NV34 (GeForce FX Mx ~350Mhz) this is a minimal difference in speed yes, but as these are HALF the speed of the NV31 (GeForce FX Ti ~650Mhz) and this is even slower than the NV30 (GeForce FX ~1,000Mhz) ... its just ridiculous.
even more so as the Radeon is larger and running hotter than the NV30!!!

ATi are now fighting against nVidia and 3dfx - personally unless they have some magic sitting in thier hat they not likely to even be able to stay considered a highend card within the 5th Generation battle.

but this all doesn't matter because DarkBasic Pro ONLY supports GeForce based cards 100% (cept GeForce256, GeForce2 or GeForce4mx)

Shaders work fine here on my radeon 8500.



hmmm... Are you saying DirectX is designed to enhance the speed of the Radeons? That would be quite nice. Or are you saying 3Dmark is desinged to make the radeons look good, if that is the case i have heard many a time 3dmark was made to make Geforce cards look good... Still zero proof either way.

3DMark is designed specifically for DirectX ... GeForce cards have been from day one 100% OpenGL Cards, thier DirectX support isn't exactly great. Radeon's however are natively DirectX with OpenGL support which isn't exactly great either.

The fact that Mad Onion have stated they will never make 3DMark to have features which are standard within a single graphics card generation... which is why when FSAA was used, they didn't impliment until GeForce2 had it as opposed to when 3dfx added it in Voodoo4.

Same with Pixel & Vertex Shader tests... they weren't implimented until there was another card aside from GeForce which could use them. Even then they added a cutdown version which wasn't hardware specific (which IS NOT what you'll find in games)

DirectX enhances the Radeons speed, simply because they're designed specifically along the same lines - the Drivers themselves add the support and DirectX9 actually has Radeon Specific functions.
Whereas the DirectX9 portion which is for GeForce only card was developed by nVidia and ... is not exactly the fastest thing on the planet - because they are OpenGL people.

If you look at the name of this document,

http://www.ati.com/developer/SIGGRAPH02/ATIHardwareShading_2002_Chapter3.pdf

...you see the word "Hardware". What is your point Raven about ATI shaders being "software"? All shaders are "software" in the sense that they're code that gets run by the GPU. Certainly either nVidia or ATI couldn't keep up if their shaders were run on the system CPU and not the GPU itself. In addition, there appears to be custom hardware involved in the 8500 and later that specifically supports the shaders, the extra registers, extra instructions, multiple instruction issue, etc. I still, after hearing you say "ATI doesn't even have hardware shaders" in several posts, have no idea what your point is.

All I'm hearing is "ATI is crap, nVidia rules, ATI sucks, nVidia rules". It's getting old.

The 9700 Pro kicks the Ti 4600 in some of the benchmarks, but others it doesn't. Same for nVidia. Multi-head performance, nVidia takes the cake. Full-screen anti-aliasing... Ti 4600 gets slaughtered by the 9700 Pro.

nVidia will and have been concerned about their D3D performance, because the D3D games exist at least 4 to 1 over OpenGL games for the Windows platform. They've had plenty of time to make their cards have fast D3D performance, and it shows. However, ATI has done a great job with D3D performance as well.
(http://www4.tomshardware.com/graphic/20030120/index.html)

You can say "I don't like ATI, I don't like their architecture", etc., all you want. When it comes down to the numbers, nVidia and ATI are neck and neck, they HAVE to be or one will end up being the next 3DFX. 3DFX was notorious for lack of OpenGL support that really worked or used the hardware to it's fullest... they bought the farm. No company can contend without having D3D and OpenGL supported and working.

If the benchmarks come up bad for nVidia (like they did when 3DMark2003 came out), nVidia starts whining about how "they didn't have time to optimize their drivers" and "no real games out today use PS 1.4 or PS 2.0", etc., etc., (cry me a river) - then ATI starts shining... they're drivers are ready to go and performing nicely.

http://www4.tomshardware.com/column/20030213/index.html
http://www4.tomshardware.com/column/20030219/index.html

If you ask me, nVidia looks like a bunch of weasels. But don't get me wrong, it just as easily could have been ATI.

So, please, let's just quit kissin' up to nVidia too much... they completely sucked when Voodoo reigned supreme, and thousands of users agreed that they sucked. Then nVidia started to get their act together. ATI sucked. They too had crappy support, crappy drivers, etc., and thousands of users agreed that they sucked. But they both had good hardware ideas, innovation, designs, and they pulled it together. The rest is history.

"its good you've done your research, but ATi have very little to do with Shaders - "

This sure sounds like ATI deveoping an extension for hardware-based shading for OpenGL to me...

http://www.ati.com/developer/ATIHardwareShading.pdf

"and an even smaller compatibility with them. A huge part of DirectX9 was to add this functionality to ATi Radeon based cards - which it has done with Software Shaders, but it isn't the same. And until ATi pull thier finger out and make a card with a Shader Processor, or add another section in addition to the FPU then they'll just trail."

Okay, I guess I'll take your word for it. But it seems that the 9700 Pro is not "trailing" the Ti 4600 in many benchmarks. How do you explain the Pro doubling the Ti in FSAA? I bet it's got something to do with "nVidia doesn't really care about FSAA", or "They're mainly OpenGL guys", or "they had a bad year that year".

The pixel shader and vertex shader versions that are documented in DX8.1 are all supported by the new ATI cards. So, I don't know what you mean when you say, "even smaller compatibility". That was one of the big issues with "3DMark2003", ATI had comptibility for PS1.4, PS2.0, etc., nVidia didn't implement it (or as they say, didn't get a chance to "optimize" their drivers for it), so ATI got a significant boost over nVidia in the results.
DX9 compatibility requirements dictate that the DX9 shaders (PS 2.0, etc.) are backward compatible with PS 1.0, 1.1, 1.2, 1.3 - 1.4 is a much like 2.0, and since nVidia didn't care much about 1.4 (as you say) they also weren't ready to extend onwards into 2.0. I don't claim to know much about them, but from the articles, it sounds to me like nVidia just didn't have it's act together for DX9 yet, and the new PS's from DX9 just weren't "all there" in the nVidia drivers. ATI had it "all there" for 3DMark2003. nVidia then claimed that the DX9 benchmarking wasn't "realistic"... no games exist or will exist for another 6 months, so DX9 benchmarks are not "real world" - and that's what nVidia claimed to excel at, real-world DX8.1 games, etc., and they also claimed that was the reason for any "low" performance in 3DMark2003...

From the looks of it, if it's really true that nVidia has specific hardware (shader units) in their design, DX9 is the bane of nVidia. They're probably running out of shader registers, etc. They'll end up having to do it in the GPU at least partly anyways. If ATI is already doing it in the GPU and outperforming nVidia, what will happen when nVidia's existing shader hardware can't handle all the extra texture registers, texture fetches, the new instructions, and the increased number of instructions, without involving the GPU... it seems like they'll end up having to either dump the "shader unit" (if it's not really just another GPU devoted to the "shader" purpose) and do it all in the GPU to remain "compatible", or you'll have to buy a new card that has a "shader unit" that will work with DX9 shaders. There's always a catch-22 when you start making very specific-purpose hardware units - boost the performance, but sacrifice the flexibility for the future.

As long as they keep extending the capabilities the "shaders" are expected to handle, it's a moving target for ATI/nVidia to devote serious "devoted" and "specific to the task" silicon hardware to. I bet the extra shader unit is no "walk in the park" for the designers at nVidia... Bus contention, memory bandwidth,... it's probably why FSAA is sucking so bad on the Ti 4x00's.

"3DMark is designed specifically for DirectX ... GeForce cards have been from day one 100% OpenGL Cards, thier DirectX support isn't exactly great. Radeon's however are natively DirectX with OpenGL support which isn't exactly great either."

Come on... this is a crock! nVidia made GeForce to take the market from 3DFX for GAMES and GAMERS buying vid cards for their PCs! There were only a handful of OpenGL games back then! Sure, Quake and such were really big, but everyone else was using DirectX for their games. And nVidia didn't really support "OpenGL"... only the part needed to get Quake and them running for cryin' out loud. It's still true today... OpenGL support is only there in the capacity that the games use it, except on the specialty cards (FireGL?) where gamers AREN'T the target market..

to me there has always been a presidency line in Graphics ...
Started with Cirrus Logic moved onto S3 during the time of the VL board, then 3dfx were pretty much creme of the crop until nVidia.

in industry terms nVidia are newbies (but also oldies if you know thier old company name) ... but that aside

ATi Hardware is not setup to handle Shaders properly ... YES their Processors got the extra intructiona dn register sets, BUT what they DO NOT have is an additonal processing unit specifically designed for them. Add this with the fact that they don't register 100% of the time, infact you're lucky if they register that the hardware is capable of running them 50% of the time!
I WOULD NOT CALL THAT HARDWARE SUPPORT, especially as DirectX detects if the Driver software is capable of them - not the hardware, and will generally use a Software Shader which i've stated before is in the same ilk as the Microsoft SDK Rasteriser.

GeForce cards DO NOT let the CPU take over shader operations if it can't handle them, infact it just drops the extra intructions, which most people chalk up and believe that this is a bug in the card - but its not, it was deisgned specifically that if it can't handle something it doesn't run it - not that it slowes down the whole system by shifting what processes it.

Quite frankly if you've been within and around 3D as long as its been around, you ask anyone who has they'll tell you that most of these tests are pure bull.
in addition to this, i've never seen a Radeon 9700 out perform GeForce Ti 4200 let alone a GeForce Ti 4600!

i see on the net all the time "ohh the new Radoen is so great, just look at these benchmarks we've done"...
after all the hulla baloo everyone made over the Radeon i got one.

So i replace my GeForce 4Ti 4800 with it - and run JK2 first at the same settings i normally do. 1600x1200 32bpp, full graphics, FSAA 8x
the Radeon crawled at 45fps - perhaps this is still playable, but when my GeForce runs at 97fps!!

i thought, oki perhaps JK2 was the wrong test, after all its only a DirectX and OpenGL crossbreed... so i ran a test in America's Army - everyone on that server told me that they rocked in that. a pure DirectX game, surely it'd be quick...
1024x768x32 full graphics, a respectable 130fps - however when heavy fighting was going on it'd slow to almost 70fps oki so this wouldn't really be majorly noticeable ... but still 70min-130max!! yet my GeForce handles this at a steady 150fps, even when heavy fighting is going on - lots of smoke even looking out over the terrain still only drops to 120fps.

i have so many cases of this i could share and quite frankly the card does not deserve any of the hype it gets... it is a cheap and chearful card - which although has power, just can't match up to the GeForce counterpart.
I have a Quadro FX 2000 now, hopeing to afford to upgrade to a Quadro FX 1000 sometime midyear - i'm not going to be touching those cards ever again.
I've never been impressed by any of thier cards during thier 13years on the market, and i think i was a fool to even think they'd made someone even remotely good now.

i also tried the card with DirectX 8.1 SDK developing a few basic programs for it ... that is SHOULD have easily run - and yet they slugged on. Not only that but for hardware support for stencil buffers and such, it was interesting to know why the hell they used SW Rasteriser for Rendering them rather than a Hardware one. If the hardware is there IT DOESN'T BLOODY USE IT!

i don't understand how anyone can even remotely like these cards, horrible performance, horrible drivers, horrible support, horrible to develop for... they should be taken out and shot. Anyone who believes they're speeded has never owned a GeForce card - its as simple as that.

Hehe, all this when all I was secretly after was a working/compatible Water - pixel and vertex shader. But the information provided here has been excellent and everyone interested in the workings of todays top gfx cards will benefit.
Thanks everyone for their replies.

"DirectX enhances the Radeons speed, simply because they're designed specifically along the same lines - the Drivers themselves add the support and DirectX9 actually has Radeon Specific functions.
Whereas the DirectX9 portion which is for GeForce only card was developed by nVidia and ... is not exactly the fastest thing on the planet - because they are OpenGL people."

You got any docs to back this up? The drivers for the vid cards run in SYSTEM memory on the P4/AMD/whatever (ain't no DRIVER gonna make fast pixel-shading in the P4 3GHz and then stream it across the AGP bus to the vid card with any kind of "real-time" performance). The drivers can load code into the GPU of the vid card (both ATI and nVidia are sure to be doing this), but of course, that code runs in the GPU/Shader Unit/etc. What is the voodoo-black-magic you're trying to sell us here?

Can you show me the ATI and GeForce specific sections of the DX9 SDK? Special function like D3D_ATI_XXXXXX or D3D_GF_XXXXXX... to support particular vid chips/cards... doesn't sound like any DX I've ever heard of. If your talking about "features" of DX9 that were added because the various cards now implement them to whatever degree, in hardware, then that would make sense. Whatever your point is, ATI and nVidia both have their hands in the "steering" of DX - it's the only way to ensure DX continues to work on their hardware that they've already made and the hardware they're currently making or planning on making.

GeForce wasn't to just take the gamers community, but the entire development side - game development software suchas 3D Studio Max has been based heavily on OpenGL for pure speed.

and they never won against 3dfx by making it work well with DirectX... they did it with the addition of TnL which just quite frankly was such a huge speed boost over 3dfx which didn't support DirectX either but Glide which is OpenGL but cutdown and 3dfx specific... they used a wrapper for DirectX programs and were notoriously bugged as a result - whereas the GeForce created additional drivers for it.

you won't find any D3D_ATI or D3D_NVD ... becuase none are named such.
Why? because Microsoft add the API development to take advantage of hardware, 4years ago Transform and Lighting was nVidia ONLY - however NOW it is put in as standard with all 3rd generation cards and above.

somehow i don't think you quite understand what the AGP was ever designed for, nor are you aware the point in FSB ... the side bandwidth addressing within a standard Althon/P4 system now is faster between the RAM<->CPU than it is RAM<->AGP however even still, this is more than fast enough with the FIFO's which quite frankly have been bog standard driver development since the early 90's to put it within the backbuffer which is all it has to actually do once processed!

this is the whole point int he AGP system!! so that processors with 3D Extensions suchas P3/P4/Althon/AlthonXP etc... can do these calculations without loosing speed between the Graphics and CPU

if this was PCI cards, then i'd agree that perhaps software shading would be slow - but these system arn't! i'd suggest you go look at the specs of how modern day computers work and why they're always improving these things called AGP and FSB ... because somehow i don't think you understand what they do!
The most major point here you appear to be missing is that the Radeons use Graphics Processors - these are RISC processors specifically setup for a single task. No doubt thier Shader Extensions are too!

GeForce use MISC Graphics Processing Units, which have a Floating Point Unit for complex math and a Shader Prosessing Unit ... like standard Processors and Co-Processors being built in layers inside each other, they're the same processing unit. However also they're capable of processing things which are outside of thier drivers, they are flexiable processing units capable of complex tasks in the same way as CPUs do - only on a less grand scale and setup more for the mathematics.

the way ATi have setup themselves up, i've seen first hand how much slower they are generically ... their technology is almost 3-4years behind nVidia's
BUT NONE OF THIS BLOODY MATTERS BECAUSE THE ORIGINAL POINT WAS THAT YOU CAN'T USE A RADEON TO RUN THE SHADERS IN DARK BASIC PRO!

there is no if but or maybe ... you can't

@Raven
Yes, but what does that have to do with what i was saying?Yes, I know this. The earliest conception of them goes back to Robert Cook's 1984 SIGGRAPH paper "Shade Trees" which lead to the development of the Renderman Shading Language.What do you mean by "layered effects"?
Shaders aren't limited to Multi-Layered Textureing. They are also capable of Transforms, Physics, Animation, and even rudimentary particle systems.
I still don't understand why you think that all the OpenGl updates are for Nvidia. If I'm not mistaken the whole point of OpenGl is so that programmers can write to one specification without having to worry about compatiablity with other graphics cards. Wouldn't creating a specification that is only for one card kind of defeat that purpose? Also, I've never heard of OpenGl 1.5 beta or otherwise. I'm not sure, but do you mean the beta verison of OpenGl 2.0?
http://www.3dlabs.com/support/developer/ogl2/index.htm

Umm...no. All of the updates are regulated by the Architecture Review Board.
http://www.opengl.org/developers/about/arb.html

As for everyone using 1.2...

Radeon 9800 Pro: http://www.ati.com/products/pc/radeon9800pro/index.html
Radeon 9600 Pro: http://www.ati.com/products/pc/radeon9600pro/index.html
Radeon 9700 Pro: http://www.ati.com/products/pc/radeon9700pro/index.html

I'll take your word for it. I don't know much about workstation cards or their drivers.
See my previous link about the ARB. Companys can release ARB approved extentions to the OpenGl specification that are specific to their cards, but they can't, by themselves, change the core specification.http://www.opengl.org/developers/faqs/technical/extensions.htm#0030
Agreed.
A 50% increase in the number of texture samples is pathetic? http://www.ati.com/companyinfo/press/2001/4389.htmlI'll agree that 2.0 is better than 1.4 in every way, but ATI has been supporting 1.4 since the Radeon 8500. For the maximum amount of compatiability I'd use 1.4 over 2.0 where I could just so I could net some of users of the older Radeons in to my pool of potential customers.
Essentially what your saying is that Radeon hardware uses your system's cpu for hardware shaders? Wouldn't that be incrediably slow? I don't think it works like that Raven else why would this paper existhttp://www.ati.com/developer/SIGGRAPH02/GHProgrammability-notes.pdfIt appears from this that ATI does have hardware capable of processing shaders.You mean future geforce cards will support ALL shader profiles because as of now there is no support for 1.4 on Geforce 4 and below hardware. I know this for a fact because I used the PIXEL SHADER EXIST() command and on my hardware and I got 1.3. I'm running a Geforce 4 ti 4200 AGP4x. I can't speak for Geforce FXs but from every indication that I have seen Nvidia has no intention of supporting 1.4. Ever.Huh? Then how do explain that page I linked to that was full of source code for shaders? If they have so little to do with hardware shaders then what is this: http://www.ati.com/technology/hardware/pdf/smartshader.pdf
Or why would they have extentsions for vertex and pixel shaders?http://www.ati.com/developer/ATIHardwareShading.pdfWhy also would they develop Render Monkey, a tool for developing shaders?http://www.ati.com/developer/sdk/radeonSDK/html/Tools/RenderMonkey.html
Then why even this entire page?http://www.ati.com/developer/techpapers.html
Look, I don't want to debate with you which card is superior. I don't care. I already have a decent graphics card and I like it but I think your letting your enthusiasm for Nvidia get a little carried away with.
Doesn't Rich have a Radeon 9700? Never mind. I give up.

just because Rich has a Radeon 9700 ... when have you seen the DBS team release that Shaders are supported on the Radoen cards.

They haven't, they stressed quite a bit that they are GeForce3 & GeForce4 only - with the exception of GeForce4 mx as it doesn't have the Shader support...

i'd spend time explaining this all to you but it seems like ya'll want you tech paper to be right and not the facts of the actual hardware.
even if they are in there - they certainly as hell arn't supported by the actual cards, or atleast they're not with thier current drivers. But then that'd be what is it called - oh yeah SOFTWARE not hardware.

:: rubs temples ::

just accept the fact of what you can possible use these features on and stop aruging it ... the fact of the matter is you can't use Radeons for these facts unless you develop sepcifically for them - this is why the GeForce are the only ones supported, because they use the generic within DirectX rather than hardware specific!

@Raven
I assumed since they mentioned the Radeon cards on the DBPro website(on the front page no less) that they supported it. Crazy me.http://www.darkbasicpro.com/index.php
Where? Can you provide a link? I'm curious.

Translation: I have no clue what I'm talking about. But Seriously, take all the time you want to explain to me the "facts" about the actual hardware. Lord only knows how many times I've tried explaining it to you.

They have to be to be fully Directx 9 compatiable.
http://mirror.ati.com/technology/wp/faq.html#5
Where do you get your info from? ::snickers evily at how hopping mad Neophyte got Raven::
I would if it were indeed fact, but you haven't shown me otherwise.Now I know I got you mad. Your slurring your speech. (joking)
Seriously Raven, there is a lot of evidence to the contrary. Take this page for example: http://mirror.ati.com/developer/indexsc.html
Its filled with examples of generic HLSL shader code that runs on Radeons. I've even got some of the Render Monkey example shaders to run on my Geforce 4(PS 1.4 was used heavily in all the examples so many of them I couldn't get to run(correctly) on my hardware. The ones I did get to run are the ones I could get to successfully recompile to PS 1.3).

explain to me how that works recompiling to PS 1.3, you have to almost fully recode the extended functions/registers within the more standard registers - you can't simply recompile and expect the same effect.

i've had all Shader versions workin on my GeForce 3, GeForce4, GeForce FX, Quadro4 XGL and Quadro FX under the 41.09 drivers ... and right now we're upto 43.83 - they released the 40.83 drivers almost 7months ago which enabled the GPU to recongise the additional instruction sets within DirectX 8.1 and 9.0 - however effectively thats Software Rendering the 1.4 Shaders.

now unless you are physically able to come around to where i'm currently staying i can't actually show you what i mean about how they perform, nor can i show you (as somehow i feel that is the only way you'll accept this) that they don't render shaders properly. And i'm not talking within a stupid Render program, i mean i'm able to run Renderman's Shaders on any card - i'm able to run CgFX on any card as its emulated ... even on my GeForce2 Go! they still perform quite admirably fast, but that isn't in a game with thousands of polygons and everything else going on.

if you want to see how the pipelines for these things work then take the time to download the DirectX SDK ... as it shows in there how they work through the hardware. Most DirectX Shaders oftenly will run

Ram -> CPU (sorts the Shaders between Hardware & Software) -> AGP -> Pipeline Buffer (oftenly level3) -> GPU >> SPU -> Backbuffer

that is the usual lifeline of the Shaders, which is partically why Software Shaders arn't actually all that slower than Hardware Shaders.
the Driver Shaders have a different life as what happens is they do this

Ram -> CPU >> Extensions >> FPU -> AGP -> Pipeline Buffer (oftenly level1) -> GPU (just for combining with the scene) -> Backbuffer

calculating within the CPU is oftenly alot slower than the GPU setup for this kinda thing, however the bypass of any real calculations oncard saves alot of time. now that is roughly how ATi are doing thier shaders, except the difference is instead of the Extensions being in the CPU for thier Shader set, its actually within the Graphics Processor... however as they're simply extensions the FPU does all the actual calculations (as in the CPU)

like this
Ram -> CPU (sorts the Shaders between Hardware & Software) -> AGP -> Pipeline Buffer (oftenly level4) -> GPU >> Extensions >> FPU -> Backbuffer

however what the GeForce cards do is rather than letting the Floating Point take care of all of these calculations what happens is this

Ram -> CPU (sorts the Shaders between Hardware & Software) -> AGP
"Existing Shaders" Pipeline Level3 -> GPU >> SPU -> Backbuffer
"New Shaders" Pipeline Level4 -> GPU >> Extensions >> FPU -> Backbuffer

This allows for alot more processing power for the CPU, and is actually why they're hardware rather than Radeons Software.
should note that the CPU sorts the Shaders into thier catagories and such it doesn't actually calculate any itself - its just quicker than letting the GPU do it because oftenly it'll already be busy doing other operations.

and incase your wondering Video Memory is only there for storing current Texture Data ... all model and such graphics data is actually stored within the System Ram.

i've got to yet stress i've yet to see a working Pixel And/Or Vertex Shader within DarkBasic Professional with a Radeon based card - There are 2 in this apartment, and niether show the effects properly when i turn off the DirectX SDK Rasteriser... i mean i can see them with all of my cards with the DirectX Rasteriser - until i see them working without it i'm not going to believe they work hardware wise, be it within DirectX or DarkBasic Pro.

i have an email from Mike sitting in my inbox which states that he has not seen the Vertex Shaders working on anything except a GeForce card and as the team do not have a GeForce4mx they are unsure if it works or not, however have heard that they don't support Pixel or Vertex Shaders so suspects they don't.

on this very forum it has been noted time and time again that GeForce4mx don't work with it as they don't support the shaders, and the team has always noted that GeForce3 and GeForce4 Ti work with it - i've never heard them mention that Radeons have been TESTED and work with them under DarkBasic Pro.
EVEN what you've quoted from doesn't say that Radeons are supported, they just said they added Pixel and Vertex Shader support ... they don't note for which cards, just that is where the idea came from!

Well, at least there are few points to be had from this discussion:

Since Raven can't get shaders to work on Radeon hardware, it can't really be done... and ATI sucks.

ATI has a crappy architecture, and all shader processing is done in the system CPU, because that's what Raven says.

It's okay if nVidia supports PS 1.4 and 2.0 without using their special "shading unit" hardware, because they have a good architecture and it still beats ATI hands down, even when they don't use their special hardware, because Raven says so.

Raven is not really prepared to back up any of his arguments with any shred of real evidence.

DBPro is supposed to support vertex and pixel shaders on cards that support them via DX - ATI cards DO support shaders (no matter if you want to call them "software" or "hardware"), and nVidia cards support shaders (whether they happen to be doing it in "hardware" at the moment or not). DBPro wasn't really tested all that much on Radeon cards, so noone (contributing to this discussion) *really* knows if it *actually* works, except Raven tried and it doesn't work so you should take his word for it.

For those not so blindly impressionable enough to be thwarted by Ravens comments, I can run all the DX8.1 shader examples from the ATI site above on my Radeon 8500 and they work nicely - they have complete source code, etc., and I don't see anything in the source that "targets" it for ATI cards specifically - it's just generic DX D3D + shader code! DBPro uses DX8.1 - there is nothing specific about DX8.1 that targets shaders to only work on nVidia cards, so theoretically, if you make a serious effort, and know what you're doing, and are persistent, you should be able to get shaders to work with DBPro on Radeon cards. At least, they'd better work. I paid $100 for a Professional package touting full use of DX8.1 features on DX-compatible hardware... they better patch up DBPro if it doesn't work.

It's a shame I don't have time to spend my life proving or disproving the claims... but then again, Raven says it doesn't work, and it's mostly because ATI cards suck, so we can just take his word for it (without any real proof otherwise).

have you tried the shaders in DBpro?
i can't give you proof that it works or not, because i can hardly give you a demo of something like that ... the only difference is if they come up black or as the Shader - and thats exactly what happens.

i could provide the screenshots but no doubt you wouldn't be happy i'm not just using another card - and there isn't exactly anything i can do to prove otherwise.
and quite frankly as has been noted they said it was because of these companies shaders NOT that they work on these cards. also it isn't beyond conception that rather than using the builtin DirectX 8.1 Pixel/Vertex Shaders, it could be using the NVSDK 5.2 for DirectX ... which is far easier to include Shaders within programs than using the DirectX equvilant.

also Ed, how many patchs have we had so far on just the basics - the Shaders are by no means high on the priority list and testing isn't exactly the easiest of things as there are just so many different drivers and setups of it.

Seems pretty clear to me from the DBPro web page we're supposed to have "full and direct control of these awesome hardware effects" in DBPro. It doesn't say, "We plan on adding these features to DBPro when we get around to it".

Where is it? Was it ever really there? Are we just to stupid to make it work?
My guess is that we just need someone who knows what the heck is really going on with VS/PS in DBPro to tell us how it really works... without a bunch of speculation about chips that suck or drivers that don't work, of even the existence of the VS/PS features in DBPro. Why is it that someone from DBS can't just step in and say "Pixel/Vertex Shaders do/don't work in DBPro... download this document for a detailed description of how we implemented them and how to make your own VS/PS work in DBPro."?

Of course you can use Pixel and Vertex shaders from the 9700 in DBPro.

I do it all the time.

I also use them on my ATI mobility 9000.

They are hardware shaders; ignore any claims to the contrary.

The GeForce ti4600 supports pixel shaders v1.3 (it is a DX 8 generation card.)

The ATI 8500 and 9000 Pro support v1.4.

The 9700 supports v2.0 (DX 9.0)

For a fast breakdown of versions supported, consider the following review link:

http://www.digital-daily.com/video/saphire-radeon-9700-pro/

I own a GF4 Ti4600, an ATI 9700 Pro, and a 9000 Mobility (pro). Pixel and vertex shaders do work in DBPro with patch 4.

Thanks Guy! It's good to get a fresh set of reasonable comments on this topic, and I'm glad to hear that shaders work for you with DBPro (and with patch 4 to boot!).

So, now that we've snagged you, would you care to post some examples of shaders + DBPro, or code snippets, or even just some quick tips... for us duffers?

A quick question: The shader files that are loaded into DBPro with "CREATE VERTEX SHADER FROM FILE ..." - do they have to be "compiled" (not even sure that's possible, but I saw mention of a VC++ Shader Compiler or somesuch) or do you just make a .psh "source" file with the ASM instructions (made with a text editor) and load that directly into DBPro?

its a standard assmebly shader you load with a text file as i did show above, yet you decided you'd have more fun trying to disprove me on things.

"nVidia's powerful GeForce range of graphic cards and the new ATI Radeon cards have inspired us to support both pixel and vertex shaders."
read that carefully... it does NOT say anywhere what cards they support, just that they are supporting the Pixel and Vertex Shaders!

That aside i've tried on multiple computers here, we all have quite different setups - Althon/Optiron/Pentium4/Xeon processors, different ram sets, infact the only thing these systems have in comming is they have a WinXP partition.
the Radeon 9700 card only shows black for shaders with DirectX SDK Raster turned off!
the Radeon 5000 also only shows black!
i'm not using the Calatyst3 or whatever it is, but the CD Drivers ... so explain to me how upgrading the drivers to a MultiDriver like Catalyst over the standard Driver developed specifically for the technology would allow HARDWARE Specific functions to be used? i've explained how it works, and yet you still don't like that...

Also my GeForce 4 Ti 4800 Supports Pixel Shaders 1.1->1.4,2.0,3.0 & Vertex Shaders 1.1->1.4,2.0,3.0, Texel Shaders 1.0->1.3 (OpenGL Only)
i doubt they'd add that support within the 4800 card only, because from what i've heard they only cut down the specs for the Mx only!
the GeForce has noted the support since upgrading to DirectX 9 for the extra pixel/vertex shaders and texel shaders have been since OpenGL 1.5 which support was added with NVSDK 6.0 + 43.00 (Beta) 2months ago.

So if you go by the upgrade drivers then the GeForce Cards STILL support better Pixel/Vertex Shaders!

and if you think somehow it is just me who's had these Radeon problems have you ever seen just how many other have complained that they can't get thier Pixel/Vertex shaders working on thier ATi cards... no, because right now so many ATi Radeon users are having multiple problems all over the place!
It's just amazing that for all the moans to the contraty, alot of people can't run them on thier ATi hardware.

So far we have just GuyS saying that they work on his ATi Radeons ... out of HOW MANY users of Radeons on this site??

@Raven

"explain to me how that works recompiling to PS 1.3, you have to almost fully recode the extended functions/registers within the more standard registers - you can't simply recompile and expect the same effect."

If I were using assembly shaders that would be true, but I'm not. The examples that I was refering to were in HLSL and the only reason I could recompile them was because they didn't exceed the ps 1.3 profile limit of no more than 4 texture reads.

"i've had all Shader versions workin on my GeForce 3, GeForce4, GeForce FX, Quadro4 XGL and Quadro FX under the 41.09 drivers ... and right now we're upto 43.83 - they released the 40.83 drivers almost 7months ago which enabled the GPU to recongise the additional instruction sets within DirectX 8.1 and 9.0 - however effectively thats Software Rendering the 1.4 Shaders."

The GPU has nothing to do with it. It's the CPU that's running those shaders because as you said thats Software Rendering and entirely useless for any realtime game that displays more than a rotating cube. I also don't see what this has to do with the subject at hand other than vaugely supporting your statement that somehow Nvidia "supports" ps 1.4. If software shading is "support" doesn't this conflict with your previous statement that ATI doesn't support shaders, but software renders them, like Nvidia does with PS 1.4, instead of hardware? If not then why bring this up here?

"now unless you are physically able to come around to where i'm currently staying i can't actually show you what i mean about how they perform, nor can i show you (as somehow i feel that is the only way you'll accept this) that they don't render shaders properly."

You don't need to do that. All you need to do is provide a link that explains how and/or why they don't render shaders properly. If what your saying is true then it must be documented somewhere else how would any one get shaders to work on any ATI card? And don't tell they don't at all. Numerous people have posted saying shaders worked on their cards and I've posted quite a few links proving that they do work on Radeons.

"And i'm not talking within a stupid Render program, i mean i'm able to run Renderman's Shaders on any card "

Off course they would. They are calculated entirely on the CPU. That's what makes them "software shaders."

"i'm able to run CgFX on any card as its emulated "

Do you mean you emulate CgFX or that CgFX is meant to be only emulatated? For a moment it sounds like your saying CgFX is for emulating shaders only that is not true. Forgive me if I'm reading more in to this than I should. I'm a little sleepy right now.

"Most DirectX Shaders oftenly will run

Ram -> CPU (sorts the Shaders between Hardware & Software) -> AGP -> Pipeline Buffer (oftenly level3) -> GPU >> SPU -> Backbuffer"

Where does it say this in the DX sdk? I have the Directx 9 sdk so could you point out where it mentions the pipeline works like this?

"that is the usual lifeline of the Shaders, which is partically why Software Shaders arn't actually all that slower than Hardware Shaders."

Huh? Are you serious? Software shaders are incrediably slower than hardware shaders. The only situation that I could think of that would be any where near what you just said being true would be only with the most simpilest of shaders.

"the Driver Shaders have a different life as what happens is they do this

Ram -> CPU >> Extensions >> FPU -> AGP -> Pipeline Buffer (oftenly level1) -> GPU (just for combining with the scene) -> Backbuffer

calculating within the CPU is oftenly alot slower than the GPU setup for this kinda thing, however the bypass of any real calculations oncard saves alot of time. now that is roughly how ATi are doing thier shaders, except the difference is instead of the Extensions being in the CPU for thier Shader set, its actually within the Graphics Processor"

So essentialy Radeon calculates shaders through their hardware. Doesn't this completely contradict what you were saying that Radeons didn't even have hardware support for their shaders? In the sixth post from the top you said:
I think the confusion here is over what you mean by "software shaders."
When you say "software shaders" I think of shaders executed entirely on the cpu like the Renderman Shaders. What you appear to mean is that shaders are only partly executed on the hardware and partly on the cpu.It appears that "setup properly" means to you that they must have a dedicated "Shader Processor" to calculate shaders with. Correct? You also seem to believe that ATI hardware does not have this "Shader Processor" therefore it is not setup correctly and therefore not "hardware." Correct? Correct me if I'm wrong but I believe you are mistaken when you say that ATI doesn't have a "Shader Processor."
http://www.ati.com/developer/SIGGRAPH02/GHProgrammability-notes.pdfAccording to this document ATI hardware has had a "Shader Processor" in their hardware since the Radeon 8500.

"however what the GeForce cards do is rather than letting the Floating Point take care of all of these calculations what happens is this

Ram -> CPU (sorts the Shaders between Hardware & Software) -> AGP
"Existing Shaders" Pipeline Level3 -> GPU >> SPU -> Backbuffer
"New Shaders" Pipeline Level4 -> GPU >> Extensions >> FPU -> Backbuffer

This allows for alot more processing power for the CPU, and is actually why they're hardware rather than Radeons Software."

No it doesn't. Take a look at your own diagrams again Raven and count how many times the CPU shows up in both the Radeon diagram and the Geforce diagram. Now assuming what you say is true, both cards only access the CPU once so how is the Geforce card allowing for more processing power for the CPU when it is using it the same number of times as the Radeon?

"i've got to yet stress i've yet to see a working Pixel And/Or Vertex Shader within DarkBasic Professional with a Radeon based card There are 2 in this apartment, and niether show the effects properly when i turn off the DirectX SDK Rasteriser... i mean i can see them with all of my cards with the DirectX Rasteriser - until i see them working without it i'm not going to believe they work hardware wise, be it within DirectX or DarkBasic Pro."

Uhh...Raven...Directx Rasterizer is the part of the Pipeline that calculates the colors and the shading. If you turn it off you won't see any colors or shading. It has nothing to do with the shaders on your Radeons not working.
Taken from the Directx 9 SDK help file entitled Pixel and Vertex Processing:

"i have an email from Mike sitting in my inbox which states that he has not seen the Vertex Shaders working on anything except a GeForce card and as the team do not have a GeForce4mx they are unsure if it works or not, however have heard that they don't support Pixel or Vertex Shaders so suspects they don't."

I can confirm for a fact that Geforce 4mx don't have pixel or vertex shaders. That is why they sell for less than a Geforce 3 ti, because they are stripped of alot of features and the only advantage that they have is that they can pump out more polygons a sec. But anyway, what does this have to do with what i was saying?

"on this very forum it has been noted time and time again that GeForce4mx don't work with it as they don't support the shaders, and the team has always noted that GeForce3 and GeForce4 Ti work with it -"

So?

"i've never heard them mention that Radeons have been TESTED and work with them under DarkBasic Pro.
EVEN what you've quoted from doesn't say that Radeons are supported, they just said they added Pixel and Vertex Shader support ... they don't note for which cards, just that is where the idea came from!"

But they also haven't stated that Pixel and Vertex shaders don't work with Radeons anywhere. I mean both Rich and Guy have Radeons so I would think that they would know and have told us by now don't you think?

@Ed Philips

"Raven is not really prepared to back up any of his arguments with any shred of real evidence."

I certainly hope he will because I'm quite eager to learn more about shaders, but so far I haven't been given any hope that he will.

@Guy

Thanks for responding and clearing this up! I also second the motion for a tutorial on how to use shaders in DBPro effectively. x-d

@Raven

"read that carefully... it does NOT say anywhere what cards they support, just that they are supporting the Pixel and Vertex Shaders!"

Which ATI Radeon 8500+ cards support. Don't you think it would be logical to conclude that ATI cards could then use shaders in DBPro?

"That aside i've tried on multiple computers here, we all have quite different setups - Althon/Optiron/Pentium4/Xeon processors, different ram sets, infact the only thing these systems have in comming is they have a WinXP partition."

Actually they have one more thing in common...you. Both Haggis Man and Guy say that shaders work just fine on their Radeons so don't you think it's possible that you could be doing something wrong? Just a thought.

"the Radeon 9700 card only shows black for shaders with DirectX SDK Raster turned off!
the Radeon 5000 also only shows black!"

They would seeming how the Rasterizer is what shades and colors polygons whether shaders are present or not.

"i'm not using the Calatyst3 or whatever it is, but the CD Drivers ... so explain to me how upgrading the drivers to a MultiDriver like Catalyst over the standard Driver developed specifically for the technology would allow HARDWARE Specific functions to be used?"

In the fifteenth post from the top you said:
I think you just answered your own question.

"Also my GeForce 4 Ti 4800 Supports Pixel Shaders 1.1->1.4,2.0,3.0 & Vertex Shaders 1.1->1.4,2.0,3.0, Texel Shaders 1.0->1.3 (OpenGL Only)"

Are you sure about PS 1.4? I'm having strong doubts that it is because I doubt Nvidia would support any of ATI's creations. They also don't mention anywhere in their Cg compiler spec for profiles that it can be compiled to. Why would they deliberetly cripple their Cg compiler by omitting a widely used profile?

As for Vertex shader 1.4...I've never heard of it. I'll give the benefit of the doubt on that one and just consider it a typo. As for PS 2.0 and 3.0 and VS 2.0 and 3.0...how could it? The Geforce 4 ti 4800 is not Directx 9 compatiable. It came out before the FX so how could it possible "support" those profiles?

Texel Shaders? You mean Fragment shaders. Which are essential another name for Pixel shaders. Don't know where you got Texel shader. :-s

"i doubt they'd add that support within the 4800 card only, because from what i've heard they only cut down the specs for the Mx only!"

That is what I heard as well.

"the GeForce has noted the support since upgrading to DirectX 9 for the extra pixel/vertex shaders"

Except PS 1.4. Really Raven I can find no mention of PS 1.4 ANYWHERE in the NVSDK 6.0. The docs I have for the Cg compiler completely omit PS 1.4 as a option to compile to. This was taken from a PDF entitled The Cg ToolKit:
(Note: You can find this section under Appendix B Language Profiles)


Notice how there is no mention of PS 1.4 at all. And later on...
If a Nvidia card supports pixel shader 1.4 then why isn't a Cg profile? Considering how I have seen for myself with the PIXEL SHADER EXIST() command that my Geforce 4 ti 4200 only supports up to 1.3 then the likely hood of that other Geforce 4s support it seems to be rapidly decreaseing. Are you sure that PS 1.4 is supported? Did you use the PIXEL SHADER EXIST() command? I'm having a hard time believeing in light of all this evidence to the contrary.

"and texel shaders have been since OpenGL 1.5 which support was added with NVSDK 6.0 + 43.00 (Beta) 2months ago."

There you go again with this OpenGl 1.5 crap. Did you read any of the OpenGl links I gave you. *sigh* http://www.3dlabs.com/support/developer/ogl2/index.htm
OpenGl 1.5 does not exist. There is neither a beta nor a working verison anywhere. I dare you to provide a link that proves otherwise.

"and if you think somehow it is just me who's had these Radeon problems have you ever seen just how many other have complained that they can't get thier Pixel/Vertex shaders working on thier ATi cards"

Nope. Just you.

" no, because right now so many ATi Radeon users are having multiple problems all over the place!"

Only with loading time. I hardly call that "all over the place."

"It's just amazing that for all the moans to the contraty, alot of people can't run them on thier ATi hardware."

Run what? Where have you heard of other users who can't run shaders on their Radeons? So far your the only one who has complained while both Haggis Man and Guy have stepped forward and said that they have no problem running shaders.

"So far we have just GuyS saying that they work on his ATi Radeons"

No Haggis man has said they work on his also.

"... out of HOW MANY users of Radeons on this site??"

That have complained about shaders under Patch 4? One. You. Haggis Man, Guy, and You are the only ones who I've seen comment on Shaders and their Radeons under patch 4. So far you are the only one having problems that I can see.

This isn't just about with Patch4!! Patch4 doesn't even alter how the Shaders are being used for one ... so unless they didn't work in patch 3.1 of course they will work in path4 - that statement itself is just stupid on its own.

ofcourse the "PIXEL SHADER EXIST()" command won't detect more than 1.3 on a GeForce card IF its DirectX9 and Drivers 43.00+ which add this support - seeing as DirectX9 isn't intergrated into DBpro only DirectX8.1 then geez i'll put my big shocked face on!

i swear ya'll are just skimming through whats written showing a bunch of documents over and over about what there is to backup claims you make?
yet you quite clearly don't have any understandings of the pipelines of these cards even slightly.

if you notice the MAJOR difference in the pipeline diagrams i showed is that the GeForce runs a Shader Processor Unit - something which the Radeons DO NOT HAVE! ... and you can search through documentation on ATi for something to contratry this but you be wasting your time.

the NVSDK Shader Help doesn't have anything on PS 1.4 - not because it isn't supported, but because they don't use it. There is a difference between Using something and supporting it!

as for OpenGL 1.5 ... OpenGL 2.0 has been being developed since 1.2, because as i've noted 1.3 & 1.4 are mostly nVidia's - and quite frankly if you didn't know that and need a piece of paper to tell you such then thats sad.
The developed support for other cards has been through external drivers like Mesa - as i've said, and 1.5 is being develop specifically for the FX range of GeForce.

The only real difference between nVidia taking OpenGL 1.3->1.9 suffrix designations for themselves and 3dfx taking OpenGL and producing Glide is that nVidia's OpenGL's are open source which adhears to the mandate of OpenGL... and yes funny you won't hear much about OpenGL 1.5 anywhere except if you're GeForce/Quadro FX owner, because the source and new isn't released until they're done ... SGI had the news of OpenGL 1.3 as its it was released, and 1.4 just kinda snuck onto the market unnoticed until it was picked up that ATi was using it to test some new technology for a console.

if you want to spend the $800 to get yourself an FX based card then feel free to then you can know the information - until then tough.

Also... i don't mean a Fragment Shader by Texel Shader, GeForce/Quadro card have something called a Texel Shader Engine Pipeline - and if you don't the difference between a Texel and a Pixel i'd suggest you do alot more homework here! Especially as most cards are capable of producing Texels within the pipelines, however Texel Shader is something which is relatively new and ONLY used within 3D Rendering Packages.
Another point should be made that Render Engines yes use Software Shaders, but they're capable of also using Hardware Shaders too ... However niether use the CPU in either Renderman, Messiah or Brazil 1.1 (which most will see soon)

Finally do you understand the difference between a
Hardware Abstract Layer, Rasteriser & RAMP Emulation?

it seems like both people making the major points here have read some little things and gone through help not actually knowing the technology behind which is what is being used to produce these results - what order they're being produced within and how the Software Drivers are telling the APi system, DirectX in this case howto go about thier calculation routines.
you just feel like because you've read and can quote the help that you actually have the faintest idea what your going on about ... and if i had the time to actually spend a few hours bloody trawling through each of the sites and help files i might actually show quotes from the same texts which could contratry your own quotes.

I'd suggest rather than sitting here trying to disprove me you go and put those research skills to some good use and ACTUALLY learn the technology you're trying so hard to defend here... perhaps then you'll relise what your trying to propose is actually impossible for it to pull of the way you believe it is being done.

lastly you mention the CgFX emulation - you've obviously not got very with nVidia Shaders if you're not sure what CgFX is, or how you can actually emulate all of its features! i mean its on the frontend of the website for it and as you've mentioned the Tutorials for it already i figured you'd downloaded the NV30 Emulator which allows any nVidia card which is comptible with Detonator4 43.01 Drivers or better to Emulate ALL of the Shaders capable on the GeForce FX NV30 ... and it doesn't do it through the CPU either!
It is still and emulator and they are still software shaders - but i'm sure you can figure out someday how that works.

I wish I had time to offer tutorials on pixel and vertex shaders. Alas, I do not. I am in progress on a major overhaul of the IDE. I will check with Mike, though, and see if I can post up one of his simple vertex shader demos - a sine wave rippling grid that's running fine on the 9700 (at obscene hardware speeds, no less.) I would post a screen shot to show pixel shader output on the 9700, but to be honest, it's not even worth the effort. I can imagine the silly claims afterward.

I will not try to convince people by throwing up more text and questioning their intelligence/knowledge.

Guy grab Pixel Shader DirectX SDK ... DON'T get mike to release one!
there's a damn'd good reason why i never posted exactly what they wanted in the first place.

try to save mike the same bother

Who mentioned Mike releasing an SDK? I certainly didn't.

i didn't either... i told you to take one from the DirectX SDK
lol i think thats a keeper for the fact that no one reads my posts - even the lil ones

[edit-]
that said... no one said he wasn't working on an sdk lol

@Raven

"This isn't just about with Patch4!! Patch4 doesn't even alter how the Shaders are being used for one ... so unless they didn't work in patch 3.1 of course they will work in path4 - that statement itself is just stupid on its own."

Apparently it's not so stupid after all.

"ofcourse the "PIXEL SHADER EXIST()" command won't detect more than 1.3 on a GeForce card IF its DirectX9 and Drivers 43.00+ which add this support - seeing as DirectX9 isn't intergrated into DBpro only DirectX8.1 then geez i'll put my big shocked face on!"

PS 1.4 is part of Directx 8.1 NOT 9 therefore it should register if my hardware is capable of supporting it.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dx8_c/directx_cpp/intro/dx8whatsnew.asp

"i swear ya'll are just skimming through whats written showing a bunch of documents over and over about what there is to backup claims you make?
yet you quite clearly don't have any understandings of the pipelines of these cards even slightly.

if you notice the MAJOR difference in the pipeline diagrams i showed is that the GeForce runs a Shader Processor Unit - something which the Radeons DO NOT HAVE!"

The irony. Speaking of someone who "skims over information" did you read my previous link which described the shading unit in the Radeon unit? In case you skimmed over it too quick here it is again. http://www.ati.com/developer/SIGGRAPH02/GHProgrammability-notes.pdf
And here is the diagram of the Radeon 8500 shading unit:

EDIT: The forum absouletly butchered the diagram. Just follow the link. Its easier.
Vertex Stream VE=vertex engine
| PP=pixel pipeline
|
__|__
| |
| |
VE VE
| |
| |
| |
___|_____|___
|Rasterization| Triangles
|_____________|
| | Pixels
______|_____|______
| | | | _________________
PP<_____PP____PP_____PP____|Texture Samples|
| | <___|______|_____| |
| | |<_____|_____| |
| | | |<____|_______________|
__|______|_____|______|_ Pixels
| Blending |
|________________________|

You continuely claim that radeons don't have a shading processor. I've repeatedly gave you links that proved otherwise but all you seem to do is skip over them. Is this diagram enough or do I have to buy a Radeon, disect it, and ships its guts to? Why do I get the feeling that no matter how many times I show you evidence to the contrary you just stick your fingers in your ears and say LALALALALALA. What is it I have to do to show you that Radeons have shading units and process their shaders on thier hardware? Please speak up and tell me so I can save myself the time of finding things that you'll just ignore.

"the NVSDK Shader Help doesn't have anything on PS 1.4 - not because it isn't supported, but because they don't use it. There is a difference between Using something and supporting it!"

Huh? If they don't use it in their hardware then isn't that not supporting it? If its in their hardware then why is it not mentioned in their sdk? Every other profile is. What other possible explaination is other than its not in their hardware?

"as for OpenGL 1.5 ... OpenGL 2.0 has been being developed since 1.2, because as i've noted 1.3 & 1.4 are mostly nVidia's "

And as I've noted you are wrong. OpenGL is not dominated by one company. As i've shown you before:

[href] http://www.opengl.org/developers/about/overview.html[/href]
How can it be vendor neutral when One company alone creates 3 whole versions for itself?

"and quite frankly if you didn't know that and need a piece of paper to tell you such then thats sad."

I could say the same of you.

"The developed support for other cards has been through external drivers like Mesa - as i've said, and 1.5 is being develop specifically for the FX range of GeForce."

Why? Just step back for a moment and look at this from a logical perspective. Whats the payoff? Why would Nvidia invest how knows how much into developing an entire language just for a few graphics cards? Why not just develop extentions from the exisiting OpenGl spec like everyone else? Isn't that as least as effeicent if not cost effective? Now look at this from a developer's point of view. What would you rather write to. A widely compatiable specification that runs on multiple graphics cards or a narrow one that runs on just three or four? Which one nets a wider potential customer base? Honestly, all this talk of Nvidia delveloping an entire OpenGl spec just for themselves is ridiculous. I can't find anything on their site to suggest that they are developing 1.5. Not a single newsletter or announce. Nothing. How could you possiblely test something like this when no one knows about it because info for it is so hard to find? Speaking of which, where exactly did you hear about OpenGl 1.5? I'm curious as to how you got wind of this "secret" spec they are developing.

"The only real difference between nVidia taking OpenGL 1.3->1.9 suffrix designations for themselves and 3dfx taking OpenGL and producing Glide"

Glide is dead. What decade are you living in? 3dfx no longer supports glide and they haven't for years. They have completely embraced OpenGL. How have they taken OpenGL and produced Glide? Seriously, where do you hear things like this? Do you care to provide some links to show me that they took OpenGl and produced Glide?

"is that nVidia's OpenGL's are open source which adhears to the mandate of OpenGL"

In order for it to "adhere to the mandate of OpenGL" it would have to pass before the ARB since they are the ones who regulate it. Unless of course you are going to deny the exsistence of the ARB and/or relavence.

"and yes funny you won't hear much about OpenGL 1.5 anywhere except if you're GeForce/Quadro FX owner, because the source and new isn't released until they're done "

According to the link above developers are notified ahead time so they can adapt to changes.Also...

Changes to the OpenGl spec can't be made by anyone member. They have to be approved of by the ARB which is composed of the members above. Face it Raven, your wrong on this one. Your going to have a hard time explaining away this one.

"Also... i don't mean a Fragment Shader by Texel Shader, GeForce/Quadro card have something called a Texel Shader Engine Pipeline"

Uh...I have no idea what your talking about.http://www.nvidia.com/view.asp?IO=IO_20030117_6779
There is no mention whatsoever of any "Texel shader Engine Pipeline."
Why not use just fragments? You can achieve the exact same thing.

"and if you don't the difference between a Texel and a Pixel i'd suggest you do alot more homework here!"

Texel is merely a pixel in a texture and is named such in order to avoid confusion with pixels on screen. Which leads to my earlier confusion with you regarding pixel shaders and "texel" shaders. You can manipulate texels with fragment shaders quite easily. Take this simple Cg code for example:

Essential what it does is access texture coords and out puts them to the rasterizer. Nothing big in fact the graphics hardware will do this for you anyway but my point was that you could access texcoords and the data they point to(texels) with fragment(aka pixel) shaders anyway so why create a special pipeline just for "texel shaders?" It just doesn't make any sense.

"Especially as most cards are capable of producing Texels within the pipelines, however Texel Shader is something which is relatively new and ONLY used within 3D Rendering Packages."

Why? As I stated above you can achieve the same thing with Fragment shaders. Can you site which 3d Rendering Packages use Texel shaders? I'd like to research this further.

"Another point should be made that Render Engines yes use Software Shaders, but they're capable of also using Hardware Shaders too "

Yes and what does this have to do with what I was saying???

"However niether use the CPU in either Renderman, Messiah or Brazil 1.1 (which most will see soon)"

I'm to tired to argue this so I'll just let it slide. I don't care.

"Finally do you understand the difference between a
Hardware Abstract Layer, Rasteriser & RAMP Emulation?"

Yup.

"it seems like both people making the major points here have read some little things and gone through help not actually knowing the technology behind which is what is being used to produce these results - what order they're being produced within and how the Software Drivers are telling the APi system, DirectX in this case howto go about thier calculation routines."

By "both people" do you mean us? Or are you refering to Just ED and I. After all of those links to hardware specs explaining to you how you were in error I can't help but not see how you are not included in this "read some little things and gone through the help not actually knowing the technology behind it"
when you repeatedly ignore everything I say that proves you wrong.

"you just feel like because you've read and can quote the help that you actually have the faintest idea what your going on about "

Thats because I do. If you think otherwise that prove what I've said to be wrong.

"and if i had the time to actually spend a few hours bloody trawling through each of the sites and help files i might actually show quotes from the same texts which could contratry your own quotes."

I won't hold my breath.

"I'd suggest rather than sitting here trying to disprove me you go and put those research skills to some good use and ACTUALLY learn the technology you're trying so hard to defend here"

I have. You on the other hand continue to insist that ATI has no shading processor when I've no less than three times provided a link to a tech paper detailing the very shader processor that you so vehemently deny exists.

"perhaps then you'll relise what your trying to propose is actually impossible for it to pull of the way you believe it is being done."

What exactly is the "way I believe it is being done?" Is it that Radeons execute shaders on their hardware? If it is so "impossible" then why have multiple users posted here claiming to the contrary? What of all the links I provided of examples to the contrary.

"lastly you mention the CgFX emulation - you've obviously not got very with nVidia Shaders if you're not sure what CgFX is"

I know exactly what CgFX is. What I was questioning is was whether you know what CgFX is. From the sound of what you were saying was that CgFX was only for emulation. I wasn't sure what you were saying so that was why I asked for clairifaction.

"i mean its on the frontend of the website for it and as you've mentioned the Tutorials for it"

I mean the Cg Tutorial the book, not the downloadable tutorials(I have them too.)

" already i figured you'd downloaded the NV30 Emulator which allows any nVidia card which is comptible with Detonator4 43.01 Drivers or better to Emulate ALL of the Shaders capable on the GeForce FX NV30 ... and it doesn't do it through the CPU either!"

*sigh* Look Raven, if it doesn't run on the cpu what does it run on? The Gpu? If the Gpu then please explain to mean how the GPU calculates instructions that it was never designed to calculate! How would a geforce 4 ti gpu calculate vertex shader 2.0 instructions? How would it calculate setup instructions like defb, and defi? Or how about mova? Or what about macros like abs, crs, expp,logp, lrp, nrm, pow, sincos, slt? Or static flow control instructions like call,callnz, else, end, endif, endloop, endrep, if, label, loop, rep, ret? All of these are new instructions and can not be supported by hardware that wasn't designed to execute them. And this is just vertex shader 2.0. I won't even get into the other shaders. The only way that these can be "supported" is through software emulation like the NV30 emulator which uses the cpu calculate these instructions for the gpu. If the gpu were capable of calculating these instructions then why emulate them? Raven, you drive me up wall!http://developer.nvidia.com/view.asp?IO=nv30_emulation


"It is still and emulator and they are still software shaders - but i'm sure you can figure out someday how that works."

You are the most stubborn person I have met(other than myself of course).

My last post in this thread: Raven - your language was quite unclear and implied an SDK release.

For those who actually read my post properly, Mike already wrote the demo - I will email him and ask for permission to release it. If he says fine, I will post it here. (Under a new thread.)

@Guy

Thats good to hear.

read what i wrote... its not the fact that DirectX 8.1 doesn't support it, its a fact that the nVidia Drivers UNDER DirectX 8.1 don't add the support for it - all drivers past 41.00 stopped enhanceing the performance for DirectX 8.1 and they started on DirectX 9.0 as it was suppose to become the new standard soon after. And the different pipeline architecture within DirectX 9.0 for the new features which gives a great performance boost (which wasn't the version originally planned for release) also makes alot of feature incompatible backwardly, in much the same way that DirectX 8.1 is completely different Architecture to DirectX 8.0



quite easily... as although they were developed specifically with nVidia cards (GeForce Series) in mind, the functions are fully released and available for other manufacturer's suchas ATi, Sonic Blue, Videologic/Imagination Systems, etc... to develop support for thier cards for functions which were becomming very much standard anyways.

and as i've noted this is VERY different to the Glide approach taken by 3dfx, which was OpenGL - all it was, was a version SPECIFICALLY developed and recompiled only to run on 3DFX Voodoo Cards. This is how it gained so much speed however this is also why they could use OpenGL programs off the bat.
The same goes for PowerVR (which was still in service with the Kyro2 a matter of 2years back) ... that is also another OpenGL which was made specifically for a certain brand of graphics card.

This is why the OpenGL's current being released with the updates from nVidia are being released - because they're not compiled for a specific card, its more a case of thier adding extra commands and support. It was like Microsoft adding support for Pixel/Vertex Shaders in DirectX even though GeForce was the ONLY card to support them ... its not to be graphics card specific but to add functions which everyone can use which just so happens to be already 100% inplace on one media. Having the Developers of that particular piece of hardware creating the drivers is a far more sane task meaning that there is a true standard set than the usual OpenGL "we'll make it and hope most cards can run it" attitude.



they're supported as the GPU on a GeForce card isn't the same as the Graphics Processor on a Radeon ... firstly, they're capable of getting upgraded instruction sets which the GPU can rely on through thier BIOS which is capable of holding 4mb of dynamic updates (as it is a flash bios).
secondly the GPU is not designed the same was as a processor with specific instructions, it is a MISC processing unit - there are very few optimisations other than the fact it is cast on a micron die. Essentially they've designed a processor which will take the graphics, they have 3 layers to them...

1st Layer - Standard Processing Functions, Maths & Floating Point Unit
2nd Layer - GeForce RISC Instruction Processor
3rd Layer - Shader Processing Unit

it has 6 pipeline to handle what goes where faster accessing, bypassing and storing in the onboard Ram to process everything ... in the GeForce/Quadro FX units they've upgraded the 1st & 2nd layers with 57 additional instructions sets specifically for added colour bandwidth to handle upto a theoretical 256bit colour and calculations, in reality this trickles down as a 128bit to keep things fast.
The FPU was updated to handle .5 megabit Floats which are set to be supported in Windows .Net - added with the .14m cast makes it a very adaptable, almost as flexible as the main CPU itself now.
The idea being on emphasising thier cards to be used for atleast 2-3generations on as at some point they need to slow down development as the FX chip cost them ~$300 million to produce.
As the take up is set to be less than last time this chip has to last for a while, which is also why the MX versions are simply speed cut and nothing else over the Ti versions - cast on a .18m so they also run slightly cooler.

that aside... all of the GeForce cards have FPU & Math Units which are comparible in setup and speed to Pentium2 Processors, this can be AS slow as the processors especially as they can only handle 32instruction sets per cycle rather than the 128 the current standard CPU's can.



on my GeForce2 Go! the emulation of most Shaders works at quite an admirable speed, ~120fps for standard Shader sets - ~50fps for Time/Light Shader sets, admitedly this is crap compaired to the NV30 itself which produces these results at ~520fps for standard Shader sets - ~380fps for Time/Light Shader sets (the demonstration ones)...

however considering my FX is running at AGP8x has triple the pipelines my Go! has and is 750Mhz faster, with built in support for these features - its not really suprising that its alot faster.
However if i put in my GeForce 256 Ultra, the speed drops ... yet i play the demo on another system the speed increases on my other systems - but only when using the NV30 Specific functions, suchas the Time/Light Shaders.

lastly a Texel isn't a Shade of a pixel on a texture/image, but the combined layer of a pixel cut into a 2x2 set which allows for greate shading depth before combined to produce the final effect.

4 Texels to a Pixel -> however that said the Texels don't base themselves off of the Pixels but the 3D Vector Data - take ths shading and editing points from that which is spread across each pixel.
If you think of them kinda like an Effect Layer within Photoshop where you add things like Shadow, Glow, etc... which can be set to affect at any depth you choose. So its there to affect the pixels - but not part of the pixels themselves

oh and i know that he has a demo for this stuff, BUT as i mentioned don't release it... mike already has enough on his plate right now, without adding to that with everyone bugging him about how everything works in his demo. And don't tell me this won't happen because we both know damn'd well it will!
- and seriously is said grab from the DirectX SDK, how on earth could have you misinterpreted that i said Mike was releasing an SDK for this.

"read what i wrote... its not the fact that DirectX 8.1 doesn't support it, its a fact that the nVidia Drivers UNDER DirectX 8.1 don't add the support for it "

Thank You. Its taken me three days to get you to say that Nvidia doesn't support PS 1.4 in their hardware. Or am I being hasty in coming to the conclusion that you finally agree with me? I can't see any other possible explaination for their drivers not registering 1.4 other than the fact that they don't support it in their hardware else why would they leave a feature completely unsupported by their drivers?

" all drivers past 41.00 stopped enhanceing the performance for DirectX 8.1 and they started on DirectX 9.0 as it was suppose to become the new standard soon after. And the different pipeline architecture within DirectX 9.0 for the new features which gives a great performance boost (which wasn't the version originally planned for release) also makes alot of feature incompatible backwardly,"

Stopped enhanceing, yes. Stopped supporting, no. So even if what you say is true with regards to the drivers, I don't see how they could fail to implement all the features from directx 8.1 seemings how 8.1(and 7.0) are included in the DX 9 runtime. If they didn't support Directx 8.1 features then anything Pre-DX 9 wouldn't run on their cards. That sounds like a finacial catastrophe waiting to happen.

"in much the same way that DirectX 8.1 is completely different Architecture to DirectX 8.0"

COMPELETLY different? I doubt it, though I could be wrong on that one. Anyway, it can't be too different because PS 1.1 and VS 1.1 were inherited from DX 8 and can still be used in hardware that supports DX 9. So even if there are incompatiablities(which there might be) that doesn't mean there are necessarily pixel(or vertex) shader incompatiablities.

" quite easily... as although they were developed specifically with nVidia cards (GeForce Series) in mind, the functions are fully released and available for other manufacturer's suchas ATi, Sonic Blue, Videologic/Imagination Systems, etc... to develop support for thier cards for functions which were becomming very much standard anyways."

I think I've finally figured out what you mean by all this. What you're talking about is extensions which is what I thought you were talking about all along. When you were saying something about entire specifications(eg. OpenGL 1.3, 1.4, 1.5) being made competely by Nvidia you must have meant that many(if not most of the) extentions were developed by Nvidia that were finally incorporated and approved by the ARB into the next revision of OpenGL thus effectively making it "their's". I thought you meant they just made the entire spec for themselves which doesn't make any sense because it wouldn't run on any other cards and thus defeat the purpose of being a standard(which OpenGl is) and the finacially reasons to develop for it(cross-platorm = larger market share). As to whether Nvidia made most of the extensions...[href] http://oss.sgi.com/projects/ogl-sample/registry/[/href]
Of the 28 ARB approved extentsions produced only 11 mention Nvidia and out of that many only 4 mention Nvidia as the sole influence in its creation(I'm going by contact info.) Also of interest is that out of all ARB extensions only one is claimed as intellectual property of Nvidia(gl_ARB_vertex_program) and that claim is contested by microsoft. And in case your wondering, these extenstions are not just for the current OpenGL spec. Some of them go back to before OpenGl 1.2(gl_ARB_Multitexture) as that extentsion became part of the OpenGL 1.2.1 spec in 1998. As for non-ARB approved extentions only 33 out of 290 were made by nvidia.

" and as i've noted this is VERY different to the Glide approach taken by 3dfx, which was OpenGL - all it was, was a version SPECIFICALLY developed and recompiled only to run on 3DFX Voodoo Cards. This is how it gained so much speed however this is also why they could use OpenGL programs off the bat.
The same goes for PowerVR (which was still in service with the Kyro2 a matter of 2years back)"

And look where Glide and PowerVR ended up. Glide is no longer supported seemings how 3dfx has completely embraced OpenGL and justs writes extentsions for it instead of make new specs now. And STMicroelectronics? I believe they completely abandoned the 3d accelerator market. So I'll stick by my previous statement about the finicial soundness of making your own spec.

"This is why the OpenGL's current being released with the updates from nVidia are being released "

Really? Where? I haven't seen any mention of any current OpenGLs being released by Nvidia. Perhaps you could provide a link to their site where they are releasing them to prove otherwise(And no I don't want just a reference to nvidia.com I want the actual link that takes me to the page where you can download it from. Shouldn't be too hard for you too produce a link if what you say is true because you know exactly where to look.)

" because they're not compiled for a specific card, its more a case of thier adding extra commands and support."

Now I know you mean extentsions. And while were talking about these extentsions. Is this what you mean by OpenGL 1.5 for the FX series?
http://developer.nvidia.com/docs/IO/1174/ATT/nv30specs.pdf

"Having the Developers of that particular piece of hardware creating the drivers is a far more sane task meaning that there is a true standard set than the usual OpenGL "we'll make it and hope most cards can run it" attitude."

All though I'll agree that having the developers of a paticular peice of hardware write the drivers for that hardware is a sane way to go about it I disagree with your assesment that the OpenGL attitude is a "we'll make it and hope most cards can run it" attitude. That might be true of Directx but not OpenGL. Nothing gets into the OpenGL spec without prior approval of the Architecture Review Board which is made up of the top 12 graphics card manufacturers. Why would they approve something that they can not support?

"they're supported as the GPU on a GeForce card isn't the same as the Graphics Processor on a Radeon ... firstly, they're capable of getting upgraded instruction sets which the GPU can rely on through thier BIOS which is capable of holding 4mb of dynamic updates (as it is a flash bios)."

First even if what you say is true, Nvidia drivers don't touch the bios.http://www.nvidia.com/view.asp?IO=IO_20011119_6206

As the FAQ states, messing with graphics cards bios can damage the graphics card permenently. Since bios vary from manufacturer to manufacturer, Nvidia doesn't touch the bios with their drivers. So your previous argument that a combination of new drivers and NV30 emulation would run the shaders on the gpu is null and void. As for the bios adding new instructions, I tried to check with my graphics card manufacturer(VisonTek) but it appears that they were bought out and now support ATI cards instead. They still support some of the old geforce 4 cards that they manufacture but that was with drivers only. I could find no mention of any video bios upgrades anywhere on their site. However, there were some parts of their site that were down so they may have some updates I just can't reach them. Could you provide the name of your manufacturer so I could check?

"secondly the GPU is not designed the same was as a processor with specific instructions, it is a MISC processing unit - there are very few optimisations other than the fact it is cast on a micron die. Essentially they've designed a processor which will take the graphics, they have 3 layers to them...

1st Layer - Standard Processing Functions, Maths & Floating Point Unit
2nd Layer - GeForce RISC Instruction Processor
3rd Layer - Shader Processing Unit"

http://developer.nvidia.com/view.asp?IO=IO_20020721_4874
From what I can see its not quite like that. If you have power point then I suggest you download the presentation and go in four slides. There you will see this diagram entitled GPU programing model.


Not to sound too picky but that doesn't exactly line up with what you have been telling me before.

" added with the .14m cast "

.13m

"on my GeForce2 Go! the emulation of most Shaders works at quite an admirable speed, ~120fps for standard Shader sets - ~50fps for Time/Light Shader sets, admitedly this is crap compaired to the NV30 itself which produces these results at ~520fps for standard Shader sets - ~380fps for Time/Light Shader sets (the demonstration ones)...

however considering my FX is running at AGP8x has triple the pipelines my Go! has and is 750Mhz faster, with built in support for these features - its not really suprising that its alot faster.
However if i put in my GeForce 256 Ultra, the speed drops ... yet i play the demo on another system the speed increases on my other systems - but only when using the NV30 Specific functions, suchas the Time/Light Shaders."

You forget to mention the cpu setups on your other systems. Still, you can't escape the fact that Nvidia itself said the emulation occurs on the cpu. I can see where you were lead astray into believing that they were working on the gpu, but still...Nvidia itself has said it runs on the cpu. End of story.

"lastly a Texel isn't a Shade of a pixel on a texture/image, but the combined layer of a pixel cut into a 2x2 set which allows for greate shading depth before combined to produce the final effect."

Thats not what my sources say.http://www.tomshardware.com/graphic/20000427/geforce2-03.html
I also take my definition from my copy of Real Time Rendering second edition. I'd qoute out of them but since there is no way to varify what I'm saying is what they are saying I won't.

"4 Texels to a Pixel -> however that said the Texels don't base themselves off of the Pixels but the 3D Vector Data - take ths shading and editing points from that which is spread across each pixel.
If you think of them kinda like an Effect Layer within Photoshop where you add things like Shadow, Glow, etc... which can be set to affect at any depth you choose. So its there to affect the pixels - but not part of the pixels themselves "

I don't know about this 4 to 1 thing but it sounds like you got them confused with a fragment.http://developer.nvidia.com/view.asp?IO=docs_fragment_processing

yes the OpenGL 1.5 revision is almost exclusively for the FX chipsets which is why it is OpenGL 1.5 as a revision and extension rather than 2.0 which is running a completely new set of libraries.

you can get the new libraries with the NVSDK 6.0 & CgFX toolkit 1.1 - but for some annoying reason you have to install and setup the libraries and inclusion files yourself (which is annoying as the setup tells you its done it for you!)

nVidia may have renamed the effect fragment processing, but from what i gather from this technique all it does is take the 3->8 surrounding pixels of a pixel and quick shades them based on the previous layer.
as what the Texel is doing is creating a layer between the 3D and 2D (2D.5 i remember it being called a while ago) it allows you to shade each pixel based on the 3D Shading routines meaning you could get much more vibrant, or deeper shades of colours just to add that soft and realistic touches.

the reason i didn't say the processor setup was because they're running on similar systems ... AlthonMP 1200+ and AlthonXP 1300+, the speed differences are minimal (both systems have AGP8x) - The Quadro FX is currently running on an Itainium system, so mentioning anything from that is a waste of time as a)its running on x86-64 and b)i have 2 of them on a Quad Processor system, which DirectX9 is capable of taking advantage of.
So i made sure that i took one out and put it in the GeForce4 system which is as of 3hours ago officially dead - as i accidentially shorted out the CPU teach me not to ground myself before pissing about with hardware ho hum.

i'll get you the name of the major nVidia manufacturer you can check for updates ... the site is playing up right now

"yes the OpenGL 1.5 revision is almost exclusively for the FX chipsets which is why it is OpenGL 1.5 as a revision and extension rather than 2.0 which is running a completely new set of libraries."

If it's one thing that continuely puzzles me it's where you get the "OpenGL 1.5" from. I can find no reference to their extentions being refered to as "OpenGL 1.5" but I can find plenty of their extentions.http://developer.nvidia.com/docs/IO/3260/ATT/nv30specs.pdf
This link takes you to the Nvidia OpenGL Extension Specification for the CineFX architecture and is what you are talking about correct? I couldn't find anything mentioning OpenGL 1.5 in their sdk but then again info in their sdk, other than source, was sparse. There was plenty of source code both for their libs and their tools but as I said no mention of OpenGL 1.5 in the source or anywhere else. Did hear the name OpenGL 1.5 from Nvidia or elsewheres or did you draw the conclusion that it was OpenGL 1.5 from the fact that they were extending OpenGL? If the former, could you specify where or when? It would be greatly appreciated as it would clear up the confusion surrounding this issue.

"nVidia may have renamed the effect fragment processing,"

Why rename it when, as you say, it is so "new"? Where percisely did you hear this term anyway? I'm curious.

"but from what i gather from this technique all it does is take the 3->8 surrounding pixels of a pixel and quick shades them based on the previous layer."

This sounds a lot like fragment(aka pixel) shading or at least something that can be done with it. Also, what exactly do you mean by "layer"? Does this mean that it is dependent on both the previous and the present state of the pixel that it is shading or did you mean something else?

"as what the Texel is doing is creating a layer between the 3D and 2D (2D.5 i remember it being called a while ago) it allows you to shade each pixel based on the 3D Shading routines meaning you could get much more vibrant, or deeper shades of colours just to add that soft and realistic touches."

Definately something that fragment shaders could do.

"the reason i didn't say the processor setup was because they're running on similar systems ... AlthonMP 1200+ and AlthonXP 1300+, the speed differences are minimal (both systems have AGP8x)"

Yes but do they take advantage of it?

"- The Quadro FX is currently running on an Itainium system, so mentioning anything from that is a waste of time as a)its running on x86-64 and b)i have 2 of them on a Quad Processor system, which DirectX9 is capable of taking advantage of."

Thats all well and good but it still doesn't detract from the fact that Nvidia itself said that the NV30 emulation is run on the cpu. I'm not sure what factors could have lead to the speed differeces your seeing but its a moot point.

"So i made sure that i took one out and put it in the GeForce4 system which is as of 3hours ago officially dead - as i accidentially shorted out the CPU teach me not to ground myself before pissing about with hardware ho hum."

I'm sorry to hear that.

"i'll get you the name of the major nVidia manufacturer you can check for updates ... the site is playing up right now"

I await your reply.

it was dubbed 'OGL 1.5' a good few months back, about 5 when they started developing the FX chips drivers ... was part of the new letter. They probably renamed it CineFX/NV30 OpenGL Extensions - probably cause non of the extensions have been fully approved yet, they did the same with OpenGL 1.4.1 stuff. They released as the Cg Extensions, it later became the 1.4.1 extension set - nVidia have a habit of forcing alot of things on the market before they're fully tested (just look at how long it takes for thier drivers to become WHQL compliant!)

"it was dubbed 'OGL 1.5' a good few months back, about 5 when they started developing the FX chips drivers ... was part of the new letter."

By "new letter" I'm assuming you mean news letter? I checked their achives and couldn't find much concerning OpenGL specs or at least for the CineFX architecture. The link for the archives that I searched is here: http://developer.nvidia.com/view.asp?PAGE=news
I don't know if its in there or not. Is there a news letter of theirs that is only for developers who subscribe(e.g. not available to the public?).

"They probably renamed it CineFX/NV30 OpenGL Extensions - probably cause non of the extensions have been fully approved yet, they did the same with OpenGL 1.4.1 stuff."

Alright. I understand what you are saying now. Thank you for helping to clear this up.

"nVidia have a habit of forcing alot of things on the market before they're fully tested (just look at how long it takes for thier drivers to become WHQL compliant!)"

I noticed that too.