partial HLE in GPU for the hard stuff?

[CaptainN]

Is it possible to mix emulation methods in a single emulator (or plugin)?

For example would it be possible to recompile (or interpret) all the normal stuff in a psx GPU and then use HLE (as described by Zilmar's emubook http://www.pj64.net/emubook/ to emulate the hard stuff, like those wonderfull blur effects in squaresoft games (Chrono Cross, Legend of Mana, Vagrant Story)?

Just curious.

[Cyberman]

Originally posted by CaptainN
Is it possible to mix emulation methods in a single emulator (or plugin)?

For example would it be possible to recompile (or interpret) all the normal stuff in a psx GPU and then use HLE (as described by Zilmar's emubook http://www.pj64.net/emubook/ to emulate the hard stuff, like those wonderfull blur effects in squaresoft games (Chrono Cross, Legend of Mana, Vagrant Story)?

Just curious.

Where did I put that can of worms?

The GPU is emulated by sending data written to the GPU ports to functions written in a DLL. I believe ePSXe does dynamic recomp on the data already. It uses the DLL's 'stubs' or references to the functions within the DLL to make a direct call to the DLL functions from the dynamically recompiled code. At least that's my guess.

An interpreted mode would likely more more acurate.

Blur affects etc. are done by READING and WRITING to the GPU video buffer using the READ_BLOCK command of the GPU. This information is dumped into PSX main memory (1M is all you have). 320x240x2 or about 153600 bytes worth of data is read from the original screen. It might be stuffed in texture memory or some such local and then copied as a texture into the video memory on a polygon using one of the transparency modes available.

Now back to your question! HLE is done on N64 emulators to by pass emulating the instructions that are queued for rendering the graphics. HLE knows that there are function calls in the N64 dev kit and looks for those function calls. It reads the information passed to it and fakes rendering the information passed to the low level GPU. Doing this on the PSX might be much more challenging since many games really don't have a decipherable pattern from the SONY dev kit. There are many high level functions that this can be done with.. I don't think the GPU is that easy to do it with. The PSX uses a 'bios' whereas the N64 has no real bios, the ROM is the boot loader. Bios functions are emulatable as well.. the end situation is.. it's not the same animal as the N64.

Cyb

[CaptainN]

Cool. That's good info.

Thanks.

[Kane]

If pete is reading, is the reason that the framebuffer stuff is so slow because it all has to be done in software (there are no reall openGl/D3D funcs for it)?

[Pete Bernert]

>If pete is reading, is the reason that the
>framebuffer stuff is so slow because it
>all has to be done in software (there are no
>reall openGl/D3D funcs for it)?

No, the reason why the framebuffer textures/reads/copies are slow is because they are done in Hardware in my plugins

All hw framebuffer read access techniques are 'bad', because they stall the rendering pipeline. Of course it heavily depends on your gfx card, on GF cards the access speed is surprising good, imho, at least with Detonator 12.xx or newer (if you don't activate FSAA).

[Kane]

Thx

[Noxious Ninja]

So that's how N64 HLE works... now I understand. I guess that's the benefit of everybody using one official devkit.

And the hardware gfx plugins do do HLE, in a way. They take the PSX graphics commands and convert them into DirectX, OpenGL, or Glide commands.

[Kane]

Don't think so

[Noxious Ninja]

???

[Lewpy]

Okay, let's try and clear this up


HLE - High Level Emulation

A technique used to emulate a system, or part of a system, by simulating the software API calls that the program makes.


LLE - Low Level Emulation

A technique used to emulate a system, or part of a system, by simulating the hardware registers that a program accesses.


What HLE does is it scans a program and "hooks" the standard API calls that a program is using (because it is designed using a standard development library, so the API calls are standard across many games). By doing this, it doesn't actually have to fully emulate the hardware in the system, and also has access to the program data before it gets mangled by any actually hardware device in the system.

LLE emulates the system at a register level, so is almost exactly the same as the system being emulated. This also means it suffers from any limitations of the system being emulated. In the case of the PSX, this means it has non-perspective correct texturing, no zbuffering, 3D engine glitches, etc.

All PSX emulator plugins that use the PSEmu Pro plugin interfaces are LLE components, because they operate at the register level of the devices they are emulating. The fact that they subsequently call D3D, OpenGL, Glide, etc. afterwards to display the data afterwards is irrelevant.

N64 lends itself very well (from what I have read) to HLE techniques, because most of the developers use[d] standard Nintendo libraries to develop their games, so used a common API for accessing the various system blocks (graphics, sound, etc.)

PSX doesn't lend itself to HLE very well, because most games are written using proprietary libraries, so that the performance of the system is maximised. I doubt there are many developers that used exactly the same libraries on multiple games.

Most emulators that use HLE only use it in part of the system. Most rely on LLE emulation of core operations, such as the CPU.

Full HLE is in effect porting an entire game from one platform to another (such as FF7 on PSX and PC): the executed code has absolutely nothing to do with the original platform code, and even the data structures are changed to optimise them for the target platform.

In theory, this is possible for a real-time emulator to do.
Practically, I don't think you will ever see such an emulator

[zero0w]

I see, so in your opinion will such thing as perfect emulation possible with PSX platforms as LLE is used with current crops of PSX emulators?

[Lewpy]

Yes, a perfect PSX emulator is possible. And a perfect emulator would run the PSX software exactly as it was meant to be run. This would require emulating every part of the PSX in software, with no reliance on fixed-operation hardware in the PC. This would mean no hardware-accelerated GPU plugins.

In other words: take VGS and iron out the bugs

[zero0w]

Well, I guess.
But I rather have some 3D enhancements for my PSX games. Thx Lewpy.

[CaptainN]

So in theory would it be possible to use HLE to change some of the "non-perspective correct texturing, no zbuffering, 3D engine glitches, etc." (not asking anyone to do it ) in specific games (like Tekken 2 or a single squaresoft game)?

To do HLE, do you need the origianal dev kits?

If you where to write a PC emulator (more specifically DirectX and D3D) for Mac OS X, would HLE be a good choice for this type of a project (I would guess that it is, if developers use the same dev kits from MS - which I don't know if they do)?

If so, could someone conceivably write a display driver for a current emulator (virtualPC etc) that contained that code, or would more of the system have to be played with?

Is the relationship between LLE and static/dynamic recompilation and interpretation the same with HLE or is HLE simply a way of implementing dynamic recompilation?

Thanks.

[Lewpy]

Okay, heavy questioning that may stretch my knowledge of these things

Originally posted by CaptainN
So in theory would it be possible to use HLE to change some of the "non-perspective correct texturing, no zbuffering, 3D engine glitches, etc." (not asking anyone to do it ) in specific games (like Tekken 2 or a single squaresoft game)?

In Theory, yes, this is totally possible. There is nothing stopping a determined person from analysing a particular game/program and working out what it is up to. Once you know what it is "doing", you can start to replace known functions with target code.
There are many pitfalls to this though. It really depends on how the program uses its data. If it were just a simple 3D pipeline, then it may be trivial (in the loosest sense of the word!!) to pass that data through a 3D pipeline that has nicer graphics. But you would also have to emulate their texture management code. And what if the data from the 3d pipeline gets used in collision-detection? etc.

To do HLE, do you need the origianal dev kits?

No, but I am sure it would help. Knowing what the API functions are, the data structures used, the parameters passed would save working them out by analysis. But it is not essential. This is what reverse-engineering is about: working out functionality without been given "hints".

If you where to write a PC emulator (more specifically DirectX and D3D) for Mac OS X, would HLE be a good choice for this type of a project (I would guess that it is, if developers use the same dev kits from MS - which I don't know if they do)?

Isn't there some DirectX layer for Linux? I would have thought that works via similar techniques. It's all related to "wrappers", that "wrap" an API around another one.

If so, could someone conceivably write a display driver for a current emulator (virtualPC etc) that contained that code, or would more of the system have to be played with?

I would have thought that depends on how the emulator is written. Probably, it would require major changes to the whole emulator.

Is the relationship between LLE and static/dynamic recompilation and interpretation the same with HLE or is HLE simply a way of implementing dynamic recompilation?

I think you could refer to HLE as "static precompilation" - it uses native code that has been compiled before execution of the emulator.

You have to be careful with terms like LLE and HLE, because they are dependant at what level you are analysing a system - how low is low, how high is high?. I am sure that statement will confuse more people than will understand it!

[CaptainN]

Thank you for that info. But I have one more if your game.

What exactly is self modifying code? In javascript there is a function called eval(), it takes code from a variable (or built in the parenthises, etc) and executes it allowing you to build code while the program runs. Is that an adaquit description of self modifying code?

Thanks again.

[Noxious Ninja]

So that isn't considered HLE? OK, since you're the knowledgeable emu guy, I'll use your definitions. :P By them, I guess Corn would be considered the current ultimate in HLE.

Would it be possible to add gfx enhancement to a software GPU plugin? I know it would be quite slow, esp. with software bilinear filtering and such, but you would get the best of both worlds.



One more thing. Is there any way to do scanlines with your Glide plugin? If not, can you add it? I think it's just about the only thing you're lacking...

[Cyberman]

Originally posted by The Khan Artist
So that isn't considered HLE? OK, since you're the knowledgeable emu guy, I'll use your definitions. :P By them, I guess Corn would be considered the current ultimate in HLE.

Would it be possible to add gfx enhancement to a software GPU plugin? I know it would be quite slow, esp. with software bilinear filtering and such, but you would get the best of both worlds.



One more thing. Is there any way to do scanlines with your Glide plugin? If not, can you add it? I think it's just about the only thing you're lacking...

1: Umm Corn does some dynamic recompilation and if you ddin't notice it DOESN'T work with all games in fact only a few and that's why. It recompiles with a new API and translates the data even. Very nice design. But impossible to do on a PSX without a custom 'translater' per each game since they all used different libraries. IE FF8_dr.dll etc etc.. one for each game a lot of work and debugging.

2: yes it is but it would be a LOT slower than hardware aceleration. I should know I've worked on that

3: You want to approximate the oringinal display as closely as possible? Other than this is something rather difficult to do with a PC hardware acel. It won't look anything like the oringinal. In my opinion, it would be a waste of time it gets you nothing at all because you have differing resolutions and differing displays. An interlaced display being placed on a noninterlaced etc. I suppose it comes down to.. you can move a mountain of sand with a pair of tweezers but what is the point of doing it?

Originally posted by CaptainN
Thank you for that info. But I have one more if your game.

What exactly is self modifying code? In javascript there is a function called eval(), it takes code from a variable (or built in the parenthises, etc) and executes it allowing you to build code while the program runs. Is that an adaquit description of self modifying code?

Nope that's not self modifying code is refering too. That's a program writting a program.

You have several 'memory' spaces used in a standard orthogonal computer system. You have Data and Program Memory traditionally. Self modifying code (I'll have to use assembly to demonstrate) does things like this.

jmp Tag1
Tag1:
... do code and RET
Tag2:
... do code and RET
Tag3:
... do code and RET
Tag4:
... do code and RET

in reality the memory location that contains the jump location after the JMP opcode (obsolute lets assume) is modified with the address of Tag1 Tag2 Tag3 or Tag4 so that it selects weather to jump to Tag1 Tag2 Tag3 or Tag4 and do a return from subroutine afterward.

You can also do this to end loops or other fancy things.

Cyb

[Exophase]

Originally posted by Cyberman


Nope that's not self modifying code is refering too. That's a program writting a program.

You have several 'memory' spaces used in a standard orthogonal computer system. You have Data and Program Memory traditionally. Self modifying code (I'll have to use assembly to demonstrate) does things like this.

jmp Tag1
Tag1:
... do code and RET
Tag2:
... do code and RET
Tag3:
... do code and RET
Tag4:
... do code and RET

in reality the memory location that contains the jump location after the JMP opcode (obsolute lets assume) is modified with the address of Tag1 Tag2 Tag3 or Tag4 so that it selects weather to jump to Tag1 Tag2 Tag3 or Tag4 and do a return from subroutine afterward.

You can also do this to end loops or other fancy things.

Cyb

Not to interrupt this interesting thread but are you sure that description of self-modifying code isn't a bit limitting? You could accomplish that with self modifying code, but on modern (say, x86) machines it would be impractical as you can jump to addresses determined at runtime (if you're more into C than ASM.. function pointers, anyone?)
It's actually quite a self explanitory term, referring code that changes itself. Not to be confused with code that writes more code, such as a dynamic recompiler; it must change what already exists. Here's a snippet from some random website I pulled off Google...

b. Self-modifying code - Code that modifies itself during execution. The original use of such code was to store the return address with the called subroutine, or the current loop counter with the loop instruction. A more macroscopic use was code overlays, where different parts of the code would be brought into memory as needed, overwriting the previous overlay. In general it was used to reduce memory and register usage. Modern architectures essentially forbid self-modifying code. For example, the VAX architecture specified the behavior of self-modifying code as undefined unless an REI (return from exception or interrupt) was executed after the modification. The reason is that in a heavily-pipelined machine, the modified instruction might already be in the pipe, and thus the old, not the new version of the instruction would be executed. Usually the operating system prevents self-modifying code by making code pages in logical memory read only.

As you can see it's not very safe.. one of those old optimization techniques thrown out the window with the advent of heavily pipelined, cached, superscalar CPUs (such as compiled bitmaps)

- Exophase

[Noxious Ninja]

Ahh, I love function pointers...


As for Corn, I know it had quite limited compatibility, but it had awesome speed, because it used static recompilation. That's why I said it's the ultimate level of HLE. Maybe it's not very practical, but it is just about the highest level of abstraction you can get.


Scanlines... no, I'm not trying to approximate the original display, I just like scanlines. I know that Pete's plugins can do scanlines. Is this something not present in Glide?