<mripard>
one of the issue I think is that our gitlab tier can only handle a single assignment through the template, so with this mlankhorst is always going to be the one assigned
<mripard>
daniels: do you know if there's anything (like a bot maybe?) we can use to set the assignees after the facts?
itoral has quit [Remote host closed the connection]
Hazematman has joined #dri-devel
<luc>
how should GLX cope with a call to glXQueryDrawable(dpy, drawable, GLX_SWAP_INTERVAL_EXT, &...) towards a driver not supporting GLX_EXT_swap_control (e.g. drisw) ?
<zamundaaa[m]>
Oh, stupid matrix bridge had me unauthenticated again. In case the message got lost, here it is again:
<zamundaaa[m]>
vsyrjala: I just found out about the SIZE_HINTS property for cursor planes, that's quite useful. In the future though, could you please cc wayland-devel about such uAPI additions? I would've really liked to have it implemented a year ago instead of only finding out about it by accident
simon-perretta-img has quit [Read error: Connection reset by peer]
cmichael has quit [Remote host closed the connection]
cmichael has joined #dri-devel
<Hazematman>
(sending again as I was having some matrix<-> irc issues) Hey I have an open MR for Android integration of llvmpipe/lavapipe that also improves some of the Android build docs. Roman Stratiienko has given me some feedback on it but is there anyone else doing Android work that could take a look and review my changes? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29344
Hazematman|irc has quit []
frieder has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
cmichael has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
cr0n has quit []
alih has joined #dri-devel
warpme has quit []
cr0n has joined #dri-devel
fab has quit [Quit: fab]
cr0n has quit []
cr0n has joined #dri-devel
pcercuei has quit [Quit: bbl]
Company has quit [Quit: Leaving]
alyssa has joined #dri-devel
<alyssa>
IHV poll - what is fmin(+0.0, -0.0) on your platform?
<alyssa>
it's seemingly impl-defined in SPIR-V
<MrCooper>
luc: BadValue error? GLX_SWAP_INTERVAL_EXT isn't a valid attribute for glXQueryDrawable without GLX_EXT_swap_control
<glehmann>
it's no longer implementation defined, though I kind of disagree with the reasoning because it retroactively changes required behavior for VK_KHR_shader_float_controls (the old one, not 2)
lemonzest has quit [Quit: WeeChat 4.3.4]
<alyssa>
glehmann: ahah, excellent, thanks :)
<alyssa>
I mean, sucks to be AGX, but it makes the path forward for NIR very obvious :)
lemonzest has joined #dri-devel
frieder has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
robert_mader has joined #dri-devel
Company has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
nerdopolis has joined #dri-devel
heat has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
cyrinux has quit []
cyrinux has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
pcornu has quit [Read error: Connection reset by peer]
anujp has quit [Remote host closed the connection]
anujp has joined #dri-devel
<alyssa>
glehmann: wait, I'm still not seeing where in the spirv spec the strict behaviour is required.
<alyssa>
I see the text "Result is... either x or y if both x and y are zeros... nmin(-0, ±0) = -0."
<alyssa>
That notably allows "nmin(+0, -0) = +0" as a valid implementation.
<glehmann>
oh right
<alyssa>
(The implementation "return the first source if the sources are equal", in fact.)
<glehmann>
so the text and the examples given contradict each other
<glehmann>
great
<alyssa>
which examples...?
<glehmann>
fmin(-0, ±0) = -0
<vsyrjala>
zamundaaa[m]: if you want kms uapi changes cc:d to somewhere other than dri-devel then i think you need to propose a change to MAITNAINERS or something. asking a random collection of people to cc uapi stuff to various places probably won't work very well
<vsyrjala>
zamundaaa[m]: or start reading dri-devel
<alyssa>
I don't think that's an example, I think that's an additional requirement
<alyssa>
and I agree with that requirement
<alyssa>
but for fully specifying AMD behaviour would require an addition line "fmin(+0, -0) = -0"
<glehmann>
ah
<glehmann>
well, that's worse
<alyssa>
without that addition, either -0 or +0 is valid
<alyssa>
I don't know if this is an oversight
<glehmann>
because the opcode should be commutative
<alyssa>
should is doing a lot of lifting there =D
<glehmann>
well it is in NIR, so you have no choice there
<glehmann>
we are not going to change that
<alyssa>
I mean. If it's not commutative in SPIR-V, maybe it shouldn't be in NIR? but also I would like to know what the SPIR-V spec actually intends before anything changes
<alyssa>
If this is a spir-v spec bug, we should fix the spir-v spec
<alyssa>
If this is actually intended, I think there are bogus Vulkan CTS tests
<glehmann>
non commutative fmin would be a nightmare for opt_algebraic
<alyssa>
yeah, agreed. wasn't a real proposal.
<alyssa>
but regardless of what NIR does, I think there's *some* khronos bug here...
<glehmann>
we should request a clarification
<zamundaaa[m]>
vsyrjala: reading dri-devel and finding the bits relevant for compositors isn't a realistic options, most people do not have time for that
<zamundaaa[m]>
If we could get a keyword in the commit message or standardize cc-ing some mailing lists on specific topics that would of course be better though
glennk has quit [Ping timeout: 480 seconds]
<alyssa>
hmm, maybe the vk cts doesn't actually test the min(+0, -0) case
<glehmann>
the question is if that's intended
<alyssa>
yeah
* alyssa
files ticket
cr0n has quit []
anujp has quit [Remote host closed the connection]
<glehmann>
two new min/max spirv issues in one hour :)
rasterman has joined #dri-devel
cr0n has joined #dri-devel
* alyssa
high fives
cyrinux has quit []
cyrinux has joined #dri-devel
tlwoerner_ has quit []
tlwoerner has joined #dri-devel
<Company>
glehmann: how many broken spec issues do you find per hour roughly?
rasterman has quit [Quit: Gettin' stinky!]
<glehmann>
not enough, probably
<Company>
I am wondering at this point how good the specs are
<Company>
ie if it's more about coding to the specs or coding to the implementations
<Company>
like, Wayland is more about the implementations and you can ask the few people involved for clarifications
<Company>
and web stuff is all about the specs and there's a big process behind making sure they cover all corner cases
<Company>
and I have no idea where inbetween GL and Vulkan live
<Company>
and if they are similar in that or both are different
jenatali has joined #dri-devel
<jenatali>
Sigh this stupid Matrix bridge keeps disconnecting without telling me that I need to re-auth
<jenatali>
I was just trying to say that the specs are pretty good
<jenatali>
They have to be, since there are so many different implementations of the spec
<Company>
with the less common implementations, they don't conform very well to the specs and people code against the implemenetations
<Company>
at least according to Google
<jenatali>
For GL? Yeah I can 100% believe that. For Vulkan, the spec is much more thorough, and much more alive
<Company>
I have the benefit of being on Linux where there's about 1.5 implementations, too
<jenatali>
For GL, yeah, 90% of the stuff is Mesa's frontend or ANGLE. For Vulkan the different implementations even in Mesa are pretty much independent
<Company>
that's because there isn't much to do
alanc has quit [Remote host closed the connection]
<Company>
and I was thinking of nvidia for the .5 - angle is more a wrapper and suffers from the backend it uses in my experience
alanc has joined #dri-devel
<Company>
kinda like zink
<Company>
and zink is one of the things that forces the Mesa Vulkan impls to actually agree on stuff
<karolherbst>
jenatali: one further question about mapping, how are you dealing with CL_USE_HOST_PTR, because this one is an annoying special case, because you have to return a pointer based on the host_ptr, but that's a bit weird if the application would map for reading at the same offset multiple times
<Company>
and they share nir and the wsi I think?
<jenatali>
karolherbst: I just store the pointer. When the app maps, I copy to staging, map that, and then CPU memcpy it to the app's actual memory
<jenatali>
It's terrible :D
<jenatali>
D3D doesn't (or at least didn't) really support importing host memory like that
<karolherbst>
uhhh
<alyssa>
Company: vulkan is very much "coding to the CTS"
<alyssa>
luckily the vulkan cts is really great
<alyssa>
but not perfect ;) ;)
<jenatali>
It really is
<karolherbst>
jenatali: but are you refcounting the pointer or are you hoping that no application will map at the same offset multiple times?
<jenatali>
karolherbst: Not sure I'm following why I'd need to refcount?
<jenatali>
The act of mapping is what copies contents into the user pointer
<karolherbst>
because in theory, I think if the app would map at 0x100 4 times, you'd return the same pointer 4 times, but the application might except being able to unmap that 4 times?
<karolherbst>
dunno
<jenatali>
Yeah that seems fine?
<karolherbst>
s/except/expect/
<karolherbst>
yeah, but that means you have to count how oftne you returned the same pointer
<jenatali>
Why?
<karolherbst>
If the buffer object is created with CL_MEM_USE_HOST_PTR set in mem_flags, the following will be true: The pointer value returned by clEnqueueMapBuffer will be derived from the host_ptr specified when the buffer object is created.
<jenatali>
Right
<karolherbst>
and nothing tells you to fail the map if it already was mapped for reading
<jenatali>
... right?
<karolherbst>
so.. you have the application calling clEnqueueMapBuffer(... offset: 0x100) 4 times
<karolherbst>
and 4 times you'd e.g. return 0x35341200
<karolherbst>
and the application will unmap that
<karolherbst>
4 times
<karolherbst>
probably
<jenatali>
Yep. And?
<karolherbst>
do you have to return an error on the 5th or the 2nd unmap?
<jenatali>
The 5th
<karolherbst>
so you have to refcount
<Company>
alyssa: does that cts greatness go for core stuff only or also for wsi things?
<jenatali>
Oh, I'm misremembering the CL API. Let me re-read what I wrote :)
<alyssa>
Company: probably mostly core
<alyssa>
given that WSI in HK is currently totally broken..........
<karolherbst>
jenatali: I don't think it's explciitly speced like that tho
<karolherbst>
there is also `CL_MEM_MAP_COUNT`, but that's for the total memory object, not specific offsets
<karolherbst>
I wonder if that needs spec clarification
<jenatali>
karolherbst: Ok so what I do is each map pushes an "outstanding map" into a queue
<Company>
alyssa: dmabuf import/export are the challenging things - and getting swapchains and GTK using the same wl_surface to not trample on each other
<jenatali>
And then unmap pops the first map out of the queue and undoes it. So when a write map gets unmapped, it'll trigger some additional copies in some cases (e.g. USE_HOST_PTR) so I need to track which maps need that
<karolherbst>
jenatali: right.. in practise none of this matters, because 1. you return a pointer to a memory allocation covering the whole range, so `size` doesn't even matter. 2. it's mapped for reading, so no write back happens, so you won't have to do anything on `unmap` in the first place
<karolherbst>
but still...
<karolherbst>
in theory this has some weird issues
<karolherbst>
e.g. in what order do you release those maps, because they can all have different sizes
<jenatali>
Yeah
<karolherbst>
anyway.. for CL_MEM_USE_HOST_PTR none of those issues matter one way or the other
<jenatali>
They do for me :)
<karolherbst>
you still should return a pointer pointing into the host_ptr region
<jenatali>
Yes, I do
<karolherbst>
ohh.. you'd fail on the 2nd unmap instead of the 5th I guess
<jenatali>
No, I track the right number and fail on the 5th
<karolherbst>
right number at the specific offset or generally?
<jenatali>
But a sequence of (write, read, write, read) that gets unmapped 4 times, those unmaps would do different things depending on the sequence in which they're supposed to correspond
<karolherbst>
that's not an issue
<karolherbst>
you can't overlap with a mapping with CL_MAP_WRITE
<karolherbst>
(and the other write thing)
<jenatali>
Oh ok
<karolherbst>
in theory you should fail the map if it overlaps with a writable region
<jenatali>
And the maps are keyed based on the pointer that's returned. So unmap of a pointer that wasn't returned will fail
sravn has joined #dri-devel
<karolherbst>
yeah
<karolherbst>
just need to remember if a specific pointer was returend multiple times
<karolherbst>
I guess...
<karolherbst>
it doesn't even matter, because the pointer remains to be valid either way
<karolherbst>
well..
<jenatali>
Right that's what I'm saying, per-pointer I have a list of the map tasks that are still outstanding, i.e. haven't been unmapped
<karolherbst>
kinda
<karolherbst>
I see
<karolherbst>
I just dislike this part of the spec, because uhhh... those corner cases are weird
glennk has joined #dri-devel
pcercuei has joined #dri-devel
<jenatali>
The CL spec as a whole is weird
<karolherbst>
yeah.. fair
dnfh^ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
macromorgan has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
simon-perretta-img has joined #dri-devel
dnfh^ has quit [Remote host closed the connection]
Dark-Show has joined #dri-devel
<glehmann>
jenatali: is WaveActiveMax(NaN) defined behavior in D3D12?
<glehmann>
SPIR-V is undefined result for some reason
<jenatali>
Hm, though WARP is going to return not-NaN
<jenatali>
It's a question of whether the hardware/driver is setting an initial value as a constant, and then doing min/max on all values, or if it's setting initial value as the value from the first active lane, and then min/max on subsequent values
lynxeye has quit [Quit: Leaving.]
robert_mader has quit [Quit: Leaving.]
<jenatali>
glehmann: Yeah WARP for WaveActiveMax(NaN) is going to give you -inf
<glehmann>
it also could set the initial value to constant NaN, that's what I wanted to change aco to, but then I noticed the weird spirv rules around exclusive scans (which require -inf for the first invocation)
Haaninjo has quit [Quit: Ex-Chat]
<glehmann>
alyssa: doesn't agx have reductions/exclusive_scans in hw? I wonder what that does for fmin/fmax
alanc has quit [Remote host closed the connection]
<jenatali>
glehmann: Yeah makes sense. D3D doesn't have min/max scans. I wonder if this is why
<alyssa>
since the reductions/scans are real binary fmin/fmax instructions
<alyssa>
whereas nir_op_fmin/fmax is implemented with a comparison-and-select instruction
<alyssa>
(flt+bcsel fused into 1 instruction, with a special mode to make NaNs do the right thing)
<glehmann>
the issue is that at this point I don't even know what correct means
<alyssa>
(which is why denorms need to be flushed manually)
<alyssa>
...Yeah
<alyssa>
Especially since this is only 754-2019, and M1 was released 2020 so the ALUs predate 2019.
<alyssa>
(does Apple participate in IEEE?)
<alyssa>
"Metal is compliant to a subset of the IEEE 754 standard" :melt:
Haaninjo has joined #dri-devel
<glehmann>
well, NaN behavior didn't change, so does your scan use -inf or NaN as identity internally
<glehmann>
that's the odd thing. to me it would have been obvious that the identity is NaN because that's... the actual identity of min/max. No idea why apparently multiple people chose +-inf
<alyssa>
mm..
smpl has quit [Ping timeout: 480 seconds]
<glehmann>
alyssa: I found another min/max spir-v issue: nmax(-Inf, y) = y.
<glehmann>
that's not true if y is NaN
* alyssa
melts
<alyssa>
true.
<glehmann>
not sure if I want to pollute your issue with that, but opening yet another one also feels weird
simon-perretta-img has quit [Read error: Connection reset by peer]
<alyssa>
good day for ieee
<glehmann>
can't wait for spir-v to get ieee-754-2019 minimum/maximum for maximum confusion
simon-perretta-img has joined #dri-devel
<jenatali>
glehmann: Looks like NVIDIA's D3D driver turns WaveActiveMax(NaN) to -FLT_MAX, and WaveActiveMax(-inf) to 0. So....... that's not great :)
<alyssa>
jenatali: excuse me
<alyssa>
??
<jenatali>
Mhmm
<jenatali>
Oh and WARP actually will give you different answers depending on whether it's a full wave or a partial one. That's fun
<glehmann>
that's the same situation aco is in rn
<jenatali>
NVIDIA's D3D driver gives sane results with a full wave FWIW, the garbage is only with inactive threads