ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
riteo has joined #dri-devel
iive has quit [Quit: They came for me...]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
apinheiro has quit [Quit: Leaving]
alice has quit [Remote host closed the connection]
alice has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
alice_ has joined #dri-devel
LeviYun has joined #dri-devel
alice has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
hakzsam_ has joined #dri-devel
mupuf_ has joined #dri-devel
hakzsam has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mupuf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
hakzsam_ has quit []
mupuf_ has quit []
hakzsam has joined #dri-devel
mupuf has joined #dri-devel
hakzsam has quit []
mupuf has quit []
mupuf has joined #dri-devel
hakzsam has joined #dri-devel
LeviYun has joined #dri-devel
i-garrison has quit []
glennk has joined #dri-devel
mupuf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
hakzsam has quit []
hakzsam has joined #dri-devel
mupuf has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
phire has quit [Ping timeout: 480 seconds]
phire has joined #dri-devel
Duke`` has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
davispuh has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
<Company> does GL have an equivalent to VkAttachmentLoadOp ?
kts has joined #dri-devel
krei-se has quit [Read error: Connection reset by peer]
krei-se has joined #dri-devel
kts_ has joined #dri-devel
LeviYun has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
kts_ has quit []
fab has joined #dri-devel
fab has quit []
riteo has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
fab has joined #dri-devel
warpme has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
warpme has quit []
phire has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
jfalempe has joined #dri-devel
frieder has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
warpme has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
tzimmermann has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
frieder has joined #dri-devel
bmodem has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<tzimmermann> mripard, hi. will there be a drm-misc-next-fixes PR this week?
jkrzyszt_ has joined #dri-devel
lynxeye has joined #dri-devel
zzoon[m] has joined #dri-devel
smpl has joined #dri-devel
rasterman has joined #dri-devel
LeviYun has joined #dri-devel
vliaskov has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
meltq[m] has joined #dri-devel
Calandracas_ has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
Calandracas has quit [Ping timeout: 480 seconds]
amarsh04 has quit []
mripard has joined #dri-devel
chema has joined #dri-devel
ungeskriptet has quit [Quit: Contact: https://david-w.eu]
u-amarsh04 has joined #dri-devel
sgerhold has joined #dri-devel
smpl has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
jljusten has quit [Quit: WeeChat 4.1.1]
jljusten has joined #dri-devel
LeviYun has joined #dri-devel
glennk has joined #dri-devel
Company has joined #dri-devel
jljusten has quit []
yuq825 has left #dri-devel [#dri-devel]
jljusten has joined #dri-devel
jljusten has quit []
jljusten has joined #dri-devel
pcercuei has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
davispuh has joined #dri-devel
robert_mader has joined #dri-devel
smpl has joined #dri-devel
<mripard> tzimmermann, mlankhorst, daniels: I've started to work on a gitlab issue template to ask for drm-misc commit rights: https://gitlab.freedesktop.org/mripard/kernel/-/tree/drm-misc-templates?ref_type=heads
<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?
guludo has joined #dri-devel
nerdopolis has joined #dri-devel
imre has joined #dri-devel
ungeskriptet has quit [Quit: Contact: https://david-w.eu]
ungeskriptet has joined #dri-devel
puck_ has quit [Ping timeout: 480 seconds]
puck_ has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
<mareko> zmike: zink will need fmulz to fix incorrect rendering in this: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11464
<zmike> hm ok
<zmike> thanks
cmichael has joined #dri-devel
<cwabbott> zink can just not set lower_fpow
zamundaaa[m] has joined #dri-devel
<mareko> indeed
luc has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
pcercuei has quit [Quit: brb]
nerdopolis has joined #dri-devel
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]
simon-perretta-img has joined #dri-devel
<luc> https://github.com/flightlessmango/MangoHud/blob/master/src/gl/inject_glx.cpp#L145 this line will run into a SEGV due to a null pdraw->psc->driScreen->getSwapInterval
frieder has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
Hazematman|irc has joined #dri-devel
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
<zmike> eric_engestrom: is there any way I can get the full process name to print in hangs here? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/60799479
warpme has joined #dri-devel
<eric_engestrom> "for process shader_runner" but I guess you want not just the process but the whole command line
<zmike> yes
frankbinns1 has joined #dri-devel
<eric_engestrom> but you'd have to ask the amd kernel devs
<zmike> ah
rasterman has quit [Quit: Gettin' stinky!]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
pcornu has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
epoch101 has quit [Quit: WeeChat 4.3.3]
robert_mader has left #dri-devel [#dri-devel]
frankbinns1 has quit [Remote host closed the connection]
alice_ is now known as alice
Haaninjo has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
epoch101 has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #dri-devel
frieder has joined #dri-devel
<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'm reading https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html , is there somewhere else with stronger text?
<alyssa> That says: "Result is... either x or y if both x and y are zeros" and "fmin(-0, ±0) = -0"
<glehmann> nmin(-0, ±0) = -0. nmax(+0, ±0) = +0.
<alyssa> Oh. NMin vs FMin. Got it.
<glehmann> fmin has the same note
<alyssa> Wait, no, even for nmin?
warpme has quit []
<alyssa> Yeah, even for NMin, I'm not seeing text requiring "fmin(+0, -0) = -0"
<alyssa> Yes
<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]
cr0n has joined #dri-devel
cr0n has quit []
<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
dumbbell has joined #dri-devel
<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?
<jenatali> Let me see if I can find out
<jenatali> glehmann: https://github.com/microsoft/DirectXShaderCompiler/wiki/Wave-Intrinsics#type-waveactivemin-type-expr - I think this is the "spec" page for these ops and isn't explicit about behavior with specials
tzimmermann has quit [Quit: Leaving]
<jenatali> glehmann: https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_3_FunctionalSpec.htm#22.10.10%20max I believe this table of specials should apply then
<glehmann> okay, so it's NaN then
<jenatali> That's what I'd expect, yeah
<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]
<alyssa> glehmann: ....Ouch. Didn't consider that.
<alyssa> Not sure what it does there.
<alyssa> It's possible that those are correct
<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
gouchi has joined #dri-devel
<alyssa> 🤡
alanc has joined #dri-devel
hakzsam has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mupuf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mupuf has joined #dri-devel
hakzsam has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
dumbbell has quit [Quit: WeeChat 4.3.3]
dumbbell has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
Kayden has quit [Quit: -> JF5]
LeviYun has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
robert_mader has joined #dri-devel
vedranm has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
robert_mader_ has joined #dri-devel
robert_mader has quit [Quit: Leaving.]
gouchi has quit [Remote host closed the connection]
nerdopolis has joined #dri-devel
Kayden has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
fab has quit [Quit: fab]
nerdopolis has quit [Ping timeout: 480 seconds]
luc has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
LeviYun has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
glennk has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
nerdopolis has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
cyrinux has quit []
Duke`` has quit [Ping timeout: 480 seconds]
cyrinux has joined #dri-devel
cyrinux has quit []
cyrinux has joined #dri-devel
LeviYun has joined #dri-devel
Company has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
sima has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
<Lyude> Are enable_vblank and disable_vblank hooks that atomic drivers should be using?
LeviYun has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
<Lyude> ah ok nvm, I think I just misread something :P
nerdopolis has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
karolherbst has joined #dri-devel
karolherbst has quit []