Opened 5 months ago

Closed 5 months ago

#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 Langbart)

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.

https://ttm.sh/wvr.mp4

observations

  • After only reducing the materialmgr.quality value from 10 to 1 the performance is much better less bad.
  • When only lowering the adaptivefps.session from 60 to 20 as mentioned in #6193 the slowdown is not noticeable between full screen and window mode.
  • When only switching from OpenGL to OpenGL ARB 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].

reproducible

  • The same map on A25 with the same game settings works normally, the problem must have been introduced after [25860].
  • Even after increasing materialmgr.quality from 2 to 10 the performance was still better in A25 compared to the latest GIT version [27009]. This means that changing the default values with [26976] cannot be the sole reason, but that another change set must also have contributed to the issue.

Attachments (7)

india_biome.jpg (399.0 KB ) - added by Langbart 5 months ago.
mainlog_6593_with_rP27013.html (82.4 KB ) - added by Langbart 5 months ago.
quarter.jpg (168.4 KB ) - added by Langbart 5 months ago.
6593_commands.txt (7.4 KB ) - added by Langbart 5 months ago.
6593_image_replay_test.jpg (142.3 KB ) - added by Langbart 5 months ago.
rc2_profile2.jsonp.zip (1.6 MB ) - added by Langbart 5 months ago.
GIT_rP27013_profile2.jsonp.zip (1.6 MB ) - added by Langbart 5 months ago.

Change History (36)

by Langbart, 5 months ago

Attachment: india_biome.jpg added

comment:1 by Vladislav Belov, 5 months ago

How does the performance change if slowly resize the window to the fullscreen size without enabling fullscreen?

comment:2 by Langbart, 5 months ago

Description: modified (diff)

adding bisect number [26859].

in reply to:  1 comment:3 by Langbart, 5 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!

Last edited 5 months ago by Langbart (previous) (diff)

in reply to:  2 ; comment:4 by Vladislav Belov, 5 months ago

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.

Bisect might lead to a local slow down which was fixed afterwards.

Last edited 5 months ago by Vladislav Belov (previous) (diff)

comment:5 by marder, 5 months ago

I can't reproduce. Both work ok for me.

in reply to:  4 ; comment:6 by Langbart, 5 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.

comment:7 by Stan‘, 5 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.

in reply to:  6 ; comment:8 by Vladislav Belov, 5 months ago

Replying to Langbart:

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].

Do you have something in logs? What if enable debug layers in config? Might it be related to throttling?

in reply to:  7 comment:9 by Langbart, 5 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(  
    121121    const CDeviceCommandContext::UploadBufferFunction& uploadFunction)
    122122{
    123123    ENSURE(dataOffset < dataSize);
    124     // Tell the driver that it can reallocate the whole VBO
    125     glBufferDataARB(target, bufferSize, nullptr, GL_DYNAMIC_DRAW);
    126     ogl_WarnIfError();
    127 
    128124    while (true)
    129125    {
    130126        // (In theory, glMapBufferRange with GL_MAP_INVALIDATE_BUFFER_BIT could be used
    void CDeviceCommandContext::UploadBufferRegion(  
    356352    ScopedBufferBind scopedBufferBind(this, buffer->As<CBuffer>());
    357353    if (buffer->IsDynamic())
    358354    {
     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();
    359358        UploadDynamicBufferRegionImpl(target, buffer->GetSize(), dataOffset, dataSize, [data, dataSize](u8* mappedData)
    360359        {
    361360            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) ====
...

in reply to:  8 ; comment:10 by Langbart, 5 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 Langbart, 5 months ago

in reply to:  10 ; comment:11 by Vladislav Belov, 5 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.

Could you check r26405 and r26406?

in reply to:  11 ; comment:12 by Langbart, 5 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.

Could you check r26405 and r26406?

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.

Last edited 5 months ago by Langbart (previous) (diff)

in reply to:  12 comment:13 by Vladislav Belov, 5 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.

in reply to:  11 comment:14 by Langbart, 5 months ago

Replying to Vladislav Belov:

I mean checking performance for these two commits, because they touch the same code.

  • Tested it for the performance problem and could not find any indication in [26405] or [26406] that would fit the description of this ticket. NO performance issue between full screen and window mode for those change sets.
  • The mainlog.html looked similar for either [26405] and [26406] as does it for [27013] with lots of warnings.

comment:15 by Langbart, 5 months ago

Is comment:9 not a suitable solution?

in reply to:  15 comment:16 by Vladislav Belov, 5 months ago

Replying to Langbart:

Is comment:9 not a suitable solution?

Unfortunately - no, it changes the behaviour described in the comment. Also the commit performance change shouldn't depend on resolution (maybe something becomes visibile during resizing?), as it affects only vertices.

comment:17 by Vladislav Belov, 5 months ago

Also performance results contradict to results from Phab:D4638. Are results for combat huge are still relevant?

Last edited 5 months ago by Vladislav Belov (previous) (diff)

in reply to:  17 ; comment:18 by Langbart, 5 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.

in reply to:  18 ; comment:19 by Stan‘, 5 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.

in reply to:  19 comment:20 by Langbart, 5 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 config folder 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.

comment:21 by Stan‘, 5 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 :(

in reply to:  21 comment:22 by Langbart, 5 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:23 by Stan‘, 5 months ago

Because you use the most recent SDK as stated in #6193.

comment:24 by Stan‘, 5 months ago

What if you set hidpi = true?

in reply to:  24 comment:25 by Langbart, 5 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 Langbart, 5 months ago

Attachment: quarter.jpg added

comment:26 by Langbart, 5 months ago

Summary: Performance issue full screen for India biome[macOS] Performance issue full screen for India biome

comment:27 by Stan‘, 5 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 Langbart, 5 months ago

System info

Replay

  • Created a map with 3 players (me+2AI's) on a normal sized Unknown map for the India biome with the Naval: Archipelago landscape. Entered the cheat code gift from the gods and sent 27 swords man on a one minute journey.

Procedure (Visual Replay)

  1. add profiler2.autoenable = true to user.cfg file
  2. run the replay in full screen mode for the GIT version and for the RC2 version
  3. open profiler2.html in browser (but only when the loading screen disappears and the actual replay starts)
  4. replay begins, choose paria and click Follow Player
  5. replay ends, click Save Live Report to file
  6. save profiler2.jsonp from the log folder and rename it

Summary: Performance on the RC2 version was nice and smooth, very bumpy on the GIT version.

Last edited 5 months ago by Langbart (previous) (diff)

by Langbart, 5 months ago

Attachment: 6593_commands.txt added

by Langbart, 5 months ago

Attachment: 6593_image_replay_test.jpg added

by Langbart, 5 months ago

Attachment: rc2_profile2.jsonp.zip added

by Langbart, 5 months ago

comment:29 by Langbart, 5 months ago

Milestone: Alpha 26
Resolution: duplicate
Status: newclosed
  • #6193 is a more concise version of this ticket and will be kept open, #6593 ticket will be mentioned over there.
Note: See TracTickets for help on using tickets.