Duke`` has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
sarnex has quit []
kts has joined #dri-devel
kzd has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
sarnex has joined #dri-devel
weechat11k was kicked from #dri-devel by ChanServ [archive link spam]
sarnex has quit []
kts has joined #dri-devel
<zmike>
surfaces were in a weird spot where they were kinda single-context but also they could be shared between contexts but they weren't actually supposed to be, and it was super confusing
<zmike>
also they're only used in framebuffer state with a small fixed number
<zmike>
vs samplerviews, which are now exclusively single-context for sure and can be passed around in gigantic arrays
kts has quit []
<karolherbst>
right... it would help me if I could share sampler views between contexts
<karolherbst>
but I suspect that's kinda hard to achieve and not only because of the destruction callback
<zmike>
I explicitly did the huge refactor months ago to prevent that
<zmike>
so don't
<zmike>
some drivers (e.g., zink) deduplicate them internally anyway
sarnex has joined #dri-devel
<karolherbst>
right, it would just be easier for me to allocate sampler views when the CL memory object gets allocated and I'd just use that one forever, but I can make it work per context... it's not hard to be better than "create sampler views when a kernel gets launched"
<karolherbst>
I can just cache them per context
<karolherbst>
it's just a bit annoying because of object lifetimes
<zmike>
suck it up buttercup
kts has joined #dri-devel
kts has quit []
<karolherbst>
yeah...
<karolherbst>
same for samplers
rgallaispou has joined #dri-devel
dsimic is now known as Guest22277
dsimic has joined #dri-devel
Guest22277 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
warpme has joined #dri-devel
epoch101 has joined #dri-devel
warpme has quit []
croissant_ has joined #dri-devel
davispuh has joined #dri-devel
croissant has quit [Ping timeout: 480 seconds]
croissant_ has quit []
croissant has joined #dri-devel
sarnex has quit []
<karolherbst>
okay.. I already figured out sampler caching :D
<karolherbst>
but those are also way simpler to deal with
JLP_ has quit [Read error: Connection reset by peer]
JLP has joined #dri-devel
<Lynne>
is there a dissassembler/decompiler for old GCN1/HD 8000-era IR (if_logicalnz r42.x, div_zeroop(infinity) r42.x___, r45.x, r42.x and so on)?
sarnex has joined #dri-devel
coldfeet has joined #dri-devel
fab has joined #dri-devel
<glehmann>
Lynne: AMD IL? grvk probably has something like that as part of their translator to spir-v
<Lynne>
oh, right, amdilc
<glehmann>
there is also a public spec for it
<Lynne>
I need something that can parse the string-based IR variant and output something more readable
<Lynne>
alternatively, I also have 64-bit addressing nvidia PTX IR
chewitt has quit [Quit: Zzz..]
flto_ has quit []
flto has joined #dri-devel
i-garrison has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
paulk-bis has joined #dri-devel
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
Company has joined #dri-devel
alanc has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
Duke`` has quit []
Mangix_ has joined #dri-devel
Mangix has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
rgallaispou has quit [Quit: WeeChat 4.6.3]
rasterman has joined #dri-devel
<karolherbst>
zmike: I'm running into a heap-use-after-free in zink inside zink_update_barriers, where "ctx->update_barriers" references pipe_resources already destroyed from e.g. inside "zink_set_sampler_views" (zink_sampler_view_destroy triggers also destroying the pipe_resource). Now I'm wondering if there is a hidden usage pattern I need to follow, or if
<karolherbst>
zink simply should reference any resource going into the ctx->update_barriers set as well
<karolherbst>
ehh "ctx->need_barriers"
<karolherbst>
or maybe it's easier to simply remove the resources from the sets, because doing anything with them also feels super pointless :)
<karolherbst>
though uhm.. don't have references to the context when destroying resources...
<karolherbst>
ohh it's the tex2d_from_buf imported resources... *sigh*
<karolherbst>
in which case this should be easy to fix..
Duke`` has quit [Ping timeout: 480 seconds]
Karyon has quit [Remote host closed the connection]
Karyon has joined #dri-devel
<karolherbst>
mhh something odd is going on there.. the imported resource has a bind_count of 0, where the main one has 1...
<zmike>
ETOOCOMPLEX
<zmike>
will think Monday
<karolherbst>
ohhh I wonder if it's zink_context_replace_buffer_storage...
<karolherbst>
it doesn't fix the bind for the imported one
<karolherbst>
nope...
<karolherbst>
okay... on unbind time the import2d one changes?
<karolherbst>
or rather it tries to unbind a different one the main was bound with earlier...
<karolherbst>
okay.. at bind and unbind a different sampler view is used.. curious... maybe I'm messing something up big times?