OpenGL port - help needed

[patrickvl]

Previously, emulation worked by patching almost all D3D API's, forwarding them to native D3D8. This worked good enough to get 5 games in the 'playable' state, but that was about the best I could get it.
Since then I've been looking for ways to improve compatibility. First, I stopped patching many API's, so that more Xbox1 code ran unmodified. This actually improved compatibility to a level that made all (but one) SDK samples run correctly! (However, games where worse off than before.)

The lesson I learned, was that less patching means behaving closer to the original, so I took the bull by the horn, removed all D3D patches and started on push-buffer level emulation. I discovered soon enough that implementing push-buffer commands via D3D was going to be problematic at best, hence my switch to OpenGL.

Even though I don't see any graphics on-screen yet, the OpenGL API does turn out to be a much better fit for the NV2A commands - many commands can be forwarded to OpenGL with little or no argument-modifications.

About the constants - the Xbox1 D3D runtime sends these to the GPU, as they are used by the 'passthrough' shader (which is send by the D3D runtime for rendering D3DFVF_XYZRHW vertex data without a user-defined shader).
There are 4 of these constants, one set (0 and 1) contains the SuperSample-Scale & -Offset respectively, the other set (58 and 59) constains the Viewport-Scale & Offset respectively.
The SuperSample constants are accessed by the 'passthrough' shader, the Viewport constants are used by a small piece of code that gets added to all user-defined shaders that have no '#pragma screenspace' directive. (The 'passthrough' shader doesn't have this extra piece).

To be complete - here's the bit that gets added (R12 will be written to oPos afterwards):

// This part applies the screen-space transform :
MUL R12.xyz, R12, c[134]; // c[-38] in D3D speak - ViewportScale,
RCP R1.x, R12.w; // Originally RCC, but that's not supported in ARBvp1.0
MAD R12.xyz, R12, R1.x, c[133]; // c[-37] in D3D speak - ViewportOffset

Anyway, I'll focus my research on the clip-planes now, I really hope to reach a breakthrough soon!

__________________
Dxbx dev - Delphi FTW ;-)

[vicviper1974]

Your da poop patrickvl. Just wanted you to know that.

[JohnJack]

I saw this thread over at the OpenGL.org forums, and it may interest you if you decide to use VBOs. From the looks of it, STREAM buffers are faster than using gl*Pointer functions.

[patrickvl]

Originally Posted by JohnJack

I saw this thread over at the OpenGL.org forums, and it may interest you if you decide to use VBOs. From the looks of it, STREAM buffers are faster than using gl*Pointer functions.

That's an interesting read, but there's a few gotcha's that should be mentioned;
It's faster only for NVidia cards (ATI seems not to be affected by this flag) and the comparison was made using conventional vertex attributes - there's no mention whether this whole story applies to generic attributes too or not.. (Conventional attributes are old-fashioned nowadays, OpenGL has moved on to generic attributes, or at least so the specs say. Don't know what this means for the drivers though.)

__________________
Dxbx dev - Delphi FTW ;-)

[JohnJack]

On the fourth page, the developer states:

ATI VA = 56 fps
NVidia VA = 9 fps
ATI VBO STREAM = 200+ fps
NVidia VBO STREAM = 200+ fps

From what we've seen in the past few weeks, conventional attributes can be emulated via generic attributes. Both glVertexAttribPointer and glVertex/Color/NormalPointer work with VBOs as their last parameter is used as an offset. Given that current standards (OGL3+/D3D10+) have focused on buffers in GPU memory rather than system memory, they are future proof. Only CAD-like applications seem to prefer system memory pointers.

[patrickvl]

You got a point there - it seems both major vendors speed up significantly when using VBO + GL_STREAM_DRAW_ARB. Once I fix all transformation & viewport issues, I will try a switch to this rendering method.

However, I do wonder : What happens to performance if the entire VBO is constantly destroyed and re-created? And/or what if the pointers themselves are constantly altered?

This is probably what my most common usage-pattern will be :

The vertex-data is either coming indirectly from a relatively static D3D VertexBuffer, indicated via a pointer, or the data is put in-place in the push-buffer - to which I can still get a pointer (unless the vertex data was split up over multiple header+batch tuples, in which case I have no choice but to collect all these batches into another, contiguous, buffer myself.)

One would expect that GL_DYNAMIC_DRAW_ARB would perform better for the pointer-based rendering, but the thread you mentioned seems to indicate otherwise. Strange.

Also, how's the OpenGL driver going to make a distinction between GL_STREAM_DRAW_ARB and GL_DYNAMIC_DRAW_ARB - does it calculate a CRC in the DYNAMIC case or something, so that it can detect periods of static data and as such prevent an upload to GPU? (STREAM mode would upload the vertex data at every draw - which I would expect *not* to give a performance improvement over the other hint flags. Still strange that the VA approach is so much slower, then.)

__________________
Dxbx dev - Delphi FTW ;-)

[Bill_gates]

any luck getting something to show?

__________________
OS: WinXP Professional Service Pack 3
CPU: Intel pentium 4 3.0GHz
Video: Nvidia Geforce 8400GS
Sound: ASUS Xonar DS 7.1 Channels 24-bit 192KHz PCI Interface Audio Card
Memory: 512 MB
HD: [C:] 140.36/449.09 GB
Connection: Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller

[patrickvl]

Nope, I'm taking a break from Dxbx for a while, as it was starting to cost me my health (staying up way too late for 3 years in a stretch has become a bit too much, or so my head seems to tell me). I still want to continue with it though, but I first have to regain my motivation. In the mean time I'm messing around with some other interesting stuff.

__________________
Dxbx dev - Delphi FTW ;-)

[JayFoxRox]

Ah sucks to hear that patrick.

Was hoping to get some help with the stuff you send me (Thanks again by the way!) as I spend almost one week labeling it and developing tools to do various things (Mostly network and GPU related).

I also started low-level emulation of the GPU now but used GLSL from the very beginning because it seems to have better support and tends to be faster, especially with the small amount of recompilations needed in xbox games.

[patrickvl]

Originally Posted by JayFoxRox

Ah sucks to hear that patrick.

Was hoping to get some help with the stuff you send me (Thanks again by the way!) as I spend almost one week labeling it and developing tools to do various things (Mostly network and GPU related).

I also started low-level emulation of the GPU now but used GLSL from the very beginning because it seems to have better support and tends to be faster, especially with the small amount of recompilations needed in xbox games.

Good to hear you found use for it! Anyway, I'm not leaving Xbox emulation; I just have to regain some strength and find a little more balance between this and other basic real life-related stuff, like sleep and stuff.

Just shoot me an email for whatever you'd want further explained/clarified.

__________________
Dxbx dev - Delphi FTW ;-)