Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Milestone tracking for "Prettify" #302

Closed
48 tasks done
Helco opened this issue Feb 4, 2024 · 1 comment
Closed
48 tasks done

Milestone tracking for "Prettify" #302

Helco opened this issue Feb 4, 2024 · 1 comment
Labels
group Issue tracking a task-group

Comments

@Helco
Copy link
Owner

Helco commented Feb 4, 2024

This is an issue where I collect my thoughts about the next milestone and track issues. I might create an actual GitHub milestone if there are enough related GitHub issues.

Next Milestone

My current high-level plan for zzio has these milestones:

  1. Gameplay working from London to leaving Endeva (without trainer fight)
  2. Polish experience of that gameplay section
  3. Start adding fights (<- we are here 😳)
  4. Draw the rest of the owl

The reason for this is this in-between milestone is to ensure that the systems are working stable before beginning another massive section of this project.

Tasks to do

in no particular order

Features and bugs

Architecture and dependencies

  • Configuration variables?
  • Rework resource disposal #180
    I might want to think a bit longer on this.
    It is bothering me and I have a less clever approach in the works
  • Cleanup dependencies
    • Veldrid does not need OpenGL or Direct3D anymore
    • Veldrid.SPIRV will not be necessary anymore
      Only present in zzmaps anymore pending Migrate zzmaps to Mlang #270
    • Mlang.MSBuild should not add runtime references
    • Replace Veldrid.SDL2 with Silk.NET.SDL
      This should also preemptively fix issues for the cross-platform stuff
    • Remove Veldrid.StartupUtilities after that ^
    • Upgrade ImGui.NET
    • build(deps): bump nunit from 3.14.0 to 4.0.1 #265
    • Replace SafeStbImageSharp with SDL
      One dependency less
  • Logging
    • Serilog looks good, how about that?
    • Is enrichment by class name possible?
    • Logging should be configurable by CLI options
    • Log to Remotery
  • Readd ImGuizmo after fixing cimgui on Windows
  • Replace DeepSource cross: Enable analyzers and fix issues #312
    • Maybe just dotnet-format?
    • Recheck if .editorconfig works good enough
  • Remotery
    Performance seems not as good as expected, Remotery should easily show the culprit and be helpful for any future performance analysis
    • Preparing bindings repository
    • Add to Zanzarah, Game, UI and Sequential*System
  • Remove legacy PipelineCollection
  • Mlang pipeline overrides to reduce stored variants
    Although instead I added variant filters to Mlang reducing both compiled programs as well as stored variants by more than half

Cross-platform testing

If possible both for developer as well as user experience
Leaving the possibility to postpone larger issues if they come up
Of course this should be one of the last topics for this milestone

  • Windows x64
    No good access to Windows ARM right now, maybe ask MM
  • Linux
    • Debian-based x64
    • Arch-based x64
    • Raspberry PI
      It apparently is Vulkan-conformant
      Quick test: vkcube is running and it can almost build (no native shaderc). Not bad, but no dev on RPi4 for now :)
  • Mac OSX
    The newer Vulkan SDK and MoltenVK really do not like Veldrid very much, even with Pizzas fork. Maybe fix myself and talk to Pizza about merging. (meaning porting to Pizzas fork might be necessary for this)
    • x64
    • ARM
    • Add GitHub CI for osx-arm (thanks to the ARM runners)

Good-to-have

Meaning I am not sure yet whether to tackle these in this milestone

Postponed

@Helco Helco added the group Issue tracking a task-group label Feb 4, 2024
@Helco Helco pinned this issue Feb 4, 2024
@Helco
Copy link
Owner Author

Helco commented Feb 20, 2024

Preliminary results of Cross-platform testing

✔️ Windows x64

Still works

✔️ Linux Debian/Arch-based x64

  • ✔️ libdl is not loaded properly due to an outdated NativeLibraryLoader.
    Switching to Pizzas Veldrid fork should fix this
  • ✔️ MojoAL was linked statically with SDL2, causing conflicts. This was fixed.
  • ✔️ Ubuntu as debian-based distro was tested
    • 🚧 The shaderc library was broken as expected as we have no Silk release with fixed libraries yet. Overwriting as CI does works fine though.
    • libdl could be worked around like on Manjaro
  • I consider linux x64 to be working after zzre: Migrate to Veldrid fork of TechPizzaDev #323, the shaderc stuff will fix itself on time and can be worked around easily enough. If the issue persists unreasonably we can probably switch to pizzas interop or manually change the library in a Mlang update.

❌ Rasperry PI (Linux ARM64)

There are many missing libraries and the libdl problem might appear as well.

  • SDL2
    Ask the Silk.NET folks whether they might include Linux ARM64 builds
  • cimgui/cimguizmo
    • I guess I should rework ImGui-Nativebuild properly, put all artifacts into an archive and include more platforms
    • Maybe send both repo changes as PR, maybe they get accepted...

✔️ OSX x64/ARM64

I am putting these two together as they are very similar.

  • There is a branch with temporary fixes
    With these both platforms seem to work fine.
  • libvulkan.dylib is not found, copying them from the Vulkan SDK fixes this.
    It is questionable whether this is just a developer task or whether this should be fixed somehow, maybe with the Ryujinx MoltenVK dependencies?
  • ✔️ Vulkan portability mode with MVK
  • ✔️ D24_U8 is unsupported
    • The easier fix would be to just check that the other platforms support F32_S8 and switch (done that for now)
    • The better fix would be to introduce pipeline overrides to the ShaderVariantCollection after all and switch per platform
  • Vulkan validations
    • ✔️ VUID-VkBufferCopy-size-01988
      This I believe is a Veldrid bug as all other commands are checked for size==0 except one.
      (For us we can workaround by checking empty atomics in WorldMesh)
      PR sent at Fix UpdateBuffer not checking zero size veldrid/veldrid#524
    • All following issues seem to be fixed by using TechPizzas fork, even the SPIRV version one...
    • ✔️ VUID-VkShaderModuleCreateInfo-pCode-08737
      This is a Mlang bug, we have to figure out the right pairs of Vulkan-SPIRV-SPIRVBinary versions and create modules accordingly
    • ✔️ VUID-VkImageCreateInfo-imageCreateMaxMipLevels-02251
      This and the following could be Veldrid bugs, but also could be fixed in Pizzas fork.
    • ✔️ VUID-VkPresentInfoKHR-pImageIndices-01430
    • ✔️ VUID-vkAcquireNextImageKHR-fence-01287
    • ✔️ VUID-vkAcquireNextImageKHR-surface-07783
  • I have only encountered this on ARM64 but this might occur on x64 as well: F2 key does not work unless it is enabled in the system settings. Thanks Apple.
  • Validation is much happier with us since zzre: Migrate to Veldrid fork of TechPizzaDev #323, however there is another error when closing the window. This seems to also happen on windows just without the validation? It should be a general race condition:
    • ✔️ > Unhandled exception. Veldrid.VeldridException: A Vulkan validation error was encountered: [VK_DEBUG_REPORT_ERROR_BIT_EXT] (VK_DEBUG_REPORT_OBJECT_TYPE_UNKNOWN_EXT) Validation Error: [ VUID-vkDestroyImage-image-01000 ] | MessageID = 0xf2d29b5a | vkDestroyImage(): can't be called on VkImage 0xde4e51000000008b[] that is currently in use by VkImageView 0x8f5f070000000095[ImGui.NET View]. The Vulkan spec states: All submitted commands that refer to image, either directly or via a VkImageView, must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.275.0/mac/1.3-extensions/vkspec.html#VUID-vkDestroyImage-image-01000)
      at Veldrid.Vulkan.VkGraphicsDevice.DebugCallback(VkDebugReportFlagsEXT flags, VkDebugReportObjectTypeEXT objectType, UInt64 object, UIntPtr location, Int32 messageCode, SByte* pLayerPrefix, SByte* pMessage, Void* pUserData)

❔ Steam Deck (Linux x64)

We should expect similar problems like for Windows/Desktop Linux here.

❔ Proton

untested

❔ Steam Runtime

untested

❌ Windows ARM64

There are some mythical stories about some Windows ARM device that supports some Vulkan in some preview, but currently there is no SDK, no drivers, no experimental previews of these and no roadmap forward.

Untested, but I might have access to a device...
There will be several missing native dependencies.
Also it is unclear whether Vulkan works on Windows ARM at all (or on my device), which would be an instant blocker.

@Helco Helco closed this as completed Mar 13, 2024
@Helco Helco unpinned this issue Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
group Issue tracking a task-group
Projects
None yet
Development

No branches or pull requests

1 participant