Original Radeon and DirectX 8 - clarification needed

let me guess chalnoth you got a kt400 board? I have had this same problem but only on the kt400 board everything seems to work great with 2.4.22 kernel with the nforce2 board if you use the externel agpgart driver built into the kernel.
 
nforce2. I used the agpgart kernel patch from the 261 nVidia Linux nforce drivers, applied to a 2.4.20 kernel. I suppose I could try a newer kernel version.
 
I still wonder (after a year selling R100 / Rage6 based AIW off) what on earth happened on PS 1.0 and VS 1.0 spec? I haven't seen any paper describing it's features ever. Only I know that it was based on mostly 3dfx hardware (rrrrrrrrrrrampage, wohoo... I just opened pandora's box.) but did nvidia made it to vanish? they certainly would have reasons for that.
 
Nappe1 said:
I still wonder (after a year selling R100 / Rage6 based AIW off) what on earth happened on PS 1.0 and VS 1.0 spec? I haven't seen any paper describing it's features ever. Only I know that it was based on mostly 3dfx hardware (rrrrrrrrrrrampage, wohoo... I just opened pandora's box.) but did nvidia made it to vanish? they certainly would have reasons for that.
Just download the DX8 or 8.1 SDK - it's all in there. Having said that though, what exactly are you referring to when say "features"?
 
This Post at Rage3D from JasonM back when it turned out the Radeon DDR didn't support Dx8 pixel shaders is the clearest collection of information that has ever been posted on the subject.

Follow that thread through page 2 and 3 for posts containing further information on the subject from Jason as well.

(There is a reason I keep the entire Rage3D forum "online". ;))
 
Ah. . . Definitely some good information! A while back when this same question was asked on some forum, with text from an old ATI tech document quoted, I thought that the capabilities mentioned sounded a heck of alot like the texture combining functionality in OpenGL (via ARB_texture_env_combine). Good to know that I was on the right track. . .
 
Neeyik said:
Nappe1 said:
I still wonder (after a year selling R100 / Rage6 based AIW off) what on earth happened on PS 1.0 and VS 1.0 spec? I haven't seen any paper describing it's features ever. Only I know that it was based on mostly 3dfx hardware (rrrrrrrrrrrampage, wohoo... I just opened pandora's box.) but did nvidia made it to vanish? they certainly would have reasons for that.
Just download the DX8 or 8.1 SDK - it's all in there. Having said that though, what exactly are you referring to when say "features"?


I did that and now I wonder, why on earth there's 1.0 and 1.1 versions? only thing I found differ on 1.0 than 1.1, is Blue replicate on Source Register selectors. :? change is so minimal that at least I don't get why make new version for it...
 
The other differences between PS1.0 and 1.1 involve register read limits and the way that certain instructions are counted:

Instruction count exceptions for pixel shader version 1.0, 1.1, 1.2, 1.3:

> For version 1.0 only, the tex instruction does not count toward the total number of instructions, although it does count toward the total number of texture address instructions.

> In version 1.0, texbem counts as two texture address instructions. In versions 1.1, 1.2, and 1.3, texbem counts as one texture address instruction.

> In version 1.0, texbeml counts as two texture address instructions plus one arithmetic instruction. In versions 1.1, 1.2, and 1.3, texbeml counts as one texture address instruction plus one arithmetic instruction.

PS1.0 total per pass = 8
PS1.1 total per pass = 12

Read port limit
Constant register > 1.0 and 1.1 = 2
Temporary register > 1.0 and 1.1 = 2 2 2 2 3
Texture register > 1.0 = 1 / 1.1 = 2
Color register > 1.0 = 1 / 1.1 = 2

Read/write limits
For PS1.0, the texture register can only be read/write for texture addressing instructions and read only for arithmetic ops. PS1.1 or higher, it can be read/write for both.
 
Neeyik said:
The other differences between PS1.0 and 1.1 involve register read limits and the way that certain instructions are counted:

Instruction count exceptions for pixel shader version 1.0, 1.1, 1.2, 1.3:

> For version 1.0 only, the tex instruction does not count toward the total number of instructions, although it does count toward the total number of texture address instructions.

> In version 1.0, texbem counts as two texture address instructions. In versions 1.1, 1.2, and 1.3, texbem counts as one texture address instruction.

> In version 1.0, texbeml counts as two texture address instructions plus one arithmetic instruction. In versions 1.1, 1.2, and 1.3, texbeml counts as one texture address instruction plus one arithmetic instruction.

okay, I got it... I have been busy working on with some NFS4 editor tools that does not involve using any PS stuff (wow, wow, that is so suprising for game that is 4 years old. ;) gosh, the only D3D part in the editor is the d3d track biewer done by "Mr. Hoo" and uses RM mode from DX5. :p oh well, maybe it is time to rewrite the track drawing routines with Glut or D3d8... ) and I just took a peek of differences described in Dx8.1SDK...

Neeyik said:
PS1.0 total per pass = 8
PS1.1 total per pass = 12

Read port limit
Constant register > 1.0 and 1.1 = 2
Temporary register > 1.0 and 1.1 = 2 2 2 2 3
Texture register > 1.0 = 1 / 1.1 = 2
Color register > 1.0 = 1 / 1.1 = 2

Read/write limits
For PS1.0, the texture register can only be read/write for texture addressing instructions and read only for arithmetic ops. PS1.1 or higher, it can be read/write for both.

well, these explains a lot of why there's PS 1.0 and 1.1. Here differences get so big that it would make some HW guys angry if their better stuff would not be supported.

thanks for explaining this stuff, though most likely I never need this information much more than rats ar**... Still, it is something you can share in guru coffee table conversations. ;)
 
Back
Top