ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
* jekstrand
gives up for the day
nchery is now known as Guest1283
nchery has joined #dri-devel
Guest1283 has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
<karolherbst>
jekstrand: I am sure it's somewhere my mistake :p
<karolherbst>
jekstrand: ohhh ohhh.. ehh.. I think I know what it is
<karolherbst>
probably caused by my not finished reworking of the kernel code
<karolherbst>
I started to move everything towards "one context is only touched by one thread" and atm I use the helper contex to create the sampler state, but use the queue context to enqueue kernels
<karolherbst>
I hope that doesn't mess things up
<karolherbst>
mhh, doesn't seem to be that either
h0tc0d3 has joined #dri-devel
h0tc0d3 has quit []
h0tc0d3 has joined #dri-devel
h0tc0d3 has quit []
h0tc0d3 has joined #dri-devel
bcheng has quit [Remote host closed the connection]
bcheng has joined #dri-devel
ngcortes has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
mhenning has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
LexSfX has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
<zmike>
jekstrand: it merged \o/
elongbug has quit [Ping timeout: 480 seconds]
h0tc0d3 has quit [Quit: Leaving]
nchery has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
nchery has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
bbrezill1 has joined #dri-devel
digetx is now known as Guest1292
Guest1292 has quit [Read error: Connection reset by peer]
digetx has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
idr has quit [Quit: Leaving]
LexSfX has quit [Read error: Connection reset by peer]
LexSfX has joined #dri-devel
aravind has joined #dri-devel
Duke`` has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
mhenning has quit [Quit: mhenning]
shankaru has quit []
mbrost has joined #dri-devel
naveenk2 has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
shankaru has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit []
thellstrom has joined #dri-devel
JohnnyonF has joined #dri-devel
thellstrom1 has joined #dri-devel
JohnnyonF has quit [Read error: Connection reset by peer]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
mbrost has joined #dri-devel
mvlad has joined #dri-devel
JohnnyonFlame has joined #dri-devel
mszyprow has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
mbrost has quit []
itoral_ has joined #dri-devel
naveenk2 has quit [Read error: Connection reset by peer]
thellstrom1 has quit []
itoral has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
nchery has joined #dri-devel
ahajda_ has joined #dri-devel
aravind has joined #dri-devel
jkrzyszt_ has joined #dri-devel
danvet has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
Daanct12 has joined #dri-devel
paulk1 has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
morphis has joined #dri-devel
bbrezill1 has quit []
bbrezillon has joined #dri-devel
MajorBiscuit has joined #dri-devel
tursulin has joined #dri-devel
lynxeye has joined #dri-devel
maxzor has joined #dri-devel
rpigott has quit [Remote host closed the connection]
<javierm>
I think that will cover most of the cases, since for example DRM drivers for small panels and whatnot shouldn't call drm_aperture_remove_conflicting_framebuffers() anyways
<javierm>
that's only for drivers that want to kick out early firmware-based framebuffer drivers
paulk1 has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
maxzor has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
shashank_sharma has joined #dri-devel
shashanks has quit [Read error: Connection reset by peer]
shashank_sharma has quit [Read error: No route to host]
romangg has quit []
shashank_sharma has joined #dri-devel
jernej_ has quit [Read error: Connection reset by peer]
jernej has joined #dri-devel
CME has quit []
CME has joined #dri-devel
frankbinns1 has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
karolherbst_ has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
gruetze_ has joined #dri-devel
samuelig has quit [Quit: Bye!]
gruetzkopf has quit [Quit: No Ping reply in 180 seconds.]
karolherbst has quit [Remote host closed the connection]
samuelig_ has joined #dri-devel
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
frankbinns has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
romangg has joined #dri-devel
Thymo has joined #dri-devel
jernej has joined #dri-devel
jernej_ has quit [Read error: Connection reset by peer]
tzimmermann has joined #dri-devel
Thymo has quit []
Thymo has joined #dri-devel
<danvet>
javierm, let me sketch something in a diff
<javierm>
because I don't see how to not make it racy, unless fbmem takes some lock exposed by sysfb
<danvet>
why?
<javierm>
danvet: scratch that, coffee just didn't kick in. Setting unregistered unconditionally is enough
<danvet>
javierm, it's still a bit unsatisfactory, since we just nuke them all
<danvet>
but it should match exactly what we hacked up with the num_registered_fbs > 0 check
<javierm>
danvet: yup, but to make it more finer grained then sysfb should keep a list of apertures for each registered device and device asked to be kicked out
<danvet>
so if you load a usb drm but want to use the fw fb driver for the main chip and it loads wrong way round
<danvet>
it's busted
<danvet>
javierm, yeah
<danvet>
probably a bit overkill
<javierm>
danvet: but then would a USB drm driver really call drm_aperture_remove_conflicting_framebuffers() ?
<javierm>
I don't see why it would
<javierm>
why would like to kick out system framebuffers ?
Daanct12 has joined #dri-devel
<javierm>
danvet: I would say go with your solution and later if found to be needed, we could add the aperture book keeping
Major_Biscuit has quit []
MajorBiscuit has joined #dri-devel
<danvet>
javierm, hm yeah good point
rasterman has joined #dri-devel
<javierm>
danvet: also, 'if (/* check it's our dev */)' do we really need that? Since do_remove_conflicting_framebuffers() alredy found the device to unregister
<javierm>
danvet: and agree on the forced_out, that's just to prevent a taking the registration_lock mutex twice so a drop and restar seems cleaner
<danvet>
javierm, well it might be a different fbdev driver
<javierm>
danvet: ah, you mean not registered by sysfb ?
<javierm>
hmm
<danvet>
yeah like vga16fb
<danvet>
or just some other fbdev
<javierm>
right
<javierm>
god, this is complex :)
<danvet>
you might accidentally unload the fbdev emulation for another kms driver
<javierm>
danvet: so that's another fbdev driver that we won't need in the future: drivers/staging/fbtft/fb_ssd1306.c
kmn has joined #dri-devel
<danvet>
yay!
maxzor has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
bluepenquin_ has joined #dri-devel
Haaninjo has joined #dri-devel
bluepenquin_ has quit []
<melissawen>
hi, I was looking at some old initiatives to implement 3D LUT in color mgmt (i.e. LUT 3D and cubic-lut)
<melissawen>
and now I see ongoing discussions for HDR planes
<emersion>
yup
<melissawen>
afaiu, the former would add 3D LUT support in the crtc stage, and the latter is focusing on color management properties for planes
<melissawen>
is there any point in which they overlap?
<melissawen>
I checked old initiatives were not landed for lacking open userspace usage
<emersion>
hm, pq isn't here for some reason :(
Daanct12 has joined #dri-devel
<emersion>
you could ask him in e.g. #wayland, he should know the latest about color management stuff
<emersion>
i _think_ both per-plane and per-CRTC LUTs might be useful, but don't trust me on this
<emersion>
per-plane to convert to a common blending space, per-CRTC to convert to output space
<emersion>
hwentlan____ has some patches on the ML with some nice graphs for AMD
<emersion>
also cc swick ^
<emersion>
note, AFAIU we're not too close from being able to type the patches to use KMS offload for color management just yet
<melissawen>
emersion, yes, I think so.. I wonder if it's ok to revive those old initiatives for CRTC.. I see HDR planes discussion has multiple points for aggrements that I don't wanna to mess up :)
devilhorns has joined #dri-devel
flacks has quit [Quit: Quitter]
itoral_ has quit [Remote host closed the connection]
flacks has joined #dri-devel
<melissawen>
emersion, btw, thanks for checking that patch for alpha property. I tried to reproduce the other tentative example, but I didn't manage to see/load the image (probably something wrong in my config)
<javierm>
danvet: but I think is still incomplete, we should split sysfb_try_unregister() in sysfb_try_unregister() and sysfb_disable() as my patch had
<javierm>
because otherwise if there are no conflicting framebuffers, then sysfb will never be disabled
<danvet>
javierm, why the separate sysfsb_disable?
<danvet>
Hm I guess there's more races that I didn't see
<javierm>
danvet: because otherwise if a DRM driver asks for the conflicting fb to be removed and there's none, the sysfb could happily register platform devices at a later time
<javierm>
so we need to disable it at the beginning of the removal loop unconditionally
<danvet>
yeah
<danvet>
just realized that
<danvet>
it's annoying
<javierm>
yeah...
<danvet>
I guess in the end we really should push the matching down into sysfb against the device's resources or framebuffer
<javierm>
danvet: anyway, I've built a kernel and will do some testing before posting. As mentioned I'll include your patch 18/19 and this should unblock your patch 19/19
itoral has joined #dri-devel
nchery has joined #dri-devel
nchery has quit [Remote host closed the connection]
<swick>
but yeah, in general 3d luts on planes and crtcs are both useful
<melissawen>
swick, right, I understood this discussion targets color management support per-plane, but since we already have color mgmt properties per-crtc, do we aim to change those terminologies too?
yoslin has quit [Quit: WeeChat 3.3]
yoslin has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
mszyprow has quit [Read error: Connection reset by peer]
itoral has quit []
nchery has joined #dri-devel
<swick>
melissawen: I don't think we can?
kts has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<javierm>
danvet: currently fighting ABBA deadlocks :(
<pinchartl>
javierm: Swedish deadlocks are the worst
<javierm>
pinchartl: LOL, took me a few seconds to get that reference
<pinchartl>
:-)
Thymo has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
kts has quit [Quit: Konversation terminated!]
lemonzest has quit [Quit: WeeChat 3.4]
aravind has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
mszyprow has joined #dri-devel
nchery has joined #dri-devel
mbrost has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
lemonzest has joined #dri-devel
sdutt has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
pjakobsson_ is now known as pjakobsson
gawin has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
nchery has joined #dri-devel
shankaru has quit [Quit: Leaving.]
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
fxkamd has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
khfeng has quit [Ping timeout: 480 seconds]
frankbinns1 has quit []
frankbinns has joined #dri-devel
zamundaaa[m] has quit []
zamundaaa[m] has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
<zmike>
jekstrand: bad news: I'm getting lavapipe deadlocks now
fxkamd has quit []
<jekstrand>
zmike: :(
<zmike>
looks like waiting on an acquire semaphore is broken
<jekstrand>
zmike: Guess what we're fighting with in v3dv. :)
<jekstrand>
zmike: I'll take a look in a moment.
<jekstrand>
zmike: Does it repro with simple demos or do I need zink?
<zmike>
jekstrand: vkcube deadlocks
<zmike>
note to self: ask jekstrand if he has run vkcube for future MRs
<jekstrand>
kk
<Kayden>
s/glxgears/vkcube in "glxgears runs, ship it!"
Duke`` has joined #dri-devel
<jekstrand>
zmike: Ok, figured out what's going on. Now I just have to figure out how to do it correctly.
nchery has joined #dri-devel
<jekstrand>
The dummy sync we're hitting is because we're in an implicit sync case. For lavapipe, I think the right thing to do is never wait on implicit syncs (already accomplished) and, when signaling an implicit sync thing, we need to stall in vkQueueSubmit() until the work is done before handing off to X11
kts has joined #dri-devel
kts has quit []
<jekstrand>
Not sure the best way to do that, TBH.
<jekstrand>
Maybe some custom LVP code? Probably.
nchery has quit [Ping timeout: 480 seconds]
agd5f_ has quit []
agd5f has joined #dri-devel
kts has joined #dri-devel
toolchains has quit []
<jekstrand>
Looks like common code is already doing that last bit. :)
<zmike>
give me a few hours to make sure I'm really seeing it render and not just some pre-recorded tech demo you snuck in
<jekstrand>
lol
<jekstrand>
anholt: How does implict sync work with v3d?
<zmike>
jekstrand: ironically if you had actually tested war thunder as I said in the original MR, this would've been caught :P
<jekstrand>
zmike: You're not wrong. :P
<Hello71>
does anyone have an idea about https://gitlab.freedesktop.org/mesa/mesa/-/issues/6229? my conclusion is that probably glibc is returning null for the tlsdesc call, but that doesn't explain why, or why it allegedly only breaks on x
nchery has joined #dri-devel
<javierm>
danvet: posted the series, reworked too much your original diff so I wasn't confortable to keep your authorship
ybogdano has joined #dri-devel
<javierm>
danvet: didn't want to blame you for my silly locking bugs :)
<zmike>
jekstrand: but now I have to ask
<zmike>
have you tested war thunder?
<jekstrand>
zmike: No. I don't have that game.
paulk1 has quit [Ping timeout: 480 seconds]
<zmike>
sighhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh not even owning such a pivotal lavapipe testing apparatus
<jekstrand>
zmike: You pretend to know how gallium works. What hook gets called from gallium's WSI to tell you to flush things?
<zmike>
what kinds of things
<zmike>
like swapchain images?
<jekstrand>
Yes
<zmike>
flush_resource
<jekstrand>
kk
<zmike>
your rb will have to wait until I can redownload and test this
<jekstrand>
:-/
<zmike>
can't believe I deleted elden ring for you
<jekstrand>
You deleted elden ring? Not enough disk space?
<zmike>
I have too many games installed
<jekstrand>
Surely there's something less important than Elden Ring to bump off...
<zmike>
it's okay I still have it on one of my steamdecks
<zmike>
I do not, however, live in a datacenter, so this will have to wait until I get back from the gym
<kisak>
Decks (plural) ... lucky you
<zmike>
that was a typo actually, I meant steamdUcks
<kisak>
... the quack?
<zmike>
they're ducks that I've trained to carry laptops around the house for me
<zmike>
it's part of my new no-furniture decor
* jekstrand
feels like he probably needs to run gears on his rpi to figure this out....
iive has joined #dri-devel
paulk1 has joined #dri-devel
CATS has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
MajorBiscuit has quit [Ping timeout: 480 seconds]
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
* jekstrand
doesn't want to read v3d code to figure this out...
jkrzyszt_ has quit [Ping timeout: 480 seconds]
caef^ has joined #dri-devel
<jekstrand>
Looking at v3d code, it seems it sets exclusive fences on everything. Awesome.
<jekstrand>
So how are there ever any sync problems?
mclasen has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
<karolherbst>
I swear I had to fix something dumb like that for nouveau at some point as well (that offset part)
<jekstrand>
karolherbst: It's actually the 2nd patch that did it. Iris has an optimization that tracks valid ranges on buffers and magically makes maps unsynchronized if it thinks it doesn't have any valid data.
<karolherbst>
ahh
<karolherbst>
annoying
<jekstrand>
And global bindings were always 100% invalid so we were getting unsynchronized maps
<jekstrand>
Woo!
<karolherbst>
noo :(
<anholt>
jekstrand: now that iris does TC, I think you can GC that code.
<jekstrand>
I'll leave that for Kayden
<jekstrand>
anholt: While I've got you.... How does implicit sync work in v3d? Reading the kernel code it looks like it implicit syncs on everything all the time.
<jekstrand>
Exclusive fences for everyone!
<anholt>
sounds right
<jekstrand>
Ok, then I have no idea how I have tearing....
<jekstrand>
Or maybe that's X11 doing some classic front-buffer rendering.
<karolherbst>
jekstrand: if it's X11, then you get tearing one way or the other :p
<karolherbst>
sooo.. how do we want to fix MEM_USE_HOST_PTR?
<karolherbst>
that should probably fix another 100 tests
<jekstrand>
karolherbst: I'm working on it
<karolherbst>
cool :)
<jekstrand>
And looking at Sachiel's Vulkan issue at the same time.
* Sachiel
gladly takes the blame for everyone's work being delayed
<karolherbst>
I think I got rusticl to be essentially thread safe now as well, there are just two things which annoy me: I have to map pipe_resources with the device helper context instead of the queues one, but I have no good solution here :/
<karolherbst>
maybe relaly just flush the entire queue and stall
<karolherbst>
or do some nasty things
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
<karolherbst>
but maybe that's fine.. dunno
h0tc0d3 has joined #dri-devel
h0tc0d3 has quit []
h0tc0d3 has joined #dri-devel
<jekstrand>
karolherbst: Ugh... Now for handling images. :-/
mvlad has quit [Remote host closed the connection]
<karolherbst>
:(
<karolherbst>
jekstrand: keep in mind that CL is a bit nice here.. I think, let me check the spec
<karolherbst>
mhh, yeah... so CL added some nice things for 2.0
<karolherbst>
if you create an image from a buffer, you have to make sure the alignment is good
<karolherbst>
but I think there was something for images as well
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
<jekstrand>
karolherbst: Hrm... clCreateImage doesn't really need the host ptr to stay around.
<karolherbst>
what do you mean?
<jekstrand>
karolherbst: We should be able to map it as a buffer and then blit
<jekstrand>
host_ptr is a pointer to the image data that may already be allocated by the application. It is only used to initialize the image, and can be freed after the call to clCreateImage.
<karolherbst>
jekstrand: that's for COPY_HOST_PTR
<karolherbst>
jekstrand: ohh, I hope you don't read like the old spec
<karolherbst>
the host_ptr has to stay, it is even required to return the host_ptr when mapping memory (even images)
<karolherbst>
and the content has to be consistent
<karolherbst>
and well.. mapImage isn't allowed to fail, because you really just return the pointer with USE_HOST_PTR
<jekstrand>
Ugh...
<karolherbst>
it was a spec bug in 2.2 as it seems :)
<karolherbst>
your sentence isn't there in 3.0
<jekstrand>
fun....
<karolherbst>
yeah.. well it contradicted MEM_USE_HOST_PTR
<karolherbst>
(and what the tests are doing)
<jekstrand>
I'm looking at test_basic hostptr
<karolherbst>
yep
<karolherbst>
but I don't think it actually tests all that much
<karolherbst>
there are some api tests who go into more depth
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst>
mhh maybe they do verify that stuff just for buffers
<karolherbst>
anyway, the spec is quite clear on that now in 3.0
<jekstrand>
I can cook something up
<karolherbst>
when calling clEnqueueMapImage, the host_ptr has to contain the most recent data and the pointer return has to be derived from host_ptr
<karolherbst>
easiest way out is if the hw supports userptr on textures :)
<karolherbst>
we could potentially update the data when mapping though
<karolherbst>
I'd just prefer to do it right from the start and make use of hw features where possible
<jekstrand>
Yeah
<jekstrand>
I've got it typed, I think.
JohnnyonF has joined #dri-devel
mhenning has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Well, it's doing a thing. :)
<karolherbst>
yay
<jekstrand>
It's not doing the right thing, though....
CATS has joined #dri-devel
idr has joined #dri-devel
<karolherbst>
jekstrand: is tiling disabled for those resources?
<jekstrand>
yup
<jekstrand>
karolherbst: Need to fix maps to handle resource offsets
<karolherbst>
ahh
<karolherbst>
right.. I rely on drivers doing the right thing there :)
<jekstrand>
karolherbst: Yeah, we could fake this all in rusticl or we can make iris do it. Doesn't much matter to me.
<karolherbst>
yeah.. but I think I saw drivers taking the offset into account for cache flushes and other things, I think.. or well something like that
<Kayden>
sounds like something iris should be doing
<jekstrand>
karolherbst: passed!
<karolherbst>
yay
* jekstrand
kicks off a new test_basic run
<karolherbst>
do you pushed it already? then I'd do a run with my scrupt
<jekstrand>
karolherbst: Do you know what's going on with async_copy_global_to_local?
<jekstrand>
karolherbst: Can't find clc function _Z17wait_group_eventsiPU3AS49ocl_event
<karolherbst>
some llvm-15 regression
<jekstrand>
I'm on LLVM 13 here
<karolherbst>
uhh, weird
<karolherbst>
maybe it's a real issue then.. I thought I saw some function regressing though
kts has quit [Quit: Konversation terminated!]
<jekstrand>
I'll poke at it
<jekstrand>
Could be another generic pointer thing
<jekstrand>
Actually... I think it is.
<karolherbst>
probably
<jekstrand>
*grumble*
LexSfX has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
<jekstrand>
karolherbst: libclc doesn't seem to have any wait_group_events functions at all
LexSfX has joined #dri-devel
<jekstrand>
Ugh... It definitely exists
<jekstrand>
hrm... it's here
* jekstrand
doesn't know what's going on
<karolherbst>
there was something weird about those, but I forgot what it was
<karolherbst>
let's check for translator bugs
<jekstrand>
Yeah, it's mangling it to generic again
<jekstrand>
*sigh*
<dj-death>
AS4 :(
lemonzest has quit [Quit: WeeChat 3.4]
<jekstrand>
karolherbst: How many of these fixes do we really want to carry in NIR? :-(
<airlied>
jekstrand: care to give rusticl/crocus a spin? :-)
<jekstrand>
airlied: Sure. Why not?
<jekstrand>
Means I need to boot the haswell, though.
<airlied>
though I think it would need that fix for offsets
<karolherbst>
jekstrand: you mean those workarounds?
<jekstrand>
karolherbst: Yeah, how many CLC fixups do we want to have be NIR passes. :-/
* airlied
looked at rebasing my amd nir compute stack, messy think I need to cherry-pick and rewrite
<jekstrand>
I'd fix it in LLVM but ugh
<karolherbst>
yeah.....
<jekstrand>
In this case, I think it's actually clc that's broken
<jekstrand>
The prototype for that one is `void wait_group_events(int num_events, event_t *event_list)`
<jekstrand>
So I think that means event_list is generic
<karolherbst>
jekstrand: I think that's the correct prototype
<jekstrand>
Or maybe that means function? I don't remember.
<jekstrand>
s/function/private
<karolherbst>
nope, it's generic
<karolherbst>
and I think the spec even defines it as generic
<jekstrand>
So, yeah, I think CLC is just being compiled wrong now.
<jekstrand>
Or maybe it's generic if you have generic pointers and it's __private otherwise?
<jekstrand>
idk
<karolherbst>
I think it was always generic
<jekstrand>
But what about CL 1.2?
<karolherbst>
I meant always as in always :)
<karolherbst>
even in the CL C 1.0 spec it's generic
<airlied>
since it's an event I think there is something else there
<airlied>
it's not a typical cl pointer
<karolherbst>
but it's a pointer to event_t
<airlied>
"The event type (event_t) cannot be used as the type of a kernel function argument. The event type cannot be used to declare a program scope variable. The event type cannot be used to declare a structure or union field. The event type cannot be used with the __local, __constant and __global address space qualifiers"
<karolherbst>
mhhh
<karolherbst>
okay, but it's not used with anything
<karolherbst>
but eh...
<airlied>
so yeah I think they need special handling somewhere
<karolherbst>
wow.. how annoying
<jekstrand>
So if you can't declare them, how do you get them?
<airlied>
you get them from the async* fns
<jekstrand>
Right
<jekstrand>
So it sounds like we really want it to be `event_t *__private event_list`
<karolherbst>
yeah
<jekstrand>
airlied: Oh... I just remembered rusticl won't work on crocus for a while. It requires softpin.
<jekstrand>
No relocations + CL yet
<airlied>
jekstrand: ah ouch
<jekstrand>
airlied: We can relax that eventually, maybe.
<Kayden>
jekstrand: think you missed two cases, left you a comment
<Kayden>
(re: maps respecting offsets)
<jekstrand>
Kayden: Read more carefully. :P
<Kayden>
jekstrand: uh...one does iris_bo_map and reads the existing contents, the other does iris_bo_map and writes the new contents?
<Kayden>
both are not respecting the offset?
<jekstrand>
Oh, unmap
<jekstrand>
drp
* jekstrand
failed at reading
<Kayden>
when "no u" is the correct response, haha
<jekstrand>
Kayden: What do you mean by "staging case"?
h0tc0d3 has quit [Quit: Leaving]
<jekstrand>
Oh, map->staging?
<Kayden>
ah iris_[un]map_copy_region
<Kayden>
offset should always be 0 there but if you felt like asserting it probably wouldn't be a bad idea
<Kayden>
if not that's fine too
<Kayden>
just thinking it'd demonstrate that we did handle it in every case, and didn't just miss thinking about it
<Kayden>
but it's probably not really that valuable either
<jekstrand>
Kayden: What about if we're sub-allocating on DG2?
apinheiro has joined #dri-devel
<jekstrand>
idk what the offset is for
<jekstrand>
Kayden: Ok, I think I've added such an assert
<Kayden>
jekstrand: offset is just for import/export
<jekstrand>
Kayden: Ok. I guess I could assert 0 for s8 too
<Kayden>
probably, yeah.
<jekstrand>
Kayden: The reason I'm doing this is because we need offsets for userptr
<jekstrand>
And we need userptr images
<jekstrand>
But not s8
<Kayden>
huh. iris_resource_from_memory doesn't set res->offset
<Kayden>
err
<Kayden>
iris_resource_from_user_memory doesn't set res->offset
<jekstrand>
It does now. :)
<Kayden>
ah
<Hello71>
why do brw_opcode_desc variables need to be thread-local?
<Kayden>
jekstrand: where does the offset come from?
<Kayden>
jekstrand: normally that comes from winsys_handle stuff
<Kayden>
jekstrand: BTW, for suballocations - bo->address on the suballocated BO already contains the offset, so no worries there
<jekstrand>
Kayden: Oh...
<Kayden>
jekstrand: and iris_bo_map() on it already accounts for that.
<jekstrand>
Kayden: I guess I could shove my userptr weirdness deeper into iris_bufmgr
<jekstrand>
Kayden: Ok, !15779 now contains all the relevant commits
<airlied>
Hello71: gnome-chess on gtk4
<airlied>
and gnome-extensions-app
<Hello71>
hm. and you are using crocus?
<airlied>
yes f36 on a haswell laptop, I update all specially to test this
<airlied>
that TLS thing is interesting though
<Hello71>
hm. and both fedora 36 and arch are on glibc 2.35...
<Kayden>
mattst88: maybe you know the answer to Hello71's question about brw_opcode_desc above?
heat has joined #dri-devel
<Hello71>
about brw_opcode_desc, i checked the original mailing list thread and briefly viewed the code, it feels like it could be replaced by a call_once?
<Kayden>
Hello71: it sure seems like we should set up the table once and just use it, yeah.
<Kayden>
looks like this was curro's code, I don't remember why he did it that way
<Kayden>
jekstrand: what you added for userptr offsets looks good to me
<Kayden>
jekstrand: I do think the change to respect offsets in map_s8 and map_tiled_memcpy is probably a good one, though. outside of OpenCL, we already support importing a dmabuf and that could have an offset and we probably ought to respect it.
<jekstrand>
Ok
<jekstrand>
I'll roll back to real offsets there
<jekstrand>
Kayden: pushed.
<Kayden>
jekstrand: R-b
<jekstrand>
I suppose I should probably run those through Jenkins...
mbrost has quit [Remote host closed the connection]
<Hello71>
airlied: are you using fedora mesa or self-compiled?
mbrost has joined #dri-devel
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
<airlied>
Hello71: fedora mesa
gouchi has quit [Remote host closed the connection]
<jekstrand>
karolherbst: Do you know what's going on with these ARRAY to IMAGE3D copy tests?
<karolherbst>
jekstrand: what test are you debugging btw?
<jekstrand>
test_basic image_param
tzimmermann_ has joined #dri-devel
<karolherbst>
mhhh
<mareko>
just discovered that 1 Xe core = 1 WGP
<bnieuwenhuizen>
ehhh, by some metrics
<mareko>
assuming 16x SIMD8 = 4x SIMD32
<karolherbst>
y
<bnieuwenhuizen>
AFAIU for basic float ops that holds true yeah
tzimmermann has quit [Ping timeout: 480 seconds]
<ajax>
dcbaker: we've dropped some things from the current docs that would apply to amber, i think. i'm open to either thing tbh.
<karolherbst>
jekstrand: mhh, that test uses CL_MEM_COPY_HOST_PTR
<jekstrand>
karolherbst: Hrm...
<jekstrand>
karolherbst: host ptr should work but I'm not sure about COPY_HOST_PTR
<karolherbst>
but CL_MEM_COPY_HOST_PTR does seem to work though
<karolherbst>
jekstrand: CL_MEM_COPY_HOST_PTR is just uploading init data to a texture
<karolherbst>
texture_subdata
<jekstrand>
right
<karolherbst>
but that seems to just work
<karolherbst>
otherwise images/kernel_read_write/test_image_streams would complain
<karolherbst>
well it does complain, but because of other reasons :)
<karolherbst>
"FAILED 48 of 243 sub-tests."
<karolherbst>
something with clamping is wrong as CL is.. well.. "ultra precise"
<jekstrand>
Well, this particular test is returning all 0 from a really trivial sample operation so....
<jekstrand>
idk what's wrong
<karolherbst>
let's see
<karolherbst>
I am sure there is a good reason for it
<karolherbst>
jekstrand: the test isn't as simple as you think it is
<karolherbst>
it's using txs to offset into the result buffer
<jekstrand>
Yeah, I know
<jekstrand>
that's fine
<karolherbst>
mhhh, probably
<jekstrand>
I know it's fine. I hacked things up to skip the read_image and write green
<karolherbst>
ahh
maxzor has quit [Ping timeout: 480 seconds]
<jekstrand>
I think I found it
<jekstrand>
bah... nvm.
<karolherbst>
I'd blame fencing/events, but... that's probably fine :/
<karolherbst>
I guess there is something wrong with the read_image call itself, no?
<jekstrand>
It is using non-normalized coordinates so I double-checked that
<jekstrand>
Anyway... It's getting late
<karolherbst>
jekstrand: soo there is one annoying thing. when using COPY_HOST_PTR I upload data via the device helper ctx, the queue uses its own context, and I could imagine that things could trip up there a little
<jekstrand>
I think I'm going to call it a day.
<karolherbst>
yeah, it does
<jekstrand>
karolherbst: Oh... That's a good call.
<jekstrand>
Yeah, we may need to do some sync there.
<karolherbst>
I already made most of it thread safe, but you never know what flushing/syncing I forgot to do
<karolherbst>
jekstrand: ahh.. I wanted to always fence + wait on helper context operations...
<karolherbst>
let me hack something up tomorrow
<jekstrand>
kk
<karolherbst>
we should probably do it regardless if that's the cause or not
morphis has quit [Ping timeout: 480 seconds]
<jekstrand>
I would guess without a flush on that context, the upload may not even be getting kicked off
<jekstrand>
much less, waited on.
<karolherbst>
yeah
morphis has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Bingo!
<karolherbst>
:)
pcercuei has quit [Quit: dodo]
<jekstrand>
karolherbst: updated my branch
<karolherbst>
yeah... I was thinking about hiding it a little, so that instead of returning a MutexGuard helper_ctx will return something which will auto flush on drop... or maybe that would be a bit too much hidden magic :)
gallo has joined #dri-devel
<jekstrand>
Yeah... that's magic
<jekstrand>
We could do two loops, one to submit all the things and one to wait on all the things.
<jekstrand>
That way the uplaods would at least parallelize across devices
<jekstrand>
That seems like the best we can do
<karolherbst>
yeah
<karolherbst>
something like that
<jekstrand>
That's better than a magic drop thingy :P
<karolherbst>
yeah.. it's always "make it hard to mess up" vs "do something which doesn't cause perf issues"
<karolherbst>
bug I'd know how to paralize with hiding it though
<karolherbst>
you just use iter().for_each()
<karolherbst>
ehh
<karolherbst>
map + collect
<karolherbst>
and then the guards drop when the stack/block is left
<jekstrand>
idk
<jekstrand>
If we want to do something fancy, I suspect we want something even smarter.
alanc has quit [Remote host closed the connection]
<jekstrand>
But I've not thought about it hard enough.
alanc has joined #dri-devel
<jekstrand>
I've also been thinking about how we're doing queues etc. I don't particularly like the clover event design which it seems like you've more-or-less copied.
<jekstrand>
But I also don't know if I can come up with anything better.
<karolherbst>
it looks copied, but it's something entirely different :p
<jekstrand>
lol
<jekstrand>
fair
<karolherbst>
clover didn't use a worker thread
<karolherbst>
which essentially changes everything after that. Most of it is derived from CL though
heat has quit [Remote host closed the connection]
<karolherbst>
CL requires only one "active" event per time, which is stupid, but it has strong sync requierements
heat has joined #dri-devel
<karolherbst>
using closures is nice, as you can just store whatever data a task entry needs without having to play silly tricks with state structs and the likes
<karolherbst>
anyway, if you tell me what you don't like I can probably come up with something better
<jekstrand>
Yeah, I don't know what that is yet
<jekstrand>
May be nothing
<karolherbst>
clovers design is quite broken in some ways, so I could imagine that similiarities look like a red flag or something :p
<karolherbst>
clover added previous events as deps which caused some stackoverflows in some tests because clover started to call "wait()" on all deps... this was fun
<jekstrand>
Yeah
<karolherbst>
at some point I have to add a dependency calculater once we start doing out of order things, but for now...
<karolherbst>
there is one thing I didn't implement though: if a dep fails, the event itself also fails
<karolherbst>
need to do that to fix some tests
khfeng has joined #dri-devel
<karolherbst>
jekstrand: the absolutely most annoying issue is, that user events can and will block processing and we have to wait on user events to be triggered...
<karolherbst>
I am quite surprised that I didn't screw this up tbh
<karolherbst>
mhh.. maybe I did fix this part already (failing events on failed deps)