<_whitenotifier>
[scopehal] hansemro 4675c02 - Correct ascending sort of Vulkan queues by feature flag count This corrects Vulkan queue sort order from descending to ascending order of feature flag count. This is the intended sort behavior as stated in the sort comment. This addresses the side effect from descending order sort, where QueueManager assigns a more featureful queue even though a more appropriate queue with
<_whitenotifier>
capable queues support more features.
<_whitenotifier>
fewer features is available. This side effect manifests on AMD integrated GPUs by assigning the only graphics-capable queue to g_vkTransferQueue (which only require Transfer capability) and rendering tasks. For reference, we want to prioritize queues with the fewest features and reserve more general-purpose queues (with graphics capabilities) for graphics/rendering tasks. This works on the assumption that graphics-
<_whitenotifier>
[scopehal] azonenberg 1cffcec - Merge pull request #794 from hansemro/vk-queue-ascending-sort-fix Correct ascending sort of Vulkan queues by feature flag count
Degi has quit [Ping timeout: 245 seconds]
Degi has joined #scopehal
<azonenberg>
ok so, sanity checking here
<azonenberg>
suppose i want to find the BER at a specific point in an eye pattern
<azonenberg>
draw a line from the point of interest to the nominal center of the eye
<azonenberg>
then integrate along that line and find the total number of samples along the path?
<azonenberg>
and normalize by total number of UIs and samples per UI?
<azonenberg>
hansemro: ok i'm getting vulkan validation errors related to the new queue code
<d1b2>
<azonenberg> It's not a bug in your code per se
<d1b2>
<azonenberg> seems to be an issue elsewhere where i assumed i had things i didn't ask for in the queue
<d1b2>
<azonenberg> VUID-vkCmdPipelineBarrier-dstStageMask-06462(ERROR / SPEC): msgNum: 2102788165 - Validation Error: [ VUID-vkCmdPipelineBarrier-dstStageMask-06462 ] Object 0: handle = 0x555564a438f0, name = g_vkTransferCommandBuffer, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x7d560045 | vkCmdPipelineBarrier(): .dstStageMask flag VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT is not compatible with the queue family properties
<d1b2>
(VK_QUEUE_TRANSFER_BIT|VK_QUEUE_SPARSE_BINDING_BIT) of this command buffer. The Vulkan spec states: Any pipeline stage included in dstStageMask must be supported by the capabilities of the queue family specified by the queueFamilyIndex member of the VkCommandPoolCreateInfo structure that was used to create the VkCommandPool that commandBuffer was allocated from, as specified in the table of supported pipeline stages
<d1b2>
<azonenberg> So basically if we are going to do barriers on compute in the transfer queue, the transfer queue has to be capable of doing compute operations
<d1b2>
<azonenberg> even if it won't ever dispatch them
<d1b2>
<hansemro> I will take a look
<d1b2>
<azonenberg> I'm about to test a fix, i think it's as simple as making the transfer queue ask for compute capability for now
<d1b2>
<azonenberg> later we can try and refactor to not need that
<d1b2>
<hansemro> Yes, I am seeing the same validation errors about missing compute capability
<azonenberg>
I think i have a fix, will push shortly
<azonenberg>
I run under validation almost constantly during dev, it makes things sooo much easier to debug
<azonenberg>
it caught bugs in seconds that had been in the OpenGL + OpenCL version of the codebase for years unnoticed just randomly causing garbage results, crashes, etc
<azonenberg>
But i'm working on some other stuff in my local copy so i just have to clean up a bit and make some atomic commits
<d1b2>
<hansemro> Yeah, that sounds like a good idea
<d1b2>
<hansemro> pipeline barrier with compute shader flag bit
<azonenberg>
Correct
<azonenberg>
Which is necessary if we're intending to then use the buffer in a compute shader
<azonenberg>
So basically it seems we cannot use a transfer-only queue if we're going to use the buffer in a compute shader unless we do some complex external fencing or similar
<azonenberg>
for now i'm just making it request compute access for the transfer queue
<azonenberg>
its a one line change i just havent pushed it
<_whitenotifier>
[scopehal] azonenberg 42f315b - Transfer queue now requests compute capability so it can be used to synchronize with compute operations
<_whitenotifier>
[scopehal] azonenberg 854611e - EyeWaveform: added GetBERAtPoint() to more accurately compute BER at a specific location within the eye
<_whitenotifier>
[scopehal-apps] azonenberg ae742dd - WaveformArea: fixed bug where BER tooltip had inverted Y axis
<_whitenotifier>
[scopehal-apps] azonenberg fd0c621 - FilterGraphEditor: initial work on fancy icons for graph editor including concept art from @j@j-w.au. So far only Threshold is supported.
<d1b2>
<azonenberg> BER readout on eye patterns (and fixed bathtub curves) in tooltip