<karolherbst>
the extension stuff isn't fixed, but the half fix landed in llvm :)
mszyprow has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost_ has quit []
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
anholt_ has quit [Quit: Leaving]
hch12907 has quit [Ping timeout: 480 seconds]
lstrano_ has left #dri-devel [#dri-devel]
lstrano has joined #dri-devel
rasterman has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mvlad has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
<feaneron>
how can i debug a crash in glDrawArrays()? it seems to be crashing deep in iris_dri.so, especifically util_fill_rect()
linkmauve has left #dri-devel [Error from remote client]
<feaneron>
it was suggested that this could be a misaligned buffer, but as far as i can see, this is not the case
<feaneron>
this is 100% reproducible in my little app, and happens with LP_NUM_THREADS=0, so it must be a problem in my application code
Company has quit [Read error: No route to host]
Company has joined #dri-devel
mclasen has joined #dri-devel
ondracka has quit [Quit: Ping timeout (120 seconds)]
<shadeslayer>
Georges Stavracas (feaneron): maybe install some debug symbols for mesa and get a full backtrace?
garrison has quit []
i-garrison has joined #dri-devel
<feaneron>
i'm doing that right now, but i wonder which particular debugging tools would be appropriate to use here (beyond, of course, gdb)
<feaneron>
ah wait, there's EGL_CONTEXT_OPENGL_DEBUG, let's see
sdutt_ has quit [Ping timeout: 480 seconds]
mclasen has quit []
linkmauve has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<shadeslayer>
Georges Stavracas (feaneron): gdb should be plenty enough for a start
tzimmermann has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
nchery has joined #dri-devel
<zmike>
is there really no nir pass that can rewrite 64bit input/output variables to 32bit?
mszyprow has joined #dri-devel
<cwabbott>
zmike: nir_lower_io does it usually
<zmike>
ughhhhhhhhh
<zmike>
that still doesn't seem to handle rewriting the variable types though
<jenatali>
zmike: I wrote my own pass for that one
<feaneron>
shadeslayer: thanks for your suggestions. do you have ideas what i should look for in the gdb backtrace? as far as i can tell, this seems to be just... fine. it's worth noticing this whole codebase is heavily threaded, but i double checked that the gbm and egl code path is only accessed by one thread at any time
<zmike>
jenatali: link?
Duke`` has quit [Ping timeout: 480 seconds]
<jenatali>
I'm looking for it...
<jenatali>
Maybe I'm misremembering and just thought I'd have to, but hacked around it in the backend instead
<jenatali>
zmike: Yeah nevermind, I just made our backend treat anything that's not a 32-bit type as if it was composed of 32-bit uints
<zmike>
at least not without being unreasonably creative
<jenatali>
I thought I'd have to do it in deref space but managed to put it after lower_io
<feaneron>
interesting. the crash happens at "util_memset32(dst, uc->ui[0], width);" (src/gallium/auxiliary/util/u_surface.c:144). i guess it should have taken the 64 bit paths by default?
<feaneron>
no, that's unrelated
lumag__ has joined #dri-devel
heat has joined #dri-devel
mi6x3m has joined #dri-devel
<mi6x3m>
hey, where can I find the earliest model ATI cards for the radeonsi driver?
<FLHerne>
mi6x3m: Southern Island ones, it's in the name ;-)
<FLHerne>
Radeon HD 7000 series
<FLHerne>
(I think some mobile '7000M' GPUs are actually older terascale things covered by r600g - yay, marketing dept.)
<mi6x3m>
FLHerne, thanks, is r600g covered by r600?
<FLHerne>
failed to parse question
<mi6x3m>
you said r600g
<mi6x3m>
but the meson conf only lists r600
<FLHerne>
yes
<mi6x3m>
thank you :)
<FLHerne>
oh, the desktop HD7350 through HD7670 are actually TeraScale too
<FLHerne>
anything GCN or RDNA is radeonsi, anything TeraScale is r600g
<mi6x3m>
THANKS!
rexbcchen has quit [Read error: Connection reset by peer]
rexbcchen has joined #dri-devel
rasterman has joined #dri-devel
mi6x3m has quit [Remote host closed the connection]
<jekstrand>
bnieuwenhuizen: Trying to understand how radv uses the framebuffer from the pInheritanceInfo
<jekstrand>
bnieuwenhuizen: I see comments about fast clears
sdutt has joined #dri-devel
<bnieuwenhuizen>
jekstrand: pretty sure clears in with inherited framebuffers are broken for subpasses with >1 attachment
<jekstrand>
bnieuwenhuizen: ....
<bnieuwenhuizen>
basically our clears work by binding a single attachment, which doesn't work if we don't know the attachment
<bnieuwenhuizen>
and the partial fix I've seen is silently ignoring all the framebuffer binding code if the attachment is missing
<bnieuwenhuizen>
which works well for a single attachment but I see no way how it would work for multiple
heat has quit [Read error: No route to host]
<jekstrand>
oof
heat_ has joined #dri-devel
<bnieuwenhuizen>
the fix I want to do is modifying some pipeline register to write shader output 0 to color target N so we can avoid rebinding any attachments but never took the time to implement that
jkhsjdhjs has joined #dri-devel
<feaneron>
does AR24 correspond to GBM_FORMAT_ARGB8888?
<jekstrand>
bnieuwenhuizen: What's super annoying here is that dynamic rendering doesn't provide image views for inheritance at all.
lumag__ is now known as lumag_
mszyprow has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
<shadeslayer>
Georges Stavracas (feaneron): uhm, a link to the backtrace would be useful :)
<shadeslayer>
Though I'm heading to bed, I can have a look tomorrow morning
<bnieuwenhuizen>
jekstrand: wdym what happens? That should work
Haaninjo has quit [Quit: Ex-Chat]
<jekstrand>
bnieuwenhuizen: You were talking about handling the MRT case.
<bnieuwenhuizen>
should work just fine
<jekstrand>
Ok...
<bnieuwenhuizen>
the shader output to RT mapping is in CB_SHADER_MASK and CB_TARGET_MASK which are part of pipeline state, not the CB state
<jekstrand>
What about depth/stencil? Can you make it totally ignore it?
<bnieuwenhuizen>
yeah you can disable the depth/stencil testing
cef has quit [Quit: Zoom!]
<jekstrand>
bnieuwenhuizen: If we can avoid having to do the subpass save/restore while inside the render pass, that'd be really helpful.
<jkhsjdhjs>
hey, I'm currently experiencing an issue which I suspect mesa/radeonsi to be the cause of. on my system, the program "rustdesk" (a remote control application like vnc, teamviewer or anydesk) causes my xorg server to crash. sometimes when I reboot my system I can start rustdesk without an issue, and if that's possible, I can restart rustdesk as often as I want without any issue,
<jkhsjdhjs>
the backtrace only contains debug symbols for mesa, because I only installed mesa with debug symbols and no other package. if further debug symbols may be useful, please tell me so.
<bnieuwenhuizen>
yeah which is why I though the best fix would be to poke at CB_TARGET_MASK for choosing the color attachment to clear
<jekstrand>
kk.
<jekstrand>
I'll see if I can figure out how to do that. :)
cef has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<mareko>
The fastest way to write into 1 attachment out of 3 is to write 1 color output as mrt0 and use CB_SHADER_MASK to map that to color buffer N. Of course in the shader you would just write to mrtN and the driver would map that to mrt0 internally to get the perf as 1 output, and then redirect it to mrtN after the shader
<jekstrand>
right
<bnieuwenhuizen>
mareko: problem is without knowing the image/texture at the place of recording the commandbuffer putting it as mrt0 is quite messy
<bnieuwenhuizen>
oh nvm, misread your comments
<karolherbst>
ehhh.. writing a winsys abstraction is annoying :(
<bnieuwenhuizen>
yeah we'd redirect and my best guess on how to do that is by shifting CB_TARGET_MASK (+ a couple of unknown on whether we need to e.g. shift the rbplus registers)
<mareko>
no CB target mask doesn't need any shifting
danvet has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
how would you redirect to mrtN after the shader then?
<bnieuwenhuizen>
are you talking about an epilog?
<mareko>
no
icecream95 has joined #dri-devel
<mareko>
You shift SPI_SHADER_COL_FORMAT to remove the holes but keep everything else the same. If CB_SHADER_MASK has 0 for mrtN, it will move into the next color buffer, but it won't increment N
<mareko>
see 3fec2f67c3d9424c8c0fdfaeef5d906e27453cd6
<mareko>
I don't remember it very well, but it works kinda like that.
<jekstrand>
bnieuwenhuizen: Ok, I think I convinced myself that RADV_META_SAVE_PASS is only used for layout transitions which means I don't actually need it with dynamic rendering.
<mareko>
*it will move TO the next color buffer
<bnieuwenhuizen>
hmm, ok I thought that CB_SHADER_MASK was what the shader output
<bnieuwenhuizen>
either way, sounds like we have an example. Thanks :)
<bnieuwenhuizen>
jekstrand: ah seems like we fixed it by making a pipeline per color attachment index, seems my memory was stale :(
<bnieuwenhuizen>
still not the most efficient thing, but at least not your problem anymore
<bnieuwenhuizen>
remaining thing is transitions & resolves but I don't think those matter for inheritance
<jkhsjdhjs>
hey, can someone point me to the correct channel for my issue? it seems to have something to do with nir or radeonsi
<jekstrand>
here is fine
heat_ has quit [Remote host closed the connection]
<jekstrand>
or #radeon
<jkhsjdhjs>
ah I see
heat_ has joined #dri-devel
<jkhsjdhjs>
I already posted the issue above, mind if I post it again for visibility?
<jekstrand>
It's only been 30 minutes. Not many people have logged on and off since then.
<jkhsjdhjs>
alright ^^
<jekstrand>
jkhsjdhjs: Have you filed a bug?
<jkhsjdhjs>
nope, not yet. wanted to check first whether this also looks like a mesa bug to you, or if something different seems to cause it in your view
<jekstrand>
Yeah, it's likely a mesa bug. Probably in radeonsi.
<jekstrand>
Steps to reproduce, if possible, are important
<jkhsjdhjs>
alright!
* jekstrand
wishes pNext chains were actually trees
* jekstrand
could make them a tree.... 🤔
<bnieuwenhuizen>
why do you want a tree?
<jekstrand>
So that I can join pNext lists
<ccr>
tree hugging?
shoragan has quit [Quit: quit]
<jekstrand>
Or maybe I can Or maybe I can just add more vk_get_pipeline_foo_info helpers
<jekstrand>
That sounds maybe less terrible
shoragan has joined #dri-devel
<jekstrand>
Really, it's the SampleCountInfoAMD that's the problem. It can come in either via the render pass or the directly on the PipelineCreateInfo pNext chain.
ngcortes has joined #dri-devel
rsripada has quit [Remote host closed the connection]