ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
tursulin has quit [Read error: Connection reset by peer]
tzimmermann_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<bnieuwenhuizen>
dcbaker: Can we get 66f7289d568db8711adb885acc56622e2aff252a cherry-picked to mesa-22.0 as requested in the "[ANNOUNCE] mesa 22.0.0-rc2" thread? Seems that has slipped through the cracks?
<mattst88>
(I think it's generally best to open an MR against the stable branch for things like that)
<bnieuwenhuizen>
mattst88: weird thing here was that a revert got cherry-picked into mesa-22.0 that we didn't want & expect unless the above patch was also included
<bnieuwenhuizen>
hence the discussion on the ML, though in hindsight maybe MR would have been better given that it slipped through :)
mbrost has quit [Ping timeout: 480 seconds]
<dcbaker>
bnieuwenhuizen: picked, sorry about that
gawin has quit [Ping timeout: 480 seconds]
<dcbaker>
I think eric_engestrom and I talked about not automatically nominating reverts anymore unless they were also cc: or fixes:, but I don't think either of us have made that happen
<mattst88>
ah, I was going to ask if the tooling automatically nominated reverts. that makes sense
<mattst88>
huh, there was an rc3. doesn't look like the announcement ever made it to the list
<kisak>
y
<bnieuwenhuizen>
IIRC it might even be documented but we forgot about it on the radv side
<dcbaker>
mattst88: oops, yeah I think I did forget to send out an annouce
<mattst88>
ahh, no problem
<dcbaker>
panfrost did have some issues with -rc3 anyway :/
<karolherbst>
jekstrand: sooo... the most annoying issue about cl_kernel is, that it's highly mutable, so I am not entirely sure how we want to deal with that. Maybe just use it as &mut if the new wrapper allow that easily... or we just use a Cell/RefCell and set the new values, which wouldn't need a &mut at all
alatiera has quit [Ping timeout: 480 seconds]
<karolherbst>
ehhh.. and I have to fix Program because it could deadlock and I have to fix something anyway..
<jekstrand>
karolherbst: that's what Mutex is for
<jekstrand>
Or RwLock
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
<karolherbst>
jekstrand: sure, but cl_kernel are not supposed to be shared, so concurrent access is undefined behavior
<karolherbst>
we could still lock if we want to, but we don't have to
<jekstrand>
sure
<jekstrand>
But, as long as most of the time is being burned in NIR, I don't care about taking a few locks.
<karolherbst>
I am not sure how relevant calls to clSetKernelArg are
<karolherbst>
in the real world I mean
<jekstrand>
And having to lock kernels sounds very much like the kind of thing we should not worry about without benchmark data. :)
<karolherbst>
but applications might compile a kernel and reuse it with different args for ever
<jekstrand>
hrm... clSetKernelArg sounds annoying
<karolherbst>
yeah...
co1umbarius has joined #dri-devel
<karolherbst>
I am sure clEnqueueNDRangeKernel will also change some state
columbarius has quit [Ping timeout: 480 seconds]
<jekstrand>
Yeah, refcell might work
<karolherbst>
my hope is that we could cover everything with Cell::set though, but we can only tell after trying that out
camus has joined #dri-devel
<jekstrand>
So Cell is basically an atomic swap?
<jekstrand>
That should work
<karolherbst>
well except it isn't atomic
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
:-/
<karolherbst>
but you overwrite the old value without needing &mut
<karolherbst>
which could be enough
<jekstrand>
But acutal races can still break it
<jekstrand>
?
<karolherbst>
sure
<jekstrand>
:-/
<karolherbst>
I think the inner state of Cell is still fine, because Cell doesn't really have state
<jekstrand>
I mean, if racing is illegal, I guess that's probably good enough
<jekstrand>
Especially for KernelSetArg
<karolherbst>
yep
<karolherbst>
Cell literally only consist of the value it wraps, nothing else
<jekstrand>
ah
<karolherbst>
so there is no state to trash
<karolherbst>
just threads reading out weird values
<karolherbst>
anyway, implementing KernelSetArg will be fun because of many reasons
<jekstrand>
But, again, if we just throw a mutex around it all, that's ok
<karolherbst>
jekstrand: if it makes you feel better, Atomics in Rust use UnsafeCell, which Cell uses as well :p
<jekstrand>
heh
<karolherbst>
they just do atomics on the Cells pointer
<jekstrand>
heh
aravind has joined #dri-devel
slattann has quit []
linearcannon has quit [Read error: Connection reset by peer]
linearcannon has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
ngcortes has quit [Remote host closed the connection]
mbrost has joined #dri-devel
shankaru has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
slattann has joined #dri-devel
alatiera7 is now known as alatiera
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
<ishitatsuyuki>
I want to investigate using a hardware-accelerated SHA1 implementation in Mesa, and apparently the kernel's sha1_ni_asm.S is dual licensed as BSD/GPL2. Are there any potential issues wrt incorporating BSD licensed code in Mesa?
linearcannon has quit [Read error: No route to host]
linearcannon has joined #dri-devel
lemonzest has joined #dri-devel
tango_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
rcf has quit [Quit: WeeChat 3.2.1]
aravind has joined #dri-devel
<mattst88>
ishitatsuyuki: no licensing issues, but I don't think we'll take optimizations like this unless there's real performance data
<mattst88>
and I don't think SHA1 is a bottleneck in any way in Mesa
rcf has joined #dri-devel
dri-logger has quit [Read error: Connection reset by peer]
mslusarz has quit [Read error: Connection reset by peer]
mareko has quit [Read error: Connection reset by peer]
glisse has quit [Read error: Connection reset by peer]
dri-logger has joined #dri-devel
Duke`` has joined #dri-devel
<ishitatsuyuki>
you're right, it's not a bottleneck at all during compilation
<ishitatsuyuki>
it did become a fairly large portion when I was replaying an already-warmed fossilize cache, so that's probably why I spotted that on perf top
fdfrng4343 has quit [Remote host closed the connection]
Daaanct12 has joined #dri-devel
mwalle has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
garrison has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
robertfoss has joined #dri-devel
<bbrezillon>
does anyone know if VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT allows 3D -> 2D dimension casting on image views used as textures, or is it just allowed on color attachment views?
<bbrezillon>
VK_KHR_maintenance1 mentions the color buffer attachment use case explicitly, but it doesn't clearly forbid it on other kind of attachments, and VkImageCreateFlagBits doesn't mention any particular usage constraint
<bbrezillon>
I'm asking because d3d12 doesn't allow 3D -> 2D casting on textures, but supports it on color buffer attachments (we can specify the target 3D slices in the RENDER_TARGET_VIEW descriptor)
<bbrezillon>
I mean, we can always lower things shader side, but I'd like to avoid that if we can
rasterman has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
<krh>
jekstrand, karolherbst: if cl_kernel is not shared, RefCell is the non-atomic version of Mutex
sneil_ has joined #dri-devel
mlankhorst_ has joined #dri-devel
sneil__ has joined #dri-devel
sneil_ has quit [Read error: Connection reset by peer]
slattann1 has joined #dri-devel
sneil has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
shankaru has quit [Quit: Leaving.]
LexSfX has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
LexSfX has joined #dri-devel
Daanct12 has quit [Quit: Quit]
shankaru has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
digetx has joined #dri-devel
slattann1 has quit []
maxzor has joined #dri-devel
MajorBiscuit has joined #dri-devel
<karolherbst>
krh: I wish that would be the case, but RefCell verifies at runtime there is just one &mut on the inner data, meaning it can fail. But given that concurrent access is undefined it might be fine
<krh>
karolherbst: yeah, it's annoying that way, but you said "cl_kernel are not supposed to be shared"
<karolherbst>
that's correct
<karolherbst>
but I hope that Cell::set is enough as it's less annoying to use than RefCell
<krh>
yeah, it's cleaner and easier if you can get away with it
Viciouss has joined #dri-devel
dllud has quit []
dllud has joined #dri-devel
mighty17 has joined #dri-devel
jewins has joined #dri-devel
agd5f has quit [Quit: Leaving]
agd5f has joined #dri-devel
adjtm is now known as Guest1785
adjtm has joined #dri-devel
iive has joined #dri-devel
Guest1785 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mattrope has joined #dri-devel
<jekstrand>
bbrezillon: It's only for rendering, I belive
<jekstrand>
Uh... Hrm...
<jekstrand>
And maybe storage?
mbrost has quit [Ping timeout: 480 seconds]
<jekstrand>
bbrezillon: Intel hardware supports it for color attachments and storage but not textures, natively.
<jekstrand>
Well, gen9 can do it for textures
mlankhorst_ is now known as mlankhorst
<mlankhorst>
airlied: is drm-next still open?
kts has joined #dri-devel
itoral has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
<Lynne>
airlied: just asking, do you take VkVideoPictureResourceKHR.codedOffset into account for the current "setup" resource?
<Lynne>
apparently it's meant to be used for interlaced content, where the bottom field is interlaved with the top field by specifying an offset
heat has joined #dri-devel
kts_ has joined #dri-devel
<robclark>
danvet: jfwiw, had a "fun" time the other day debugging a kernel deadlock which eventually turned out to be caused by (no surprise) SW_SYNC ;-) ... it did make me think we should revisit using per-crtc kthreads for non-block atomic commits, since blocking system_unbound_wq when that happens is unfriendly
kts has quit [Ping timeout: 480 seconds]
enilflah is now known as halfline
rkanwal has quit [Ping timeout: 480 seconds]
Terman has quit [Remote host closed the connection]
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
ardera_ has quit [Remote host closed the connection]
nchery has joined #dri-devel
kts_ has quit []
kts has joined #dri-devel
maxzor has quit [Remote host closed the connection]
<danvet>
robclark, hm I thought it should spawn more workers?
<danvet>
that's at least what I thought unbound means, as in you can hog a work forever and nothing much bad happens
<danvet>
or did someone flush that wq (which would be a bug I think, don't ever do that)?
gawin has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
<robclark>
danvet: so userspace eventually detects the hang and tries to restart.. and ofc that causes various wq flushes that add to the hilarity..
<bbrezillon>
unless you see a good reason to wait, I'll update the dozen MR to use the new helpers
kts_ has joined #dri-devel
<jekstrand>
bbrezillon: Sounds good. I've got lavapipe MRs posted for CmdBeginRendering and CmdBindDescriptorSets
jessica_24 is now known as Guest1795
<jekstrand>
bbrezillon: They're both running in CI now but I'm pretty confident.
jessica_24 has joined #dri-devel
shankaru has quit [Quit: Leaving.]
kts has quit [Ping timeout: 480 seconds]
<bbrezillon>
jekstrand: yep, added R-b on the MRs already
<jekstrand>
\o/
<jekstrand>
bbrezillon: Sadly, lavapipe-asan is failing on the beginrendering one. Investigating now.
<jekstrand>
drp... Forgot to un-comment BeginRendering
Duke`` has joined #dri-devel
idr has quit [Quit: Leaving]
Guest1757 has quit [Ping timeout: 480 seconds]
karolherbst_ has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
gawin has joined #dri-devel
abhinav__ has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
abhinav___ has left #dri-devel [#dri-devel]
slattann has quit []
gawin has quit [Ping timeout: 480 seconds]
kts_ has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
rkanwal has joined #dri-devel
ngcortes has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<karolherbst_>
jekstrand: now: clSetKernelArg... I hope that won't be too annoying to implement as it requires quite a lot in the end
<karolherbst_>
would be fun to represent the args as rust enums
<karolherbst_>
each enum value can even take a different type internally
<jekstrand>
karolherbst_: Yeah, that's probably the best way to do it.
<karolherbst_>
we even have three tests just testing clSetKernelArg :) nice
<karolherbst_>
ehhh they all want workGroupInfo implemented as well.. oh well
<airlied>
mlankhorst: nope, unless it's for fixes since we are post rc7
ngcortes has quit [Remote host closed the connection]
<karolherbst_>
argh...
<karolherbst_>
clc could contain the normal spirv kernel arg parsing :D
<karolherbst_>
jenatali: are you using nir or spirv to parse the kernel arguments?
lynxeye has quit []
ybogdano has joined #dri-devel
<karolherbst_>
ehh probably you are doing it at a dxil level?
gouchi has joined #dri-devel
<karolherbst_>
mhh I need to think about this
<anholt>
jekstrand: thanks for fixing the vulkan cmd queue codegen!
<karolherbst_>
jekstrand: any initial thought about where we want to parse out all the actual kernel args? I kind of lean towards nir, because then we really don't have to do anything with the spirv
<jekstrand>
anholt: yw!
<jekstrand>
karolherbst_: idk. I never really felt like I had a good handle on why we did it with SPIR-V in clover.
<karolherbst_>
I think because this was way before nir was in a good enough shape
<airlied>
do you still have all the info for clGetKernelArgInfo at the nir stage?
<karolherbst_>
airlied: that's a different thing
<karolherbst_>
clGetKernelArgInfo is already implemented :D
<airlied>
ah cool
<karolherbst_>
but it's very useless for running kernels
<karolherbst_>
it only returns the (type) names inside the source which could be typedefs or whatever
<karolherbst_>
as literal strings
<karolherbst_>
also.. clGetKernelArgInfo requires -cl-kernel-arg-info passed in
<karolherbst_>
okay.. anyway.. I have to do something similiar to clc_spirv_to_dxil
<karolherbst_>
maybe it makes sense to split it out into clc so we can generate nir_shaders directly out of clc
rcn-ee has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<karolherbst_>
anyway.. that's going to be fun
<karolherbst_>
project for the weekend
<jekstrand>
karolherbst_: I'm still not sure NIR is in good enough shape. It doesn't have any of the actual types. Just representative bit sizes.
<karolherbst_>
jekstrand: why would you need the actual types?
<karolherbst_>
it's all just sized data except for samplers and mem objects
<karolherbst_>
well and local* handling
<karolherbst_>
passing in a command_queue will be fun, but that's like CL 2.0 stuff, no?
<karolherbst_>
anyway, we don't have to know the actual types for clSetKernelArg
<airlied>
karolherbst_: are you not targetting CL3.0 straight away?
<karolherbst_>
I am starting with implementing all the CL 1.0 stuff first :D
<karolherbst_>
but yes.. the platform itself reports CL 3.0
<karolherbst_>
dealing with queue_t is probably a lot of pain
<karolherbst_>
"Device-side enqueue and on-device queues are optional for devices supporting OpenCL 3.0" nice
pnowack has quit [Quit: pnowack]
mhenning has joined #dri-devel
JohnnyonFlame has joined #dri-devel
sdutt has joined #dri-devel
Kayden has quit [Quit: to office]
tzimmermann_ has quit []
ngcortes has joined #dri-devel
gawin has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<dcbaker>
Is there a way to get the CI to just run everything?
<dcbaker>
It comes back green, then I push a patch and suddenly something unrelated is failing, and the 22.0 branch is just a clusterfuck because the CI is not running everything
<dcbaker>
I thought it was green, then it suddenly isn't because the CI decided to not run half the CI!
<anholt>
do you mean "run all the manual jobs"?
<anholt>
or do you mean "don't do the filtering thing of what jobs are available"?
<dcbaker>
I see "green check mark" but that means "I ran some subset of tests and that passed"
<dcbaker>
because clearly we weren't ready to release yesterday
<anholt>
you're using the branch interface, rather than an MR?
<dcbaker>
because 22.0 is a branch and we don't land MR's?
<dcbaker>
I run a script, and push the branch to the staging/22.0 branch
<dcbaker>
without MRs
<dcbaker>
if there are regressions, we force push
pnowack has joined #dri-devel
<dcbaker>
that's the way this was done since we added CI
<anholt>
it sounds like maybe you want an exception like how ignore_scheduled_pipelines is included in all the test-source-dep, which looks at the branch name and repo and runs everything?
<dcbaker>
I think so?
<dcbaker>
I mean, normally this would be fine
<dcbaker>
but I was sick for a week and ended up with like 50 patches that got semi-blindly pushed
<dcbaker>
doing release management with covid might not have been a good idea, in retrospect
<dcbaker>
so right now I really just want to get a complete snapshot of the state of 22.0
<dcbaker>
Because I don't know what's even broken in the branch
<anholt>
but yeah: doing dev on a branch given our filter rules means you have to make sure you touched something related to every job that failed, or it won't re-run that job and you can lose track of what's busted.
<dcbaker>
Okay, I missed that change becanse 21.2 didn't have that :/
mbrost has joined #dri-devel
gawin has joined #dri-devel
lk95 has joined #dri-devel
<lk95>
Hi I'm having trouble using semaphores inside kthreads where removing the kernel module freezes the system. Anybody can help? I've been banging my head for two straight days. I'm sure I'm missing something but the internet wasn't of much help. Here is an extremely simplified version of the code which has the same problem. https://pastebin.com/VRcH026k. kthread_stop isn't interrupting the down_interruptible call, so the kernel freezes.
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst_>
lk95: does kthread_stop even interrupt?
mvlad has quit [Remote host closed the connection]
rkanwal has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
linearcannon has quit [Read error: Connection reset by peer]
mbrost has quit [Ping timeout: 480 seconds]
bluebugs has quit [Quit: Leaving]
bluebugs has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
ngcortes has joined #dri-devel
mattst88 has quit [Remote host closed the connection]
mattst88 has joined #dri-devel
mbrost has joined #dri-devel
<dcbaker>
anholt: thanks, that got me going! thankfully just a bunch of unexpected passes that I wasn't aware of
<anholt>
dcbaker: zmike has taken to putting the ci updates in a separate commit for some reason, which will cause you trouble when you cherry-pick the fix back.
<zmike>
I don't think those are mine
<anholt>
looked like some of the asan fixes were in that branch
gouchi has quit [Remote host closed the connection]