v0.13.0-image-hot-reload

New

This release adds a few quality-of-life improvements to dealing with images. The le_resource_manager has been rewritten so that it becomes very easy to hot-reload any images. If an image is added via the resource manager and tagged as watched, any changes to the original image will trigger a resource reload. This even works if the updated image has different file size, format, or dimensions.

le_pixels has been rewritten from the ground up - image decoders now must implement a generic interface, which means that the resource manager can interact with them in an abstract way (shout-out to Barbara Liskov) - and you can implement & register new image decoders with the resource manager at run-time and get all the benefits of resource hot-reloading for any new image format for free.

When you register an image decoder with a resource manager, you give a file extension for which to use this decoder. You can register new decoders for new filetypes, or override the defaults at runtime. The resource manager by defaults loads decoders from le_pixels for .jpg, jpeg, .png, ...

To make image loading more efficient, the renderer is now able to directly map GPU memory - this means that image decoders may read their pixels directly into GPU memory - and the new version of le_resource_manager certainly does.

What's Changed

• b19d116 [image_decoder] add an abstract interface for image decoders, which anyone may implement
• 243ddde [core] core only zeroes out an api on initial load, which allows you to persist pointers throughout api reload if you choose - this can be useful to hold persistent references to singleton objects for example
• 5a6b3e1 [image decoder] update stb_image to latest version
• d7b6d3a [renderer] implement mapping image and buffer memory directly to GPU memory
• 90fe8ec [resource_manager] use direct memory mapping when uploading resources
• b82da59 [cmake] output build artifacts into ./bin --- this should keep things a bit cleaner
• 53c403e [le_resource_manager] make image import format aware - attempt to find a matching vkFormat based on image data (e.g. eR8Unorm for a grayscale image)
• e10cb7a [beauty] add constant width grid shaders
• ee28fca [le_imgui] make le_imgui self-contained by using pre-compiled shaders, and by embedding default font (you don't have to add any resources anymore when using le_imgui)

Fixes

• 79cf03d [le_renderer] fix issue where re-using renderpasses would generate wrong debug .dot graphs
• 2102510 [le_tweaks] fixes to le_tweaks - making tweaks more robust after hot-reloading
• 12ef73a [cmake] warn if the imgui submodule is missing

Full Changelog: v0.12.0-vk-video-decode...v0.13.0-image-hot-reload

v0.12.0-vk-video-decode

New

Hardware accelerated video decoding (H.264, for now) using Vulkan Video Decode.

Island's new le_video_decoder module allows you to use your GPU most efficiently by shifting video processing onto dedicated video decode hardware. Instead of using an extra dependency, le_video_decoder implements this by using the new Vulkan Video API, therefore keeping video decoding perfectly on the GPU.

The new video decoder module provides a simple API that aims to abstract away any gnarly sync issues: the latest decoded frame is made available as a plain image resource handle which synchronizes nicely and implicitly with Island's rendergraph. By default, videos will loop perfectly; YCrCb conversion happens automatically using specialized Vulkan samplers. A new example application shows the video player in action.

Adding and implementing Vulkan Video Decode has been a long time in the making; This release has been tested on Linux (ubuntu 22.04 LTS) and Windows (11) and an Nvidia 4090 GPU, where I got to comfortably decode and play 14 1920x1080@50fps videos simultaneously.

Other GPUs will most likely work, too as long as they support a Video Decode Queue (it's recommended to update drivers, as Vulkan Video is still fairly new). I'd love to find out how this fares on Intel and/or AMD GPUs - test reports, PRs or hardware donations (so I can test & implement fixes) are most welcome ;)

There are a lot more features and bug fixes in this release.

What's Changed

• NEW Video decoder by @tgfrerer in #57
• e383df6 NEW Video player example app: an Island example application that shows how to use the new video decoder module
• 9704b25 NEW implement automatic hardware-accelerated YCbCr conversion for textures annotated with __ycbcr__ in sampler code
• b4210f4 NEW add callback forwarding for Windows, so that callbacks can be hot-patched on all supported architectures now - one-file minimal POC here
• d7ec70d Refactor TWEAKS: refactor near-instant code-tweak mechanism by putting it into its own module, le_tweaks -- see le_tweaks for usage hints
• Update Vulkan struct scaffold generator helper: now even more interactive, and useful for Vulkan Video structs, too.
• Update VOLK to version 250
• Fix querying correct device properties from device list by @ldkuba in #55
• Fix missing standard includes by @jopadan in #58

New Contributors - Thank you :)

• @ldkuba made their first contribution in #55
• @jopadan made their first contribution in #58

Full Changelog: v0.11.0-tracy...v0.12.0-vk-video-decode

v0.11.0-tracy

What's Changed

• add support for nano-second resolution profiling with Tracy

You can profile any Island app by compiling it with the line add_compile_definitions( TRACY_ENABLE ) added to its project's top-most CMakeLists.txt file. When the app runs, it will connect to the Tracy Profiler. Tracy will give you real-time insight into where the app spends CPU time.

Profiling works with Debug and Release builds - both on Linux and Windows. Profiling works with hot-reloading - you can add and remove profiling primitives while hot-reloading and profiling.

The Tracy profiler is a standalone, separate app. You can build it from source from the code contained in the tracy submodule (found in modules/le_tracy/3rdparty/tracy/profiler/build/)

You can profile application code regions by adding the le_tracy module, and including the le_tracy.h header. This header gives access to all the Tracy profiling primitives, if tracing is enabled via TRACY_ENABLE (see above).

When tracing is not enabled (as is the default), tracing primitives melt away to no-ops.

Note

Tracy is included via a submodule - you need to invoke

git submodule init
git submodule update

for the tracy source code to be checked out.

Full Changelog: v0.10.0-renderpass-ergonomics...v0.11.0-tracy

v0.10.0-renderpass ergonomics

What's Changed

Api breaking changes

• refactor encoder facade: added new specializations for Encoders: le::GraphicsEncoder, le::TransferEncoder, le::ComputeEncoder, le::RtxEncoder. You must choose one of these instead of the deprecated general le::Encoder. Based on which specialization you choose, this narrows down the choice of operations that can be done with an encoder to whatever is allowed with this particular type of encoder; this makes it harder to accidentally issue an encoder command which is not allowed in the context of a particular type of Renderpass (e.g. issueing a compute command in a Draw Pass...

Features / Fixes

• command stream storage may now dynamically adapt to number of commands issued, and grow as needed.
• Fixed an issue with non-continuous bindings in shaders - if bindings get optimised away by the shader comiler because they are not used in the shader code, this will crash the app on shader reload.
• update Asterisks example to use gamepad input - this example is now even more arcade ;)
• performance improvement: reduce number of api calls when dealing with linear allocator
• add a new Setting for whether the renderer should verify argument state on each draw: LE_SETTING_BACKEND_SHOULD_CHECK_ARGUMENT_STATE, false by default on Release builds
• simplify CommandBindVertexBuffers implementation

Full Changelog: v0.9.0-gamepad...v0.10.0-renderpass-ergonomics

v0.9.0-gamepad

What's Changed

Implement gamepad support

• add gamepad events to events stream
• app windows can automatically subscribe to gamepad events if a gamepad is connected
• default camera is steerable via gamepad if a gamepad is connected
• up to 16 gamepads can be connected - le_window_settings allow windows to opt in/out of event stream for specific gamepad ids

Gamepad control for the default camera controller is a no-code change; any apps that use the default camera controller can now additionally be controlled via gamepad, if a gamepad is detected. You just need to connect a gamepad, that's all.

Full Changelog: 0.8.0-dynamic-swapchains...v0.9.0-gamepad

v0.8.0-dynamic swapchains

What's Changed

• NEW: dynamic swapchains swapchains may now be added or removed at runtime. See updated multi_window_example, and take a look what happens when you close one window...

• remove index-based swapchain getters: you must now pass an (opaque) swapchain handle to query swapchains. You will receive a swapchain handle when adding a swapchain, and you can query the renderer for available swapchain handles.

• refactor shader pipeline generator - shader handle is now generated via parameters fingerprint, which makes for better cache hits and fewer shader recompilations.

• improved compilation times (about 3-4s for full recompile using clang) by separating renderer.hpp and renderer.h:

  renderer.hpp contains the c++ façades which are templated, and only of use to application code, while renderer.h may be used by others who depend on renderer. Application code should include renderer.hpp. remove unused header includes

• updated to vulkan version 1.3.236

• updated volk to 1.3.236

• updated vk_mem_alloc

• updated spirv_reflect

• updated codegen scripts, and generated code for vk 1.3.236

• cleanup api to better conform c-header style: deprecate const & passing in public api parameters

Full Changelog: v0.7.0...0.8.0-dynamic-swapchains

v0.7.0-console-and-settings

What's Changed

• le_console : Add support for an interactive console to Island apps via le_console. Add this module to your app and it will listen on localhost:3535 once you start its server. If you connect to the console via telnet or similar and then type tty, you enter an interactive console, from where you can interact with the app by setting or reading LE_SETTINGS, and by monitoring le_log logging events.
• LE_SETTING Add, set and get global settings anywhere in an Island app. Settings are type-aware, and are especially useful for debugging, and for setting startup options such as LE_SETTING_SHOULD_USE_VALIDATION_LAYERS.

Full Changelog: v0.6.0...v0.7.0

v0.6.0-multiqueue

What's Changed

• Refactor Rendergraph - see blog post for details.
• Automatic multi-queue, automatic resource queue ownership transfers - see blog post for details.
• Generate .dot files for multi-queue, and Rendergraph - this is dependent on LE_SETTING
• add LE_GET_SETTING - persistent settings that can be set/tweaked and accessed across all modules.
• add le_settings module - a module which allows you to list all global settings and their respective type information (unstable)
• bugfix: add logic to release and recycle callback forwarders (this was causing an issue when running out of forwarders after reloading a shader more than 255 times)
• lots of under-the-api-surface refactors in backend
• BREAKING: le_camera remove inclusion of glm from le_camera.h
• BREAKING: renderpasses must now declare resource access flag bits when using a resource (this might get simpler in the future)
• BREAKING: Update project generator script to be self-contained in python: rename to: create_project.py, relative paths are now relative to current directory
• various optimisations & bug fixes

Full Changelog: v0.5.0...v0.6.0

v0.5.0

What's Changed

• compile time improvements: reduce compile times by factor 3 by using vulkan.h in favour of vulkan.hpp
• refactor le::RenderGraph
• bump vulkan version to 1.3
• use synchronisation2 for synchronisation, clarify synchronisation in comments
• add windows continuous integration by @tgfrerer in #34
• move to github workflows for ci
• better consistency in how le:: namespace is used
• codegen for vulkan enums, interactive codegen tools for vulkan structs

Full Changelog: v0.4.0...v0.5.0

v0.3.0

Refactor resource handles to be type-safe, and not based on hashes anymore.

• Allows you to create anonymous (unnamed) resources
• Better debug data attached to resource handles
• type-safety: le_img_resource_handle, le_buf_resource_handle, le_tlas_resource_handle, le_blas_resource_handle can all be downcast to le_resource_handle, but api methods may request specific handle type for extra safety.