Next Generation Emulation banner

61 - 70 of 70 Posts

·
Registered
Joined
·
423 Posts
Discussion Starter #62
Patrick, what is cooking in the GL area? Can't help reading the SF change logs!!!
Well, since I've succeeded in lowering the GPU emulation to the push-buffer level, there's that little detail called "implementation"... and since we're at a junction here, I thought it would be wise to investigate if OpenGL could be a better suited API for the NV2A (before I start investing lots of time in a D3D implementation).

The thing is, even though I'm now able to parse GPU commands right from the push-buffer (and we're posing as if the GPU is actually handling them) that still leaves us with the question of how to emulate these commands.

Because of my previous work on Dxbx, I've learned enough about D3D to know that emulating push-buffer commands with D3D8 (or 9) will be problematic at best. Also, D3D lacks a few features that the NV2A offers (like two-sided lighting, quad primitives, etc.) so that made me wonder how OpenGL would fare.

So what you've seen in the SVN commits, is a little experiment to use OpenGL. The first results where encouraging - I got the (very simple) CreateDevice tutorial running with OpenGL powered pushbuffer emulation in a day or two.
This sounds nice and all, but it doesn't really mean anything; CreateDevice does nothing much more then just clear the screen with flashing colors. No drawing, no nothing.

Emulating draw commands turns out to be quite the challenge in OpenGL however. I've been busy for days already to get even the simplest triangle drawn on screen. So far no luck.

The trouble is, there's so much involved with this; This is my first time using OpenGL, so I have to learn as I go. Also, some push-buffer commands can be forwarded to an OpenGL API without much intervention (like SetViewPort), but others are turning out to be quite difficult (like vertex attribute pointers and shaders).

Luckily, revel8n (who has a bit more experience with OpenGL) is helping me sort things out, but we haven't yet produced a single triangle yet.

So we're at an impasse right now. I really hope we reach a breakthrough soon, as it does seem like using OpenGL could be the better solution.

If this experiment fails, I would have to go back and use D3D to emulate the push-buffer commands with (knowing it will never emulate everything correctly, while OpenGL could have).


And to give you an idea what I'm talking about 'problematic' push-buffer commands:

Xbox1 titles call things like SetRenderState, SetStreamSource and other realtively simple API's. Some of those API's result in 1 single push-buffer command that's simply the GPU version of that API. Emulating these won't be much of a problem.
Many other API's however are decomposed into multiple GPU commands, and the arguments given to them are not always enough to reconstruct the original call with. (Some GPU commands also appear in multiple contexts, so it's sometimes hard to deduce which API was responsible for which command.)

Take SetViewport for example; The Xbox keeps state for two matrices (called World and View) but the push-buffer command multiplies these two matrices together into a 'ModelView' matrix. Since the push-buffer only receives the 'ModelView' matrix, I cannot emulate that in D3D - as a matrix multiplication is a one-way operation, which cannot be decomposed into it's original arguments.

Let me illustrate that with a question : What two numbers did I multiply to get at 16?
Was it (1*16) ? Or (2*8) ? Or (4*4) ? Or (8*2) ? Or (10*1.6)?

The same loss of information is happening to many other GPU commands, so that will be a big problem in it's own right.

Okay, thanks for reading, I'll let you all know how this turns out soon enough. Cheers!
 

·
Registered
Joined
·
175 Posts
Dx11 have some kind of push-buffer (or something similar), right? I don't know about quads, but in theory, what do you think, how would it handle NV2A emulation? Off course, this would impose even biger problems 'couse it will make WinXp useless.
 

·
Registered
Joined
·
376 Posts
Off course, this would impose even biger problems 'couse it will make WinXp useless.
Especially considering that Dxbx currently has several issues with Windows 7, let alone will even work on 7 64bit, which is more popular than 7 32bit.

And it goes without saying that 7 is more popular than Vista.
 

·
Dolphin dev
Joined
·
11 Posts
Erm, D3D11 doesn't have that kind of pushbuffer (I don't actually know what kind of stuff you might be talking about anyway :D).

Generally speaking, while D3D11 offers some nice stuff compared to D3D9/8, it (especially when it comes to emulation) is in some areas much more restrictive actually.
Fwiw, when I coded the D3D11 plugin for Dolphin, almost no D3D<->OpenGL compatibility problems had been solved, so there's only limited advantage in using it.
 

·
Registered
Joined
·
423 Posts
Discussion Starter #66
The only D3D that has an API for push-buffer recording & replaying (that I know of), was the D3D8 deriviate that was written specifically for the Xbox1's NV2A.

Anyway, having no D3D11 on XP (and it not offering much additional features to help with NV2A-emulation either) is all the more reason to strive for a OpenGL implementation; One glaring problem I'm having I asked here, if anyone can help -please do !
 

·
Registered
Joined
·
137 Posts
Hi All I just wanted to tell you I got windows xp 32bit in vmware to work for me I tried several games for dxbx and some work and some crash but I don't know why the games crash but it is still pretty cool for me I am using directX 9c for my graphics and etc because I don't like opengl in general my question is should I upgrade my graphics to 10 or 11 for directx or not at all? so far homebrew and other games work except the debug ones the debug ones don't work at all just yet because dxbx is still in development well I want to appreciate shadow and patrick for their cool improvements and keep it up the great work well see ya later one last thing windows xp will only work for dxbx emulator vista and windows 7 have major errors!
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
thanks for keeping us updated! I hope you reach more breakthroughs with opengl!
edit: From reading the svn it looks like youve at least got something showing
with certain samples now :D
 

·
Registered
Joined
·
34 Posts
I don't know about other GPUs, but until now I've seen 313 pushbuffer commands (although some are replicated to multiple instances, so the total is about 1900 commands). I suspect that around a 100 to 150 commands will be enough to support most of the XDK samples, and perhaps a 100 more for games.
Lets just see how far we can take this; It's certainly going to be a lot of work, so that's what we'll be focussing on right now.
Cheers!
Can you tell me how / where you found 313 operations?

I have 2 independent sources saying that there are only 267 operations supported by the MS D3D Driver in 5933. So unless MS decided to remove some, 313 sounds strange to me.

Rev-Engineered from the libs: NV2A Operations - Pastebin.com

There's more info about the operations which I didn't parse yet though.

Personally I didn't come accross any other operations so far either [except for some using flags]. Obviously that's not very good double-checking because my emu only runs very few samples right now - I guess the more advanced emus like Dxbx and Cxbx can find the pushbuffer CMDs more easily where apps actually submit those very often ;)

0x1FFC seems to be the opcode mask by the way.
 

·
Registered
Joined
·
423 Posts
Discussion Starter #70
Can you tell me how / where you found 313 operations?

I have 2 independent sources saying that there are only 267 operations supported by the MS D3D Driver in 5933. So unless MS decided to remove some, 313 sounds strange to me.

Rev-Engineered from the libs: NV2A Operations - Pastebin.com

There's more info about the operations which I didn't parse yet though.

Personally I didn't come accross any other operations so far either [except for some using flags]. Obviously that's not very good double-checking because my emu only runs very few samples right now - I guess the more advanced emus like Dxbx and Cxbx can find the pushbuffer CMDs more easily where apps actually submit those very often ;)

0x1FFC seems to be the opcode mask by the way.
The number 313 came from the Renouveau NV20 header files, a chip that closely matches the NV2A. Meanwhile I've extended the list for the NV2A to 322 entries (not counting constants for shifts, bit-masks and sizes) by inferring the meaning of empty slots and actual push-buffer contents.

But your last remark got me intrigued; What emu are you working on, and what samples does it run? Please PM me, if you please...
 
61 - 70 of 70 Posts
Top