ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
ngcortes has quit [Remote host closed the connection]
CME has quit [Read error: No route to host]
CME has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
kts has joined #dri-devel
jacobcrypusa[m] has left #dri-devel [#dri-devel]
kts has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
fxkamd has quit []
fxkamd has joined #dri-devel
fxkamd has quit []
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
dviola has quit [Quit: WeeChat 3.6]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
pallavim has joined #dri-devel
Daanct12 has joined #dri-devel
Daanct12 has quit []
slattann has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
slattann has quit [Read error: Connection reset by peer]
slattann has joined #dri-devel
pallavim has quit [Remote host closed the connection]
pallavim has joined #dri-devel
slattann has quit []
slattann has joined #dri-devel
Company has quit [Quit: Leaving]
ppascher has joined #dri-devel
aravind has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
Duke`` has joined #dri-devel
slattann has quit [Read error: Connection reset by peer]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
jewins has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
itoral has joined #dri-devel
jewins has joined #dri-devel
fab has joined #dri-devel
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
garrison has quit []
i-garrison has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest982
srslypascal has joined #dri-devel
aravind has joined #dri-devel
Guest982 has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
saurabhg has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
mvlad has joined #dri-devel
fab has quit [Quit: fab]
tzimmermann has joined #dri-devel
<vsyrjala>
airlied: yeah, i've asked him to cc intel-gfx at a previous occasion when he broke i915 (earlier this year). he even seemed to agree back then. but still no cc happening so i915 keeps breaking
<vsyrjala>
i suppose ideally we'd just make the ci pull stuff from dri-devel too, but i don't think it has the bandwidth for it
kts has joined #dri-devel
MajorBiscuit has joined #dri-devel
fab has joined #dri-devel
Haaninjo has joined #dri-devel
<javierm>
vsyrjala: I wonder if would make sense to have in MAINTAINERS a DRM core entry or something, that could list drivers/gpu/drm/drm_* and other core files
<javierm>
vsyrjala: that way it could have intel-gfx as another L: and make sure that core changes are ran in the CI
<javierm>
but still ignore driver patches
jkrzyszt has joined #dri-devel
saurabhg has quit []
kts has quit [Ping timeout: 480 seconds]
i-garrison has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
tursulin has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
Daanct12 has joined #dri-devel
vliaskov has joined #dri-devel
fahien has joined #dri-devel
kts has joined #dri-devel
sarahwalker has joined #dri-devel
dv_ has quit [Ping timeout: 480 seconds]
dv_ has joined #dri-devel
<vsyrjala>
javierm: perhaps. i was also wondering if the ci itself could filter the patches, and only test the ones touching core/helper stuff
rgallaispou has joined #dri-devel
lynxeye has joined #dri-devel
rasterman has joined #dri-devel
garnet has joined #dri-devel
<MrCooper>
anholt: I hope you mean libEGL.so.1 :)
<HdkR>
I made the mistake of loading `libvulkan.so` a week ago. Oops :D
flibit has joined #dri-devel
<MrCooper>
no cookie for you
<HdkR>
Better yet, CI caught my mistake and slapped me
<MrCooper>
nice
flibitijibibo has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
pallavim has quit [Remote host closed the connection]
pallavim has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<tzimmermann>
why is there a plane_helper_funcs.disable, but no plane_helper_funcs.enable ?
<tzimmermann>
(or rather atomic_disable, but no atomic_enable)
dakr has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
devilhorns has quit []
devilhorns has joined #dri-devel
sravn has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I wondered the other day the same, that's why I ended adding an encoder to ssd130x just to have atomic_{en,dis}able callbacks
<javierm>
tzimmermann: but I first considered adding the power on/off logic to the plane callbacks until I realized that there wasn't an .atomic_disable
<tzimmermann>
javierm, the plane would not have been the right place, i guess
<javierm>
tzimmermann: no, it wouldn't. I think that an encoder makes much more sense anyways, but that made me wondered about the lack of symmetry in the plane callbacks
<tzimmermann>
yeah, some of the drivers could make use of an atomic_enable. maybe it wasn't necessary so far
<tzimmermann>
you can do everything in atomic_update, but it's somewhat overloaded
lplc has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: yes, for example some drivers clear the screen in their probe but that could be done in an atomic_enable
<javierm>
s/screen/plane buffer
srslypascal has quit [Quit: Leaving]
tanty has quit []
pepp has quit [Read error: Connection reset by peer]
tanty has joined #dri-devel
nchery has joined #dri-devel
srslypascal has joined #dri-devel
Plagman has quit [Remote host closed the connection]
lplc has joined #dri-devel
sravn has joined #dri-devel
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #dri-devel
calebccff_ has quit []
tanty has quit []
calebccff has joined #dri-devel
Plagman has joined #dri-devel
tanty has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<marex>
is mesa 22.2 still not released ? :)
pepp has joined #dri-devel
fahien has joined #dri-devel
garnet has quit [Ping timeout: 480 seconds]
fab has quit [Remote host closed the connection]
nchery_ has joined #dri-devel
fab has joined #dri-devel
nchery has quit [Read error: No route to host]
nchery has joined #dri-devel
garnet has joined #dri-devel
nchery_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
rasterman has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
cengiz_io has joined #dri-devel
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
Lucretia has quit []
<bl4ckb0ne>
is there a way to make piglit use the egl header from mesa?
Lucretia has joined #dri-devel
bmodem has joined #dri-devel
eukara has quit []
eukara has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
pendingchaos_ is now known as pendingchaos
eukara has quit []
bmodem has quit []
nehsou^ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
fxkamd has joined #dri-devel
fab has quit [Quit: fab]
garnet has quit [Read error: Connection reset by peer]
KunalAgarwal[m][m] is now known as KunalAgarwal[m]
<KunalAgarwal[m]>
didn't get this "input buffer you only use for texturing as normal"
<anholt>
MrCooper: nope, unfortunately angle is bad at shared libs.
<KunalAgarwal[m]>
<pq> "KunalAgarwal[m], input buffer..." <- also then how should I fill the output texture with raw image data which is in input buffer
<anholt>
(but then, given the frequency of this error, pretending that you'll be able to do a major version bump is unrealistic anyway)
bmodem has joined #dri-devel
fab has joined #dri-devel
<pq>
KunalAgarwal[m], I don't understand. You read from input buffer and write to output buffer. Why would you copy raw data from input to output when you are supposed to process that raw data?
<pq>
KunalAgarwal[m], your fragment shader gets invoked for each output pixel you write. That shader will read from the input texture from any number of positions it likes.
<pq>
KunalAgarwal[m], for de-bayering I don't think there is any reason to do read-modify-write on the output buffer. Just a write is enough.
fahien has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
jewins has joined #dri-devel
kts_ has joined #dri-devel
kts_ has quit []
<eric_engestrom>
bl4ckb0ne: iirc the egl headers in mesa don't have anything not present in the khronos headers anymore; why do you ask?
rgallaispou has joined #dri-devel
<bl4ckb0ne>
im working on implementing an egl ext
<bl4ckb0ne>
that introduces a new token
<bl4ckb0ne>
seems to work when I install my local build to /usr/local but its a bit annoying
kts has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
<KunalAgarwal[m]>
<pq> "KunalAgarwal[m], I don't..." <- Why is "dmabuf -> EGLImage -> bind to GL texture" needed for the input buffer or is it not needed
<eric_engestrom>
bl4ckb0ne: in that case I suggest adding an `#ifndef EGL_FOO_EXT #define EGL_FOO_EXT 0x3456` so that it doesn't break piglit for everyone else once your test lands :)
<eric_engestrom>
(adding that in your piglit test, I mean)
<pq>
KunalAgarwal[m], it is needed. That is how you read the buffer: you use it as a texture.
fahien has joined #dri-devel
<bl4ckb0ne>
eric_engestrom: havent thought about that, thanks!
<KunalAgarwal[m]>
<pq> "KunalAgarwal[m], it is needed..." <- sorry but How and where should I use that input texture then? since I will bind the output texture to FBO right
<KunalAgarwal[m]>
glFramebufferTexture2D will be called for output texture if I am not wrong
<daniels>
KunalAgarwal[m]: you might want to work through some of the basic usage guides on https://open.gl
<daniels>
and by 'might', I mean 'definitely'
<pq>
KunalAgarwal[m], I think you need to find a tutorial on using a texture in OpenGL. The most basic tutorial you can find that draws a textured... anything.
fab_ has joined #dri-devel
fab_ is now known as Guest1021
<KunalAgarwal[m]>
ah sure thanks :-)
<pq>
KunalAgarwal[m], the only difference here will be that instead of calling glTexImage2D like in a tutorial, you already have a GL texture handle from that EGLImage thing.
<jekstrand>
Woah, look at all that Rust code in my mesa!
<karolherbst>
:)
<karolherbst>
jekstrand: late to the party?
fab has quit [Ping timeout: 480 seconds]
<KunalAgarwal[m]>
pq: ahh okay this clears things a bit
<karolherbst>
jekstrand: btw.. is there anybody we could bribe into reviewing the remaining iris MRs?
<jekstrand>
karolherbst: Just haven't pulled in a bit.
<jekstrand>
karolherbst: Kayden is the obvious choice. Not sure what to bribe him with, though.
<karolherbst>
mhhh
<jekstrand>
karolherbst: Yeah, looks like those are Kayden patches. Shouldn't be a hard review, though.
<karolherbst>
jekstrand: might make sense for you too look over the additional patches in !18581
<karolherbst>
might be better to merge them into !16442
<MrCooper>
anholt: I don't expect any ABI bumps, the .so symlink may not exist at runtime though
<jekstrand>
karolherbst: They look fine
nehsou^ has quit [Remote host closed the connection]
<karolherbst>
anyway.. besides the three open MRs on the tracker, everything else went in :)
<jekstrand>
\o/
<jekstrand>
Yeah, those really need Kayden to sign off
<jekstrand>
Especially the one for 128 textures. I committed a few sins in that one. :-/
<karolherbst>
btw I think panfrost already passes all tests as well :D
chipxxx has quit [Read error: No route to host]
<karolherbst>
yeah...
srslypascal has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
ybogdano has joined #dri-devel
<bl4ckb0ne>
what's the rule about where to put egl tests? tests/egl or tests/egl/spec?
<bl4ckb0ne>
the test i want to add is for a new ext, depending on a gl ext
<bl4ckb0ne>
erm not a new ext, extending an existing one
jkrzyszt has quit [Ping timeout: 480 seconds]
<ajax>
bl4ckb0ne: .../spec seems to be the trend
garnet has quit [Ping timeout: 480 seconds]
<linkmauve>
ajax, I wrote a Glide backend for my game last week!
<linkmauve>
It’s only half as fast as my OpenGL backend!
tursulin has quit [Ping timeout: 480 seconds]
<linkmauve>
Although I haven’t checked on a real 3DFX yet, so maybe I’m doing things wrong.
<bl4ckb0ne>
spec it is, thanks ajax
<linkmauve>
The biggest annoyance so far has been that the best texture formats available are RGB565 or ARGB4444.
<DavidHeidelberg[m]>
ajax: Hey, thanks for R-b on EGL X11 transparency, do you have any ideas how to implement it to get it working as intended?
chipxxx has joined #dri-devel
<DavidHeidelberg[m]>
any idea what to try is welcome
bmodem has quit [Ping timeout: 480 seconds]
<ajax>
DavidHeidelberg[m]: it's... kinda icky
* ajax
reads...
<ajax>
ugh
<ajax>
one of the hardest skills i've had to learn is recognizing the difference between not understanding the code, and understanding that the code makes no sense
<ajax>
in unrelated news i'm reading src/egl/drivers/dri2/platform_x11.c
<DavidHeidelberg[m]>
I tried to understand a little bit, but I'm afraid I'm at like 5%
garrison has quit []
<ajax>
heh
i-garrison has joined #dri-devel
<marex>
:))
<ajax>
so, dri2_x11_add_configs_for_visuals. i think what it does is: find the first X visual for each X visual class, filter the driver's list of configs by that visual's depth, and create eglconfigs from that
<ajax>
this is what the amish would call "stupid" (if they cared about x11, and frankly i can't blame them for not)
<DavidHeidelberg[m]>
ajax: I got to same conclusion
srslypascal has joined #dri-devel
<DavidHeidelberg[m]>
if I understand right, there is exception to 24 and 30 bit to match 32bit currently. But we want also 32 bit to match 32 bit and put them into second group.
<ajax>
right. i think this is a case where the need for exceptions means you built the thing wrong to begin with
<ajax>
i think what you want is to pick one visual for every depth/class pair, instead
<ajax>
because the argb visual is going to be truecolor, and last in the list
<ajax>
_after_ your xrgb depth-24 truecolor visual(s)
<ajax>
so you build the list for 24TC and 24DC and then have to go back and cram a 32TC visual in somewhere
iive has joined #dri-devel
<ajax>
s/so you/so we currently/ if that wasn't clear
<DavidHeidelberg[m]>
hmm, make sense
<MrCooper>
ajax: X might be getting old enough to be interesting to Amish :P
sarahwalker has quit [Remote host closed the connection]
ybogdano has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
kts has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
fahien has quit [Ping timeout: 480 seconds]
<hakzsam>
dcbaker: what happened to 22.2.0-rc4 or final btw?
<dcbaker>
I’m ready to make a release, just need karolherbst to let me know if nouveau is ready for .0 or another rc :)
<zmike>
karolherbst doesn't do nouveau anymore though, only CL? 🤔
<karolherbst>
dcbaker: it's ready. The fixes are merged and should be all Fixes or CC: stable
<karolherbst>
zmike: heh
<dcbaker>
Perfect, I’ll make .0 asap (when my kid takes his nap)
<karolherbst>
what's the proper way in gallium to map a resource "non blocking" but always succeeding, but having explicit synchronization of content validity?
<karolherbst>
or rather.. I need a pointer where the driver will map a resource into without actually syncing content
<karolherbst>
but not only for writes, also for reads
<karolherbst>
maybe something alike PIPE_MAP_FLUSH_EXPLICIT, but also covering the read size (I need this range to be updated from the GPUs memory) and then later (this range was written, please sync it ot the GPU)
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<karolherbst>
I suspect I might have to do all of that in rusticl more explicitly...
cengiz_io_ has joined #dri-devel
cengiz_io has quit [Ping timeout: 480 seconds]
<karolherbst>
but there is a non blocking way of mapping resources in OpenCL and I already don't like my current solution, which also doesn't for with nouveau e.g.
<karolherbst>
I can't really use PIPE_MAP_PERSISTENT, because that means I have to create all pipe_resources with PIPE_RESOURCE_FLAG_MAP_PERSISTENT
<karolherbst>
and that might make drivers allocate all resources in GART
alyssa has left #dri-devel [#dri-devel]
ybogdano has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
gouchi has joined #dri-devel
rasterman has joined #dri-devel
<bl4ckb0ne>
im hitting this error with a es 3.0 test on piglit `piglit: error: waffle_config_choose failed due to WAFFLE_ERROR_UNKNOWN: eglChooseConfig found no matching configs`
<bl4ckb0ne>
is there a special config to run tests with gles?
slattann has quit [Quit: Leaving.]
<jenatali>
karolherbst: I don't think there is such a thing in gallium today
<jenatali>
You could look at what clover is doing though? Or does it just use persistent?
<karolherbst>
jenatali: yeah.. I am currently thinking about trying to use PIPE_MAP_DIRECTLY, if that fails use the same mechanism for shadow host_ptr buffers
<karolherbst>
jenatali: it's doing tons of transfers
<karolherbst>
I think...
<jenatali>
Yeah that's what I'd expect
<karolherbst>
but I also want to have this fast path for UMA GPUs
<karolherbst>
but I think PIPE_MAP_DIRECTLY is good enough for that
<jenatali>
Yeah should be
<karolherbst>
I already have the logic in place for keeping the shader buffer for failed USE_HOST_MEM buffers, which I think I can just reuse here
<karolherbst>
maybe...
<karolherbst>
need to think about it
<karolherbst>
mhh, but PIPE_MAP_DIRECTLY is also weirdly handled with UMA drivers :(
<karolherbst>
I really want something more like PIPE_MAP_UNSYNCHRONIZED
<airlied>
you want persistent and unsynchronized and fix the drivers :)
<karolherbst>
I don't want persistent
<karolherbst>
and unsynchronized isn't valid for reads
<karolherbst>
none of the PIPE MAP flags really fit the use case here
<karolherbst>
couldn't I even create a pointer by cutting it of the processes VM and bind the actual memory later? :D
<karolherbst>
like doing mmap magic or something
<karolherbst>
I really just need a pointer I can give the application where it can expect stuff to be after it synchronizes the queue
kts has quit [Ping timeout: 480 seconds]
<airlied>
so you want a map that maps, but then returns a fence instead of waiting
<karolherbst>
yes
<karolherbst>
I just need the pointer, but the application has to wait on the cl_event before it can access that
<karolherbst>
and has to unmap before the CL device is allowed to use the same memory
<karolherbst>
so the rough idea is ptr = mem.map_async(); queue.enqueue( /* actually make the ptr point to something valid */);
<airlied>
for gallium I'd just always block until you can work it out
<karolherbst>
I can't block
<airlied>
well the app can't stop you :-P
<karolherbst>
it can
<karolherbst>
the runtime could dead lock
<airlied>
guess you better dig into the api then
<karolherbst>
gallium?
<karolherbst>
guess I'll have to..
<karolherbst>
probably need a MAP_CREATE_TX_ONLY flag and then APIs to explicitly sync the tx object?
<karolherbst>
mhh
<karolherbst>
or make transfer_flush_region work in both directions
pallavim has quit [Ping timeout: 480 seconds]
lina has joined #dri-devel
<zmike>
typically you would just create a new map any time you wanted to sync the read data
<karolherbst>
yeah...
<karolherbst>
but CL allows you to get a pointer before that
<airlied>
yeah it's just an explicit sync map
<karolherbst>
maybe we could an API where we can tell drivers where ti transfer into
<karolherbst>
*add
<karolherbst>
so instead of driver allocating the storage, the frontend does
<airlied>
move to vulkan already :)
<airlied>
karolherbst: I think you'd want a way for a transfer to contain a fence
<jekstrand>
-ENOTVULKAN is the best error message to give other humans. :D
<zmike>
I tried that at the DMV the other day and it didn't go well
ngcortes has joined #dri-devel
<airlied>
and somehow map that fence to the event
<karolherbst>
well.. drivers might enqueue some gpu commands to copy out the data anyway, so we just need them to not wait
<karolherbst>
well actually we also need them to not do the copy in the first place
<airlied>
we need the transfer to happen just fenced
<karolherbst>
because it might happen at the wrong time
<karolherbst>
no
<karolherbst>
that can lead to incorrect behavior
<karolherbst>
we have to tell the driver when to do the transfer
<airlied>
huh why?
<airlied>
is there incoming fences?
<karolherbst>
because a kernel writing to the resource could be in the queue
<karolherbst>
but you do the non blocking map before that kernel was even launched or submitted
<karolherbst>
so you do enqueue a bunch of stuff and then say "after this kernel is done, I want this map to be completed, but I want the ptr to access that map right now"
ella-0 has joined #dri-devel
<airlied>
ah there is an event_wait_list input to clEnqueueMapBuffer
<karolherbst>
yeah, but even without that, if the queue is ordered, events coming before have to complete
<airlied>
karolherbst: the queue though is just on the context
<airlied>
so flushing the context is fine here
<airlied>
when you get that command?
<karolherbst>
it's not, because I don't have the context on the API call
<airlied>
you have cl_command_queue?
ella-0_ has quit [Read error: Connection reset by peer]
<karolherbst>
yeah sure, but I can't flush the context
<karolherbst>
internally it's hidden in the worker thread anyway
<karolherbst>
but again, I _can't_ flush the context here
<karolherbst>
the kernel could wait on user events, and that could only be triggered after the application got the pointer back
<airlied>
that doesn't stop you flushing though
<airlied>
like you can submit all the pending stuff to the hw, and get a fence back
<karolherbst>
a fence to what?
<karolherbst>
transfer copying the wrong data?
<karolherbst>
that's not useful
<airlied>
the fence wouldn't get signalled until after the stuff executes
<airlied>
assuming operation on a single cl_command_queue have to be in-order
<karolherbst>
sure, but I can't tell the driver to create the transfer yet if I didn't submit all the stuff from the queue yet
<karolherbst>
the transfer has to happen in the precise moment it's put in the queue
<karolherbst>
not before
<airlied>
yes so you have times you have to submit the queue then
<karolherbst>
okay, but then I need a pointer from the driver it transfers into in some future API call I do from rusticl
<airlied>
you submit all pending work, and a transfer on the end and get a transfer with a fence back
<airlied>
the transfer with the fence has the ptr and the fence you have to convert into an event
<karolherbst>
I have to get the pointer before all of that though
<karolherbst>
before submiting pending work
<airlied>
why?
<airlied>
the api doesn't seem to demand that
<karolherbst>
because that what the CL API requires
<karolherbst>
it does
<karolherbst>
in the case when blocking_map is false
<airlied>
nope it just says it returns an event, it doesn't mention flushing
<karolherbst>
I have to return a pointer
<airlied>
which you get back from the transfer
<karolherbst>
and I can't flush the queue
<karolherbst>
but how?
<karolherbst>
I can't create the transfer yet
<airlied>
is this due to the threading model?
<karolherbst>
no
<karolherbst>
just how CL queues work
<airlied>
you can always implicitly flush them though, they are more like GL contexts than Vulkan command
<karolherbst>
I can only do the actual transfer when the queue gets to the non blocking map, but when the API call returns, I need to get a valid pointer to the data without flushing the queue
<karolherbst>
I can't
<karolherbst>
again
<karolherbst>
the queue can't be flushed here
<airlied>
then you need to figure out how to make it flush :-)
<karolherbst>
nope
<karolherbst>
that's a req, that I don't flush
<airlied>
where?
<karolherbst>
because it's impossible
<airlied>
give me the spec quite
<karolherbst>
okay
<karolherbst>
the application creates a user event
<karolherbst>
then launches a kernel
<airlied>
that is fine
<karolherbst>
and is donig an non blocking map
<airlied>
flushing the queue isn't blocking on that
<karolherbst>
how can I flush the queue?
<airlied>
just flush it, the hw will wait on the user event
<karolherbst>
the queue blocks on user events
<karolherbst>
what if the application signals if after it got the ptr from mapbuffer?
<karolherbst>
and never before
<karolherbst>
=> deadlock
<airlied>
why does the queue block on user events though?
<karolherbst>
because the CL API specifies it this way
mvlad has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
<airlied>
in my mind you'd submit all that to the kernel scheduler
<airlied>
and use syncobjs for the events
<karolherbst>
if the kernel depends on the user event (it does so automatically in in-order queues, or when set as a dep), the queue has to wait on it
<karolherbst>
sure, and I still deadlock
<airlied>
once the job is submitted then it will just wait for the syncobj to signal
<karolherbst>
if the user events depends on clEnqueueMapBuffer to return, but I wait in clEnqueueMapBuffer on the user event there can only be a dead lock
<airlied>
then you submit more work depending on that work to do the transfer map
<airlied>
why are you waiting though
<airlied>
the kernel scheduler should be waiting in my mind
<karolherbst>
how do I get the pointer ?
<airlied>
or the hw somewhere
<airlied>
you get the driver to return a transfer object with map + fence
<airlied>
you have the ptr and a gallium fence to wait on for the results
<karolherbst>
but what does the fence points to?
<airlied>
the gallium fence should be in the queue after all the other stuff
<karolherbst>
it can't point to the copy as it doesn't exist
<airlied>
you submit the copy after the kernel
<karolherbst>
right.. and how to do that in gallium
<airlied>
flush command queue, submit copy, flush command queue, get fence to wait for
<airlied>
you have to rewrite the transfer_map to be async friendly and use a fence
<karolherbst>
I need the ptr gefore the first flush
<karolherbst>
*before
<airlied>
why? you can flush, get the ptr, submit the copy, and return the fence
<karolherbst>
I can't flush
<karolherbst>
again, because it might depend on user events
<airlied>
the kernel scheduler should take care of it
<airlied>
you shouldn't be blocking in userspace for those user events
<karolherbst>
I have to
<airlied>
then you have to fix that first
<airlied>
like you could model all the syncobjs in userspace with threads, but it might get messy
<airlied>
or we should accelerate the move to vulkan where this is a lot easier to model :-)
<airlied>
you could possibly go with the non-optimal path of just ignoring the drivers here alright
<karolherbst>
the easiest solution is to just alloc a buffer in the frontend and copy into that
DPA- has joined #dri-devel
<karolherbst>
well.. do the copy in the queue
DPA has quit [Ping timeout: 480 seconds]
<karolherbst>
the annoying part is really calling any function on the pipe_context after the user events
<karolherbst>
the annoying bit.. user events _can_ call CL API functions
<karolherbst>
so they could mess with the CL state
<karolherbst>
and that might affect things done after the user event
<karolherbst>
like uploading data or something
<karolherbst>
or setting kernel parameters
<karolherbst>
so how could I flush the queue even, if the kernel launch could be affected by suer events?
<karolherbst>
*user
<karolherbst>
flushing is not an option, period
<airlied>
where do user event call CL API functions?
<airlied>
in the callback?
<karolherbst>
yeah
<airlied>
Behavior is undefined when calling expensive system routines, OpenCL APIs to create contexts or command-queues, or blocking OpenCL APIs in an event callback.
<airlied>
get out of jail free card :-P
<karolherbst>
nope
<karolherbst>
setKenrelARg is not expensive
<airlied>
"There is no guarantee that the callback functions registered for various execution status values for an event will be called in the exact order that the execution status of a command changes. Furthermore, it should be noted that receiving a call back for an event with a status other than CL_COMPLETE, in no way implies that the memory model or execution model as defined by the OpenCL specification has
<airlied>
changed. For example, it is not valid to assume that a corresponding memory transfer has completed unless the event is in a state CL_COMPLETE."
<airlied>
so the ordering is what you'd call quite undefined there
<karolherbst>
it's actually defined, but in a different way
<karolherbst>
the issue is, that the application changes the event status
<karolherbst>
and it might do _whatever_ it wants before that
<karolherbst>
setting kernels args
<karolherbst>
or something
<karolherbst>
so you enqueue a user event to fire new kernel params when a kenrel is done
<karolherbst>
you set new params and fire a user event a new kernel waits on
<airlied>
I also don't think you can clSetKernelArg for something that is already enqueued
<karolherbst>
and then a second kernel runs with the new params
<karolherbst>
mhh actually don't know
<karolherbst>
but yeah.. might be right
<airlied>
once something is enqueued it should be immutable
<airlied>
so you can always flush the current queue
<airlied>
as long as you keep the ordering correct
<karolherbst>
yeah... but anyway, that doesn't change the fact, that an application can do transfers, fire a user signal and then a kernel uses the new data
<karolherbst>
doing stuff in the callback.. sure that might be less defined
<airlied>
it can enqueue transfers
<airlied>
so it can enqueue a kernel waiting on a user event, and a transfer, and you can in theory flush on the transfer enqueuing
<airlied>
and return an event blocked on the copy operation
<karolherbst>
the transfer can be done on a different queue though
<airlied>
then it needs events to sync those
<karolherbst>
yeah, user events
<karolherbst>
but be it as it may, if I flush and wait on user events in a non blocking map, I can deadlock
<airlied>
yeah it's never going to be pretty, need to fix gallium to be more explicit sync in more plces
<karolherbst>
but yeah.. if we can make sure that this user event can't affect events coming after, we could cheat a little
<karolherbst>
though I am not sure if the API actually promises that
<karolherbst>
anyway.. the simpliest solution is to either tell the driver to transfer into a given buffer or get a pointer from a driver where it might transfer to in the future
<karolherbst>
this even model is totally nuts anyway :(
<karolherbst>
for now I'll just allocate a shadow buffer and synchronize it. If we have a better API in the future we save one copy
<karolherbst>
though I think transfering into a given buffer is probably the easiest solution here...
<karolherbst>
so instead of drivers doing the malloc, the frontend would
ybogdano has quit [Read error: Connection reset by peer]
chipxxx has quit [Read error: Connection reset by peer]
<mareko>
vulkan experts: is it OK to defer glWaitSempahoreEXT and glSignalSemaphoreEXT execution to a later time due to glthread batching etc.?
<zmike>
no
<zmike>
this was discussed recently in WG
<mareko>
why?
<zmike>
glSignalSemaphoreEXT implies an immediate flush operation
<mareko>
if you flush glthread or TC, that doesn't mean it will be executed when the flush returns
<zmike>
it has to be
<zmike>
that's what the api requires
<mareko>
so it has to flush + wait until the kernel processes the job?
<zmike>
it can't return until the work has been submitted to the gpu
<zmike>
glWaitSempahoreEXT can be deferred, however
<zmike>
assuming that the command causes subsequent commands to obey the blocking nature of the command
<zmike>
I need to clean up the piglit tests for this actually; they add a glFlush with glSignalSemaphoreEXT and that's unnecessary
<mareko>
the kernel GPU scheduler doesn't guarantee immediate submission to the GPU, it only guarantees that it will be scheduled
<zmike>
I mean submitted to the gpu in the sense that you have passed the batch to the kernel (or whatever mechanism is translating the gl call into the semaphore signaling)
<mareko>
ok
<zmike>
the reason for this is that if the signal operation is deferred, waiters in threads may end up waiting on a semaphore that should have been signaled at time X but wasn't
<zmike>
and waiting on an unsubmitted semaphore is undefined
<mareko>
ok so we have to flush and wait for all CPU threads
<zmike>
correct
<mareko>
ok I guess I can fix the Mesa part, will put the fixes into the glthread MR
<mareko>
it's blocking it anyway
<zmike>
the mesa part should be functional already in main?
<mareko>
no thread syncs
<zmike>
you mean glthread?
<zmike>
I suppose not, I didn't change anything there
<mareko>
yes
<mareko>
TC does
<zmike>
tc and drivers should already be handling everything correctly
<mareko>
radeonsi/CS and glthread don't
<zmike>
ah
<zmike>
I guess I didn't fix radeonsi properly when I did the full mesa pass
<mareko>
vk-semaphores passes with my fixes in !18223, but hangs with -fbo
danvet has quit [Ping timeout: 480 seconds]
DPA has joined #dri-devel
flibit has quit []
flibitijibibo has joined #dri-devel
<ccr>
hmmm.
Guest1021 has quit []
YuGiOhJCJ has joined #dri-devel
neobrain has quit [Remote host closed the connection]
neobrain has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Remote host closed the connection]
* ccr
senses a great frustration in the Force.
<karolherbst>
airlied: *sigh*... so one annoying part of why allocating the buffer upfront doesn't work is, that we need the transfer object to get the row/layer pitches from the driver :(
<karolherbst>
but I suspect we want to tightly pack stuff anyway
<karolherbst>
or maybe that's fine.. dunno
<airlied>
karolherbst: yeah seems more like creating vulkan then
<karolherbst>
the more I think about using vulkan the more I am convinced in using zink tbh
<airlied>
won't solve the gallium API problems though
<karolherbst>
yeah.. but we can change gallium
<karolherbst>
anyway.. the idea of passing in the SPIRV directly will probably become a huge pita, and then if we have to do the same thing zink is doing, it becomes easier to just use zink :)
<karolherbst>
and going with more SPV extensions for vulkan spir-v is probably also better than making vulkan capable consuming CL spirv
<karolherbst>
one major annoyence is the DCE of kernel inputs e.g.
<karolherbst>
I have kernels where I DCE 80% of the kernel input
<airlied>
can't the backend just do that?
<karolherbst>
and how do we agree on the kernel input buffer?
<karolherbst>
*ABI of the
<airlied>
yeah you just either use push constants or make the first UBO
<airlied>
or add an extension
<karolherbst>
well.. how do we decide how the ubo layout is if the runtime DCEs parameters?
<karolherbst>
*what
<karolherbst>
it might not be perf critical, but I suspect for tools like darktables it can actually matter quite a bit
<airlied>
does it matter, DCEing in the shader is probably more important than compression the inputs
<karolherbst>
if you start launching tons of tiny kernels
<airlied>
sparse inputs seems less of a problem
<karolherbst>
I suspect it matters
<airlied>
like hey I used 16-bytes instead of 128-bytes is probably not going to be the sort of problem you need to solve upfront
<airlied>
suspect isn't useful
<airlied>
numbers are useful
<karolherbst>
it will be ugly to fix later
<airlied>
not any uglier than fixing it now
<airlied>
since it needs new API probably
<karolherbst>
or it doesn't and we just allow vulkan spirv doing global loads
<airlied>
if you use vulkan spirv, you are just replacing clvk
<airlied>
and we have that, and know the limitations of it
<karolherbst>
hence adding extensions to spirv
<karolherbst>
but yeah...
<karolherbst>
I am still not settled on either path
<karolherbst>
alternatively I could just DCE the CL SPIR-V a little
<airlied>
karolherbst: they've been adding exts to spirv for yearsn ow
<karolherbst>
heh...
<airlied>
not sure they've covered it all yet
<airlied>
like clvk/clon12 has limitations, mostly called works with photoshop, who cares after that
<karolherbst>
true
<karolherbst>
anyway, I don't really want to drop support for gallium, so it's either layering inside rusticl or using zink (by either using VK or CL spir-v)
<karolherbst>
in the end it's more of a question if the overhead of using zink actually matters of if we can just fast path everything
<karolherbst>
passing in the SPIRV directly is the smallest issue to solve
<karolherbst>
new shader type, big deal
<airlied>
karolherbst: yeah solving the gallium api mismatches is just going to be trickier
<airlied>
like may as well add proper buffer<->image copies while you are there :-P
<karolherbst>
yeah...
<karolherbst>
though we could teach resource_copy_region to just accept that :P
<karolherbst>
or do a blit
<karolherbst>
though I suspect a blit is already supported? or can't you blit to/from a buffer?
<zmike>
can't blit
<karolherbst>
mhhh
<karolherbst>
PIPE_CAP_CAN_BLIT_BUFFER
<karolherbst>
problem solved
<zmike>
but zink already handles buffer<->image in resource_copy_region so that gets my vote
<karolherbst>
ahh, cool
<karolherbst>
cool
<karolherbst>
yeah, then let's just do that
<karolherbst>
for me it's removing an if :)
<karolherbst>
zmike: do we have a CAP for it already?
<zmike>
doubt
<zmike>
imo just yolo it
<karolherbst>
k.. could add one once we got to it
<zmike>
drivers supporting rusticl will do it
<zmike>
and others won't
<zmike>
doesn't need a cap
<karolherbst>
mhhh
<karolherbst>
maybe
<jenatali>
karolherbst: I thought you already have CL conformance... how if you don't have some of these basic things hooked up? Just slow paths?
<karolherbst>
jenatali: doesn't matter on iris
<karolherbst>
that's really just important for discrete GPUs now
lygstate has joined #dri-devel
<jenatali>
Uh... there's a CL api command for buffer <-> image copies?
<karolherbst>
there sure is
<karolherbst>
but yeah, that one is a sw copy at the moment :)
<jenatali>
I see
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<linkmauve>
I profiled some application startup and shader hashing using SHA-1 was amongst the top most used functions, then wrote https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18644 but perhaps it’d be better to use a faster hash function instead?
<zmike>
ccr: this is the one.
<zmike>
I can feel it.
rasterman has quit [Quit: Gettin' stinky!]
<linkmauve>
Would it be an issue to change the hash values for every single user across the codebase? Or to use a non-cryptographically “secure” algorithm (SHA-1 is not considered secure any longer, but for any purpose in Mesa it is)?
<linkmauve>
I’m thinking about xxHash3 instead, which is faster than SHA-1 in every situation.
<linkmauve>
This could also help on non-ARM platforms, although on x86 it doesn’t seem to be such a hot spot.
<linkmauve>
Scratch that, it’s still about 2% of the startup time of the same GTK 4 application.
<linkmauve>
(Which is much lower on my laptop than on my phone, so still comparatively less of an impact.)
<airlied>
jenatali: mem to image copies are effectively that
iive has quit [Quit: They came for me...]
mbrost has quit [Ping timeout: 480 seconds]
loki_val has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
sigmaris_ has quit [Ping timeout: 480 seconds]
sigmaris has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
ybogdano has quit [Read error: Connection reset by peer]