Skip to content

Switch renderer from OpenGL to ANGLE#35

Merged
Wires77 merged 52 commits into
PathOfBuildingCommunity:masterfrom
zao:angle-meld
Sep 22, 2023
Merged

Switch renderer from OpenGL to ANGLE#35
Wires77 merged 52 commits into
PathOfBuildingCommunity:masterfrom
zao:angle-meld

Conversation

@Wires77
Copy link
Copy Markdown
Member

@Wires77 Wires77 commented Sep 17, 2023

To be done before merging:

  • Merge in master
  • Update CI script
  • Default ImGUI to off
  • Find out why debugging Lua doesn't let PoB launch
  • For running on wine (Running in an Ubuntu VM) it looks like we will need to also build VCRUNTIME140D.dll and ucrtbased.dll in order for it to work.

Nice-to-haves for later PRs:

  • Update SG version (1 -> 2)
  • Update README.md
  • Update PathOfBuilding-Launcher to support this update
  • Remove .sln and .vcxproj files
  • Update vcpkg hash
  • Remove vcpkg.txt and vcpkg-ports

zao added 30 commits May 14, 2021 16:52
The naive implementation only supported `*`, `*.*` and `*.ext` type patterns.
This improves the matching mechanism by mechanically rewriting the file part of the pattern into a regular expression. Do not pass untrusted paths into this as it doesn't guard against expressions of high complexity.
commit 4fdaf05
Author: Lars Viklund <zao@zao.se>
Date:   Mon Aug 22 19:27:01 2022 +0200

    Bump vcpkg to one with working LuaJIT, disable x64 builds

commit c5a1278
Author: Lars Viklund <zao@zao.se>
Date:   Sun Aug 14 23:55:56 2022 +0200

    Specify vcpkg.json path explicitly to avoid conflicts with registry

commit 601ea2c
Author: Lars Viklund <zao@zao.se>
Date:   Sun Aug 14 23:52:16 2022 +0200

    Add vcpkg registry for own LuaJIT build
There's plenty of optimization possible when drawing UI primitives where
primitives related by texture or colour can be merged into composite GPU
draw calls. This optimization can currently not be enabled wholesale as
much of the Lua code has hardcoded assumptions about draw order within
layers being preserved.

In order to more clearly manifest such order dependencies there's also
an entertaining option to completely shuffle the draw order of
primitives within each layer.

These new variables are `r_layerOptimize` and `r_layerShuffle`, both
defaulting to 0 (off).
zao added 6 commits September 13, 2023 19:34
It's possible that a legacy version of `cldapi.dll` is present on older
systems where it's not officially supported, which may have a different
set of exports. Guard against this by explicitly checking if the export
we desire is present.
Between no merging of draw calls at all and aggressively merging draw
commands in a way that the draw order differs from the submission order,
there's the possibility of a conservative order-preserving optimization.

This merges any contiguous sequence of draw calls that have the same
batch key into a single vertex buffer and drawing them together. This
reduces the number of GPU draw calls submitted, yielding decent frame
rate gains.
We can detect if nothing has changed from the previous frame by
computing a cheap hash of the draw command stream and if it matches we
reuse the previous contents of the render target we prepare anyway for
resolution scaling.
zao added 7 commits September 17, 2023 07:50
Historically we broke up draw batches by texture, viewport or blend
mode. If any of those changed, a new batch was opened and the previous
one was submitted to the GPU as it could no longer be appended to
without violating ordering constraints.

This commit adds a vertex attribute used to select among a set of
textures, limited by the maximum texture sampler count the OpenGL ES
implementation supports. As long as no more than that many textures are
used in adjacent draw calls they can all be merged into a single draw
call.

With an implementation that supports 16 texture samplers, a typical
passive skill tree can be drawn in around six draw calls with correct
draw ordering.
Viewport clipping can be emulated in shaders by passing in the viewport
extents via primitive attributes and discarding fragments in the
fragment shader with `discard` statements. This allows us to merge more
draw calls across previously uncrossable batch boundaries that arose
from viewport changes as those caused GPU state changes that must be
between draw calls.
Some views in the application can have a lot of geometry outside of the
viewports, particularly the passive skill tree.

We can save a lot of GPU work and emit fewer batch boundaries if we
conservatively cull out quads that are entirely outside of their
viewports by testing axis-aligned bounding boxes. This greatly speeds up
the skill tree when partially zoomed, which tends to be a common case.

This has benefits in reducing the amount of batch boundary cuts by not
having to consider the render states of unseen geometry, especially
texture changes.
Comment thread vcpkg.txt Outdated
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need this file now that we have vcpkg.json?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The vcpkg.txt files are indeed superfluous now in manifest mode as we have it all declared in vcpkg.json.

Copy link
Copy Markdown
Member Author

@Wires77 Wires77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need the vcpkg-ports folder anymore, right? Didn't they add a luajit version upstream we can use?

@zao
Copy link
Copy Markdown
Contributor

zao commented Sep 20, 2023

We don't need the vcpkg-ports folder anymore, right? Didn't they add a luajit version upstream we can use?

The local ports tree is currently unused, we are currently using a LuaJIT port from vcpkg upstream as we define which baseline vcpkg commit and what overlay ports to use in vcpkg-configuration.json.
I didn't remove the tree as I was uncertain if upstream LuaJIT would be good enough.

Copy link
Copy Markdown
Member Author

@Wires77 Wires77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw some support for other OSes in here, is the only thing unsupported opening URLs?

Comment thread engine/render/r_main.cpp
glLoadIdentity();
nextViewport_ = cmd->viewport;
if (showStats_) {
// ImGui::Text("VIEWPORT: %dx%d @ %d,%d", cmd->viewport.width, cmd->viewport.height, cmd->viewport.x, cmd->viewport.y);
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guessing these commented lines can be uncommented or removed?

Comment thread engine/render/r_main.cpp
Comment on lines +697 to +700
r_layerOptimize = sys->con->Cvar_Add("r_layerOptimize", CV_ARCHIVE | CV_CLAMP, "1", 0, 1);
r_layerShuffle = sys->con->Cvar_Add("r_layerShuffle", CV_ARCHIVE | CV_CLAMP, "0", 0, 1);
r_elideFrames = sys->con->Cvar_Add("r_elideFrames", CV_ARCHIVE | CV_CLAMP, "1", 0, 1);
r_drawCull = sys->con->Cvar_Add("r_drawCull", CV_ARCHIVE | CV_CLAMP, "1", 0, 1);
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, was going to ask if these were defaulted properly, as they weren't last time I tested.

@@ -0,0 +1,158 @@
// SimpleGraphic Engine
// (c) David Gowor, 2014
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically this isn't their work ;)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, surprised that most of this isn't necessary with GLFW

wrec.right = wrec.left + cur.mode[0];
wrec.bottom = wrec.top + cur.mode[1];
AdjustWindowRectEx(&wrec, style, FALSE, exStyle);
// TODO(LV): Verify that stored coordinates are aligned right.
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Showstopping TODO or nice-to-have?

@Wires77
Copy link
Copy Markdown
Member Author

Wires77 commented Sep 20, 2023

So one big issue I'm finding is that if I try and attach a debugger on the Lua side via PyCharm, PoB doesn't open and also doesn't kill the process. That invocation looks like this in Launch.lua:OnInit():

package.cpath = package.cpath .. ';C:/Users/trevo/AppData/Roaming/JetBrains/PyCharmCE2021.1/plugins/EmmyLua/debugger/emmy/windows/x86/?.dll'
local dbg = require('emmy_core')
dbg.tcpListen('localhost', 9966)
dbg.waitIDE()

I tried to use GetCloudProvider on Windows 11 using these reproduction steps: PathOfBuildingCommunity/PathOfBuilding#5390 (comment) Unfortunately, the output of the function showed a status of 1 for both a file that had been freed up, and one that was available...

For running on wine (Running in an Ubuntu VM) it looks like we will need to also build VCRUNTIME140D.dll and ucrtbased.dll in order for it to work.

Finally, we need to hide the ImGUI UI by default.

@zao
Copy link
Copy Markdown
Contributor

zao commented Sep 20, 2023

On the debugger - you seem to use the x86 rather than the x64 DLL. The docs need an update around this assuming it's the only problem. I could attach to the process (which had no window at the time) with PyCharm's Emmy plugin.

The cloud state is more about the provider as a whole rather than individual files as it queries the state of the sync root that contains the path. I couldn't find any conclusive state to query for whether a file could be successfully obtained apart from attempting to actually read it.
The cloud status mostly indicates if the service is running and as such has a chance to hydrate files, with 0 being disconnected, 1 being connected and values up in the 0x8000'0000s suggest that a new file hasn't been ingested yet.

We should never have a dependency on the Debug runtime in a shipping situation and custom is to not ever deploy it outside of a development machine as the license doesn't allow redistribution. To run a Debug build on a machine that doesn't have a dev environment you need to privately deploy those non-redist files - were you running a Debug build or has aspects of it crept into the release?

ImGui - yep.

@Wires77
Copy link
Copy Markdown
Member Author

Wires77 commented Sep 20, 2023

On the debugger - you seem to use the x86 rather than the x64 DLL. The docs need an update around this assuming it's the only problem. I could attach to the process (which had no window at the time) with PyCharm's Emmy plugin.

Doh, I just kept using my existing debug lines, forgetting they would have different DLLs. Works fine now as well.

The cloud state is more about the provider as a whole rather than individual files as it queries the state of the sync root that contains the path. I couldn't find any conclusive state to query for whether a file could be successfully obtained apart from attempting to actually read it. The cloud status mostly indicates if the service is running and as such has a chance to hydrate files, with 0 being disconnected, 1 being connected and values up in the 0x8000'0000s suggest that a new file hasn't been ingested yet.

It's better than nothing, we can see what kind of things we can do with that information at least.

We should never have a dependency on the Debug runtime in a shipping situation and custom is to not ever deploy it outside of a development machine as the license doesn't allow redistribution. To run a Debug build on a machine that doesn't have a dev environment you need to privately deploy those non-redist files - were you running a Debug build or has aspects of it crept into the release?

I found it easiest to pull the built binaries onto my VM via this PR: PathOfBuildingCommunity/PathOfBuilding#6705 They were built with these commands:

cmake -A x64 -G "Visual Studio 17 2022" --toolchain .\vcpkg\scripts\buildsystems\vcpkg.cmake -B build-output -DCMAKE_INSTALL_PREFIX=runtime
cmake --build build-output --config RelWithDebInfo -t INSTALL

@Wires77 Wires77 merged commit c3860c9 into PathOfBuildingCommunity:master Sep 22, 2023
@zao zao deleted the angle-meld branch October 16, 2023 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants