Understanding the Source Code (or trying to)

[[Unknown]]

(05-20-2014 10:13 AM)mtmarco Wrote:  here we configure coreParam object, and then we launch PSP_InitStart(coreparms,err_string) and PSP_InitUpdate function;

For all intents and purposes, this is where it "enters" the emulator. All the stuff up to this point have just been platform specific / UI specific stuff.

(05-20-2014 10:13 AM)mtmarco Wrote:  6 -> here i'm getting lost: i've tried to manipulate output randomly messing up the PixelShaderGeneratorDX9.cpp, thinking this was the display output generator for a Windows PC with dedicated GPU (thinking the switch will chose DX9GPU), but from some test i saw no result in games, modifying boolean values into ComputeFragmentShaderIDDX9(id); so i tried with changing the same code in the FragmentShaderGenerator.cpp from GLES GPU class, but no result the same as before;

So, as far as the CPU, it's a bit more complex but that's mainly handled in Core/MIPS/. I recommend not worrying too much about that, because it's believed to be mostly correct (except some lingering issues in the armjit and NAN stuff etc.)

For most CPU stuff that's buggy, look in Core/HLE/. This is where we emulate all of the library functions that ship with the OS/firmware updates.

As far as the GPU, you're gonna want to stick to the GLES stuff, yes (or Common.) Look at GLES_GPU.cpp, everything runs through FastRunLoop() which calls the Execute_XYZ() functions. These set state which eventually pumps through StateMapping and is flushed in TransformAndDrawEngine.

If you're changing FragmentShaderGenerator, note that it CACHES shaders. There's a function GenerateFragmentShaderID(), which needs to generate something unique per shader. If the shader id matches, it won't go into the generate function.

The generation of the shader source code is done only one time per shader id.

(05-20-2014 10:13 AM)mtmarco Wrote:  7 -> in the end I've ended in GPUCommon.cpp, and i think our emulator is specifing the GPU class into the Common one (not the DX9 nor the GLES, that obviously is for mobile);

GPUCommon is definitely used, but even on desktop GLES is used.

(05-20-2014 10:13 AM)mtmarco Wrote:  fopen(file,"w") of a new empty specific file(thinking the debug console isn't working with printf cause we are in a win32 app).... and ive discovered that the software go into gpucommon.

I recommend you open Debug -> Log Console and instead use:

NOTICE_LOG(G3D, "Hello.");

It uses printf() syntax so you can log variables. You'll see LOG statements in various places of the code.

(05-20-2014 10:13 AM)mtmarco Wrote:  (elf reading, relocation or what has to be done to get the instruction disassembled and reexecuted)

ELF is in Core/ELF, as is relocation. Mostly it's triggered in Core/HLE/sceKernelModule.cpp. Jit is per arch, e.g. in Core/MIPS/x86/.

(05-20-2014 10:13 AM)mtmarco Wrote:  or at least generate parameters for the following rendering....

Yes, these parameters then affect primitives that are drawn when it flushes (these use the vertex and fragment shaders.)

FYI, Software can also be used and obviously does not use any shaders. DirectX doesn't work on Windows yet.

(05-20-2014 10:13 AM)mtmarco Wrote:  Ok now this last part is mostly my assumption, so my question is: from the point 5 in advance what does really happens??:
CPU_init() basically with which class/sourcefiles connects and what pactically does? And where does GPU_init() hook/end up?

The GPU is initialized, potentially running on a separate thread from the CPU (depending on settings.) Then the CPU runs. All GPU work is triggered by the CPU in some way.

Normally, this is via Core/HLE/sceGe.cpp. It will submit displaylists or what have you. Also, frames are displayed in Core/HLE/sceDisplay.cpp. These functions are called by game code or on a timer in a couple cases (like vblanks.)

(05-20-2014 10:13 AM)mtmarco Wrote:  and also i have a snapdragon 800 smartphone with GLES 3 adreno 330 gpu (samsung galaxy Note 3), with not so high performance as expected with ppsspp on android, and so i want to see also this...

Well, it might be useful to profile your device to see why it does not have good performance. My phone does not even support GLES3 and is Adreno as well, and I get okay performance. I know that larger screen resolution has a big impact (try e.g. "small display" to see if this is a problem.) But, different games have different issues.

-[Unknown]