use compute instead of geometry shaders

...or at least support compute shaders as an alternative...
...because (a) it'll work on Metal / Mac, and (b) the performance of geometry shaders sucks
https://forum.unity.com/threads/ios-11-metal2-has-no-geometry-shader.499676/#post-3315734
https://stackoverflow.com/questions/50557224/metal-emulate-geometry-shaders-using-compute-shaders

My voxelization implementation is based on this source, which provides a good insight on the subject matter.
The thing about voxelization that it is just as simple as render object to the screen, but instead of writing color to the screen buffer, we collect the depth value and output to a volume buffer. The problem arises when the depth gradient of a particular triangle is high (ddx(depth) > 1.0 || ddy(depth) > 1.0), "crack" will form on the result voxel volume.

To solve this issue, we just need to project the triangle onto a plane where the projection area is the largest. That means we would need 3 rendering passes to project the scene into 3 different axes.

The nice thing about the geometry shader is that we can combine all the 3 rendering passes into one. Because the voxel volume is a cube and the projection axes X, Y, Z are orthogonal to each other, we only need to swizzle the X, Y, Z components of vertex position in voxel space. This can be done in geometry shader to calculate the triangle normal and select the corresponding projection axis. You can see it here: https://github.com/Looooong/Unity-SRP-VXGI/blob/5e3acd7f042a828883cf19dde947c38aa2516a2f/Runtime/Shaders/Basic.shader#L206-L257
About the problem on Metal API, without geometry shader, we just use 3 rendering passes to voxelize the scene, which might triple the processing time. I ran the GPU profiler, and the processing time of voxelization stage with geomertry shader is quite trivial with respect to other processing stages. So I don't think tripling the processing time doesn't matter much.
If I were to implement this on compute shader, I doubt that this would add more complexity to the project and re-invent the wheel.  The developers from the game Factorio (which I'm a fan of) tested geometry shader on variety of PCs last year and found that new GPU executes geometry shader better than the older generation.

It is good to know they improved the performance of geometry shaders.
AFAIK, the compute-shader method does not require three passes, and it does not change the code much. The geometry shader simply move into a compute shader. It takes the same input, it produces the same output. Instead of one draw call, you get one compute call and one draw call.
This is what is described in the third link I posted.. here:
https://stackoverflow.com/questions/50557224/metal-emulate-geometry-shaders-using-compute-shaders
This developer complains that the compute-shader version takes double the memory, because it has an input buffer and output buffer. Perhaps there is a way around this by using the same buffer for input and output from the compute shader.

Here are 2 problems:
1. Double-memory because of input and output buffers
Unity uses a list of vertex positions and a list of triangles to store Mesh data. The list of triangles contains indices that refer to the list of index positions. This data structure helps reduce memory footprint because a same vertext position can be referred by multiple triangles.
Now, we need to voxelize the the mesh data. We need to separate the triangles, and "rotate" them to face the projection plane accordingly. This means that vertex positions on the some of the triangles changed. For example, a vertex, that is used by 2 triangles, can be separated into 2 vertices with different position. Therefore, the output mesh data might be different than the input mesh data if any of the triangles is rotated. This is the reason why we need separate input buffer and output buffer to process mesh data.
2. Provide the compute shader with vertices data
Once we get the meshes that need to be voxelized, we need to pass these mesh data to the compute shader. We can do something like this, which uses ComputeBuffer.SetData. But this thing is slow as hell, because data has to be moved from CPU bound to GPU bound. Another method is to use CommandBuffer.SetComputeFloatParams, which has the same issue.
I don't know about this, but I think Unity has an internal mechanism that is used to transfer, not only mesh data, but also UVs, textures, normals and tangents data to the internal render pipeline, which is very fast. This mechanism is used by CommandBuffer.DrawMesh, CommandBuffer.DrawRenderer, ScriptableRenderContext.DrawRenderers and few more methods.
In conclusion, we need to find this fast mechanism to pass renderer data to the compute shader. Otherwise, issuing a draw call 3 times is probably faster than just moving the data back and forth.

I understand. Thanks for your response!
In the case of #2, I can't find any discussion of ComputeBuffer.SetData being incredibly slow. Perhaps there is some synchronization or other issue.
Probably better to move to the new SRP in 2019 before worrying about Mac anyhow.
It is interesting that Unity Mac OpenGL supports Geometry Shaders but not compute shaders, and Unity Mac Metal supports Compute Shaders but not Geometry Shaders.

I think that it is pretty obvious that people don't discuss about it. The thing about this is that you have to move the data from the CPU memory to the GPU memory through the computer data bus. If you have ever studied computer architecture, you would have know that CPU usually wait for I/O because fetching data from RAM is usually slower than the CPU executing instructions in 1-2 cycles. The same thing applies to GPU. GPU with the architecture, designed to be able to execute instruction fast in parallel, might actually wait for the data transfer from RAM to the GPU memory.
Is there a way to solve this issue? Yes, we just need to find a way to access mesh data that is (probably) already available on the GPU. Unity does have Mesh.GetNativeIndexBufferPtr and Mesh.GetNativeVertexBufferPtr that point to internal graphics API, but these things are native.
You can test the ComputeBuffer.SetData for yourself. I had tested it before when I was developing the voxelizer. After the scene voxelization, I tried to get voxel data with ComputeBuffer.GetData and the frame dropped at high voxel resolution. After that, I found out that I could use CommandBuffer.DrawProcedural to visuallize the voxel data, which is already available on the GPU:
https://github.com/Looooong/Unity-SRP-VXGI/blob/2f4bce1f3ad7a7dd4b59d7320c7f228fd44d5480/Runtime/Scripts/SRP/VXGIRenderer.cs#L182-L203
https://github.com/Looooong/Unity-SRP-VXGI/blob/2f4bce1f3ad7a7dd4b59d7320c7f228fd44d5480/Runtime/Shaders/VXGI.shader#L216-L309
Another time, I was developing the light injection mechanism by using CommandBuffer.SetGlobalFloatArray to inject 64/128 light indices. And the result is the same, frame rate drops. For now, we only support 16 different lights within the voxel space 😅
P/s: use the CPU/GPU profiler and frame debugger to see the processing that of these operations. Try uploading an array with the length of 1.000/10.000/100.000/1.000.000.

It is interesting that Unity Mac OpenGL supports Geometry Shaders but not compute shaders, and Unity Mac Metal supports Compute Shaders but not Geometry Shaders.

This post saids that is because Apple refused to support modern OpenGL versions 🤣

Yes, I understand Compute Architecture. I am a 45 y/o Computer Engineer Programmer. I understand GPU and CPU hardware much more than Unity and current graphics APIs.
Of course transferring data to the GPU takes time. However, it takes the same amount of time to send the data to the GPU whether it is into a ComputeBuffer or a VB/IB buffer. This is normally done ahead of time, when the mesh is created, not every frame.
I think I understand now that Unity is hard-coded to put Mesh data into VB/IB buffers. And even though all graphics APIs have mechanisms for Compute Shaders to see VB/IB buffers, Unity Compute Shaders have no such mechanism.
What we need is something like Mesh.GetNativeIndexBuffer_AsComputeBuffer() and Mesh.GetNativeVertexBuffer_AsComputeBuffer(), so the data which Unity has already downloaded to the GPU for the mesh can be sent to the compute shader. It seems the inability to do this is a limitation of Unity.
Another reason to port to Xenko!

As for ComputeBuffer.GetData, being slow, this is not a Unity issue. It is always slow if attempting to use it in the same frame, because has to wait for the compute task to finish, create a synchronization barrier to force all data to be flushed into GPU RAM, then schedule the data for DMA and wait for it to get to CPU RAM. As you found, the solution to this is use CommandBuffer.DrawProcedural to allow GPU drawing to read from the ComputeBuffer output that is already on the GPU.

So, we will put this issue on hold. Meanwhile, are you interested in reviewing my PRs when I modify the code? In the future, I want to restructure the codebase properly to make it easier for others to understand or collaborate on this project.

Yes, I would be happy to!
Do you plan to make improvements next? or update for 2019 SRP? If the latter, it may make sense to make a release/tag/branch for 2018.3 first.

Currently, here is my plan:

Make use of Constant Buffer to reduce the costs of draw call setup.
Implement shadow mapping for high priority lights for better quality.
Implement a high quality reflection algorithm, like screen space reflection, that can be blended with the voxel reflection based on material smoothness.
Port to Unity 2019.
Extend LWRP/HDRP with my code. With this, we can integrate the existing Post-processing stack. Also, ProBuilder is broken on my render pipeline, but it works for the other two :(
Implement signed distance field for voxel volume. Currently, lighting visibility is calculated by marching a ray through voxel volume, but the result doesn't look so good. With the SDF, the visibility function can be more accurate. I don't know if I can implement this anytime soon.

I think that I want to improve the quality as much as I can before putting a version tag on it.

The soft shadows they get in NVidia VXGI 2.0 / VXAL are pretty impressive.
I think frosted voxel refraction can also be quite interesting in VXGI, as in this example from Armory3d:

Ah yes, refraction, I almost forget about it. I implemented refraction before, it only works if light pass through a single layer of glass to the camera. Because the glass acts as a "lens" to "see" the voxel world, it doesn't work with multiple layer of glasses. I want to implement subsurface scattering as well. Let's add them to the list.
About the soft shadow, I think it is pretty easy, we just need to change the visibility function from ray tracing to cone tracing.

Can you go into github project settings and enable the Wiki?  This is an easy place to keep some simple installation instructions and notes.
Also, github has a nice "todo list" feature, where you use - [ ]  or - [x]markdown for bullets and it draws as checkboxes.. so you could take your above plan and either put it in a new issue with checkboxes, or put it in a wiki page with checkboxes

[ ] todo 1
[x] done

Yes, I will enable the Wiki. About the plan, I will have it setup inside Github Project page. I will add you to the list of collaborators so you can see it.

I've been reading the code, trying to understand it.... does it do Toridial addressing for the voxel buffer to reuse parts of the voxel buffer from frame-to-frame? As described here?

I have just reorganized the file structure with minimal code modifications. Hope it doesn't affect you much.
I didn't implement Toridial addressing. I have never heard of clipmap until now. This is a very interesting resource you have here. I will spend the weekend researching it.
One question: is it applicable for anisotropic voxel cascade (implemented in "The Tomorrow Children")? Because I'm planning to implement that.


fix(di): preserve original metadata on @Inject decorator

Closes #2399

:tada: This PR is included in version 7.34.4 :tada:
The release is available on:

v7.34.4
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 7.35.0-beta.5 :tada:
The release is available on:

v7.35.0-beta.5
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 7.35.0-rc.1 :tada:
The release is available on:

v7.35.0-rc.1
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 7.36.0-rc.1 :tada:
The release is available on:

v7.36.0-rc.1
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 7.36.0 :tada:
The release is available on:

v7.36.0
GitHub release

Your semantic-release bot :package::rocket:


rename w1,z1 args to external_inputs, external_outputs

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 90.73%. Comparing base (56aa3db) to head (a808394).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #107      +/-   ##
==========================================
+ Coverage   90.69%   90.73%   +0.04%
==========================================
  Files          19       19
  Lines        2761     2764       +3
==========================================
+ Hits         2504     2508       +4
+ Misses        257      256       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Set :regex true in analyzer/read-string

Without this, clojure.core.match macro expansion breaks.
If we're doing macroexpansion in the analyzer, we should make sure our read of the blocks matches the normal reader as closely as possible.
Minimal example
(ns notebook.matcher-fail
  (:require [clojure.core.match :as m]
            [nextjournal.clerk :as clerk]))

;; This form will compile fine, however, when analyzer and evaluating in clerk,
;; the macroexpandion of m/match will fail because that environment does not see
;; the method definition

(m/match ["foo" "bar"]
         ["foo" #"b.*"] "baz"
         :else "quux")

Note that it will break in the analyzer with or without the regex extension loaded.  That is not the issue, tho I did go down that garden path 8^)

We need the form reading to be deterministic because we're using it as a key for anonymous top-level expressions, see #84 for the original issue.
@craig-latacora could you please create an issue outlining the problem so we can discuss alternative solutions there?

Will do, thanks for the context.  Still learning my way around the analyzer.  I had assumed that the hash-codeblock, which is based on hashing a pr-str of the form, was being used to track changes to forms.


spacefm: warnings on startup, missing dependencies, thumbnails don't work

I installed spacefm on nixos-unstable channel. I observed a couple of problems:

Most of the program icons are missing.
Thumbnails do not work. I tried view -> preferences, click "show thumbnails" asked to edit /etc/spacefm and said it was going to ask for a root password. After that thumbnails still did not work but the checkbox shows checked.

Here is a log https://gist.github.com/ryantm/066e581d1ccc607c8c61

Adding
    hicolor_icon_theme
    gnome3.adwaita-icon-theme

as dependencies, fixes the icon warnings.

Turning on the at-spi2-core service fixes the accessibility warning.
  services.gnome3.at-spi2-core.enable = true;

This looks relevant to
** (.spacefm-wrapped:14409): WARNING **: No root settings found in /etc/spacefm/  Setting a root editor in Preferences should remove this warning on startup.   Otherwise commands run as root may present a security risk.

https://github.com/IgnorantGuru/spacefm/issues/577

Is this issue fixed by #9681 ?

@lethalman Unfortunately, no. I didn't figure out how to fix the thumbnailing.

On my system, it is not coming up with the correct mime-type for a .jpg file, so that might be why the thumbnails are not working.

I haven't tried, but I guess the solution I have purposed for #9679 should also work here.

The mime problem might be fixed by afdfe76.

And the thumbnailing issue does look same as in #9679 (not that I have a good solution for that though).

Are these issues still relevant? Also see my recent fix #36797, which should improve the mime-type situation.

I'm not sure, I stopped using spacefm. I'll close this.

Thumbnails aren’t working for me at all, for anything. I have the “show thumbnails” option checked. I’m using SpaceFM 1.0.5 in Ubuntu MATE 18.04 LTS. (note: I originally posted this at #9679, whoops)


Rename settings image

KeyboardKit specifies image assets that are automatically used by the standard appearance. Most images are static Image properties, to keep using them easy.
However, the settings image is too generally named, and often result in collisions in my own apps and previews. I will rename this to keyboardSettings, deprecate the original name and remove the original in the next major version.

This can be tested in master.


Release pipeline

Examples:
https://github.com/dotenv-linter/dotenv-linter/blob/master/.github/workflows/release.yml

MVP pipeline added in 07eb186d01968fecf9b7b7cfcab70fc747c0dbb5


melody rnn

Ubuntu
Invalid instruction (the memory stack is flushed to disk)

@wSedler you're likely using a machine that doesn't support some of the instructions the default Tensorflow package is compiled with (e.g., FMA or AVX2). You'll probably need to install Tensorflow from source and not enable some of these instructions.