Next Generation Emulation banner

41 - 60 of 70 Posts

·
Registered
Joined
·
423 Posts
Discussion Starter #41
Well, there's the Nouveau project, which has reverse engineered most of the NV20 (the Xbox1 has a NV2A which is mostly similar) - this is a big help indeed.

Also, I can compare the pushbuffer contents with the actions that we had patched before, so I can deduce what functions put which codes into the pushbuffer.

Lastly, I've build my own disassembler into XbeExplorer, which already shows me a list of detected symbols, so I can easily jump to a function and read through it's disassembly to see what type of codes it puts in the pushbuffer, and how it mangles the arguments.


I intend to build up from the simple to more complex tutorials and samples.
Right now, I have CreateDevice working again via a single-shot patch on SetRenderTarget. The pushbuffer is now being filled with about 25 pushbuffer commands. (I just ignore the all, but later I'll probably have to keep some state for them.) I already wrote some code to emulate D3DDevice_Clear, but there's a crash I still have to overcome before this code is reached. Anyway, the crash happens in MakeRequestedSpace, which is a bit of a problem, as it's a big function that I don't want to replicate just for a little fix... we'll see how it goes.
 

·
Registered
Joined
·
175 Posts
It is surprising how much i'm excited over something that still doesn't work. When this is done i"ll surely fall unconsious.
Ehm, is this patchless approach going to bring emulation a tinny bit closer to x64? But in reality, i already know the answer - No. I'm not rushing anything, i can wait.
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
any luck with intro movies with this patchless approach?
 

·
Registered
Joined
·
423 Posts
Discussion Starter #44
I've got two experiments running right now;

First, I'm trying to get everything up & running with an approach that removes most of the Create-calls, Register and a bunch of other patches. This works surprisingly well : I got all samples running with this, and yes - I even got overlays (both in software and in hardware mode) working again. [The fact that some intro movies don't show up or stop playing within a few frames is probably due to some timing issues.]

Secondly, I'm attempting to emulate purely at the pushbuffer level. This is even more interesting, as it would remove the need for a patch on most D3D calls, and we could even dare to hope to run LTCG titles with this approach. (It's also more hardware-oriented, the GPU would be nearly low-level emulated.)

As for my progress on both;

The first attempt (no Create patches) is not finished yet, as none of the games we ran before, are working with this. I haven't looked into all issues yet, so I can't give you an estimate to when this would be 'done'.

Actually the fact is, that I'm more interested in the second experiment; I've been working on it for a few days and I *think* I got the basics down; I disabled almost all D3D patches, worked my way around all hardware accesses and can now see the log being filled with pushbuffer commands (yeah!). The CreateDevice sample looks simple enough (doing just a Clear + Swap), but this was/is actually quite a tough job to get running!

First, I had to figure out how the pushbuffer is actually created (this is done somewhere in the initialization routines), then I had to see how the GPU is triggered into action (there seems to be a specific address-bit for that) and then I had to make sure that all original (Xbox1) pushbuffer-related code actually runs (like functions that point the GPU to the correct buffer address, that kick-off the GPU, code that spins in the busy-loops until the GPU is done, that grows and/or wraps the push buffer, etc.).

Now that I have these things somewhat working, I encountered yet another problem: This level of emulation needs to work with a resource field (called 'Lock') that we abused up until now (we wrote a pointer to the native resource in that spot for easy access). Because this field cannot be used anymore, I'll have to build a fast double-associative datastructure, so that we can quickly match an Xbox1 resource to our native counterpart (and vice versa).

So you see : There's lots of difficulties to overcome, but it's not impossible. If I succeed with this line of emulation, it will open up a whole new realm of possibilities, as we would be much less dependent on symbol scanning. And: It will certainly help us reach the 'in-game' state with many more Xbox1 titles (at least, if not hindered by other factors, like sound, networking or other device-related issues).

Wish me luck!
 

·
Registered
Joined
·
137 Posts
Hi Patrick and ShadowTJ I just wanted to say you both are doing a great job in producing a awesome emulator keep up the great work and maybe we will see an xbox emulator that actually all of the games can be made to work on it. I appreciate your coding job as well I know nothing about emulators but maybe one day I will make one as well I am learning java as a beginner I got a software that does java and it is easy for me not much coding and programming as well, but I haven't made anything just yet like games, software, applications, and etc. sorry I haven't been in the forum lately I have been busy in my sparetime, one last thing I got a very easy software that can make anything no coding or programming is required it is up to you what you want to make or create I know your busy so I will leave at that for now I can't do high level coding and programming to hard I am not that smart in doing that but you guys are better at that then I am in general and in private I am not trying to put anyone down as well most can do it and most can not but by learning code and programming it becomes easier I believe.
 

·
Registered
Joined
·
75 Posts
These are tremendously exciting developments. Reading all these comments is way better than watching a B-grade action movie. There are lots and lots of plot twists (Having suddenly announced that you're already planning to move the DXBX emulator all the way down to as low a low-level emulation level as possible only a short time after saying that you're working on a hybrid hi & low-level emu. The great Blueshogun coming back after a difficult hiatus, and then making some before-untouched cool games work somewhat.), and surprising story developments. There's things like how you've come back to work on the emu after taking a rest from development for what I thought would be 1-3 months, which is understandable. Heck, I wouldn't even mind that at all, just coz we were happy and assured & all that the Xbox emulation has been progressing comfortably well and many games have been added to various levels of compatibility.

This is such a great and thrilling narrative, and we the few readers have been so lucky to be absorbed in it! That's because it's got a feeling of the 'unknown' out there, because we don't know what's going to happen in the future, so we're addicted to hearing more about it, heh.

So is the resource field, the 'Lock', something that was developed for the PC, or was it a part of the Xbox1 dev kit?

And are you sure that you wouldn't need those symbol scanning detection back into the emu again in the future. Oh well, perhaps one factor removed equals a massive leap in faster to update full-level games compatibility list...
 

·
Registered
Joined
·
376 Posts
I find it interesting that we can consider LLE at ALL, presumably due to the performance requirements saved by not having to emulate the CPU. LLE seems to be completely out of the question for emulators like Dolphin and PCSX2, probably since they need PC that makes even Crysis cry.
 

·
Registered
Joined
·
423 Posts
Discussion Starter #48
Well, I don't really know where this is leading, all that I'm doing is follow my gut feeling that this emulation of the GPU on the push-buffer level is totally feasible.
Take the example from the VMWare hardware acceleration driver - they also have a system like this running, so it's not like this is a big pocket of hot air... it's just never done before (that we know of) for the NV2A (I don't know how the Xbox1 emulator for the Xbox 360 works, it could well do the same).

Regarding the 'Lock' field in Xbox1 resources : It's is used for synchonization - any resource that has outstanding push-buffer commands is associated with a time stamp, which is put in the 'Lock' field by the d3d runtime. Once the GPU crosses a certain 'fence' the resources are no longer considered to be locked, and the first call to IsBusy resets the Lock field. If I ever want to emulate the GPU correctly, I better make sure this concept works identical in our emulator.

PS: I wasn't aware that my ramblings can be interpreted as some kind of geeky soap, but it's nice to see that at least /some/ people are interested in this stuff ;-)


Anyway, I'll keep you all informed on my progress, and will try to commit to our SVN more often.
Back to coding!
 

·
Registered
Joined
·
423 Posts
Discussion Starter #49
GPU emulation!

Like I said yesterday, I would keep you updated on any developments, so here it is :

A few hours ago I committed the code that can run the CreateDevice XDK sample without any D3D patches - it's working solely by emulating pushbuffer commands, which can be seen as actual hardware emulation of the Xbox1 NV2A GPU! :D

Now, don't get all excited (I did that myself already :innocent:); This is only the first step towards full GPU emulation. There will be plenty of problems that must still be overcome, but the basics work.

At least this proves that it is actually possibly to play nice to Xbox code and pretend there's a GPU doing the drawing, while in reality Dxbx is passing on the rendering towards D3D8!

The coming days I'm going to work on some additional GPU commands, so that this code can show output for more XDK tutorials. (A few run just fine, but they don't show much else than a blue background, since I've only implemented Clear and Swap right now.)

For most of you, this will not be very exciting, as the screenshots I will surely post the next few days will show you nothing new. But for the few coders lurking around in here, I can tell you this is very exciting - it means no more D3D patching, which will drastically reduce our reliance on correct symbol scanning. Heck, even LTCG titles suddenly don't seem to be a problem anymore!

So again : Wish me luck!
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
kudos on the progress so far! It wasnt too long ago when your idea to emulate at the push buffer level was just an idea. It must be an encouraging first step
getting the createdevice sample running. Hopefully it wont be long before you get even more samples running :) Good luck! :D
 

·
Registered
Joined
·
8 Posts
But for the few coders lurking around in here, [...]
There might be more than you think. That's the problem of the web - the lack of visible feedback as everyone can consume w/o getting recognized, till he might finally post something. ;)

I can tell you this is very exciting - it means no more D3D patching, which will drastically reduce our reliance on correct symbol scanning. Heck, even LTCG titles suddenly don't seem to be a problem anymore!
Congratulations, if this works out then you are about writing emulation history! Such a success must be a wonderfull feeling, especially as LTCG seemed impossible to handle by your chosen approach until now.

How many pushbuffer commands would you have to emulate for implementing a full pushbuffer emulation? Will it simply be some diligent but routine piece of work (besides the supprises that will come up) or are many of the pushbuffer commands still in the dark & you would have to figure out what they do & how to emulate them? Finally, will it be possible to emulate them all with standard D3D8?

thx,

microdev
 

·
Registered
Joined
·
376 Posts
Wouldn't this mean that Dxbx is the first emulator that LLEs the GPU of a mainstream 3D-accelerated console? AFAIK DC, PS1, PS2, N64, GCN, Wii, DS, and PSP emulators all use HLE for GPU emulation. (I know there's an LLE Saturn emulator, but that's not exactly a mainstream console :p)
 

·
Registered
Joined
·
423 Posts
Discussion Starter #53
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!
 

·
Dolphin dev
Joined
·
11 Posts
Wouldn't this mean that Dxbx is the first emulator that LLEs the GPU of a mainstream 3D-accelerated console? AFAIK DC, PS1, PS2, N64, GCN, Wii, DS, and PSP emulators all use HLE for GPU emulation. (I know there's an LLE Saturn emulator, but that's not exactly a mainstream console :p)
We're emulating the Wii in Dolphin on the command processor & register level which is about as LLE as it can get. ;)
Then again, I'm not sure what these pushbuffers actually are, maybe it's some even more low-level-ish thing... Anyway, Dolphin doesn't go any deeper since there really is no need to LLE at a deeper level than the CP&registers.

EDIT:
If XTL_EmuExecutePushBufferRaw from uPushBuffer.pas is what emulates those pushbuffers, then it's pretty much equivalent to the Wii's command processor ;)
 
41 - 60 of 70 Posts
Top