<azonenberg>
if you've put in the work to not need it, why not go all the way
<d1b2>
<david.rysk> doesn't seem like the functionality is replaced yet
<d1b2>
<david.rysk> e.g. LogFatal("DeEmbedFilter CPU fallback not available on Apple Silicon");
<azonenberg>
So that's the fallback path we never use
<azonenberg>
outside of unit tests
<azonenberg>
so it sounds like the only missing thing is integrating a non-GPL FFT lib in the test cases (accepting that this means the unit test binaries become GPL - this is OK IMO as we won't redistribute them)
<d1b2>
<david.rysk> (or cpu-based vkfft)
<azonenberg>
well so i specifically wanted another fft lib to cross check vkfft against so that any problems with how we set up vkfft get noticed
<azonenberg>
or any patches we might make to vkfft in the future
<azonenberg>
vkfft in e.g. swiftshader won't fulfill that
<azonenberg>
anyway it sounds like ffts is not 100% removed yet. but this continues to be a goal
<azonenberg>
but yes the gpu filter disable flag is bascially only used in unit tests, i dont even know if ngscopeclient supports setting it via a debug argument
<azonenberg>
the idea being vulkan is now so core to application functionality there's no reason to even consider the scenario where it's not available
<azonenberg>
and sorry i meant, integrating a GPL FFT lib in the test cases
<azonenberg>
i.e. fftw
<azonenberg>
we just need to be careful about cross contamination and make sure we never use it outside of test cases
<azonenberg>
having the code to detect/link to it only be in the tests directory should be sufficient
<d1b2>
<david.rysk> is PocketFFT usable?
<azonenberg>
No idea, this is the first iv'e heard of it
massi has quit [Remote host closed the connection]
<azonenberg>
lain: reviewing the PR: compute queues do indeed need transfer capability because you very often bind an AcceleratorBuffer to a compute shader which doesn't contain an up to date GPU copy of the waveform
<azonenberg>
you don't want to have to stop and sync between multiple queues for that
<azonenberg>
that said, IME transfer is enabled in ~every queue type for exactly that reason
<azonenberg>
so asking for it isnt a big deal
<azonenberg>
compute and graphics capabilities are the less common ones
<azonenberg>
lain: also, if i understand this right, QueueHandle's are tied to a specific queue family even on Metal?
<d1b2>
<david.rysk> could you add that homebrew path to glslang_c_interface.h?
<d1b2>
<david.rysk> homebrew does /opt/homebrew/include/glslang/Include ; macports probably does /opt/local/...
<azonenberg>
Send a PR
<d1b2>
<david.rysk> I haven't tested without homewbrew installed
<azonenberg>
Then coordinate with lain and ehntoo and any other mac folks here
<azonenberg>
lain: anyway i just merged a bunch of your changes and fixed some things that broke on x86
<azonenberg>
as well as broken unit tests
<azonenberg>
lain: also suggestion: right now it seems your queue allocation is greedy
<azonenberg>
you find the first queue meeting the requested type and hand it out
<azonenberg>
we could probably get better results if you were a bit more choosy
<d1b2>
<david.rysk> lain, ehntoo: can you add those two lines to lib/schopehal/CMakeLists.txt and see if it works?
<azonenberg>
in particular if you ask for a transfer-only queue and there's a transfer-only family, use it
<azonenberg>
and if you ask for a compute-but-not-render queue and there's a matching family, use that
<azonenberg>
As it stands, on nvidia, we risk allocating all of the general purpose "use for everything" queues first
<azonenberg>
and using them for things that don't actually need that functionality
<azonenberg>
then when it comes time to allocate, say, a render queue there might be none left
<d1b2>
<david.rysk> otherwise I'll prepare a PR later
<d1b2>
<ehntoo> catching up on scrollback. azonenberg, I think I can answer your question of "also, if i understand this right, QueueHandle's are tied to a specific queue family even on Metal?" - yes. Vulkan ties a command buffer to a queue family, but in Metal a command buffer is tied to a particular queue rather than the family. MoltenVK papers over that by only having a single queue in any particular family, so we'll need to tie a handle to a particular
<d1b2>
family.
<d1b2>
<ehntoo> @david.rysk re: additional includes paths for glslang_c_interface.h, I see no reason it should break anything. I'd really like to get rid of those explicit paths entirely, but haven't sat down to figure out the right CMake incantations. That said, If another explicit path fixes something for you now and doesn't break macOS CI, I personally have no objections to adding it. I won't be able to sit down and do a trial myself for a bit.
<d1b2>
<david.rysk> Yeah fixing the cmake script would be best long term. I’ll look into it