PowerVR VS 3.0 Demo!!!

So what does this all mean?

The program that tests SM3.0 is poorley coded?

Nvidia's SM3.0 part/6800 is a hoax and doesn't support SM3.0 properly?

More work need to be done on the drivers for the 6800 to run the SM3.0 paths?

nvidia's hardware (6800) is a poor design and doesn't have enough implementations in hardware to functionally support SM3.0??

I don't have a clue here...some one please enlighten me. :idea:


I would really like to know if the 6800 is in reality just an overated part that will in actuallity be unable to run SM3.0 proficiently or whether the opposite is true.?

Also, can the 6800 run SM2.0+ proficiently? or are there major problems for the 6800 even running shaders at that level.?

:?: :?: :?:
 
You can program on a platform so that it won't work on another.

It's easy to do it on purpose, but it's also easy to do it by accident (see farcry that didn't run correctly on nv40 before the first patch and other errors commonly made like the "pow2/nonpow2conditional" caps).

Sometimes it requires a crystal ball to do things right so it's not necessarily one person or another one's fault.
 
I believe the reference rasterizer will run the demo, albeit extremely slow...
 
i think the sm3.0 driver is not full ready yet , nvidia have remove the sm 3.0 flag in newly drivers .
 
DemoCoder said:
It could be failing to run simply because a surface format isn't available, this is fairly common.
Click to expand...

This is the case for the D3DCloth demo AFAIK, it uses a format which NVIDIA currently (?) does not expose in their drivers ? Also AFAIK if you work around this (which is trivial and easy to do and source is available) then it still does not work, the cloth does not show up (just the sphere) ... driver/HW bugs ?

The D3DVoxel demo needs a one letter change in the shaders to use texldl (user supplied LOD) since the other texture sampling functions are no longer supported within branches (not a limit in place at the time of writing of the demos). This demo will be updated with this fix at some point.

K-
 
Tha Man Himself

There you go, straight from the hourses mouth.

Just Curious K, what texture does nVidia NOT support?
 
Ante P said:
I've tried running the dmeo after installing DX9.0c on an NV40 with 61.11 and it just complains about lack of SM3.0 support.

Pixel Shader 3.0 in Shadermark 2.1 works perfectly though (except for one test which is all f'ed up)
Click to expand...

does ShaderMark 2.1 out yet???
 
Re: Tha Man Himself

Jodi said:
There you go, straight from the hourses mouth.

Just Curious K, what texture does nVidia NOT support?
Click to expand...

Currently D3DFMT_R16F, seems like they only support formats which are 32 bits in total, so they expose R16G16F and R32F but non of the others. At least thats based on the info I have so far.

Anyway how are the sheep, Richard ? 8)

K-
 
Kristof, is it still a requirement for SM3.0 on DX9.0c? I've read that some requirement for the demos are no more requirement for SM3.0.
 
Evildeus said:
Kristof, is it still a requirement for SM3.0 on DX9.0c? I've read that some requirement for the demos are no more requirement for SM3.0.
Click to expand...

I am not sure what you mean ?

AFAIK there are 2 SM3.0 demos, one is my Cloth demo which has no issues with DX9.0C as it was released - no code changes are required and it will work on all released versions of DX9 AFAIK using the refrast. The other demo is Voxel and this one will no longer work as is on the DX9.0C release because it uses a texture access with automatic LOD determination inside a dynamic branch - now this means that potentially some pipes end up disabled meaning HW might not be able to accurately determine the LOD. For this reason DX9.0C only allows texldl instruction within branches and with this instruction the program itself needs to calculate and supply the LOD value. An updated version of Voxel should be available soon.

The exposed texture formats are tricky, AFAIK there are certain minimum spec of texture formats that have to be exposed but I am not sure if this includes the various float variations. At the time of coding I just used the smalest format suitable and using R16F is more sensible than using R16G16F with the G-component containing nothing... but its an easy code change to make, actually its 3 letters added in the source code :LOL:

[added] Or do you mean is it possible to translate this demos to SM2.0B ? Cloth uses vertext texturing which is not exposed in 2.0b so thats not possible. I think I have a loop inside the cloth PS which I assume you could now unroll and run on SM2.0B. Voxel uses dynamic branching in the PS again not supported in SM2.0B and probably tricky and slow if you decided to unroll and hack the branching in using multiply by zeros.

K-
 
Thanks, your reponse was really informative. I was speaking of SM 3.0. Why do you think the cloth's demo doesn't work on NV40?

My only reference on that is this quote (in french):

L´équipe de développement de PowerVR qui a pas mal travaillé sur les Pixel et Vertex Shader 3.0 (tant au niveau software que hardware) a publié il y a quelques mois plusieurs démos faisant appel aux Pixel Shader 3.0. Ces démos ne pouvaient tourner qu´en mode software auparavant. Tournent-elles correctement sur le GeForce 6800 ? Non.

Elles ne se lancent d´ailleurs même pas. Elles sont en fait tout simplement incompatibles avec DirectX 9.0c qui a introduit quelques limitations dans les Pixel Shader 3.0. Il est ainsi interdit d´utiliser des textures dépendantes et quelques autres instructions à l´intérieur d´une branche. Cette nouvelle limitation n’avait pas pu être prise en compte au moment de la réalisation des démos vu qu´elle n´existait pas. Cette limitation a-t-elle été introduite par Microsoft pour coller à celles du hardware ?
Click to expand...
http://www.hardware.fr/articles/491/page6.html
 
Evildeus said:
Thanks, your reponse was really informative. I was speaking of SM 3.0. Why do you think the cloth's demo doesn't work on NV40?
Click to expand...

I have been talking to those guys trying to get the demo to work, and they tried a version which uses supported texture formats and I don't use filtering on the vertex texture so it "should" work on NV40 based on its CAPS but it did not. The demo should show a cloth falling on a sphere and on NV40 only the background and sphere showed up when they tested it. The cloth did not show up and there was no debug warnings or output so its really in NVIDIAs hands... its not an application issue since it all works fine on the refrast and there are no failing D3D calls. Could be all kinds of issues I use MRTs which is "new" for NVIDIA, and possibly their vertex texturing implementation is not complete ? Hard to say... its definitely not a simple demo quite a bit of stuff going on even though it looks simple.

All AFAIK... I'll be happy to spend some more time on it if someone sends me a free NV40 :devilish:

K-
 
Ok, thanks. If i understand you correctly it's the Nv40's drivers that doesn't make the demo to work, atm and AFAUK?
 
Evildeus said:
Ok, thanks. If i understand you correctly it's the Nv40's drivers that doesn't make the demo to work, atm and AFAUK?
Click to expand...

Correct. Not sure if NVIDIA has released newer drivers in the mean time. I think the french guys did report the issue but I have heard nothing new so far.

K-
 
Ok, thanks for the precisions Kristof. I hope to see it working on Nv40 (and Series 5
whistle.gif
)
 
You must log in or register to reply here.

Similar threads

Rys
  • Sticky
Hello again
3 4 5
Replies
91
Views
12K
homerdog
homerdog
Rys
Reopening Architecture and Products + rules and guidelines changes
3 4 5
Replies
90
Views
16K
Shifty Geezer
Shifty Geezer
G
Is there a Windows wizard in the house?
Replies
14
Views
4K
Grall
G
Rys
Subscriptions and Donations
3 4 5
Replies
96
Views
32K
entity279
E
V
  • Locked
Open letter yo AMD Staff - FreeSync and my misconceptions
2
Replies
37
Views
10K
Shifty Geezer
Shifty Geezer
Back
Top