Client performance rant

[jordancoles]

Thanks for the info Loftar

You're clearly working hard

[loftar]

Just for the record, as a continuation of point 3, if anyone else, unlike me, can get some meaningful GPU profiling to work, I'd be quite interested in any results that may provide, or for a guide on how I can get it to work myself.

[romovs]

There is this old and now deceased - gDEBugger which seems to work on Windows 7 x64 with nvidia 4200M but not on Intel. This version in particular v5.8.1 (not an official source. Might be shady.) with latest nvidia driver.
Weirdly a year ago it wouldn't even launch on the same machine, I guess it might be picky towards video drivers version.
Has tons of performance metrics and produces some nice data. Although I haven't played with it much yet...

On Linux I wasn't able to get anything working either except apitrace which might be marginally useful, it's a call tracer but IIRC has a GPU timings graph.

Tried installing Nsight for VS right now. It captures performance analysis, producing some sort of timeline report, but I failed to make anything meaningful from it. The juicy stuff might be in its Graphics Debugging feature which is disabled. Probably c/c++ only.


EDIT:
Ok Nsight is useless. Doesn't work properly with java or maybe just due to GL 2.
gdebugger apparently is not very useful either. Can't inspect on per frame basis and generally buggy and I could make it work with nvidia performance counters. The only interesting things it complained about were:

- High number of glGetError calls. However disabling it on Windows nvidia 4200M and Intel 3000 has zero effect. But on Linux with Intel 530 it leads to 7FPS increase
- Some dud state changing commands but imo none of that should have much effect.
- Really small percentage of vertices out of total drawn with large percentage of batches.

[loftar]

- High number of glGetError calls. However disabling it on Windows nvidia 4200M and Intel 3000 has zero effect. But on Linux with Intel 530 it leads to 7FPS increase

That's somewhat interesting. I've left them all in simply because on the systems I've tried on, removing glGetError calls has made no difference (and it is somewhat helpful in some error reports). If that helps on more systems, then it is perhaps a cheap way to increase performance for those people until larger rewrites.

- Really small percentage of vertices out of total drawn with large percentage of batches.

What does this mean?

Thanks for looking into it, btw.

[Amanda44]

Hey, I can't help you with 'meaningful GPU profiling' ... ... but nice to see you working on client performance and 'hi' ...

[romovs]

- Really small percentage of vertices out of total drawn with large percentage of batches.

What does this mean?

Sorry I should have explained better.

By batch they refer to vertex drawing functions.
Statistics on the screenshot are per application run. Logged in and stood in a middle of the village for a minute or so.

A more detailed view of the aggregation from the first screenshot.


So essentially, there is large amount of batches (69% out of the total) that draw relatively small amount of vertices each (between 6 to 1728).
Unfortunately it doesn't show the statistics at a frame level nor actual function calls, so hard to make out the specifics from this.

[Jalpha]

Interesting read, thanks for sharing.

[Lizard_Paszczyk]

Did you think to write this game in C++ instead of java? C++ is much faster...

[loftar]

C++ is much faster...

That is debatable. It has been like 20 years since Java was slow.

But yes, I have considered it from time to time. Besides the prospect of rewriting everything, though, what I'm relying on the most right now in Java is the ability to load and run downloaded code in a platform-independent way, which I don't really have any alternative for in C/C++ that I have found to my liking.

[algorithm]

the ability to load and run downloaded code in a platform-independent way

JavaScript?