Print

[openxdkman]

My study of xbox gpu is going well, but there is a "small" part i'm a bit unable to decipher with existing legal available stuff I have in my hands (and I wish to stick with legal stuff)... Beside this part all the rest is unrevealing itself nicely, no worry.

It's the encoding of vertex shaders.

Here is one (0x30 unsigned longs), probably the most common running on xbox, doing almost nothing special:
         0x00000000,0x0020001B,0x0836106C,0x2F100FF8,
         0x00000000,0x0420061B,0x083613FC,0x5011F818,
         0x00000000,0x0400001B,0x083613FC,0x2070F82C,
         0x00000000,0x0240081B,0x1436186C,0x2F20F824,
         0x00000000,0x0060201B,0x2436106C,0x3070F800,
         0x00000000,0x00200200,0x0836106C,0x2070F830,
         0x00000000,0x00200E1B,0x0836106C,0x2070F838,
         0x00000000,0x0020101B,0x0836106C,0x2070F840,
         0x00000000,0x0020121B,0x0836106C,0x2070F848,
         0x00000000,0x0020141B,0x0836106C,0x2070F850,
         0x00000000,0x0020161B,0x0836106C,0x2070F858,
         0x00000000,0x0020181B,0x0836106C,0x2070F861

It's a very basic one, that fetches data, processes it with parameters located in floats located nearby code
and gives out result

I'm writing this post, because I feel there may be some experts in NVidia GPUs reading this forum that may know legal sources that may be reused to disassemble existing shaders code and assemble new ones.

I would hate to be compelled to use shaders code written by others and not be able to add in my future commented demos shaders that are fully understandable and fully customizable by developper itself.

I have no idea if xbox gpu shaders are coded differently than other NVidia GPUs and if there is any official legal documentation on this low-level encoding.

So, I'm gathering all VS encoding related documentation (and tools sources) I can, with this post.

I still hope to publish some optimized 3D source code before end of year. It's damn slow to dig in undocumented stuff, but it should bring nice rewards. Even if VS stays opaque, I will do, anyway.

[openxdkman]

Shader works with 2 quaternion constants C0 and C1 (i.e quads of floats)

C0=XScale, YScale, ZScale, 1.0f
(1.0f can be replaced with ZScale*1/WFar, WFar calculated from projection matrix)

C1=XBias, YBias, 0.0f, 0.0f
(Bias is a kind of cosmetic value allowing better final result while targetting pixels for antialiasing passes)

(An amazing channel 9 podcast shows XNA in action. For people like me, who can't just throw $99 each year, I think optimized 3D can still be a nice way in front of xbox 360 single core jited xna sharpc dot net. And since it's too hard to do it on PC with random attached graphics hardware, last-gen console is great. Interviewed person admitted they could do it only because of the power of xbox 360, and that it would be impossible to do on xbox 1. That means there is a huge power loss between optimized compiled code and jited interpreted code. Even if, in the case of xbox 360, the gap is completely compensated by hardware power.)

This post has been edited by openxdkman: Nov 30 2006, 05:39 PM

[fghjj]

I'm not sure if there's anybody active here who can help you with this.

But yeah, the $99/year XNA subscription and a userbase 10 people kinda makes this uninteresting for homebrew. I think it's more intended as a platform for the small-time companies that currently make all those Flash mini games etc. They can make some money selling their games through Xbox Marketplace. Amateur gamedevelopers could use XNA to build a portfolio, so they can get a job "in the business".

I wouldn't worry about the speed of jitted code, I have yet to see a homebrew game (not a port) that could make full use of Xbox360 3D power. Best thing I can come up with is a free GPL FPS called Nexuiz which nobody in the world plays. You need a large game company to provide all the content if you want to make 100% use of nextgen hardware.

Anyway, I think it will be a major step forward for OpenXDK if it could just do GPU-accelerated 2D. Textured rectangles, alpha channels and some filters (bilinear interpolation etc) is basically all you need to get a smooth running emulator or video player

[openxdkman]

Ok, I will keep in mind the features you are expecting, for a future demo.

I've a better view now on what I still need to do to create a small nice demo, and I fear that it won't happen before next year (pixel shader and texture stuff is a bit too much for the remaining time before end of year)

But here is a last apetizer before the real meal. It's the code that clears a rectangle on screen at top speed.

p=pb_push_begin();
pb_push(p++,0x1D98,2);
*(p++)=((x2-1)<<16)|x1;
*(p++)=((y2-1)<<16)|y1;
pb_push(p++,0x1D8C,3);
*(p++)=Depth|Stencil;
*(p++)=Color;
*(p++)=Flags;
pb_push_end(p);

I love push buffers!

This post has been edited by openxdkman: Dec 6 2006, 04:46 PM

[_zlinky]

Hi, I see you've really been working hard on this vertex shader stuff

Have you looked at any open source NVidia GPU drivers?  That should help (especially if you need any fixed function pipeline stuff).  Try checking out nouveau @ http://nouveau.freedesktop.org/wiki/.  They have some info on Vertex Shaders for the NV20 which is the basis of the NV2A.  And I don't know how interested you are in any fixed pipeline stuff, but I can lead you in the right direction of GPU registers.  Just remember that the NV2A is just like or similar to other older NVidia GPUs such as NV01, RIVA 128, TNT, TNT2, GeForce 256, and even GeForce 2.  I've been studying NVidia GPU architecture for many months now and things are making alot more sense.  I'm not very knowledgeable about shaders though

[openxdkman]

Thx. Any piece of info is welcome.

I'm almost finished with my study of xbox gpu. I just need to see how pixel shader alpha and color combiners are encoded in gpu inner registers before I start to code some open source demo.

I call gpu inner registers the ones that are targeted by push buffer sequences.

Do you know if they are mapped to normal memory somewhere?
(I mean is it possible to just poke values to make small tests instead of using the push buffer dma engine?
 I dunno if it's possible and I dunno if there is an address where they can be found. For the push buffer commands it's an adress between 0x0000 and 0x1EA4 for 3D subchannel 0, and need to add 0x2000 for each subchannel, for now I've seen subchannels 2,3 and 4 used a very little bit beside the 3D subchannel)

Because, if I do a typo error in my first push buffer dma engine, I may be stuck for weeks before I find out the mistake.

About open source drivers... Each time I look at linux drivers I get strong headaches (insane wrappings)...
For the afl packet driver I've quicly used another method to get quicker to a simple & efficient result...

For shaders, I will use the default opaque passthru ones for now.

The riemers' tutorials (riemers.net) for xna are quite good for understanding the whole 'modern' 3D thing. It even invites you to use the free tool FX composer (a gift from a NVidia developper it seems) to code shader and even look at its disassembly. I guess I will just have to compare binary and this dissasembly to find out the shaders encoding. I'm confident that I will be able to do interesting comparisons between my xbox1 and my geforce 7300 gt on my pc. I can't believe there will be a too deep difference. Or am I wrong? Eventually I can reuse my old GeForce 2 or my old GeForce 4.

Thx for any info. I wish to help openxdk developpers and also to promote usage of standard PCs without harddisk (and thus without OS, just a bootable piece of code establishing network link with another full equipped desktop PC, through homeplug standard for example) as home theater pc (in order to be ready when xbox1 will become too rare, since for codecs the best way for now is to just reuse i386 dlls code with a trick).

If you have legal stuff, try to publish them and give us the link. The more the funnier... My first demo source will hold full description of all inner GPU registers.

This post has been edited by openxdkman: Dec 22 2006, 10:31 AM

[openxdkman]

I've visited the "nouveau" site before.
Actually, I'm using the constants of the "rules" file, and I've added many new ones (will appear in demo header). But about sources... I haven't really found something clear enough to reuse.

I'm in contact with d0wnlab who is very fond of Linux (I'm not), and I think he's interested in starting some mesa driver. So I leave to him the nasty digging. I'm sending him all my findings when I can.

Personally I will do a small, simple, code that may serve as a healthy base for more sophisticated stuff. I will try to do what Chris "Neovanglist" Gilbert did for ps2dev with his library gsKit. I will just use pbKit as library name (pb for push buffer). His approach is very "clean" and well fitted for modern 3D design, and most important, the speed oriented 3D design. I hate sources that are too much complicated for no reason. If you know what you want to do with the GPU you purchased, you shouldn't be forced to go through tons of useless opaque functions...

This post has been edited by openxdkman: Dec 22 2006, 11:08 AM

[Sirmatto]

This is all indeed very good news.  Once your documentation is complete, I would love to try to start porting over some simple, stupid PoC apps I've made.  I assume you will be porting this all back to OpenXDK?

[openxdkman]

What does PoC mean?

Yes, I want to rely on openxdk library. I have some ideas about a possible way to still have SDL working (and thus to have all existing sources compatible with openxdk+sdl running without a single change). If I manage to do things correctly, the SDL screen may just be considered by people that use pbKit as a pre-existing dynamically textured 3D rectangle in front of camera pre-defined in the persistent queue (and thus can be moved, turned... may be fun to have a 3D livingroom with an old console in front of a TV screen that is actually the SDL target surface and 'plays' the old console -already existing- emulator... or just SDLDoom).
It may also be possible to start from a 2D SDL game source and add 3D object in front of the 2D screen.
But that's a bit too early to promise that.

First demo will be quite simple. Hardware accelerated Pong will be enough, with AntiAliasing if possible... (maybe that will be the second demo). Lol... You can't imagine how complex is the push buffer engine alone (there is a dozen of dma channels to setup)... (but easy to use afterward once it's initialized correctly).

I won't promise any release date. All registers will be quickly explained, but useful samples (demos) will be released one by one slowly.

But don't worry, it's coming, because I'm obsessed by this, since I study GPU for 6 months now. Crazy...


This post has been edited by openxdkman: Dec 22 2006, 05:31 PM

[_zlinky]

Yeah, NVidia GPU's can be rather complex.  I've been studying them for a long time now too.  Also, is it ok if you write some documentation based on your findings on the NV2A?  That would be great.  I'll let you know if I find anymore NVidia documentation.  And I still don't understand exactly how NV DMA registers are accessed0 yet... only the FIFO registers.

[_zlinky]

Sorry for the double post (the forum won't let me edit my post), but I'm almost done figuring out how Nv10Dx6MultiTexturedTriangle works, I just need to learn the possible parameters and how many polygons can be rendered per call.  With lighting figured out already, Fixed pipeline normal mapping and bump mapping will be a snap.  

[Sirmatto]

QUOTE(openxdkman @ Dec 22 2006, 07:57 AM)

What does PoC mean?

PoC means "Proof of concept" as in the proof to myself of the concept that I'm not a total coding noob...although in the opinion of some more seasoned programmers, it might stand for "piece of crap" (IMG:style_emoticons/default/wink.gif)

Nonetheless, this is all very good news.  Hopefully it will spark a renewed interest in Xbox homebrew development.

[openxdkman]

I need this one to be disassembled too (really does nothing, typical passthru shader):

         0x00000000,0x0020001B,0x0836106C,0x2F100FF8,
         0x00000000,0x0020001B,0x0836106C,0x2F100FF8,
         0x00000000,0x0420061B,0x083613FC,0x5011F818,
         0x00000000,0x002008FF,0x0836106C,0x2070F828,
         0x00000000,0x0240081B,0x1436186C,0x2F20F824,
         0x00000000,0x0060201B,0x2436106C,0x3070F800,
         0x00000000,0x00200200,0x0836106C,0x2070F830,
         0x00000000,0x00200E1B,0x0836106C,0x2070F838,
         0x00000000,0x0020101B,0x0836106C,0x2070F840,
         0x00000000,0x0020121B,0x0836106C,0x2070F848,
         0x00000000,0x0020141B,0x0836106C,0x2070F850,
         0x00000000,0x0020161B,0x0836106C,0x2070F858,
         0x00000000,0x0020181B,0x0836106C,0x2070F861


This other one is optional, like first one :

         0x00000000,0x022000AA,0x0836086C,0x201FF828,
         0x00000000,0x0020081B,0x0836106C,0x2070F820,
         0x00000000,0x0420061B,0x083613FC,0x5011F818,
         0x00000000,0x00200E1B,0x0836106C,0x2070F838,
         0x00000000,0x0240021B,0x14361800,0x2F20F834,
         0x00000000,0x0060201B,0x2436106C,0x3070F800,
         0x00000000,0x0020101B,0x0836106C,0x2070F840,
         0x00000000,0x0020121B,0x0836106C,0x2070F848,
         0x00000000,0x0020141B,0x0836106C,0x2070F850,
         0x00000000,0x0020161B,0x0836106C,0x2070F858,
         0x00000000,0x0020181B,0x0836106C,0x2070F861

In the order the 3 passthru shaders appear in this thread, beside the passthru role, they involve :
1) Fog and W usage
2) Speculars (I need this one disassembled, I'm testing triangles drawing with it at the moment!)
3) Fog and no W usage

I'm testing second one and focusing on it at the moment.
Since I'm not planning on using speculars (shaped spotlights) for now, I rather like understanding it and shrinking it to the only purpose I need for pbKit (just passthru).

Also I'm almost sure there might be legal issues in just copying/pasting other people shaders code into one's source.

I'm pretty sure it's not so hard to discover how xbox1 shaders are encoded. I can't think about a completely different encoding compared to other NVidia chips... I heard NVidia chips NV2A is a good target.

This post has been edited by openxdkman: Jan 17 2007, 01:43 PM

[openxdkman]

Additional info about Specular & passthru vertex shader :

A sequence of 16 values is sent to GPU along with vertex shader code.
It's probably about the vertices feed itself :

0x22,2,2,2, 2,2,2,2, 2,0x22,2,2, 2,2,2,2

[openxdkman]

Vertex feed format expected by "specular" shader in a trianglelist (draws 1 triangle) :
x,y,u,v,
x,y,u,v,
x,y,u,v

x,y: position of pixel
u,v: texture coordinates

maybe the 0x22 values disabled the z or w elements (just a guess so far)