Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PCSX2 Debugger
#1
Will PCSX2 have a GPU Debugger in the future, i see they already have a CPU Debugger but will they have a GPU Debugger in the future like the one on psspss
Reply

Sponsored links

#2
I'm pretty sure it's not really necessary. If we need to debug the GS, we'd use .gs dumps instead. They provide more of the necessary information as the GS has its own MIPS instructions
[Image: 36a66c559937a1f5d0cd7460362d4093.jpg?bg=2c2c2c]
Reply
#3
Depends of what you want to do. But you can
* print log of various stuff (openGL)
* Dump a txt file that describe the draw call (from GS point of view)
* Dump all textures of a draw call
* Use an external tool to trace everything in a nice GUI (see polygon, texture, configuration), GPU side (rather than GS side)

I debugged tons of issue this way. It is quite efficient.

For the record, GS isn't a CPU (and so not MIPS).
Reply
#4
(08-21-2016, 10:49 AM)gregory Wrote: Depends of what you want to do. But you can
* print log of various stuff (openGL)
* Dump a txt file that describe the draw call (from GS point of view)
* Dump all textures of a draw call
* Use an external tool to trace everything in a nice GUI (see polygon, texture, configuration), GPU side (rather than GS side)

I debugged tons of issue this way. It is quite efficient.

For the record, GS isn't a CPU (and so not MIPS).

Can you tell me how to do that
Reply
#5
what do you want to do? This way I could provide you the best answer instead to write a long wall of text.
Reply
#6
(08-21-2016, 10:49 AM)gregory Wrote: * Dump all textures of a draw call

Any way to load edited textures back?
Hey,  I'm writing yet another PCSX2 frontend. Source code is being hosted at GitHub.
Reply
#7
(08-22-2016, 05:33 PM)FaithLV Wrote: Any way to load edited textures back?

i think we all discussed that a bunch of times. it's not working. due to the texture cache. it's a flux memory cache. and textures can be assigned random locations in the gs memory pages. that can change per drawcall. in those 'worst case' games this is not trackable to assign a specific texture that needed specific address or value or hash or anything to identify and to replace it without failure.

in some games (i'd only refer to wipeout fusion i know) where the core gs memory footprint seems to be fixed per track it could work, but an engine that reloads textures on the fly and a lot are impossible to overload.
Reply
#8
A visual debugger for GS will be nice someday for monitoring color/depth/texture_dump/register states, but however it would probably be limited to the GS plugin itself rather than a core implementation.
Reply
#9
You can dump info with
* dump = 1
* save = 0 (save framebuffer)
* savef = 0 (final frame)
* savel = 20 (number of draw call)
* saven = 0 (first draw call)
* savet = 0 (save texture)
* savez = 0 (save depth buffer)


   

Here an example of a GPU debugger (apitrace, but Windows/Intel/AMD/Nvidia provide some too). On the left, you can see draw call configuration with all logging, you can fold info. On the top right you can see current shader/texture(example below)/vertex data/constant parameters. It works well for the HW renderer. For SW, I generally dump everything (with above options) and then I compare both renderer side by side.
Reply




Users browsing this thread: 1 Guest(s)