11:52 graphitemaster: Does anyone know how a f32 -> f16 write, followed by a f16 -> f32 read can end up with a NaN when the original f32 was not a NaN
11:53 graphitemaster: This is on NV 2000 series GPUs
11:53 graphitemaster: Is this a hardware bug?
11:55 jbara: Hey , the patch worked (sorry for reporting a bit late)
11:56 jbara: I'm using that `HP Pavilion Gaming Laptop 15-ec1xxx`
11:58 jbara: I haven't tested another monitor yet, but i tried different resolutions on the same monitor and they all have problems .. luckily , sway supports gaps and outer gaps makes things look cool (until you full screen something)
12:04 karolherbst: graphitemaster: that would be odd...
12:04 karolherbst: jbara: tried checking for a setting on the TV?
12:05 karolherbst: but interesting that the patch works. Did you remove nouveau.runpm=0 as well?
12:05 jbara: I don't see resolution related settings
12:05 karolherbst: it's not really resolution specific
12:06 jbara: I didn't actually add it , just used `e` when booting with grub
12:06 jbara: so yes
12:07 jbara: a small "weird note" , when plugging the hdmi nothing happens .. but when booting with the hdmi plugged in , the tv works
12:07 karolherbst: anyway.. in android TV it's I think part of the screen settings and might be something like display area or scene select or wie mode or somthing
12:07 jbara: maybe i'm doing something wrong ?
12:07 karolherbst: mhh
12:07 karolherbst: could be that hot plugging detection is a bit broken
12:07 karolherbst: or not wired up
12:07 karolherbst: that's all within ACPI once the GPU is turned off
12:08 jbara: not an android tv .. i'll try a decent monitor this saturday .. and i'll report back
12:08 karolherbst: does it work after you do something like "DRI_PRIME=1 glxinfo"?
12:08 karolherbst: we try to detect new monitors once the GPU is turned on, so that might work
12:08 jbara: you mean the resolution or the detection ?
12:08 karolherbst: detection
12:09 karolherbst: so plugging in HDMI and if nothing happens, run anything via DRI_PRIME=1 so it uses the nvidia GPU
12:09 jbara: okay , i'll try it and report back
12:09 karolherbst: well... anything using GL
12:09 jbara: i only have nouveau installed btw
12:09 jbara: no propriatary blobs
12:09 karolherbst: yeah shouldn't matter
12:09 karolherbst: I think
12:10 jbara: just so that we're on the same page .. DRI_PRIME=1 in kernel parameters right ?
12:10 karolherbst: there is some firmware from linux-firmware needed for acceleration, but that shouldn't change anything in regards to display detection
12:10 karolherbst: no
12:10 karolherbst: userspace
12:10 karolherbst: it's an env var inside mesa to change which GPU is used
12:11 jbara: so i need to export it (as root) before plugging in the monitor ?
12:11 karolherbst: no
12:11 karolherbst: just when running an application
12:11 karolherbst: and after that
12:12 karolherbst: it's really just there to kickstart the GPU so it gets turned on
12:12 jbara: ohw , alr
13:50 graphitemaster: karolherbst, Yeah I genuinely thing I found a hardware bug on the 2000 series GPUs where single that is not a NaN stored to half then read back as half is not a NaN, but the conversion to single when using texelFetch or imageLoad produces a NaN.
13:50 graphitemaster: s/thing/think/
13:51 karolherbst: huh.. I wouldn't be surprised if filtering could produce NaNs, but neither txf nor imageload use samplers...
13:52 karolherbst: though maybe it's something in the shader itself
13:52 karolherbst: or lowering we do
13:52 karolherbst: might make sense to look into the shader we generate
13:52 graphitemaster: ItSimple passthrough shader, this is on propeitary driver and
13:52 graphitemaster: It's a simple passthrough shader, this happens on prprietary and nouveau
13:52 karolherbst: they still could insert weirdo things
13:52 karolherbst: and so could we
13:52 graphitemaster: It does not happen if I do a blit
13:53 karolherbst: yeah, so blits aren't using 3D in the optimal case
13:53 karolherbst: so they don't run on shaders
13:53 graphitemaster: 3D texture too fwiw, I never tested 2D
13:53 karolherbst: mhh
13:53 karolherbst: yeah.. could be that 3D texturing is broken there
13:54 karolherbst: but anyway.. I wouldn't be surprised if we do something silly in the sahder
13:56 graphitemaster: well i dumpped the proprietary glasm anyways and it's a pretty standard shader which looks fine, but of course glasm isn't the actual ptx