glxsync - explicit frame synchronization sample implementation
could be used for tests. This is pretty much version 0.0.1. i.e. is clean enough to release. Regards, Michael Clark [1] https://fishsoup.net/misc/wm-spec-synchronization.html [2] https://lwn.net/Articles/814587/
Re: glxsync - explicit frame synchronization sample implementation
On 12/30/21 11:19 PM, Eero Tamminen wrote:
Hi,
Different window managers do resizes differently. See for example:
https://gitlab.gnome.org/GNOME/mutter/-/issues/60
On which window managers did you test this?
I did mention that. I tested with the mutter compositor inside
gnome-shell, along with whichever decorator extensions are loaded from
the toolkits present in GNOME on Ubuntu 20.04 LTS and Ubuntu 21.10.
; ( for i in $(pgrep gnome-shell); do sudo lsof -p $i ; done ) | grep
mutter | awk '{ print $9; }'
/usr/lib/x86_64-linux-gnu/mutter-6/Meta-6.typelib
/usr/lib/x86_64-linux-gnu/mutter-6/ClutterX11-6.typelib
/usr/lib/x86_64-linux-gnu/mutter-6/Cogl-6.typelib
/usr/lib/x86_64-linux-gnu/mutter-6/Clutter-6.typelib
/usr/lib/x86_64-linux-gnu/mutter-6/Cally-6.typelib
/usr/lib/x86_64-linux-gnu/mutter-6/CoglPango-6.typelib
/usr/lib/x86_64-linux-gnu/mutter-6/libmutter-cogl-path-6.so.0.0.0
/usr/lib/x86_64-linux-gnu/mutter-6/libmutter-cogl-6.so.0.0.0
/usr/lib/x86_64-linux-gnu/libmutter-6.so.0.0.0
One would hope folks implement standards in such a way that clients
using the documented window manager sync protocols are interoperable.
This is in fact the reasoning that spurred this email. Is there a
reference implementation for frame synchronization for X11 GLX apps?
I guess I am primarily satisfied if I can solve the artifacts on the
window manager that I use but if I am distributing an app more widely
then I might like something well-tested and a little more robust.
Does KDE implement _NET_WM_SYNC_REQUEST et al?
- Eero
On 30.12.2021 7.20, Michael Clark wrote:
Dear Mesa Developers,
I have been using GLFW for tiny cross-platform OpenGL demos for some
time but something that has really been bothering me are the visual
artifacts when resizing windows. Over the last year or so I have made
multiple attempts at solving this issue, digging progressively deeper
each time, until spending the last month researching compositor
synchronization protocols, reading compositor code, and writing this
demo as a prelude to figuring out how one might fix this issue in GLFW
or even Chrome.
I decided that first it might be a good idea to come up with the
simplest possible isolated example comprising of a near complete
solution without the unnecessary complexity of layering for all of the
cross-platform abstractions. It seems to me despite the ease this can
be solved with Wayland EGL, it is still useful, primarily for wider
compatibility, to be able to package X11 GLX applications, which is
the window system that I typically use when targeting Linux with GLFW.
That brings me to _glxsync_ which is an attempt at creating a
minimally correct implementation of explicit frame synchronization
using X11, GLX, XSync and the latest compositor synchronization
protocols [1,2], tested to work with mutter and GNOME on Xorg or
Xwayland.
^^ here
- https://github.com/michaeljclark/glxsync/
_glxsync_ is an X Windows OpenGL demo app using GLX and XSync extended
frame synchronization responding to synchronization requests from the
compositor in response to configuration changes for window resizes.
The demo updates extended synchronization counters before and after
frames to signal to the compositor that rendering is in progress so
that buffers read by the compositor are complete and matches the size
in configuration change events. It also has rudimentary congestion
control.
_glxsync_ depends on the following X11 window system atoms:
- _NET_WM_SYNC_REQUEST
- _NET_WM_SYNC_REQUEST_COUNTER
- _NET_WM_FRAME_DRAWN
- _NET_WM_FRAME_TIMINGS
- _NET_WM_PING
_glxsync_ *does not* yet implement the following extensions:
- _NET_WM_SYNC_FENCES
- _NET_WM_MOVERESIZE
_glxsync_ depends on the following libraries: _X11, Xext, GLX, GL_.
I have to say there were numerous subtle issues that I found while
testing this code on Ubuntu 21.10 XWayland with an Intel Mesa graphics
stack and Ubuntu 20.04 LTS Xorg with the NVIDIA proprietary graphics
stack, so I have no idea how it will fly with other drivers and am
very interested in feedback. There really is not much sample code that
I could find that addresses this issue.
I found the Intel driver particularly finicky and there are some very
carefully placed XFlush calls *before* frame renders, and XSync calls
during congestion. There are also the beginnings of adaptive frame
rate using frame times and render timings stored in a circular buffer.
That said, there is no advanced adaptive frame rate logic beyond
detecting circumstances that can lead to tears with a back-off to the
measured short term average frame rate from statistics, and some logic
to delay frames when there are collisions with Expose events.
There is also some rudimentary tracing infrastructure and some
carefully placed calls to poll, XEventsQueued(d, QueuedAlready),
XEventsQueued(d, QueuedAfterReading) to avoid blocking in XNextEvent
at all costs. I found it necessar
Re: glxsync - explicit frame synchronization sample implementation
On 30/12/21 6:20 pm, Michael Clark wrote: Dear Mesa Developers, I have been using GLFW for tiny cross-platform OpenGL demos for some time but something that has really been bothering me are the visual artifacts when resizing windows. Over the last year or so I have made multiple attempts at solving this issue, digging progressively deeper each time, until spending the last month researching compositor synchronization protocols, reading compositor code, and writing this demo as a prelude to figuring out how one might fix this issue in GLFW or even Chrome. I decided that first it might be a good idea to come up with the simplest possible isolated example comprising of a near complete solution without the unnecessary complexity of layering for all of the cross-platform abstractions. It seems to me despite the ease this can be solved with Wayland EGL, it is still useful, primarily for wider compatibility, to be able to package X11 GLX applications, which is the window system that I typically use when targeting Linux with GLFW. That brings me to _glxsync_ which is an attempt at creating a minimally correct implementation of explicit frame synchronization using X11, GLX, XSync and the latest compositor synchronization protocols [1,2], tested to work with mutter and GNOME on Xorg or Xwayland. - https://github.com/michaeljclark/glxsync/ _glxsync_ is an X Windows OpenGL demo app using GLX and XSync extended frame synchronization responding to synchronization requests from the compositor in response to configuration changes for window resizes. The demo updates extended synchronization counters before and after frames to signal to the compositor that rendering is in progress so that buffers read by the compositor are complete and matches the size in configuration change events. It also has rudimentary congestion control. _glxsync_ depends on the following X11 window system atoms: - _NET_WM_SYNC_REQUEST - _NET_WM_SYNC_REQUEST_COUNTER - _NET_WM_FRAME_DRAWN - _NET_WM_FRAME_TIMINGS - _NET_WM_PING _glxsync_ *does not* yet implement the following extensions: - _NET_WM_SYNC_FENCES - _NET_WM_MOVERESIZE _glxsync_ depends on the following libraries: _X11, Xext, GLX, GL_. I have to say there were numerous subtle issues that I found while testing this code on Ubuntu 21.10 XWayland with an Intel Mesa graphics stack and Ubuntu 20.04 LTS Xorg with the NVIDIA proprietary graphics stack, so I have no idea how it will fly with other drivers and am very interested in feedback. There really is not much sample code that I could find that addresses this issue. I found the Intel driver particularly finicky and there are some very carefully placed XFlush calls *before* frame renders, and XSync calls during congestion. There are also the beginnings of adaptive frame rate using frame times and render timings stored in a circular buffer. That said, there is no advanced adaptive frame rate logic beyond detecting circumstances that can lead to tears with a back-off to the measured short term average frame rate from statistics, and some logic to delay frames when there are collisions with Expose events. I would like to add these implementation notes to the README because this is information one cannot easily find. It occurs to me that XFlush before frames makes a lot more sense than after frames if one thinks about Nagle and flow control combined with frame pacing. If we have capacity to render at a constant frame rate with accurate scheduling for the start of frames, then an XFlush(dpy) marker placed at the start of the frame will occur at a constant rate, subject to variable render times, whereas an XFlush(dpy) marker placed at the end of the frame would have irregular timings needing stats for recovery. I am guessing these are conversations that folks have already had because it seems to work on my machine. An XSync(dpy, False) marker for congestion control also seems to make sense to me because if we get frame drops we want to resynchronize input and output. I am not sure under which conditions one may wish to do XSync(dpy, True). Possibly some sort of watchdog or hang check for IO when recovering from flooding. Anyway I don't know where to go for this information so I am verbalizing it to see if anyone can acknowledge it as being reasonable protocol. There is also some rudimentary tracing infrastructure and some carefully placed calls to poll, XEventsQueued(d, QueuedAlready), XEventsQueued(d, QueuedAfterReading) to avoid blocking in XNextEvent at all costs. I found it necessary to add a heuristic to avoid frame submission until receiving frame timings from the compositor. Intuitively one might think this makes the loop synchronous, but with the NVIDIA driver, it appears the heuristic still allows multiple frames to be submitted in advance. It is certainly finicky to debug. There is a --no-sync option to simulate the absence of compositor synchronization
Re: glxsync - explicit frame synchronization sample implementation
On 31/12/21 1:31 pm, Michael Clark wrote: I would like to add these implementation notes to the README because this is information one cannot easily find. It occurs to me that XFlush before frames makes a lot more sense than after frames if one thinks about Nagle and flow control combined with frame pacing. If we have capacity to render at a constant frame rate with accurate scheduling for the start of frames, then an XFlush(dpy) marker placed at the start of the frame will occur at a constant rate, subject to variable render times, whereas an XFlush(dpy) marker placed at the end of the frame would have irregular timings needing stats for recovery. I am guessing these are conversations that folks have already had because it seems to work on my machine. An XSync(dpy, False) marker for congestion control also seems to make sense to me because if we get frame drops we want to resynchronize input and output. I am not sure under which conditions one may wish to do XSync(dpy, True). Possibly some sort of watchdog or hang check for IO when recovering from flooding. Anyway I don't know where to go for this information so I am verbalizing it to see if anyone can acknowledge it as being reasonable protocol. I wrote up the sample implementation notes here: - https://github.com/michaeljclark/glxsync/blob/trunk/README.md I made one minor change after reasoning about when the frame buffer is volatile. It seemed safe to move the start of the lock from just before draw_frame to just before swap_buffers. The notes on buffer safety and waiting until present timing has been received before starting a new frame are from observations with the Mesa Intel driver in Ubuntu 21.04. My account of events for a synchronized window update look like this: - _ClientMessage_ - _synchronize_ (`_e.xclient.data.l[0] == _NET_WM_SYNC_REQUEST`) - store synchronizatized rendering serial number: - `sync_serial = _e.xclient.data.l[2]` - _ConfigureNotify_ - _resize_ - signal synchronizatized rendering initiated: - `sync_counter(dpy, extended_counter, sync_serial + 0)` - _Expose_ - _XFlush_ - make sure last frame has been flushed. - _draw_frame_ - run user code to draw the frame. - _begin_frame_ - signal buffer contents for serial number are rendering (urgent): - `sync_counter(dpy, extended_counter, sync_serial + 3)` - _swap_buffers_ - the frame buffer contents are volatile at this point. - _end_frame_ - signal buffer contents for serial number are now complete: - `sync_counter(dpy, extended_counter, sync_serial + 4)` - _ClientMessage_ - _frame_drawn_ (`e.xclient.message_type == _NET_WM_FRAME_DRAWN`) - drawing at this point is *not safe* because present has not been scheduled (buffer has not been copied). - _ClientMessage_ - _frame_timings_ (`e.xclient.message_type == _NET_WM_FRAME_TIMINGS`) - drawing at this point is *safe* frame because present has been scheduled (buffer has been copied).
[Mesa-dev] gears ports: Vulkan vk1_gears and OS Mesa kitty_gears
Hi Folks, I have been working on several gears ports that I thought I'd share: - https://github.com/michaeljclark/glkitty/ ## Background I have found the Mesa gears demo to be a very useful test case for porting to new OpenGL API variants. In fact I did a search and found "gearsvbo", a port that I worked on over a decade ago while familiarizing with OpenGL ES1 that I had completely forgotten about: - https://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg07140.html I present glkitty, a header framework for creating OS Mesa apps using kitty terminal graphics protocol, of which the first app is kitty_gears. I also colocated several other gears ports including Vulkan vk1_gears. The Vulkan samples version of gears had a large number of dependencies on a C++ framework so I decided to do a simpler pure C port. The web page has a full description. Here is a brief outline: - kitty_gears - OS Mesa gears using kitty terminal graphics protocol - gl1_gears - OpenGL 1.x gears using GLFW similar to the original - gl2_gears - OpenGL 2.x gears using VAO/VBO, programmable shaders - vk1_gears - Vulkan 1.x gears using spirvtools and SPIR-V shaders # gl2_gears gl2_gears is similar to es2gears in mesa-demos, however it uses defacto standard linmath.h plus gl2_util.h which contains common shader loader and vertex buffer functions. gl2_util.h is used for several small tests. # kitty_gears kitty_gears uses OS Mesa and gl2_util.h. It could be useful to render test images from test runs, something that console history will be well suited to. It still needs a little work with lifecycle management of kitty images, as the terminal state now includes these image surfaces. It supports ZLib compression and animation... # vk1_gears vk1_gears is a Vulkan port that might be useful for testing Vulkan window resize, reshape, pipe reconfiguration and semaphores. I have used it with the NVIDIA Vulkan and the Mesa Vulkan drivers with varying levels of success. Anyhow, that's about it. Let me know if you find this useful. I was actually specifically interested in using kitty for inspecting test case output where I can run a batch of tests and can scroll through results. Regards, Michael. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gl4_gears - SPIR-V and shader module reflection
Hi again, On 11/24/20 9:43 PM, Michael Clark wrote: - kitty_gears - OS Mesa gears using kitty terminal graphics protocol - gl1_gears - OpenGL 1.x gears using GLFW similar to the original - gl2_gears - OpenGL 2.x gears using VAO/VBO, programmable shaders - vk1_gears - Vulkan 1.x gears using spirvtools and SPIR-V shaders I decided to use this app to experiment with some of the new OpenGL features in particular the ability to share shader modules between OpenGL and Vulkan. Be nice because we will have portable binaries... subsequently added: - gl3_gears - moved vertex array objects here and downgraded gl2_gears - gl4_gears - added uniform buffer objects and SPIR-V shader modules OpenGL 4.x SPIR-V attribute reflection branch is here: - https://github.com/michaeljclark/glkitty/tree/opengl4-experiment gl4_gears is decidedly experimental and there issues with attribute reflection that need to be resolved. NVIDIA OpenGL 450 implementation has bugs with reassignment of attribute locations when using the #version 450 shader dialect with explicit location, used by the SPIR-V shader modules, so a different set of locations is used in comparison to vk1_gears. likewise Mesa has a somewhat alternate behavior and also appears buggy. It's really a bit messy, especially given I still want to perform reflection but now the shaders have mandatory location attrs. that seems to me like a backwards step for hot reloading of experiments. See the #define in: shaders/gears.vert#L3-L5 - GENERIC_VULKAN - set by default to enable vk1_gears - NVIDIA_OPENGL - set to run gl4_gears with nvidia-450 - MESA_OPENGL - set to run gl4_gears with Mesa 20.0.8 similarly there is a USE_SPIRV define near the top of gl4_gears.c which currently has only been tested to work with NVIDIA OpenGL 450 need to spend some time reading ARB_gl_spirv.txt. it seems reflection is becoming optional instead of intrinsic, which is a step backwards for OpenGL, although I can see why OpenGL ES, of potentially large games, may want to statically link offsets, but previously I could rely on dynamic evaluation of shader module attribute names. It makes life easy for the developer/user of these APIs. noticing I might be able to compile separate SPIR-V modules: #ifdef GL_SPIRV which is also not ideal because now I don't have portable binaryies given its silly (now manual) linkage. it seems reflection is optional for SPIR-V, and the attribute reflection is not yet? working in Mesa? also it seems if I find the attribute I can't relink it. there is a whole set of new APIs to explore. just an fyi on a gl4_gears that could be an interesting test cast for mesa-demos as this port of gears is still pure C. I am actually working in C++, but tend to like to isolate dependencies when working on small tests for context initialization and what not... anyway keep up the good work!!! i'm surprised how close Mesa is to supporting all of the latest APIs. the next step was exploring bindless... Regards, Michael. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gl4_gears - SPIR-V and shader module reflection
On 11/30/20 3:38 PM, Michael Clark wrote: Hi again, On 11/24/20 9:43 PM, Michael Clark wrote: - kitty_gears - OS Mesa gears using kitty terminal graphics protocol - gl1_gears - OpenGL 1.x gears using GLFW similar to the original - gl2_gears - OpenGL 2.x gears using VAO/VBO, programmable shaders - vk1_gears - Vulkan 1.x gears using spirvtools and SPIR-V shaders I decided to use this app to experiment with some of the new OpenGL features in particular the ability to share shader modules between OpenGL and Vulkan. Be nice because we will have portable binaries... subsequently added: - gl3_gears - moved vertex array objects here and downgraded gl2_gears - gl4_gears - added uniform buffer objects and SPIR-V shader modules OpenGL 4.x SPIR-V attribute reflection branch is here: - https://github.com/michaeljclark/glkitty/tree/opengl4-experiment gl4_gears is decidedly experimental and there issues with attribute reflection that need to be resolved. NVIDIA OpenGL 450 implementation has bugs with reassignment of attribute locations when using the #version 450 shader dialect with explicit location, used by the SPIR-V shader modules, so a different set of locations is used in comparison to vk1_gears. likewise Mesa has a somewhat alternate behavior and also appears buggy. It's really a bit messy, especially given I still want to perform reflection but now the shaders have mandatory location attrs. that seems to me like a backwards step for hot reloading of experiments. See the #define in: shaders/gears.vert#L3-L5 - GENERIC_VULKAN - set by default to enable vk1_gears - NVIDIA_OPENGL - set to run gl4_gears with nvidia-450 - MESA_OPENGL - set to run gl4_gears with Mesa 20.0.8 similarly there is a USE_SPIRV define near the top of gl4_gears.c which currently has only been tested to work with NVIDIA OpenGL 450 need to spend some time reading ARB_gl_spirv.txt. it seems reflection is becoming optional instead of intrinsic, which is a step backwards for OpenGL, although I can see why OpenGL ES, of potentially large games, may want to statically link offsets, but previously I could rely on dynamic evaluation of shader module attribute names. It makes life easy for the developer/user of these APIs. noticing I might be able to compile separate SPIR-V modules: #ifdef GL_SPIRV which is also not ideal because now I don't have portable binaryies given its silly (now manual) linkage. it seems reflection is optional for SPIR-V, and the attribute reflection is not yet? working in Mesa? also it seems if I find the attribute I can't relink it. there is a whole set of new APIs to explore. just an fyi on a gl4_gears that could be an interesting test cast for mesa-demos as this port of gears is still pure C. I am actually working in C++, but tend to like to isolate dependencies when working on small tests for context initialization and what not... anyway keep up the good work!!! i'm surprised how close Mesa is to supporting all of the latest APIs. the next step was exploring bindless... I managed to get a solution that works with NVIDIA Vulkan and OpenGL drivers as well as the Mesa Drivers in Ubuntu. I did this by disabling reflection and just scanning the re-assigned in a reverse lookup from the name, which is ironic. It seems that reassigning the indices does not work on some drivers. I was doing that because of NVIDIA driver's dislike for 0. It begs the question of where OpenGL, OpenGL ES and GLSL are headed. I am quite interested in the position of Intel and freedesktop on the SPIR-V draft: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt location seems like redundant boiler plate to me. It seems natural to see the declarations like a struct and use declaration order if location is not present. This would not affect Vulkan in any substantive way, as it would be an "re-addition" versus a "subtraction" of reflection to the OpenGL suite of APIs. I am a proponent of concise and hot-reload. Supposedly necessary but unnecessary complexity. Like an artist protecting his encrypted SPIR-V assets so they can make a crust on the web, instead of asm.js and text-only for certain assets. And of course (location = ?) does not make sense there. I understand the need. It just seems there are some mutually exclusive forces at play. Why can't I have a binary module and export the names of functions and struct members, Vulkan would need some utility interfaces outside of the driver to find the strings in the SPIR-V, but it seems straight forward given the constraint has been "added", with both OpenGL and OpenCL traditionally being relatively low-level interfaces with introspection and reflection. Just so you are aware of one independent developer's position. I would like to reflect on function arity and make JIT dispatch proxies so that C can transparently call GLSL code with fixed sized a
Re: [Mesa-dev] gl4_gears - SPIR-V and shader module reflection
On 12/1/20 11:27 AM, Michael Clark wrote: On 11/30/20 3:38 PM, Michael Clark wrote: Hi again, On 11/24/20 9:43 PM, Michael Clark wrote: - kitty_gears - OS Mesa gears using kitty terminal graphics protocol - gl1_gears - OpenGL 1.x gears using GLFW similar to the original - gl2_gears - OpenGL 2.x gears using VAO/VBO, programmable shaders - vk1_gears - Vulkan 1.x gears using spirvtools and SPIR-V shaders I decided to use this app to experiment with some of the new OpenGL features in particular the ability to share shader modules between OpenGL and Vulkan. Be nice because we will have portable binaries... subsequently added: - gl3_gears - moved vertex array objects here and downgraded gl2_gears - gl4_gears - added uniform buffer objects and SPIR-V shader modules OpenGL 4.x SPIR-V attribute reflection branch is here: - https://github.com/michaeljclark/glkitty/tree/opengl4-experiment gl4_gears is decidedly experimental and there issues with attribute reflection that need to be resolved. NVIDIA OpenGL 450 implementation has bugs with reassignment of attribute locations when using the #version 450 shader dialect with explicit location, used by the SPIR-V shader modules, so a different set of locations is used in comparison to vk1_gears. likewise Mesa has a somewhat alternate behavior and also appears buggy. It's really a bit messy, especially given I still want to perform reflection but now the shaders have mandatory location attrs. that seems to me like a backwards step for hot reloading of experiments. See the #define in: shaders/gears.vert#L3-L5 - GENERIC_VULKAN - set by default to enable vk1_gears - NVIDIA_OPENGL - set to run gl4_gears with nvidia-450 - MESA_OPENGL - set to run gl4_gears with Mesa 20.0.8 similarly there is a USE_SPIRV define near the top of gl4_gears.c which currently has only been tested to work with NVIDIA OpenGL 450 need to spend some time reading ARB_gl_spirv.txt. it seems reflection is becoming optional instead of intrinsic, which is a step backwards for OpenGL, although I can see why OpenGL ES, of potentially large games, may want to statically link offsets, but previously I could rely on dynamic evaluation of shader module attribute names. It makes life easy for the developer/user of these APIs. noticing I might be able to compile separate SPIR-V modules: #ifdef GL_SPIRV which is also not ideal because now I don't have portable binaryies given its silly (now manual) linkage. it seems reflection is optional for SPIR-V, and the attribute reflection is not yet? working in Mesa? also it seems if I find the attribute I can't relink it. there is a whole set of new APIs to explore. just an fyi on a gl4_gears that could be an interesting test cast for mesa-demos as this port of gears is still pure C. I am actually working in C++, but tend to like to isolate dependencies when working on small tests for context initialization and what not... anyway keep up the good work!!! i'm surprised how close Mesa is to supporting all of the latest APIs. the next step was exploring bindless... I managed to get a solution that works with NVIDIA Vulkan and OpenGL drivers as well as the Mesa Drivers in Ubuntu. I did this by disabling reflection and just scanning the re-assigned in a reverse lookup from the name, which is ironic. It seems that reassigning the indices does not work on some drivers. I was doing that because of NVIDIA driver's dislike for 0. It begs the question of where OpenGL, OpenGL ES and GLSL are headed. I am quite interested in the position of Intel and freedesktop on the SPIR-V draft: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt location seems like redundant boiler plate to me. It seems natural to see the declarations like a struct and use declaration order if location is not present. This would not affect Vulkan in any substantive way, as it would be an "re-addition" versus a "subtraction" of reflection to the OpenGL suite of APIs. I am a proponent of concise and hot-reload. a readdition. I had written addition, and realized it is not an addition, so added re- but missed the context. i was a little rushed. Supposedly necessary but unnecessary complexity. Like an artist protecting his encrypted SPIR-V assets so they can make a crust on the web, instead of asm.js and text-only for certain assets. And of course (location = ?) does not make sense there. I understand the need. It just seems there are some mutually exclusive forces at play. Why can't I have a binary module and export the names of functions and struct members, Vulkan would need some utility interfaces outside of the driver to find the strings in the SPIR-V, but it seems straight forward given the constraint has been "added", with both OpenGL and OpenCL traditionally being relatively low-level interfaces with introspection and reflection. Just so you are awa
