<javierm>
mripard[m]: wonder if I should do what rob suggest, which is more correct from a hardware description POV even if could potentially cause issues on linux...
slattann has quit [Read error: Connection reset by peer]
frieder_ has quit [Ping timeout: 480 seconds]
kj has quit [Quit: Page closed]
kj has joined #dri-devel
frieder_ has joined #dri-devel
Major_Biscuit has quit []
frieder_ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
frieder_ has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
mripard has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
frieder_ has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
frieder_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
thellstrom1 has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
frieder_ has quit [Ping timeout: 480 seconds]
frieder_ has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
frieder_ has quit []
frieder has joined #dri-devel
mclasen has joined #dri-devel
linkmauve has left #dri-devel [#dri-devel]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
<pepp>
airlied: thanks, I'll take a look
lygstate_ has joined #dri-devel
shashank_s has joined #dri-devel
flacks has quit [Quit: Quitter]
bbrezillon has joined #dri-devel
mripard has joined #dri-devel
flacks has joined #dri-devel
shashank_sharma has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
thellstrom has quit [Read error: Connection reset by peer]
linkmauve has joined #dri-devel
linkmauve has left #dri-devel [#dri-devel]
itoral has quit [Remote host closed the connection]
linkmauve has joined #dri-devel
itoral has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kchibisov has quit [Read error: Connection reset by peer]
itoral has quit [Read error: Connection reset by peer]
kchibisov has joined #dri-devel
itoral has joined #dri-devel
MajorBiscuit has joined #dri-devel
maxzor has joined #dri-devel
<shadeslayer>
Hi, does someone know how to insert layout qualifiers with N
<shadeslayer>
*NIR
<dj-death>
shadeslayer: usually on the nir_variable
<dj-death>
shadeslayer: what qualifier in particular?
<shadeslayer>
early_fragment_tests , anv is constructing a blorp shader and I'd like to insert a early_fragment_tests qualifier in the blorp shader to see if that helps with fixing the early_fragment_test cts fails
<jani>
hwentlan____: hey, I'm trying to figure out what the "aconnector->base.override_edid = false/true" in amd/display/amdgpu_dm/amdgpu_dm.c are supposed to do. I'd just like to nuke them, because they complicate override edid handling. I traced them back to 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") but that's not really helpful. any thoughts?
<dj-death>
shadeslayer: in that case shader->info.fs.early_fragment_tests = true;
<shadeslayer>
ah if it's the same as just setting that to true, that didn't help
HankB__ has quit [Remote host closed the connection]
HankB__ has joined #dri-devel
itoral has quit []
ahajda has joined #dri-devel
fxkamd has joined #dri-devel
<javierm>
demarchi: I have a kmod question, suppose that there are two drivers that have the same module alias (i.e: an IC that supports both I2C and SPI, and there are different kernel drivers for each)
<javierm>
demarchi: would kmod load both modules or only the first one that matches ?
<javierm>
or udev, not sure which component handles this actually...
<arnd>
javierm: the module loading happens by 'modalias' property in sysfs, and this encodes the driver subsystem name
<arnd>
so it should only ever load the correct one
<arnd>
if the device is actually connected to both buses in a single system, it should load both drivers, and match the them correctly. I assume bad things would happen if you actually try talking to it on both at the same time though
shankaru has quit [Quit: Leaving.]
<javierm>
arnd: answered you in #armlinux since geert commented there too
cwebber has quit [Remote host closed the connection]
calebccff has quit []
anholt has quit [Ping timeout: 480 seconds]
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
calebccff has joined #dri-devel
lstrano has quit [Remote host closed the connection]
Kayden has quit [Remote host closed the connection]
Kayden has joined #dri-devel
lstrano has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
paulk2 has quit []
frieder has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Yeah, I'm aware of the bug.
paulk has joined #dri-devel
anholt has joined #dri-devel
<karolherbst>
mhhh.. I think I can drop the Arc around Pipecontext now
<karolherbst>
this would be nice
frieder has joined #dri-devel
<karolherbst>
ohh nice, it works :)
<karolherbst>
jekstrand: do you have any patches locally I should pick? Because I think you might want to rebase on my rusticl/wip_next branch or something
<jekstrand>
karolherbst: Have you picked up any of my rusticl/wip branch?
<karolherbst>
I am sure I picked all from the branch you pushed
<karolherbst>
some you might also just drop
<jekstrand>
Ok, I've not pushed anything since friday
<karolherbst>
like the flushing ones
<karolherbst>
okay
<karolherbst>
crash rate did came down quite significantly also with llvmpipe, so I think I actually fixed some races at least
mdroper has joined #dri-devel
<karolherbst>
jekstrand: btw, I found a solution without having to do shadow buffers for async maps, not sure if you've seen it
khfeng has quit [Ping timeout: 480 seconds]
<karolherbst>
but I also don't know how much drivers rely on a pipe_transfer to only being used from one context, because CL doesn't care at all as it seems
<jekstrand>
karolherbst: For persistent maps, there's no reason why we can't use the default CTX. For other maps, where the driver may blit, we have to juggle.
<jekstrand>
karolherbst: What do you mean by CL doesn't care about contextx? Are you allowed to enqueue a map on one queue and enqueue an unmap on a different one?
<karolherbst>
jekstrand: sure
<karolherbst>
at least I didn't see anything disallowing that
<jekstrand>
Oof
<jekstrand>
I mean, it does make some sense but oof
<demarchi>
javierm: the 2
<jekstrand>
If we do everything with persistent maps and manage the shadows ourself, it's not too much of a problem.
<karolherbst>
jekstrand: yeah soo.. I use the default ctx for non blocking a.k.a. PIPE_MAP_UNSYNCHRONIZED and the queue context for blocking ones
<demarchi>
javierm: an alias resolves for a list of modules, which are all loaded if that is the case
<jekstrand>
And I doubt driver-managed maps will actually be a problem in practice.
<karolherbst>
and use the used context for unmaping in both cases
<karolherbst>
*queues context
<demarchi>
javierm: /resolves for/resolves to/
<karolherbst>
jekstrand: thing is... persistent maps require persistent resources, which don't live in VRAM
<jekstrand>
karolherbst: Not sure if that works w/ iris or not. I'll have to look. I think iris stashes the context in the map.
<karolherbst>
so we wouldn't be able to place anything inside VRAM
<jekstrand>
karolherbst: They don't require things to not live in VRAM.
<karolherbst>
jekstrand: it does seem to work at least
<jekstrand>
They just require them to be coherent, i.e. no flushing on unmap.
<karolherbst>
jekstrand: right, but drivers don't put them there
<karolherbst>
at least nouveau and radeonsi put them into GART
<jekstrand>
karolherbst: Depends on the driver, probably. Likely, you have to do a write-only map or explicitly flag it as an upload resource to get VRAM.
<karolherbst>
yeah...
<karolherbst>
anyway.. I'd rather not use persistent maps if we don't have to
<jekstrand>
We definitely want to use them all the time on iris
<jekstrand>
On integrated, anyway
<javierm>
demarchi: gotcha, thanks a lot for the clarification. Then it's safe if two drivers have the same module aliases
<jekstrand>
On discrete, we need something more nuanced.
<karolherbst>
jekstrand: does it actually changes anything on iris?
<jekstrand>
I've not looked at what all controls you get from CL to make decisions about buffer placement.
<karolherbst>
none
<karolherbst>
there are WithProperties calls to create buffers, but CL doesn't define any properties
<jekstrand>
I'm not sure what all it changes on iris. Iris may optimize to persistent maps behind your back.
<karolherbst>
well.. there is CL_MEM_HOST_NO_ACCESS you can pass in
<karolherbst>
but that's like CL 1.2+
<karolherbst>
but in the end, the question is just what that gives us, it's not like CL knows persistent/coherent mappings anyway
<karolherbst>
so you need to unmap before doing real stuff with buffers
<jekstrand>
:-/
<jekstrand>
Yeah, CL does map/unmap rather than explicit flushes like Vulkan.
<jekstrand>
Which is a bit annoying.
<karolherbst>
yeah
<karolherbst>
if drivers prefer persistent mappings, we could add a flag, I just know that discrete ones don't :)
<karolherbst>
for images none of that matters, because images are usually not huge heaps of memory contrary to buffers
<jekstrand>
And images are almost always going to have to blit on map/unmap
<jekstrand>
Except in the weird USE_HOST_PTR case
<karolherbst>
so not really minding staging buffers for images, but for buffers that's a completely different story, so I want to prevent anything like that there
<karolherbst>
(and for images, drivers do the staging for us already)
<karolherbst>
jekstrand: soo.. what we could do is, to have a "please don't tile this image, because the host is going to read/write that one" and allow some fast paths
<karolherbst>
but that's in the "future optimizations" domain
<karolherbst>
but I think we already have a flag for that?
<jekstrand>
karolherbst: We always want to tile images unless we have a really good reason to do otherwise.
<karolherbst>
mhh
<karolherbst>
I guess
<jekstrand>
I mean, if they really badly want to scratch in an image from both GPU and CPU, it might be faster to leave it linear, but ugh.
<karolherbst>
yeah..
<karolherbst>
the annoying part is.. that stuff wasn't in CL from 1.0
<karolherbst>
and not even required to pass in
<karolherbst>
but if applications do use "CL_MEM_HOST_NO_ACCESS" a lot we could actually take that into account
<karolherbst>
but...
<karolherbst>
ohh
<karolherbst>
there is CL_MEM_ALLOC_HOST_PTR as well
<karolherbst>
I ignored it for now, but this essentially says "please allocate the resource in CPU accessible memory" completely forgot about that one
<karolherbst>
I guess if that is used, we can disable tiling
<karolherbst>
jekstrand: also.. I still have to think about how to implement 1D_BUFFER images
<karolherbst>
seems iris crashes are those two things: 1d_buffers and clear_buffer being broken
<karolherbst>
ehh and user_ptrs on 1d/3d/array images
<karolherbst>
uhm.. 3d and array
anujp has joined #dri-devel
<karolherbst>
jekstrand: uhmm.. also, could you look into why integer_ops integer_clz integer_mad_hi and integer_mul_hi are crashing?
pcercuei has quit [Read error: Connection reset by peer]
shankaru has quit [Quit: Leaving.]
mripard has quit [Quit: leaving]
pcercuei has joined #dri-devel
mripard[m] has quit []
mripard[m] has joined #dri-devel
<jekstrand>
karolherbst: Yeah, I think if they use CL_MEM_ALLOC_HOST_PTR, we can use psersistent maps and it always lives in system ram
<karolherbst>
yeah... sounds like a good idea
mripard[m] has quit []
mripard[m] has joined #dri-devel
lygstate_ has quit [Ping timeout: 480 seconds]
* karolherbst
fixes clCreateContextFromType
gawin has joined #dri-devel
<dj-death>
spirv allows you to do pretty awkward stuff
<dj-death>
apparently you can end a for loop and within that for loop, have an if/else block that goes out of it without breaking
Haaninjo has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<demarchi>
javierm: that depends on what the drivers do.... kmod can't know if it's safe or not
<javierm>
demarchi: yup I understand that. But kmod will happily list all modules and attempt to load them
<javierm>
for some reasons I thought that only the first match was loaded. But got confused by the fact that only a single module alias is supported
<karolherbst>
dj-death: structured spir-v is only required for non kernel spir-vs :)
frieder has quit [Remote host closed the connection]
<karolherbst>
jekstrand: mhh.. any idea how we can fix this "link kernels together" issue? I think the issue is that the linked spirvs don't list used variables on extern entrypoints after linking
apinheiro has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
rkanwal has joined #dri-devel
heat has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
aravind has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
sdutt has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
mbrost has joined #dri-devel
ybogdano has joined #dri-devel
<jenatali>
What's the problem?
sneil_ has joined #dri-devel
sneil has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
rasterman has joined #dri-devel
<karolherbst>
jenatali: the translator doesn't list them on extern entry pointers
<karolherbst>
ehh wait.. that has to do with called kernels
<karolherbst>
right.. linking won't add variables pulled in by the linked function
<karolherbst>
I think the translator actually does the right thing?
<karolherbst>
not sure
<karolherbst>
jenatali: do you have a workaround for that?
<jenatali>
What's the purpose of the variable list?
<karolherbst>
to declare input/outputs and with 1.4 everything
<jenatali>
Oh. I don't use 1.4, that's my workaround :)
iive has joined #dri-devel
<karolherbst>
ahh
<karolherbst>
yeah.. maybe it's actually fine then
<karolherbst>
I do get a 1.0 spir-v afterall
<karolherbst>
but vtn crashes
<karolherbst>
ehh wait
<karolherbst>
jenatali: global invoc id is "Input"
<karolherbst>
"An OpVariable in a SPIR-V module with the BuiltIn decoration represents a built-in variable. All built-in variables must be in the Input storage class."
<karolherbst>
so that needs to be listed there
<jenatali>
Interesting. Yeah I dunno what the deal is with those variable lists. I haven't tried anything CL in a long time though personally
<karolherbst>
ahh, it crashes when the linker ends up not adding the variable to any entry point
<karolherbst>
mhh, or the "called" one?
<karolherbst>
ehh wiat
<karolherbst>
okay, so if the kernel which I compile against doens't contain the list, it crashes
<karolherbst>
anyway, this sounds like an issue inside the spirv linker
aissen_ has quit []
aissen has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
wow spirv-opt does have some very interesting stuff
<karolherbst>
jekstrand: do we have a workaround somewhere in vtn for variables not declared in the entry point?
danvet has joined #dri-devel
tzimmermann has joined #dri-devel
mbrost has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
MajorBiscuit has joined #dri-devel
MajorBiscuit has quit []
MajorBiscuit has joined #dri-devel
ybogdano has joined #dri-devel
cheako has joined #dri-devel
<karolherbst>
ehh I didn't tested against 3.0 on ADL-S
jewins has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
nchery has quit [Read error: Connection reset by peer]
sneil_ has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
sneil has joined #dri-devel
nchery has joined #dri-devel
nchery is now known as Guest1707
nchery has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
Guest1707 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
nchery has quit [Read error: Connection reset by peer]
danvet has quit [Ping timeout: 480 seconds]
abhinav__ is now known as Guest1711
nchery has joined #dri-devel
abhinav__ has joined #dri-devel
shankaru has quit []
gouchi has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: That shouldn't be a problem for CL, I didn't think.
mbrost has joined #dri-devel
<karolherbst>
jekstrand: yeah well.. it is because spirv-link is buggy
<airlied>
karolherbst: the translator could be broken for 1.4 requirements there
<karolherbst>
it isn't a translator bug
<airlied>
though I thought I saw a recent MR in that area
<karolherbst>
so you have one spir-v calling an extern kernel but not using variables itself, this entry point gets declared without inputs
<karolherbst>
now you link in that extern kernel which does use inputs and has them listed, as required
<karolherbst>
but the final module doesn't list the inputs on the outer kernel
<karolherbst>
althoug it should
<karolherbst>
*although
<karolherbst>
or at least I think it should list them
<karolherbst>
the caller has to merge the list of called functions into its own list, which apparently doesn't happen in case of linked in functions
<jekstrand>
mattst88: In any case, if you want to open a Mesa bug and link to that, I'd be happy to throw on a Closes: tag. It'd be nice to know if there's a test case outside OpenCL that is affected by this.
<jekstrand>
I was a bit surprised none of the CTSs hit it.
<jekstrand>
mattst88: is test_integer_ops a piglit test?
<jekstrand>
That sounds like an OpenCL test name. Like exactly the one I fixed. :D
<karolherbst>
:D
<karolherbst>
wait, why are people using CL :P
<mattst88>
jekstrand: I think it's an OpenCL test name
gouchi has quit [Remote host closed the connection]
<karolherbst>
jekstrand: btw, your MR doens't regress anything :)
<karolherbst>
mattst88: we already have fixes for that one :P
<mattst88>
\o/
<jekstrand>
As much as I don't want to, I feel slightly compelled to write a test case for that fix.
shashank_sharma has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
<jekstrand>
Hrm... It seems maybe GLSL doesn't have 64-bit versions of those?
<jekstrand>
Yeah, looks like no. Vulkan CTS tests it is.
<karolherbst>
jekstrand: ever looked into why allocations image2d_write is failing?
<jekstrand>
karolherbst: uh... No, I don't think I sorted that one.
<karolherbst>
okay, let's see...
<karolherbst>
a little crazy to create an 1G image, but what do I know
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
Ugh... Doing this in the Vulkan CTS looks horrible. :(
* jekstrand
files a CTS bug
<karolherbst>
okay, so... the image is all 0
<karolherbst>
huh
<karolherbst>
I think the kernel is not executed
<karolherbst>
ehh wait, I failed to disable the shader cache
<karolherbst>
the hell is this shader :O
<jekstrand>
hehe
<karolherbst>
mhh
<karolherbst>
nothing weird going on though
<karolherbst>
just heavily unrolled
<karolherbst>
it uses image_size though
<karolherbst>
but that should work fine
<karolherbst>
huh...
mszyprow has quit [Ping timeout: 480 seconds]
<karolherbst>
it's doing weird math alright, but that doesn't explain the image being all zero.. mhh
Surkow|laptop has quit [Ping timeout: 480 seconds]
<karolherbst>
gotcha
<karolherbst>
"==1141091==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fffa0252000 at pc 0x7ffff7619b00 bp 0x7fffe076ffe0 sp 0x7fffe076f790"
<jekstrand>
?
<jekstrand>
That could do it. :)
<karolherbst>
I already think to know why that happens but let's see
<karolherbst>
yeah... welll....
<karolherbst>
I hate CL
<karolherbst>
although no.. that's fine.. origin is 0, 1 and image size is 8192, 8192
<karolherbst>
and maps a 8192, 1 area
Surkow|laptop has joined #dri-devel
ybogdano has joined #dri-devel
<karolherbst>
ehhh
<karolherbst>
I think I write to a wrong place :)
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
ahhhhh
<karolherbst>
uhm...
<jekstrand>
You're making lots of noises. :P
<karolherbst>
yeah so.. apparently the buffer I write into is already freed
<jekstrand>
Awesome!
<karolherbst>
bonus points: it's a buffer allocated by the CTS
<karolherbst>
but there might be something else weird going on...
<karolherbst>
I think tsan ouput is very bogus and I just overshoot the buffer by a lot
<karolherbst>
CTS pointer is at 0x7fff9f391800 and I write into 0x7fffa0252000, which is offseted from the first one..
<karolherbst>
but why..
<karolherbst>
ehhh, because I am stupid and it's the source which is bogus *hmpf*
<karolherbst>
ahhhh
<karolherbst>
I found it
<karolherbst>
applied the offset twice
rasterman has quit [Quit: Gettin' stinky!]
nchery has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
nchery has joined #dri-devel
<karolherbst>
jekstrand: wow.. by not mapping the entire resource I speed this test up by a factor of... I assume 8000x
<karolherbst>
but it's passing now :)
<karolherbst>
I guess I will fix up internal mappings by not always mapping the entire thing
<jekstrand>
oof
<karolherbst>
yeah...
<jekstrand>
If you're copying 1GB every time, that'll do it!
<karolherbst>
yep
<karolherbst>
the CTS reads out line by line
<karolherbst>
but if we map the entire 8192x8192 image each time..
<karolherbst>
I always wanted to clean up the sw_copy paths by mapping at the proper offset anyway
<karolherbst>
that's just annoying if you do 2D ops on buffers
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Haaninjo has quit [Quit: Ex-Chat]
pcercuei has quit [Quit: dodo]
suren has quit []
mbrost_ has joined #dri-devel
heat has quit [Remote host closed the connection]
ppascher has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
TJ_Mercier has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]