<bailsman>
I think I found a race condition and I want to make sure I'm not imagining it.
<bailsman>
In src/vulkan/wsi/wsi_common_x11.c:wsi_CreateSwapchainKHR we call iface->create_swapchain which I believe goes to src/vulkan/wsi/wsi_common_x11.c:x11_surface_create_swapchain on my system
<bailsman>
directly after that function returns we assign swapchain->fences = vk_zalloc(...)
<bailsman>
however, *before* that function returns, it does a pthread_create on x11_manage_fifo_queues and that function uses that chain->fences value
<bailsman>
I think on my system this is crashing because I'm getting unlucky. What's the right way to fix this? Add a null check before using the fences pointer?
DMJC has joined #dri-devel
Jeremy_Rand_Talos has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
a-865 has quit [Quit: ChatZilla 0.17b1 [SeaMonkey 2.53.17/20230610105000]]
illwieckz has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
JohnnyonF has joined #dri-devel
Johnny has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
dsrt^ has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
DMJC has quit [Read error: Connection reset by peer]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
a-865 has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
pcercuei has joined #dri-devel
rasterman has joined #dri-devel
jagan_ has joined #dri-devel
Haaninjo has joined #dri-devel
kunzite has joined #dri-devel
kunzite has quit []
i509vcb has quit [Quit: Connection closed for inactivity]
<MrCooper>
Company: pretty rare IME
itsmeluigi has joined #dri-devel
ultra has quit [Quit: ultra]
penguin42 has joined #dri-devel
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
ultra has joined #dri-devel
<dottedmag>
Does drm_connector.possible_encoders mean "all possible encoders for this connector"? I had a look at drmdb, and in most submissions I see a bunch of encoders never mentioned in possible_encoders
<zamundaaa[m]>
dottedmag: have a look at the encoder type. The ones that aren't mentioned are for DP MST, so the connectors that would use them only appear if you use DP MST
<dottedmag>
zamundaaa[m]: I see, that's the only case in drmdb. Do these encoders ever end up in possible_encoders, and what triggers them?
<zamundaaa[m]>
They should be in the encoders array when the connector is DP MST, so if it's from a usb c dock for example
<emersion>
new connectors appear when DP-MST is used
<dottedmag>
Aha, so typically it may happen on hotplug? And encoder represents is a chunk of silicone on display controller, so it's static for the whole lifetime of the card?
<zamundaaa[m]>
Yes
<zamundaaa[m]>
But why are you asking these questions? As a user of the drm API you should ignore encoders, except for determining the crtcs you can use for a connector
<dottedmag>
Curiosity. I like understanding how things actually work.
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
ultra has quit [Remote host closed the connection]
ultra has joined #dri-devel
ultra has quit []
ultra has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
tango_ has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
ultra has quit [Remote host closed the connection]
ultra has joined #dri-devel
ultra has quit []
digetx has joined #dri-devel
junaid has joined #dri-devel
greenjustin has quit [Remote host closed the connection]
greenjustin has joined #dri-devel
ultra has joined #dri-devel
junaid has quit [Remote host closed the connection]
CME_ has joined #dri-devel
CME has quit [Ping timeout: 480 seconds]
<neobrain>
Is it desirable that lavapipe force-enables threaded queue submits even when LP_NUM_THREADS=0? I'm using that envvar to get a specific backtrace from a crash in my Vulkan app, but due to the submit thread it won't point me to the specific line in my Vulkan code that's crashing (i.e. it only shows the lavapipe-internal stack frames)
<neobrain>
(I did manage to disable threaded queue submits locally, just curious if this should be the default behavior for num_threads==0)
Haaninjo has quit [Quit: Ex-Chat]
<zmike>
yes that's the default behavior intentionally
<zmike>
it's otherwise impossible to simultaneously submit work and wait on semaphores/fences
<zmike>
if you need a breakpoint set it on the enqueue functions
<neobrain>
Breakpoints are useful in other cases, but not if you're trying to find out which line of code triggered a crash in the first place :)
<neobrain>
I saw some references to some "on demand" mode for threaded submit, but I'm guessing that doesn't do what I think. Could you determine that submit work can safely be async without risking deadlocks based on feature flags, or is what you're describing a problem even for Vulkan-1.0-style semaphores/fences?
<neobrain>
err, can safely be done synchronously*
<zmike>
I'm not sure what issue you're trying to debug that you can't get a crash?
<zmike>
if it's memory access use ASAN or valgrind, otherwise gdb will catch asserts normally in threads
<zmike>
if you're having trouble understanding the command flow, you can use LVP_CMD_DEBUG=1
<neobrain>
zmike: If the crash happens in lavapipe/llvmpipe, I'll get a backtrace of the queue submit thread even if LP_NUM_THREADS==0. I won't be able to (easily) learn which submit in *my application code* triggered the crash
<zmike>
LVP_CMD_DEBUG will probably be enough for that
<zmike>
or at least it has been for me
<zmike>
also LP_XYZ env vars are for llvmpipe
<zmike>
they don't affect frontends
<neobrain>
is that still the current name of the variable? Can't find any references to it in the mesa source
<zmike>
maybe update your mesa source if it's too old
<zmike>
but it's been in there for a long time now
<neobrain>
Ah thanks! Don't tell anyone but my checkout is from January 🙈
<zmike>
😬
<neobrain>
And I get what I deserve for that, because the latest version fixes the crash... (not that this makes my Vulkan code correct, but now I can finally debug it in renderdoc!)
<HdkR>
\o/
<HdkR>
zmike: One does not simply enable ASAN and expect it to work in this world :P
Johnny has quit [Ping timeout: 480 seconds]
<zmike>
it works in my world
<zmike>
get on my level
carbonfiber has joined #dri-devel
<HdkR>
I want to be where the ASAN is
junaid has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
JohnnyonFlame has joined #dri-devel
kzd has joined #dri-devel
junaid has quit [Remote host closed the connection]
junaid has joined #dri-devel
junaid has quit []
junaid has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Danct12 has quit [Quit: A-lined: User has been AVIVA lined]
junaid has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
sima has joined #dri-devel
Haaninjo has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
nehsou^ has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
phire has quit [Read error: Connection reset by peer]
phire has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<anarsoul|2>
our of curiosity, why there is no nir_op_atan or nir_op_atan2? Are these not commonly implemented in hw?
<alyssa>
correct
<alyssa>
and in so much as they they aren't perf criticla
<HdkR>
Alternatively, if it was perf critical, the developer already screamed in to the void and found approximation that was faster :P