Alphakill

I heard RSX has a feature normally unsupported by PC gpus called Alphakill. What it does and how do you emulate it also does RSX has any other atypical exotic functions or fixed function hardware that is hard to emulate like this like for example Gamecube's Zfreeze.

I heard RSX has a feature normally unsupported by PC gpus called Alphakill. What it does and how do you emulate it also does RSX has any other atypical exotic functions or fixed function hardware that is hard to emulate like this like for example Gamecube's Zfreeze.

One of the weirdest things that I encountered was Destiny trying to access gl_Position in a fragment shader!
vlj probably knows a lot of weird things about RSX.

Rsx is fairly close to pc gpu. Of course some functions are not exposed by api but they're often deprecated (and thus can be emulated otherwise) or performance related, giving hints to the hardware but doesn't change the output.
Alpha kill belongs to the first category : it discards a pixel when some comparaison operation on pixel alpha value is true.
The feature is used by virtually every game today to mimic grass, hairs,... Based on alpha component (="transparency&quot of a texture. Instead of relying on a fixed function the discard operation is moved to the shader.

There is an alpha I'll feature on texture although I don't know how it works. It's likely similar but happen when a texture is sampled instead of waiting shader has finished execution.

I'm worried about per camera facing value ref/function settings since it's not supported by d3d (2 sided stencil can only accept different ops and mask) but no rendering technics I'm aware of use this so it's likely not very used.

The bare metal memory access is the difficult thing to emulate because all pc api wrap memory object but it's common to every device you want to emulate.

Rsx is fairly close to pc gpu. Of course some functions are not exposed by api but they're often deprecated (and thus can be emulated otherwise) or performance related, giving hints to the hardware but doesn't change the output.
Alpha kill belongs to the first category : it discards a pixel when some comparaison operation on pixel alpha value is true.
The feature is used by virtually every game today to mimic grass, hairs,... Based on alpha component (="transparency&quot of a texture. Instead of relying on a fixed function the discard operation is moved to the shader.

There is an alpha I'll feature on texture although I don't know how it works. It's likely similar but happen when a texture is sampled instead of waiting shader has finished execution.

I'm worried about per camera facing value ref/function settings since it's not supported by d3d (2 sided stencil can only accept different ops and mask) but no rendering technics I'm aware of use this so it's likely not very used.

The bare metal memory access is the difficult thing to emulate because all pc api wrap memory object but it's common to every device you want to emulate.

For the record, alphakill sample currently doesn't work properly. The cubes with alphakill are solid.

Rsx is fairly close to pc gpu. Of course some functions are not exposed by api but they're often deprecated (and thus can be emulated otherwise) or performance related, giving hints to the hardware but doesn't change the output.
Alpha kill belongs to the first category : it discards a pixel when some comparaison operation on pixel alpha value is true.
The feature is used by virtually every game today to mimic grass, hairs,... Based on alpha component (="transparency&quot of a texture. Instead of relying on a fixed function the discard operation is moved to the shader.

There is an alpha I'll feature on texture although I don't know how it works. It's likely similar but happen when a texture is sampled instead of waiting shader has finished execution.

I'm worried about per camera facing value ref/function settings since it's not supported by d3d (2 sided stencil can only accept different ops and mask) but no rendering technics I'm aware of use this so it's likely not very used.

The bare metal memory access is the difficult thing to emulate because all pc api wrap memory object but it's common to every device you want to emulate.

About that alpha on texture feature does it have any name? Does RSX support destination alpha test or any exotic blending modes that require programmable blending with texture barrier to emulate like say PS2, PSP ,GC and even Saturn? Does it support alpha to coverage? I'm not sure I understand about that per camera function is that something related to the viewport? I remember hearing about something called Flip Control too. Does RSX still have register combiners in addition to shaders or was that already removed and finally does it support tessellation since I know Xenos does.

About that alpha on texture feature does it have any name?

Texture alpha kill I think. This is a rather low level functionnality that doesn't really increase shader expressive power.

Does RSX support destination alpha test or any exotic blending modes that require programmable blending with texture barrier to emulate like say PS2, PSP ,GC and even Saturn?

No.

Does it support alpha to coverage?

Yes.

I'm not sure I understand about that per camera function is that something related to the viewport?

Not really.
Triangles from vertex shader can be either "front facing" or "back facing". Usually back facing triangle are culled since they're assumed to be unviewable.
However it's possible to disable back facing triangle culling.

Stencil functionnality have several parameters like mask, opcode for zfail, zpass, fail, and function.
RSX allows to set different parameters for front and back facing triangle. D3D12 on the other hand allows only a couple of parameters to be different.

Does RSX still have register combiners in addition to shaders or was that already removed and finally does it support tessellation since I know Xenos does.

No and no.

About that alpha on texture feature does it have any name?

Texture alpha kill I think. This is a rather low level functionnality that doesn't really increase shader expressive power.

Does RSX support destination alpha test or any exotic blending modes that require programmable blending with texture barrier to emulate like say PS2, PSP ,GC and even Saturn?

No.

Does it support alpha to coverage?

Yes.

I'm not sure I understand about that per camera function is that something related to the viewport?

Not really.
Triangles from vertex shader can be either "front facing" or "back facing". Usually back facing triangle are culled since they're assumed to be unviewable.
However it's possible to disable back facing triangle culling.

Stencil functionnality have several parameters like mask, opcode for zfail, zpass, fail, and function.
RSX allows to set different parameters for front and back facing triangle. D3D12 on the other hand allows only a couple of parameters to be different.

Does RSX still have register combiners in addition to shaders or was that already removed and finally does it support tessellation since I know Xenos does.

No and no.

1. So I get from this that RSX has some stencil buffer features not supported by modern PC gpus? Can it use early Z or Stencil rejection/test? Are depth and stencil buffers in RSX combined or still separate?
2. How do you emulate triangle fans in D3D12. Triangle fans were deprecated in D3D10.
3. What is the highest MSAA level supported by RSX and does it support SSAA as well or just MSAA? I guess 4xMSAA but it was too weak so games probably used 2x only at best.
4. Have you emulated mipmapping and LOD already and do you directly emulate RSX texture cache? Is texture caching crucial for accuracy of PS3 emulation like it is for example for PS2 emulation(PCSX2 has many errors and unemulated functions like mipmapping due to botched texture cache design)?
5. How difficult do you think it would be to emulate modern tile-based deferred renderer like Power VR SGX543 in PS Vita or even Pica200(it has combination of vertex shaders and fixed functions) in 3DS compared to RSX?
6. I noticed rpcs3 has LLE mode now. Do you emulate Cell and RSX at the register level?

I'll leave rest to vlj, as I can't comment on those.

6. What do you mean register level? We need to interpret (or recompile) the code to the native platform's code. Currently it's best to use the interpreter, as the recompiler is not very good and has many problems.

I'll leave rest to vlj, as I can't comment on those.

6. What do you mean register level? We need to interpret (or recompile) the code to the native platform's code. Currently it's best to use the interpreter, as the recompiler is not very good and has many problems.

I found this explanation of HLE and LLE.
http://www.emutalk.net/archive/index.php/t-3585.html

Here is something Lewpy posted over at NGemu when someone brought up the subject of HLE and PSX emulation:

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

That sounds very wrong. Either that or my basic knowledge of emulation is very wrong.
Okey, here we go!

What is emulation?
Emulation is (usually) software, that behaves like another hardware/system would behave.
This means, that the software will need to emulate the processor, RAM, instruction set, GPU, or whatever other stuff the hardware has (interrupts, IO registers, timings, etc).

What is HLE emulation?
HLE (High Level Emulation) is a process, where calls to the libraries of the system (in this case the modules for the interaction with hardware) are replaced with calls to code, that (should) behave and perform the same actions and output, as the calls on the system itself.
For an example, a call to a file system library, would be replaced with a custom function in the emulator, that takes the inputs given to the function, then calls the file system libraries on the current system/OS.

What is LLE emulation?
LLE (Low Level Emulation) is a process, in which calls to the libraries of the system are emulated using the actual instructions, that would be executed on the system. This usually means obtaining the BIOS/firmware files, that include the instructions, and then interpreting and emulating them same as they would be executed on the system's CPU. This is almost always slower, but a lot more accurate.

This is the basic gist of HLE vs LLE, from what I know and understand. Probably a couple mistakes slipped by, and I'd appreciate if they would be corrected.