We move the initialization of the renderer to the core class, while
keeping the creation of it and any other specifics in video_core. This
way we can ensure that the renderer is initialized and doesn't give
unfettered access to the renderer. This also makes dependencies on types
more explicit.
For example, the GPU class doesn't need to depend on the
existence of a renderer, it only needs to care about whether or not it
has a rasterizer, but since it was accessing the global variable, it was
also making the renderer a part of its dependency chain. By adjusting
the interface, we can get rid of this dependency.
All tested games that use a single texture show no regression.
Only Texture2D textures are supported right now, each shader gets its own "tex_fs/vs/gs" sampler array to maintain independent textures between shader stages, the textures themselves are reused if possible.
Long queries write a 128-bit result value to memory, which consists of a 64 bit query value and a 64 bit timestamp.
In this implementation, only select=Zero of the Crop unit is implemented, this writes the query sequence as a 64 bit value, and a 0u64 value for the timestamp, since we emulate an infinitely fast GPU.
This specific type was hwtested, but more rigorous tests should be performed in the future for the other types.
This is based on research from nouveau. Many things are currently unknown and will require hwtests in the future.
This commit also stubs QueryMode::Write2 to do the same as Write. Nouveau code treats them interchangeably, it is currently unknown what the difference is.
The Ryujinx macro interpreter and envydis were used as reference.
Macros are programs that are uploaded by the games during boot and can later be called by writing to their method id in a GPU command buffer.
TODO: A shader may not use all of these textures at the same time, shader analysis should be performed to determine which textures are actually sampled.
This macro binds the SSBO Info Buffer as the current ConstBuffer.
This buffer is usually bound to c0 during shader execution.
Games seem to use this macro instead of directly writing the address for some reason.
Writing to this method will cause the written value to be stored in the currently-set ConstBuffer plus CB_POS.
This method is usually used to upload uniforms or other shader-visible data.
It'll now set the CB_SIZE, CB_ADDRESS and CB_BIND registers when it's called.
Presumably this SetShader function is binding the constant shader uniforms to buffer 1 (c1[]).
Register 0xE24 is actually a macro that sets some shader parameters in the register structure.
Macros are uploaded to the GPU at startup and have their own ISA, we'll probably write an interpreter for this in the future.
bunnei
Lioncash
Subv
James Rowe
N00byKing