<airlied>
well it's more if you can take out the system if you happen to do it at the wrong time
<karolherbst>
ahh yeah
Guest1364 has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: I am not waiting forever though
<karolherbst>
ehh, on the fence I do
<karolherbst>
anyway, yes, there is no timeout
Surkow|laptop has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
<Kayden>
mattst88: Yeah, I think that was it...every thread could have its own generation-specific table. I can't really figure out why anybody would care about that feature though
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
<Kayden>
hmm, he was adding support for mapping hw opcode <-> IR opcode enum both ways
<Kayden>
since some opcodes started aliasing, where the same number meant one thing on one gen and another thing on a different one
<Kayden>
IIRC we suggested putting the tables in brw_compiler at the time but we might have had to plumb it through some places so he just went with TLS tricks
<Kayden>
I think it's pretty clearly just "clever" and not really necessary
cheako has quit [Quit: Connection closed for inactivity]
<zmike>
mareko: pointsize should be done now when you get a min
<airlied>
Kayden: yeah that's pointlessly clever
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
DanaG has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
eukara_ has quit []
ppascher has joined #dri-devel
<mattst88>
Kayden: oh yeah, that sounds familiar. I think it was about possibly loading the driver for 2 distinct GPU gens (since discrete is a thing) in the same process (???)
<Kayden>
that's also possible
<Kayden>
but very speculative, since said drivers have their own screens and own brw_compilers and there are a million other things that don't do this
<Kayden>
I haven't heard yet why it's an actual problem
<Kayden>
but it does seem like something we could change if we wanted
<airlied>
yeah seems like something you could just store in brw_compiler as a pointer
aravind has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
shankaru has joined #dri-devel
DanaG has quit [Remote host closed the connection]
DanaG has joined #dri-devel
natto has quit [Remote host closed the connection]
natto has joined #dri-devel
Duke`` has joined #dri-devel
mclasen has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
mclasen has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
mhenning has quit [Quit: mhenning]
agd5f has quit [Ping timeout: 480 seconds]
sdutt_ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
danvet has joined #dri-devel
mbrost_ has quit []
jewins has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
maxzor has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
DanaG has quit [Remote host closed the connection]
DanaG has joined #dri-devel
frieder has joined #dri-devel
macromorgan is now known as Guest1380
macromorgan has joined #dri-devel
mszyprow has joined #dri-devel
paulk1 has quit [Ping timeout: 480 seconds]
Guest1380 has quit [Read error: Connection reset by peer]
jkrzyszt_ has joined #dri-devel
ahajda_ has joined #dri-devel
MajorBiscuit has joined #dri-devel
Major_Biscuit has joined #dri-devel
lemonzest has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
paulk1 has joined #dri-devel
tursulin has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
tobiasjakobi has joined #dri-devel
tarceri has quit []
camus has quit []
camus has joined #dri-devel
tarceri has joined #dri-devel
h0tc0d3 has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
lynxeye has joined #dri-devel
ella-0 has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
ella-0_ has quit [Read error: Connection reset by peer]
hansg has joined #dri-devel
pcercuei has joined #dri-devel
maxzor has quit [Remote host closed the connection]
toolchains has joined #dri-devel
asocialblade has quit [Ping timeout: 480 seconds]
<danvet>
javierm, something went wrong, the revert patch is empty for me?
<danvet>
in your resend pile
<danvet>
but also since that patch is authored by me your sob counts as implied review anyway :-)
apinheiro has joined #dri-devel
<javierm>
danvet: yeah, I'll add my Reviewed-by in the next version. Since I did in fact review it :)
<javierm>
danvet: unsure why it was empty... I got it correctly on my inbox
<javierm>
but I saw the same issue before, Chen-Yu's patches were all empty on my RH inbox but could read it from my personal inbox
<danvet>
hm maybe fdo misdelivered and lore picked up the one it got from lkml?
<javierm>
danvet: ah, that could be indeed
<javierm>
danvet: ah, btw. Checkpatch complains about your revert patch
<javierm>
WARNING: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
<danvet>
ah yes I'm evil
<javierm>
do you mind if I fix that in the next revision?
<danvet>
yeah you can
<javierm>
or it's OK to keep it as is ?
<danvet>
I just sob them with both
<javierm>
ah, Ok will do that
<danvet>
i.e. pls keep the intel one, they have the copyright on this stuff :-)
<javierm>
danvet: sure, will add both
<javierm>
danvet: btw, if there's a v2 patch series that I reviewed already and nobody else chimed in for v1, how long should I wait to push it to drm-misc-next ?
<javierm>
I would like to land ASAP so I could rebase my ssd130x SPI series on top
Haaninjo has joined #dri-devel
<danvet>
javierm, oh for drivers I wouldn't wait that long really
<danvet>
especially when it's all reviewed
<danvet>
the 1-2 weeks is more a rule of thumb for shared code or where you expect others might want to chime in
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
<javierm>
danvet: ah, Ok. I'll wait a day or two then and land it
<danvet>
javierm, well if v1 is a few days ago already imo just go ahead and land v2
<javierm>
danvet: roger that
sdutt_ has quit [Ping timeout: 480 seconds]
hansg has quit [Quit: Leaving]
<ifreund>
I can reliably reproduce an amdgpu hang/crash during a specific boss fight in elden ring played through steam's proton. I'm assuming there's a buggy shader used by the game there, but I'd like it if amdgpu recovered properly. I see several issues on the mesa tracker that seem similar but no real resolution.
<ifreund>
since I seem to have 100% reliable reproduction, is the any information I can collect to make debugging/fixing this easier?
<javierm>
ifreund: '[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!' seems to be the issue, the question is why timed out
<javierm>
ifreund: echo 0xff > /sys/module/drm/parameters/debug will give you more debug output
toolchains has quit []
toolchains has joined #dri-devel
<ifreund>
thanks, will get new logs with that
shankaru has quit [Quit: Leaving.]
<ifreund>
well, enabling debug output seems to have made the bug not reproduce, I love race conditions
<ifreund>
at least I can carry on with the game now I guess :/
<javierm>
ifreund: fun
flacks has quit [Quit: Quitter]
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
flacks has joined #dri-devel
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
devilhorns has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
<emersion>
ifreund: timeouts are sometimes due to driver bugs, sometimes to sync bugs in the vulkan client, afaik
toolchains has joined #dri-devel
<emersion>
ifreund: have you tried with mesa-git?
<emersion>
(driver bugs → user-space driver bugs i mean)
tobiasjakobi has quit []
icecream95 has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
<ifreund>
emersion: no, i was using 21.3.7. If it happens again I will investigate further
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
Company has joined #dri-devel
toolchains has quit [Remote host closed the connection]
caef^ has quit [Remote host closed the connection]
shankaru has quit [Quit: Leaving.]
deathmist has quit [Remote host closed the connection]
deathmist has joined #dri-devel
itoral has quit [Remote host closed the connection]
apinheiro has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
mclasen has quit [Ping timeout: 480 seconds]
<javierm>
mripard[m]: did you notice that vc4 is broken with latest drm-misc-next ?
<javierm>
don't know if Christian König is here to double check that patch
<javierm>
mripard[m]: nvm, I asked him in the list
mclasen has joined #dri-devel
shankaru has joined #dri-devel
fxkamd has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
tzimmermann_ has quit []
toolchains has joined #dri-devel
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
rakko_ has joined #dri-devel
sdutt has joined #dri-devel
mbrost has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
oakk has quit [Ping timeout: 480 seconds]
<bcheng>
hey jekstrand, in ca791f5c it looks like from_wsi is never set. shouldn't it be set in anv_image_init bsaed on the presence of WSI_IMAGE_CREATE_INFO_MESA?
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
kts has joined #dri-devel
iive has joined #dri-devel
<jekstrand>
bcheng: Uh... maybe? From the comment, it looks like that was just to avoid an assert.
<jekstrand>
So if it's not asserting, we can drop the whole from_wsi bit
khfeng has quit [Remote host closed the connection]
khfeng has joined #dri-devel
<bcheng>
its not asserting because its never gets set to true, so it doesn't really serve a purpose atm
ced117 has quit [Ping timeout: 480 seconds]
paulk1 has quit [Ping timeout: 480 seconds]
<bcheng>
and since it doesn't do anything meaningfull, I was just wondering if we should use it as intended (by setting it somewhere) or just drop it
<jekstrand>
IMO, we should drop it unless proven otherwise.
<jekstrand>
There are cases on TGL where we may need it in future but we can drop it for now.
khfeng has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom1 has quit []
lynxeye has quit [Quit: Leaving.]
thellstrom has quit [Ping timeout: 480 seconds]
guru_ has quit []
oneforall2 has joined #dri-devel
eukara has joined #dri-devel
ybogdano has joined #dri-devel
paulk1 has joined #dri-devel
DanaG has quit [Remote host closed the connection]
DanaG has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
rgallaispou has left #dri-devel [#dri-devel]
kts has joined #dri-devel
h0tc0d3 has quit [Remote host closed the connection]
h0tc0d3 has joined #dri-devel
Duke`` has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
<zmike>
ccr: what do you think about putting up a MR with your python trace stuff?
<zmike>
seems like it would be a good addition
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<jekstrand>
mareko, Kayden: Is there a PIPE_BIND flag for ensuring something is CPU-visible (i.e., can be mapped)?
<jekstrand>
I'm not seeing one but I don't really understand how all that works.
<jekstrand>
Trying to figure out what to do with CL_MEM_ALLOC_HOST_PTR
<zmike>
jekstrand: it's not a bind flag
<zmike>
it's uhh... PIPE_USAGE?
<zmike>
there's DYNAMIC, STAGING, IMMUTABLE, ...
<jekstrand>
Yeah, that's a heuristic thing. This is a capability thing.
<jekstrand>
Or maybe gallium assumes everything is mappable all the time?
<zmike>
correct
<zmike>
up to drivers to handle it
<jekstrand>
Ideally, I'd like it to be something where, if you can't get a direct map (i.e., it might require a bit), the allocation would fail.
<jekstrand>
I think
<jekstrand>
I'm still not sure I grok what CL is doing there.
<zmike>
use the NO_WAIT flag?
<mareko>
jekstrand: dealing with invisible VRAM?
<jekstrand>
mareko: Trying to make sure CL can request visible VRAM
<jekstrand>
I'm not dealing with an actual problem yet besides looking at the spec and trying to figure out how to map it to gallium.
<mareko>
there is no such flag, but mapping a buffer for CPU access should force it into a VRAM; if you set the persistent resource flag, the driver will map it directly, else it will map it using a temporary copy
<mareko>
*into visible VRAM
toolchains has joined #dri-devel
<zmike>
could always create the resources as STAGING? pretty sure every driver will give you something directly mappable then :D
<jekstrand>
mareko: Ok, so maybe I want to turn MEM_ALLOC_HOST_PTR into "always set MAP_PERSISTENT"? That would probably work.
* jekstrand
is too used to Vulkan where these things are explicit and not the GL world of "just do a thing; it'll work, promise."
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ppascher has joined #dri-devel
zf has joined #dri-devel
rakko_ has quit []
oakk has joined #dri-devel
toolchains has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<DanaG>
huh, there's a new package, libglx-amber0. What the heck is amber?
<jekstrand>
It's old drivers that have been discontinued from main Mesa development.
<jekstrand>
You probably don't have any hardware that requires amber.
<DanaG>
The package description didn't really describe that at all, it just gave generic stuff about what Mesa is.
<jekstrand>
Someone should probably fix that....
<DanaG>
There's an aarch64 package of it for some reason; the only .so file in it is: /usr/lib/aarch64-linux-gnu/libGLX_amber.so.0.0.0
mbrost has joined #dri-devel
<DanaG>
`strings` of that file includes: Override the DRI driver to load i830 i965 crocus iris radeon r200 r300 r600 radeonsi nouveau_vieux nouveau virtio_gpu
<DanaG>
Old drivers, you mean things like S3 Savage and old ATI Rage and such?
<DanaG>
Now I'm picturing somebody putting an ancient GPU in an ARM box... doubt it would work, given the lack of EFI.
<kisak>
DanaG: Mesa 22.0.0 dropped support for "classic" (non-gallium based OpenGL) drivers. The mesa 21.3 release branch has been fitted with an amber mode to allow it to slot in beside a newer mesa build to fill that missing support.
devilhorns has quit []
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
<Kayden>
it's not old as in S3/Rage/etc - those DRI1 drivers were dropped long ago
<Kayden>
amber is all the classic drivers
Major_Biscuit has quit [Ping timeout: 480 seconds]
<DanaG>
I see, like the ones shown in `strings`.
<DanaG>
Is nouveau non-gallium? If so, what's the gallium one? Or does the strings output show gallium ones too?
<jekstrand>
There's an old nouveau that's classic
<jekstrand>
But modern nouveau is gallium
shankaru has quit [Quit: Leaving.]
<Kayden>
seems like it's showing gallium ones too...radeonsi, iris, crocus, etc should come from upstream mesa still, not the amber branch.
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
anujp has joined #dri-devel
<DanaG>
Yeah, I wonder why those are in strings? But maybe they're just coming from a list of known args of things, rather than from the actual modules.
<DanaG>
Weird, vulkaninfo is crashing on my arm64 machine (Radeon WX 4100 in the PCIe slot). http://dpaste.com//6S43TAHTE
<ajax>
yes, just the list of known drivers on that branch
<ajax>
we haven't nerfed the rest, but -Damber=true builds won't try to build them
gouchi has joined #dri-devel
rasterman has joined #dri-devel
samuelig_ has quit []
samuelig has joined #dri-devel
nanonyme has joined #dri-devel
<nanonyme>
Hey, would anyone be able to explain, what is this _XkeyTable thing actually that keeps getting flagged in our ABI tests for libX11? Is it something super-internal or is it a problem its size keeps changing?
<ajax>
not a problem as long as it doesn't shrink
<ajax>
and not, in fact a problem, it's only declared in a non-sdk header, any non-libX11 code that touches it is already in a state of sin
<nanonyme>
Okay, sounds like with 99% certainty to the purpose we run ABI checks at all it can be completely ignored.
<nanonyme>
I guess this is same category where various other projects use symbol version FOO_INTERNAL and whatnot
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
<ajax>
yeah. the problem is nobody wants to actually go through libX11 and fix visibility for non-sdk things, both because it's boring and because libX11 is such a long-baked de facto abi that you're just going to cause yourself problems
<nanonyme>
That's fair. Thanks, this allows us to keep updating libX11
aravind has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
<zmike>
dcbaker: ping re: #6269
<zmike>
any thoughts on this?
heat has joined #dri-devel
toolchains has joined #dri-devel
<jekstrand>
Kayden: Struggling with iris_map_copy_region. It doesn't seem to support writes. Am I crazy?
toolchains has quit [Ping timeout: 480 seconds]
* jekstrand
is very confused
<nchery>
jekstrand: writes happen in iris_transfer_flush_region
toolchains has joined #dri-devel
<Kayden>
jekstrand: Yeah. map does an optional read of the existing data into the staging area. unmap writes any updated data back
Sachiel has quit [Quit: WeeChat 3.4]
<Kayden>
iris_transfer_flush_region also lets you write back things early
<Kayden>
iris_flush_staging_region does the actual write
Sachiel has joined #dri-devel
<jekstrand>
Ok, that makes sense. I didn't realize there was another stage
kts has quit [Quit: Konversation terminated!]
ngcortes has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
toolchains has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
toolchains has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
h0tc0d3 has quit [Remote host closed the connection]
toolchains has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Found another flush bug
* jekstrand
needs to read more about opencl queues
mclasen has joined #dri-devel
<jekstrand>
karolherbst: Ok, so CL queues are pretty much like Vulkan queues.
<jekstrand>
karolherbst: I'm starting to wonder if we don't want to require all drivers that want to do CL things to support syncobj and use that for events.
<jekstrand>
Then you really could have, say, to AMD cards going at the same time and synchronizing back-and-forth without having to stall in userspace between things.
<jekstrand>
*two
nchery has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
toolchains has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<jenatali>
jekstrand: You can have an unlimited number of CL queues though, where Vulkan has caps to report how many there are
<jenatali>
I couldn't map them to D3D queues in any kind of sane world, I had to completely virtualize them and only translate to D3D when the queues actually drain to the "device"
<karolherbst>
jekstrand: we have to stall in userspace anyway
<karolherbst>
there are still user events where we block on the application marking an event as done
<karolherbst>
and what if we do some stuff in sw only?
<karolherbst>
jekstrand: also, I am still super unhappy about the helper context situation. Currently what I am doing with the pipe_transfers is not thread safe at all :
<karolherbst>
:/
toolchains has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<jekstrand>
jenatali: Yeah, maybe. Vulkan (and probably D3D) are weirder than they need to be there, though. And, yeah, we may need to virtualize.
<jenatali>
D3D doesn't have a limited number, but yeah it's still not quite a good enough mapping
<jekstrand>
karolherbst: Application marking an event as done can be done with syncobj too.
<karolherbst>
mhhh
<jekstrand>
You just need each event to start off in the reset state and have the queue wait until the point has materialized.
* jekstrand
really needs to write that kernel patch.
<karolherbst>
I suppose we don't have gallium interfaces for that yet, right?
<jekstrand>
karolherbst: Uh... maybe? There's something for GL <-> Vulkan sharing but I don't know how it works.
<jekstrand>
We could also use sync_file
<jekstrand>
That might be easier, actually.
<jekstrand>
As long as we don't worry about running out of files.
<karolherbst>
I have no idea about those kernel interfaces anyway
<airlied>
let's not use sync_files
<airlied>
unless things are going inter-process
<jekstrand>
I think binary syncobj is what we really want
<karolherbst>
jekstrand: what's the big problem with gallium fences though?
ngcortes has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Can you share them between devices?
<karolherbst>
I don't think so
<jekstrand>
There's your problem. :P
<karolherbst>
jekstrand: how we are making sure we follow the event status thing though?
<jekstrand>
What do you mean?
<karolherbst>
CL has this weird req that previous events have to be CL_COMPLETE before you can even submit them to the hardware.. well.. according to the spec
<karolherbst>
I think it's all stupid, but....
<airlied>
that sounds like the same thing as vulkan has for semaphore signalling
<karolherbst>
airlied: sure, but that doesn't happen on literally all operations, does it?
<airlied>
yes you have to submit the thing that signals the semaphore before you submit the thing that waits on it
<karolherbst>
I can't even imagine how people looked at the CL spec and thought "ahh yeah, that's great for throughput if _all_ events have to be finished on the hw before we start submitting new ones"
<karolherbst>
airlied: ohh sure, but for CL this is valid for _all_ events
<karolherbst>
not just dependencies
<karolherbst>
only _one_ event is CL_RUNNING
<karolherbst>
or well CL_SUBMITTED
<airlied>
you really don't want the hw blocking on a spinlock
<airlied>
esp a user controlled spinlock
apinheiro has joined #dri-devel
<karolherbst>
I know
<airlied>
it makes things very difficult :-P
<karolherbst>
well
<karolherbst>
I am just saying what the CL spec says
<airlied>
I think some of those concepts were concieved when someone thought that was a good idea :-
<airlied>
:-P
<karolherbst>
before you can start working on an event, all previous ones have to be complete
<karolherbst>
:D
<karolherbst>
yeah, hence me saying it's all stupid
<jekstrand>
karolherbst: spec text?
<jekstrand>
Something I can search for?
<karolherbst>
kind of the entire "5.11. Event Objects" section
* jekstrand
reads
<karolherbst>
the problem is, you can even install callbacks
<karolherbst>
which listens on events going from one to another status
<karolherbst>
and the CTS verifies some stuff there
<karolherbst>
so we can't even bend the rules unlimited
<karolherbst>
ahh well and there is "5.12. Markers, Barriers and Waiting for Events" as well
<karolherbst>
markers and barriers only matter for out of order queues though
<airlied>
"There is no guarantee that the callback functions
<airlied>
registered for various execution status values for an event will be called in the exact order that
<airlied>
the execution status of a command changes"
<karolherbst>
yeah, the order doesn't matter
adjtm has quit [Read error: Connection reset by peer]
<karolherbst>
there is one problem
<karolherbst>
you are only submit when everything previously + deps are completed
<karolherbst>
but you can't flush, because that would mean if something fails previously you would change state
<karolherbst>
so you kind of have to wait
<airlied>
it's pretty much what syncobjs and the kernel scheduler do
Daaanct12 has joined #dri-devel
<karolherbst>
can't flush a kernel call to hw if you are not sure that previous stuff completed
danvet has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: okay, so you can submit something and revoke the submission if some operation failed?
<karolherbst>
like if you have a user event in the middle and it gets set to an error state
<airlied>
nope, you just say it relies on this other thing, don't send it to hw, and if something fails you lost context
<airlied>
like failing seems like a pretty big thing to happen here, like a GPU crash
<karolherbst>
so I'd have to kill the entire context if the user event gets an error state?
<airlied>
seems about right
<karolherbst>
ehhh mhh
Haaninjo has quit [Quit: Ex-Chat]
<jenatali>
karolherbst: Yeah I originally tried to write something that would be more efficient and batch together a chain of dependent commands into a single stream, but ended up following the spec text exactly and only submitting non-dependent work together at the same time
<karolherbst>
airlied: doesn't really sound like something we want to use then?
<karolherbst>
jenatali: yeah... CL is just broken in this regard sadly
* airlied
isn't sure what you think should gracefully degrade here
<karolherbst>
airlied: dependencies
<karolherbst>
ehh
<karolherbst>
the other thing
<airlied>
like why does a dependency fail?
<karolherbst>
airlied: so in a perfect world, you have like 10 CL events with work attached and you just flush it out to the hardware
<karolherbst>
and everything is fine, because you know, nothing fails in a perfect world
<karolherbst>
so you can just cheat and mark the status of those events according to the spec
<airlied>
if they have dependencies you probably never flush it all out to the hw
<karolherbst>
_but_ now you have user events
<karolherbst>
and user events are in the control of the application
<karolherbst>
airlied: why not?
<airlied>
yeah if you have a user controlled thing, you probably ain't sending it to hw at all
<karolherbst>
airlied: but the user thing depends on stuff and other things depend on that
<airlied>
karolherbst: because we learned that gpu semaphores are a bad idea
<airlied>
and wrote a gpu scheduler
<karolherbst>
but that's a different thing, isn't it?
<airlied>
no events are pretty much semaphores
<airlied>
you have one command stream with a wait for event, other command stream with a signal event
<karolherbst>
I can just call 5 times launch_grid in gallium, and I can rely on that things happen in order, no?
<airlied>
you submit both of them to separate queues in theory and they sync up
<airlied>
on the hw
<airlied>
in practice you should submit them to a gpu scheduler and it does the ordering
<karolherbst>
ehh, but I am only talking about one command stream and one queue
Daanct12 has quit [Ping timeout: 480 seconds]
<jekstrand>
Yeah, I'm not seeing why CL events are any different than some smashing together of VkFence and VkSemaphore.
<karolherbst>
if you have multiple, sure, you have to sync and everything
<karolherbst>
but the case with just one queue is already bonkers
<airlied>
like if you set a user event and the user never signals it, you blow away the context
<airlied>
just like we do for vk events
<karolherbst>
CL doesn't know timeouts
<airlied>
but yeah it's also fine to just not submit it to hw at all
<airlied>
and wait for the user to signal it before you do
<airlied>
because I doubt anyone cares about optimallity in this path
<karolherbst>
right
<karolherbst>
but then we have to wait on the CPU side anyway, no?
<airlied>
yes
<airlied>
we always have to wait on the CPU side, waiting on the GPU is never a good idea
<karolherbst>
right
<karolherbst>
but that's kind of what I am doing atm anyway
<karolherbst>
not waiting until thre is a need to
adjtm has joined #dri-devel
<karolherbst>
I think I am not really getting the point what syncobjs or something else would win us here
<karolherbst>
so what would it change/improve?
<karolherbst>
(also I am sure, that drivers will use synbobjs for gallium fences internally anyway, no?)
<jekstrand>
What it buys us is moving the CPU waiting closer to the hardware.
<jekstrand>
Into the kernel, in particular.
<karolherbst>
but the driver can do that
<jekstrand>
Not cross-device
<jekstrand>
Or even cross-cl_queue
<jekstrand>
(ok, maybe if we're virtualizing)
DanaG has quit [Remote host closed the connection]
DanaG has joined #dri-devel
rasterman has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
<jekstrand>
As far as callbacks go, I'm not that worried. We can kick off a thread that waits, fires the callbacks, and then dies.
<jekstrand>
But I think the bigger problem to fix is default context usage
<jekstrand>
Right now, we're using it for all maps. We need to only use it for cl_mem initialization and nothing else.
<karolherbst>
yeah...
<karolherbst>
I honestly have no good solution here, because pipe_contexts are not thread safe at all
<karolherbst>
and CL applications can do queue stuff on every thread and assume it's all thread safe
<karolherbst>
also
<jekstrand>
So we have a thread per queue which manages the pipe_context
<karolherbst>
ehh no
<jekstrand>
Or we lock around the pipe_context
<karolherbst>
jekstrand: yes.. but you have to return the ptr
<jekstrand>
For maps?
<karolherbst>
yes
<jekstrand>
Yup. So we have to synchronize.
<karolherbst>
so we can't just push a task to the worker thread, because we need the result
<karolherbst>
yeah...
<karolherbst>
thing is
<karolherbst>
there are also non blocking maps
<jekstrand>
How are those expected to work?!?
<karolherbst>
they don't flush the queue?
<karolherbst>
we have a PIPE_MAP flag for that
<airlied>
you get an event back and the map is on valid once the event is set
<karolherbst>
but...
<airlied>
so you'd really have to queue up the maps rather than asking for them
<karolherbst>
airlied: sure, you still need the pointer and for that a pipe_context
<jekstrand>
I mean, we could mmap(MAP_ANONYMOUS) to get some VA space and then hand that to the gallium map function somehow.
<karolherbst>
jekstrand: maybe
<jekstrand>
There are two other options:
<karolherbst>
I kind of like the idea of a worker thread, because throughput and we don't have to lock around a pipe_context... but....
<jekstrand>
1. Do a persistent map which is immediate and trust the client not to touch it. This only works for buffers, probably.
<jekstrand>
2. Create a temporary which we can persistently map, schedule a blit to that, and then return the mapped pointer.
<karolherbst>
we can't
<karolherbst>
map has to return the host ptr if that was used
<karolherbst>
so no temporary in that case
<jekstrand>
Yeah, so we short-circuit in that case
<jekstrand>
That's case 1
<karolherbst>
we could use PIPE_MAP_UNSYNCHRONIZED ...
<karolherbst>
like always
Duke`` has quit [Ping timeout: 480 seconds]
<jekstrand>
Yup
<jekstrand>
So for HOST_PTR, we return the host pointer. Else, for buffers, we MAP_UNSYNCHRONIZED always. Else, we make a temporary and schedule a blit.
<karolherbst>
ehhh
<karolherbst>
I don't like that temporary part :p
<jekstrand>
What do you think iris is doing for image maps?
<karolherbst>
drivers internally can do whatever they want :D
<jenatali>
Yep that's what I did
<jenatali>
I also have a single worker thread managing a context, and all the queues push work into a pool that the worker thread pulls from
<jekstrand>
Gallium is an immediate API. OpenCL isn't. We're going to have to do some drivery things.
<karolherbst>
jekstrand: there is one annoying thing about UNSYNCHRONIZED: "It should not be used with PIPE_MAP_READ."
<jekstrand>
karolherbst: *should*
<karolherbst>
:D
<karolherbst>
okay
<karolherbst>
fine
<jekstrand>
karolherbst: That's because it's likely going to be a write-combined pointer which is going to suck for perf on discrete cards.
<karolherbst>
right
<jekstrand>
That's where the create hints come in.
<karolherbst>
jenatali: okay, so for non blocking maps you create a temporary buffer and all that?
bbrezillon has quit [Ping timeout: 480 seconds]
<jenatali>
Yep
<karolherbst>
mhhh
<karolherbst>
I guess we could do that
<jekstrand>
If we flag it as an upload resource, we'll probably get write-combine. If we flag it as a download resource, we'll probably get something stuck in system RAM which will suck from the GPU a bit but otherwise be fine.
<jenatali>
D3D doesn't have as much flexibility here anyway, we don't currently expose CPU-accessible vidmem
<jekstrand>
We can also do temporaries for buffers for read/write maps
<jekstrand>
And only do unsynchronized for write-only
<karolherbst>
yeah.. somebody or I need to optimize that flag situation anyway sooner or later
<jekstrand>
But integrated cards really want us to use PERSISTENT for everything.
<karolherbst>
jekstrand: can't we use PIPE_MAP_UNSYNCHRONIZED | PIPE_MAP_DONTBLOCK always?
<karolherbst>
although that still doesn't help with what context to use..
<karolherbst>
the non blocking case is what's annoying anyway
<nanonyme>
Is there btw any agreement on how to handle LLVM-support with Mesa amber? Is the intent that at some point amber and new releases will require different LLVM versions?
<jekstrand>
nanonyme: No amber drivers use LLVM.
<karolherbst>
okay.. so 1. if hostptr return hostptr, 2. if blocking do tricks with the event task and wait on that to get the ptr 3. if non blocking create a temporary resource and blit to that?
<airlied>
except the GL_SELECT path :-P
<jekstrand>
Yeah....
<jekstrand>
But that works on basically any LLVM version
<nanonyme>
jekstrand, oh, it's *that* old? Well, that's a relief
<airlied>
jekstrand: the question is if we have to maintain amber for newer llvm
<jekstrand>
karolherbst: Roughly?
<jekstrand>
karolherbst: We may want a gallium cap for "are unsynchronized map reads fast?" and change behavior based on that.
<karolherbst>
ehh I guess for third we just allocate mem and transfer it in the queue
<karolherbst>
*into it
<nanonyme>
airlied, right, was asking with packager hat on
<karolherbst>
ehh wait...
<karolherbst>
no, that's fine.. we deallocate on unmap then
ybogdano has joined #dri-devel
<karolherbst>
jekstrand: yeah.. let me try to hack something up over the weekend then, got some ideas on how to do that without being too ugly
<jekstrand>
karolherbst: Cool
<jekstrand>
karolherbst: FYI, I pushed another patch to my rusticl/wip branch to fix more context flushing issues. :-/
<jekstrand>
I hate it but it fixes a real bug. I'm down to two known test_basic fails on iris now
<jekstrand>
I'm going to attack the libclc bug now
<karolherbst>
yeah, I saw it
<karolherbst>
but that's going to be fixed by the above anyway
<karolherbst>
ehh well
<karolherbst>
I'd consider it when fixing all of that
<karolherbst>
(or it needs to change regardless)
<karolherbst>
jekstrand: what I don't like is, that we sometimes use pointers for HashMap keys :/
<karolherbst>
I think I'd really just use Arc<...>s for now, they are relatively cheap and just a pointer interally anyway. I was thinking about using references but that's like super ugly
<karolherbst>
ohhh.. I think I might be able to use a Vec instead for that...
<karolherbst>
mem objects aren't as annoying as program/kernels so we can rely on a device list from the context, mhhh
<karolherbst>
yeah.. I see a bigger project for the weekend :D
<jekstrand>
I don't see a way around having a HashMap which maps map pointers to the underlying pipe_transfer_map and relevant stuff.
<jekstrand>
At least not for images and other cases where we don't just use the host pointer and/or a persistent map
<karolherbst>
jekstrand: I was more refering to Mem.res
<jekstrand>
Yeah...
<karolherbst>
I am annoyed by the unsafe { **d } we do for the helper ctx :p
<jekstrand>
Yeah, that's not great
ngcortes has joined #dri-devel
<karolherbst>
but I think I can just use a vec and do mem.res.iter().zip(mem.context.devices) and get a (resource, device) thing, but that sucks in the kernel case where we need a resource for a particular device
<karolherbst>
maybe I just use Arc and call it a day
gouchi has quit [Remote host closed the connection]
<karolherbst>
I'll experiment a little
mbrost has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
mbrost has joined #dri-devel
icecream95 has joined #dri-devel
<jekstrand>
Ok, have wait_group_events hacked. test_basic should complete now.
pcercuei has quit [Quit: dodo]
<jekstrand>
FAILED 2 of 112 tests.
sdutt has quit []
sdutt has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
khfeng has joined #dri-devel
mbrost has quit []
apinheiro has quit [Quit: Leaving]
toolchains has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
ahajda_ has quit [Read error: Connection reset by peer]
<jekstrand>
PASSED 112 of 112 tests.
<karolherbst>
:)
<karolherbst>
now to figure out the crashes with test_conversions and math_brute_force
tursulin has quit [Ping timeout: 480 seconds]
<karolherbst>
I am sure it's some 64 bit stuff
<karolherbst>
or maybe that map race
<karolherbst>
(well I assume there are races)
ybogdano has joined #dri-devel
mhenning has joined #dri-devel
<jekstrand>
Well, now that I have maps working....