#6593 closed defect (duplicate)
[macOS] Performance issue full screen for India biome
| Reported by: | Langbart | Owned by: | |
|---|---|---|---|
| Priority: | Release Blocker | Milestone: | |
| Component: | Core engine | Keywords: | |
| Cc: | Patch: |
Description (last modified by )
Issue
When playing a specific random map with the default settings applied in full screen everything felt very slow, like walking through mud. Performance was better in window mode.
to reproduce
- start the following map with the default settings and full screen
- Notice the extreme performance drop between full screen and window mode.
- See video below for more clarity. Watch the women walking to the meeting point. Everything is smooth in window mode, but slow in full screen mode.
observations
- After only reducing the
materialmgr.qualityvalue from10to1the performance ismuch betterless bad. - When only lowering the
adaptivefps.sessionfrom60to20as mentioned in #6193 the slowdown is not noticeable between full screen and window mode. - When only switching from
OpenGLtoOpenGL ARBorVulkan(came with [27488]) the slowdown is not noticeable.
bisect
I am very confident that the change set [26859] is the cause of the problem.
Just to be clear, I also tested [26858], but the performance problem could not be observed in this big change set, it must be [26859].
Attachments (7)
Change History (37)
by , 14 months ago
| Attachment: | india_biome.jpg added |
|---|
follow-up: 3 comment:1 by , 14 months ago
follow-up: 4 comment:2 by , 14 months ago
| Description: | modified (diff) |
|---|
adding bisect number [26859].
comment:3 by , 14 months ago
Replying to Vladislav Belov:
How does the performance change if slowly resize the window to the fullscreen size without enabling fullscreen?
I noticed the slowdown ~1550x1038, see video below for more clarity!
follow-up: 6 comment:4 by , 14 months ago
follow-up: 8 comment:6 by , 14 months ago
| Description: | modified (diff) |
|---|
Replying to Vladislav Belov:
Replying to Langbart:
adding bisect number [26859].
The commit code doesn't depend on resolution. If it's the reason it should behave the same for various resolutions.
I undid all the code changes from [26859] and compiled, when I tested, the slowdown was not observed. I am very certain that the issue came with [26859].
PS: Added two notes to the ticket description regarding FPS and render backend under observations.
macOS
The ticket might be related to #6193 (1/Jun/21). See related IRC 0ad-dev discussion 1/Jun/21 about #6193.
follow-up: 9 comment:7 by , 14 months ago
Can you try something ? Move back
// Tell the driver that it can reallocate the whole VBO glBufferDataARB(target, bufferSize, nullptr, GL_DYNAMIC_DRAW); ogl_WarnIfError();
From UploadDynamicBufferRegionImpl to CDeviceCommandContext::UploadBufferRegion
Might be useless, it's just to check.
follow-up: 10 comment:8 by , 14 months ago
comment:9 by , 14 months ago
Replying to stanislas69:
Can you try something ?
I have made the change you see below and the slowdown is no longer observed. It fixes that particular problem described in this ticket.
-
source/renderer/backend/gl/DeviceCommandContext.cpp
a b void UploadDynamicBufferRegionImpl( 121 121 const CDeviceCommandContext::UploadBufferFunction& uploadFunction) 122 122 { 123 123 ENSURE(dataOffset < dataSize); 124 // Tell the driver that it can reallocate the whole VBO125 glBufferDataARB(target, bufferSize, nullptr, GL_DYNAMIC_DRAW);126 ogl_WarnIfError();127 128 124 while (true) 129 125 { 130 126 // (In theory, glMapBufferRange with GL_MAP_INVALIDATE_BUFFER_BIT could be used … … void CDeviceCommandContext::UploadBufferRegion( 356 352 ScopedBufferBind scopedBufferBind(this, buffer->As<CBuffer>()); 357 353 if (buffer->IsDynamic()) 358 354 { 355 // Tell the driver that it can reallocate the whole VBO 356 glBufferDataARB(target, buffer->GetSize(), nullptr, buffer->IsDynamic() ? GL_DYNAMIC_DRAW : GL_STATIC_DRAW); 357 ogl_WarnIfError(); 359 358 UploadDynamicBufferRegionImpl(target, buffer->GetSize(), dataOffset, dataSize, [data, dataSize](u8* mappedData) 360 359 { 361 360 std::memcpy(mappedData, data, dataSize);
But I get 1 warning when compiling!
... ==== Building engine (release) ==== ==== Building graphics (release) ==== DeviceCommandContext.cpp ../../../source/renderer/backend/gl/DeviceCommandContext.cpp:119:38: warning: unused parameter 'bufferSize' [-Wunused-parameter] const GLenum target, const uint32_t bufferSize, ^ 1 warning generated. Linking graphics /Library/Developer/CommandLineTools/usr/bin/ranlib: file: ../../../binaries/system/libgraphics.a(precompiled.o) has no symbols ==== Building atlas (release) ==== ...
follow-up: 11 comment:10 by , 14 months ago
Replying to Vladislav Belov:
Do you have something in logs?
Nothing in interestinglog.html but a multitude of warnings in mainlog.html (will attach as mainlog_6593_with_rP27013.html)
... Loading trigger script 'maps/scripts/ConquestCommon.js' Loading trigger script 'maps/scripts/Conquest.js' Info when linking program 'shaders/glsl/model_common.vs'+'shaders/glsl/solid.fs': WARNING: Output of vertex shader 'v_depth' not read by fragment shader WARNING: Output of vertex shader 'v_lighting' not read by fragment shader WARNING: Output of vertex shader 'v_shadow' not read by fragment shader WARNING: Output of vertex shader 'v_tex' not read by fragment shader WARNING: Output of vertex shader 'v_los' not read by fragment shader Info when linking program 'shaders/glsl/model_common.vs'+'shaders/glsl/solid.fs': WARNING: Output of vertex shader 'v_half' not read by fragment shader WARNING: Output of vertex shader 'v_normal' not read by fragment shader WARNING: Output of vertex shader 'v_depth' not read by fragment shader WARNING: Output of vertex shader 'v_lighting' not read by fragment shader WARNING: Output of vertex shader 'v_shadow' not read by fragment shader WARNING: Output of vertex shader 'v_tex' not read by fragment shader WARNING: Output of vertex shader 'v_los' not read by fragment shader Info when linking program 'shaders/glsl/model_common.vs'+'shaders/glsl/solid.fs': WARNING: Output of vertex shader 'v_half' not read by fragment shader WARNING: Output of vertex shader 'v_normal' not read by fragment shader WARNING: Output of vertex shader 'v_depth' not read by fragment shader WARNING: Output of vertex shader 'v_lighting' not read by fragment shader WARNING: Output of vertex shader 'v_shadow' not read by fragment shader WARNING: Output of vertex shader 'v_tex' not read by fragment shader WARNING: Output of vertex shader 'v_los' not read by fragment shader Info when linking program 'shaders/glsl/model_common.vs'+'shaders/glsl/solid.fs': WARNING: Output of vertex shader 'v_depth' not read by fragment shader WARNING: Output of vertex shader 'v_lighting' not read by fragment shader WARNING: Output of vertex shader 'v_shadow' not read by fragment shader WARNING: Output of vertex shader 'v_tex' not read by fragment shader WARNING: Output of vertex shader 'v_los' not read by fragment shader ...
What if enable debug layers in config?
Do you mean those ?
; Enables additional debug information in renderer backend. renderer.backend.debugcontext = "false" renderer.backend.debugmessages = "false" renderer.backend.debuglabels = "false" renderer.backend.debugscopedlabels = "false"
Might it be related to throttling?
No, it can not be throttling the issue does not occur in A25b with the same config and game settings.
by , 14 months ago
| Attachment: | mainlog_6593_with_rP27013.html added |
|---|
follow-ups: 12 14 comment:11 by , 14 months ago
Replying to Langbart:
Do you mean those ?
; Enables additional debug information in renderer backend. renderer.backend.debugcontext = "false" renderer.backend.debugmessages = "false" renderer.backend.debuglabels = "false" renderer.backend.debugscopedlabels = "false"
Yep.
follow-up: 13 comment:12 by , 14 months ago
Replying to Vladislav Belov:
Replying to Langbart:
Do you mean those ?
; Enables additional debug information in renderer backend. renderer.backend.debugcontext = "false" renderer.backend.debugmessages = "false" renderer.backend.debuglabels = "false" renderer.backend.debugscopedlabels = "false"Yep.
After I have activated it, I do not see any messages and the mainlog has no noticeable different messages from the one with the renderer.backend.debug* set to false.
You mean looking for the occurrence of these warnings in the mainlog? Because I already did a full bisecting between HEAD and A25b and ended at [26859] for this ticket's issue.
comment:13 by , 14 months ago
Replying to Langbart:
You mean looking for the occurrence of these warnings in the mainlog?
I mean checking performance for these two commits, because they touch the same code.
comment:14 by , 14 months ago
Replying to Vladislav Belov:
I mean checking performance for these two commits, because they touch the same code.
comment:16 by , 14 months ago
follow-up: 18 comment:17 by , 14 months ago
Also performance results contradict to results from Phab:D4638. Are results for combat huge are still relevant?
follow-up: 19 comment:18 by , 14 months ago
Replying to Vladislav Belov:
Also performance results contradict to results from Phab:D4638. Are results for combat huge are still relevant?
Only the difference in full screen and window mode was tested here.
follow-up: 20 comment:19 by , 14 months ago
Hey,
I cannot seem to be able to reproduce on my M1 MacBook Pro. Are you testing on an Intel based Mac or on an AARCH64 one?
I tried with A25B and RC2 and I don't see a huge drop in performance.
Maybe we have different graphics settings? Could you take a screenshot of your options for both versions, maybe you have something like whole map shadows.
Replying to Langbart:
Replying to Vladislav Belov:
Also performance results contradict to results from Phab:D4638. Are results for combat huge are still relevant?
Only the difference in full screen and window mode was tested here.
I think he means that this patch specifically was meant to fix a performance bug you found, so it's weird that it fixed it but at the same time introduced a huge slow down.
comment:20 by , 14 months ago
Replying to stanislas69:
Are you testing on an Intel based Mac or on an AARCH64 one?
Could you take a screenshot of your options for both versions, maybe you have something like whole map shadows.
- I move my normal
configfolder always to a different location for testing, so I always test with the default settings.
Replying to Langbart:
Replying to Vladislav Belov:
Also performance results contradict to results from Phab:D4638. Are results for combat huge are still relevant?
Only the difference in full screen and window mode was tested here.
I think he means that this patch specifically was meant to fix a performance bug you found, so it's weird that it fixed it but at the same time introduced a huge slow down.
This bug is similar to #6193, where I also experienced a huge slowdown.
follow-up: 22 comment:21 by , 14 months ago
Could you test the release bundle then ? Because if its that one there is nothing we can do before we switch to Vulkan :(
comment:22 by , 14 months ago
Replying to stanislas69:
Could you test the release bundle then ? Because if its that one there is nothing we can do before we switch to Vulkan :(
Have tested the RC2 version and the problem from this ticket is not reproducible there, but it is still present in my GIT version. The whole config folder was deleted for testing, no background applications and no special commands were used to start pyrogenesis. Even after a clean build the problem remains the same, why do the tests between my GIT version and RC2 differ?
comment:25 by , 14 months ago
Replying to wraitii:
From what I can tell, this doesn't happen:
- when compiled against the 10.12 SDK (as does the CI)
- when enabling High DPI in the SDL2 window
- when limiting the frame rate below some magic number, but that's less consistent.
hidpi = true has no effect, the issue remains for my working copy. It should be noted that hidpi only gives me a quarter of the game window.
I can close this a duplicate?
by , 14 months ago
| Attachment: | quarter.jpg added |
|---|
comment:26 by , 14 months ago
| Summary: | Performance issue full screen for India biome → [macOS] Performance issue full screen for India biome |
|---|
comment:27 by , 14 months ago
It seems so but before we do, could you run Profiler2 (Your usual setup) so we can see if any of the graphics graph show the gaps? It could be a driver bug from Intel.
comment:28 by , 14 months ago
System info
Replay
- Created a map with 3 players (me+2AI's) on a
normalsizedUnknownmap for theIndiabiome with theNaval: Archipelagolandscape. Entered the cheat codegift from the godsand sent 27 swords man on a one minute journey.
Procedure (Visual Replay)
- add
profiler2.autoenable = truetouser.cfgfile - run the replay in full screen mode for the GIT version and for the RC2 version
- open
profiler2.htmlin browser (but only when the loading screen disappears and the actual replay starts) - replay begins, choose
pariaand clickFollow Player - replay ends, click
Save Live Report to file - save
profiler2.jsonpfrom the log folder and rename it
Summary: Performance on the RC2 version was nice and smooth, very bumpy on the GIT version.
by , 14 months ago
| Attachment: | 6593_commands.txt added |
|---|
by , 14 months ago
| Attachment: | 6593_image_replay_test.jpg added |
|---|
by , 14 months ago
| Attachment: | rc2_profile2.jsonp.zip added |
|---|
by , 14 months ago
| Attachment: | GIT_rP27013_profile2.jsonp.zip added |
|---|
comment:29 by , 14 months ago
| Milestone: | Alpha 26 |
|---|---|
| Resolution: | → duplicate |
| Status: | new → closed |
comment:30 by , 8 months ago
| Description: | modified (diff) |
|---|
Update: Vulkan as a renderer backend came with [27488]
The issue remains exactly the same as described in the ticket, but only for OpenGL, when I switch to Vulkan the issue is gone.
- added the new info to the ticket summary
How does the performance change if slowly resize the window to the fullscreen size without enabling fullscreen?