Posts: 34
Threads: 3
Joined: Nov 2016
Reputation:
0
Location: Nowhere
p, li { white-space: pre-wrap; }
On Wednesday, January 11, 2017 3:23:39 PM EST Gregory Hainaut wrote:
> You don't compare the same thing. This perf is GSdx alone (with pre recorded
> core emulation). And the 50 fps is without the draw call (so yes the
> overhead is 0 in this case but the screen remain black). I'm sure that
> Vulkan overhead is far from 0. I let you manage the conclusion.
>
> I have a good CPU, haswell at 4GHz. 50 fps is awfully low to render a black
> screen. With normal rendering (Nvidia driver) I'm around 160 fps on SotC
>
> By latest driver, you mean latest Mesa? Free driver is really slow but I
> need to benchmark it again. It ought to be better. If they merge gl
> threading, I'm pretty sure we will get a massive speed boost.
Ah thanks for the explanation,
Now I have two (real) questions:
1. What exactly do you mean by "prerecorded?" The core emulation is done and saved somewhere and used by GSdx?
2. You said "If they merge GL threading," - is there a way to install from source with it now? If so, I'd be very, very happy to benchmark.
Oh right.
3. How can I perform a benchmark of speed on my computer so I can check how much of an impact a PR or a driver update makes?
Thanks in advance.
Moved this to forum as it was off-topic
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
1/ Imagine a standard video game. Let's you can record all GPU PCIe transactions in a dump file. If you want replay the rendering you just need to read the dump, and regenerate the same transactions. You can do the same with the GS. You can record all the transaction from the CORE to the GS (called gsdump). Therefore you can easily replay/debug/benchmark a scenario without core emulation.
2/ Marek did a branch to implement gl threading. I don't know the status, neither I remember the branch name.
3/ It depends of what you want to want to benchmark. On the GS/GPU side, it is better to use the built-in GSdx benchmark mode (done automatically when you replay a gs dump).
You first need to generate a dump (search on the forum), tweak the GSdx option (in particular linux_replay), then build the replayer to replay the dump.
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
IMHO it is harder the speed impact as you have more parameters in the equation. Anyway you can look at the various value in the title bar.
The % are the thread activity. 0 == sleeping. +90 == suck CPU power.
You need to find some interesting scene to benchmark. Maybe you can increase blending accuracy to increase driver work.
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
By the way there is likely an option to enable disable gl threading
Posts: 34
Threads: 3
Joined: Nov 2016
Reputation:
0
Location: Nowhere
There is - IIRC from last night when I stayed up until two trying to get marek's branch working an env variable named mesa_threading should be set to "true" to enable it.
I need to fix my computer. Maybe you can help. When I installed the branch I compiled, it overwrote Debian's files (most importantly the DRI and libGL.so files). Now multiple GL extensions are no longer supported, and glxinfo gives this:
name of display: :0
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 48
Current serial number in output stream: 47
I'm going to try compiling the X11 Server as well and see if that helps, but in all honesty I have NO clue what I'm doing right now. I don't usually work this close to system libs, which is why I first tried installing into /usr/local/ instead of /usr. Yeah, nope.
Posts: 6.069
Threads: 68
Joined: May 2010
Reputation:
167
Location: Grenoble, France
Restore your debian lib.
You can use this kind of command "apt-get install --reinstall ....mesa_package_name...."
I will give you tonight the instruction to use mesa without any installation (it can be done with env variable).
Note: you need to compile a 32 bits version of Mesa.
The GS % contains the CPU time of thread. Currently it includes the time spent in the driver. Once you enable the new option, driver gl command will be dispatched to a separate thread. So GS % must go down.
Posts: 34
Threads: 3
Joined: Nov 2016
Reputation:
0
Location: Nowhere
I know how to reinstall packages, one of the first things I did was reinstall GL and the DRI and try again. I didn't know that I could use mesa without installing. Oops. Need to recompile mesa again.
I've noticed that a DX9 implementation exists in mesa. If I compile and install it, do you know if WINE could use it at higher speed? I only ask here because I spent over eight hours trying to figure it out before giving up and you clearly know more about mesa3d than I do.
Posts: 34
Threads: 3
Joined: Nov 2016
Reputation:
0
Location: Nowhere
01-13-2017, 09:00 PM
(This post was last modified: 01-13-2017, 09:01 PM by pixelherodev.)
Question: keeping --with-dri-drivers= blank will prevent the installed drivers from being overwritten, right?
Also, it did break mine. Currently, it will not load the intel (i965 IIRC) driver. It's staying with the llvmpipe one. I can't fix it. I'm just going to reinstall in a few minutes.
Since it's not based on Gallium, will your script still work?