00:00imirkin_: yeah, i generally have tried keeping codegen fairly separate from everything
00:00imirkin_: anholt_: acked-by: me
00:01imirkin_: assuming you give it the ol' compile check
00:01imirkin_: also the nir table is wrong ... it has BGRA_INTEGER instead of BGRA8_UNORM
00:01anholt_: it... it doesn't compile on your driver. the thing I'm asking for is help fixing up the c++ to compile because I don't know how to make a function that's part of a class's namespace that isn't part of an instance of the class.
00:01anholt_: I really really don't know this language
00:02imirkin_: that will require some in-front-of-compiler time then - what you did looks like it could work, although sounds like it doesn't
00:02imirkin_: i'll try to work it out tonight. i've sadly done a lot less c++ of late than i used to
00:03imirkin_: [and i can't look in detail right this second, finishing up some work stuff]
00:25anarsoul: imirkin_: is driver supposed to clip everything that's outside of viewport?
00:26imirkin_: hardware, ideally...
00:26imirkin_: and for points, there's some disagreement
00:26imirkin_: (for wide points)
00:26imirkin_: desktop GL says no, ES says yes
00:29HdkR: point clipping is for when you really hate consistency
00:32imirkin_: anarsoul: also, ES doesn't have this, but there's ARB_depth_clamp which allows you to clamp depth instead of clipping it
00:32anarsoul: I see, thanks!
00:32imirkin_: e.g. adreno hw supports it (a3xx, a4xx ... failed to find it on a5xx, but i'm sure it's there)
00:33chrisf: imirkin_: EXT_depth_clamp does this for ES.
00:34imirkin_: support by ... mesa
00:36anarsoul: Passed: 595/602 (98.8%)
00:36anarsoul: definitely better
00:36imirkin_: that's better
00:36imirkin_: which ones still fail? stupid wide points?
00:37imirkin_: if you did it using the scissor, not sure how you handle the case of viepwort + scissor -- ideally those would be handled separately
00:37imirkin_: er, i guess it's the intersection, so you should always be ok
00:37imirkin_: on that note -- good luck -- i gtg. anholt_ -- will try to look at the c++ thing later tonight or weekend
00:38anarsoul: imirkin: it's intersection
03:20anarsoul: hm, either something's wrong with lima or dEQP-GLES2.functional.polygon_offset.default_displacement_with_units doesn't enable depth test for some reason
03:37imirkin: anarsoul: passes on nouveau
03:38anarsoul: I set breakpoint on lima_bind_depth_stencil_alpha_state() and it binds only one state with all zeroes
03:38anarsoul: maybe my deqp is outdated? :)
03:39imirkin: weird. i ran with GALLIUM_TRACE=foo.xml and i see depth enabled
03:39imirkin: i have an ancient deqp though
03:39imirkin: but i doubt it's changed
03:39anarsoul: let me try that
03:41anarsoul: that's weird
03:42imirkin: oh, that might fail with nir. dunno
03:42imirkin: i figure mareko will fix it soon if it does though.
03:42imirkin: since i'm pretty sure he uses trace a bunch
03:45imirkin: you can just use u_dump to print out the state
03:45imirkin: and then check what gets bound
03:45anarsoul: imirkin: I just checked it with gdb, depth test is not enabled
03:45imirkin: where did you break?
03:46imirkin: and you looked in hwcso->base?
03:46imirkin: is there only one ever bound? that could just be the first one
03:47anarsoul: nope, second time it's called I get NULL as hwcso
03:49imirkin: dunno what to tell ya
03:50anarsoul: totally can be some issue on my side
03:50imirkin: (zsa->pipe = the pipe_depth_stencil_alpha object)
03:51imirkin: do an apitrace and check the state when the draw is called?
03:51imirkin: could also be a state tracking bug that only comes up with your PIPE_CAP settings but not nouveau's for example
03:52anarsoul: could be
03:53imirkin: i see it alternate between enabled = 1, writemask = 1 and enabled = 1, writemask = 0
03:54anarsoul: yeah, that's how it's supposed to work
03:55anarsoul: let me try apitrace
03:56imirkin: that said, i'm not completely on mesa master (but like a week old), and a deqp from at least 1y ago, but probably 2
03:57anarsoul: hm, my apitrace doesn't want to trace surfaceless deqp :(
04:00imirkin: --api=egl maybe?
04:02anarsoul: imirkin: thanks. There's "glEnable(cap = GL_DEPTH_TEST)" in trace but for some reason it doesn't get to me :(
04:02imirkin: boo =/
04:20imirkin: anholt_: https://hastebin.com/upapaneken.cpp -- enjoy
04:21imirkin: some core nir changes you seem to have missed, and then a few syntax/etc fixes. all good.
04:32suprothunderbolt: I' attempting to get a panel working, I've got the timings and data sheet but it's looking okay but blurring along the vertical. Is there a way I can calculate the correct porch etc in case they've given me the wrong data?
04:33suprothunderbolt: it's MIPI DSI connected and rest of the hardware is working fine with another panel.
05:13anarsoul: imirkin: so looks like I get ctx->DrawBuffer->Visual.depthBits == 0 in st_update_depth_stencil_alpha()
05:17imirkin: oh yeah, you have a weird config
05:17imirkin: in your cmdline, no?
05:18anarsoul: seems to work with --deqp-gl-config-name=rgba8888d24ms0
05:19imirkin: makes sense
05:19imirkin: you're forcing a depth-less visual i guess?
05:19anarsoul: now at 10/14 for dEQP-GLES2.functional.polygon_offset.*, that's some progress
05:19imirkin: you probably have to shift the offset scale by 2
05:20imirkin: pretty much every driver has to do this
05:20imirkin: no clue why.
05:20anarsoul: I'm already doing that
05:20imirkin: heh ok
05:22anarsoul: dEQP-GLES2.functional.polygon_offset.*_depth_clamp fail
05:22anarsoul: these don't even run on blob though
05:22imirkin: might not be in mustpass
05:23anarsoul: what is depth_clamp?
05:23imirkin: could be that ext...
05:24anarsoul: that we don't support but didn't disable?
05:24imirkin: there's a PIPE_CAP for it
05:24imirkin: it's core DX10 functionality
05:24imirkin: didn't make it into GL for a while though
05:25anarsoul: mali4x0 is back from dx9 times
05:25imirkin: or it could be something else - dunno
05:26imirkin: ah. nv30 (early DX9) can't even support ES2.0 properly
05:26imirkin: missing separate blend funcs for alpha/color, and a few other things i think
05:31anarsoul: PIPE_CAP_POLYGON_OFFSET_CLAMP is already 0 by default
05:31anarsoul: so must be something else
05:38imirkin: fwiw dEQP-GLES2.functional.polygon_offset.default_result_depth_clamp fails on nouveau
05:39anarsoul: imirkin: what about dEQP-GLES2.functional.polygon_offset.default_factor_1_slope, dEQP-GLES2.functional.polygon_offset.fixed16_result_depth_clamp and dEQP-GLES2.functional.polygon_offset.fixed16_factor_1_slope?
05:39imirkin: yup, all fail
05:40imirkin: the rest pass
05:44anarsoul: same here
05:44anarsoul: imirkin: thanks a lot for your help!
05:44imirkin: same across nv50 and nvc0, it seems
12:59udovdh: who can I discuss AMDGPU instability with on AMD Ryzen 5 3400G with Radeon Vega Graphics?
12:59udovdh: The box crashes HARD multiple times per day with no logging that I am aware of
13:00udovdh: Firefox appears to be the trigger
13:00udovdh: I have bugs open on kernel.org as well as on redhat for these and related issues
13:01udovdh: But what can I, we do to find a root cause?
13:01udovdh: This is not the amdgpu.noretry=0 issue that appeared much quicker.
13:01udovdh: This issue causes hard crashes after a few hours with firefox active
13:02udovdh: Should I pospone investing in Ryzen 7 4800H because of this? https://tweakers.net/pricewatch/1508180/amd-ryzen-7-4800h.html
13:07udovdh: As it will have similar video hardware...
13:39bnieuwenhuizen: udovdh: any of those bugs you can link?
13:41udovdh: Also https://gitlab.freedesktop.org/drm/amd/issues/934 but that issue is fixed with the amdgpu.noretry=0 option. What remains are what I experience now is hard hangs, firefox crashes, etc
13:41udovdh: https://bugzilla.redhat.com/show_bug.cgi?id=1789477 for that issue
13:41bnieuwenhuizen: do you use hardware video decode on firefox?
13:41udovdh: I guess I paid for that so I'll use it; yes.
13:42udovdh: but I can check to be sure
13:42udovdh: `Use hardware acceleration when available` is checked
13:42udovdh: so I am not sure if indeed it is active
13:42udovdh: How to verify that one?
13:43bnieuwenhuizen: oh apparently firefox does not do video decode acceleration for libva (AMD implemented mechanism), so I guess answer is no
13:43udovdh: I can disable it to see if stability improves.
13:44udovdh: only for libva? there's more mechanism for graphics accelleration?
13:46bnieuwenhuizen: as far as I can google there is no API supported both by firefox and the linux AMD drivers
13:46udovdh: as far as libva? or none at all?
13:47udovdh: so that acceleration option is a no-op?
13:47udovdh: we'll find out...
13:47bnieuwenhuizen: well, there is general graphics acceleration which is enabled there and hardware video decode, I was asking about the latter because not a lot of apps use it, while your options is likely about the former
13:48bnieuwenhuizen:is just wondering why you'd primary have issues around firefox
13:48udovdh: How to check the hardware video decode in firefox? Or would that part be more or less bug free?
13:48udovdh: firefox is the trigger.
13:49udovdh: there's no messages about fs corruption and all the disks are redundant
13:49bnieuwenhuizen: from what I can read more or less non-existent instead of bug free
13:49udovdh: fsck runs quite regularly and raid is checked often due to the crashes
13:49udovdh: ok so no worry for this situation then?
13:50udovdh: the option in ff is now off we'll see how long ff keeps running...
13:50udovdh: usually I watch a few youtube vids, browse, etc for a few hours and then when I open a new tab or go to a different tab the thing hangs solid
13:51udovdh: when an application can make that happen I susupect a more intimate connection to the OS
13:52udovdh: would that be a correct assumption?
13:52udovdh: if the situation improves with that acceleration in ff swicthed off I will make not e in the bugs
13:54udovdh: any changes in amdgpu coming that would be beneficial for Ryzen 3400G?
13:54bnieuwenhuizen: so typically userspace (mese etc.) does have enough access to hang your GPU, but at the same time the kernel is supposed to be able to reset the GPU. I suspect at least the reset is not working
13:54bnieuwenhuizen: as for what is causing the hang in the first place, whether that is userspace or kernel I don't know
13:54udovdh: we have amdgpu.lockup_timeout=1000 in extlinux.conf
13:55udovdh: and amdgpu.gpu_recovery=1
13:55udovdh: should be enoygh to enable recovery?
13:55bnieuwenhuizen: right, but it does not always work perfectly (for example, in https://gitlab.freedesktop.org/drm/amd/issues/934#note_378953 the kernel tried recovery but it failed)
13:59udovdh: hmm ok
14:04udovdh: thanks for looking itno this
14:04udovdh: but *IF* the situation improves because of switching off the hardware acceleration, then what should I do?
14:04udovdh: make note in the bugs, change affected item(s) in the bug(s)?
14:24kallisti5: anyone available for a quick sign off on https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3324 ?
14:25kallisti5: pretty much just build fixes for Haiku
16:26udovdh: bnieuwenhuizen, experienced another hard crash...
16:27udovdh: so disabling hw acceleration in FF does not help?
16:27Venemo: udovdh: is this actually a crash that you see or a GPU hang?
16:28udovdh: a hard crash.
16:28udovdh: no response: no numlock action, no ctrl-sysRq-whatever response
16:29Venemo: udovdh: does your system become completely non-responsive? that sounds like a hang to me, not a crash.
16:29Venemo: udovdh: can you SSH into the machine after this happens?
16:29udovdh: a hang, a crash, excuse myn wording. I call it an ungraceful ending to a running state
16:29bnieuwenhuizen: Venemo: https://bugzilla.kernel.org/show_bug.cgi?id=206017
16:29Venemo: yes, sorry for the nitpick
16:30Venemo: ok I can see that you even managed to collect a dmesg log
16:30udovdh: no neat crashdump in the logs to help fix the issue, no...
16:30Venemo: that is what I was gonna ask you to do.
16:30udovdh: for the older situation yes, before we had amdgpu.noretry=0
16:31udovdh: when it ends running as it currently does, how can I force it to produce some useful logging?
16:32udovdh: even /var/log/messages has nothing useful
16:32Venemo: if you can ssh into the machine while it is in this state, you can get a dmesg log. if it's a debug kernel it might show more info (though it's gonna give you less performance in general)
16:32udovdh: networks is unresponsive after such a hang so I cannot get a dmesg
16:32udovdh: how to make a debug kernel?
16:33udovdh: performance is not improtant as these crashes are limiting enjoyment of the system
16:33Venemo: so not only the GPU hangs, but your whole system freezes up completely?
16:33udovdh: looks like that yes
16:33udovdh: and mostly firefox is involved
16:34Venemo: well, that's a very sucky thing and unfortunately I can't give you an easy way to get anything useful out of it. however, if you have a serial port (or a usb serial port), it is possible to get the kernel to log things on the serial port. so it the port is connected to another computer you can see what it logs.
16:36udovdh: We have serial ports yes. even a vt320 nearby
16:38Venemo: so, one thing to try is disable hardware acceleration in firefox. not only the hardware video decode as bnieuwenhuizen suggested but all hw acceleration. you can do this in firefox preferences -> general -> performance, untick "use recommended performance settings", then uncheck "use hardware acceleration". if you still see the problem after this, it is very possible that it's not a graphics related problem
16:39udovdh: Under Performance I see:
16:39udovdh: Use recommended performance settings (unchecked)
16:39udovdh: and (indented further) Use hardware acceleration when available (unchecked)
16:39udovdh: I could check the Use recommended performance settings?
16:40Venemo: if both are unchecked then firefox does not use hw graphics acceleration
16:40udovdh: then Use hardware acceleration when available disappears from veiw.
16:40Venemo: the recommended setting is to enable it, afaik
16:41udovdh: and restarted ff
16:41Venemo: so uncheck both
16:41Venemo: then see if the problem remains.
16:41udovdh: let's see if this makes the system saty up beyond 24 hours as currently that is quiet hard
16:41udovdh: both were unchecked and it did still hang
16:41Venemo: I see
16:42Venemo: then it is possible that it's not a graphics problem.
16:42udovdh: so now we try the Use recommended performance settings
16:42udovdh: yes, but how can I find out?
16:42udovdh: memory is OK
16:42udovdh: disks are redundant
16:42udovdh: CPU is not too hot
16:42Venemo: if you are comfortable with serial ports, I recommend trying that approach
16:42udovdh: will have to find some howto for more easy implementation
16:43Venemo: basically you add a kernel parameter to tell the kernel which port to log stuff, and then just see what it outputs
16:43udovdh: I can disconnect the UPS serial port and use that to send out data
16:44udovdh: simply a console on rs232? https://wiki.freepbx.org/display/PC/Capturing+Kernel+Panic+via+Serial+Port
16:44udovdh: I could do that tomorrow or so
16:44MrCooper: udovdh: I assume unchecking "Use recommended performance settings" leaves "Use hardware acceleration when available" at the default, which might be enabled... I'd check about:support
16:45Venemo: at some point I had the exact same symptom on my laptop. I was completely out of options and somebody suggested this to me. so I borrowed two FT234 dev boards and hooked them up, set the kernel parameter to use ttyUSB0 and then looked at the output.
16:45Venemo: MrCooper: unchecking the recommended one gives you the ability to manually enable or disable the actual setting.
16:45MrCooper: Venemo: Firefox has no video decode HW acceleration yet on Linux
16:46Venemo: I'm not talking about video decode
16:46MrCooper: Venemo: ah right, brain fart :)
16:46MrCooper: you were earlier though
16:46udovdh: HW_COMPOSITING: force_enabled by user: Force-enabled by pref; blocked by env: Acceleration blocked by platform
16:46udovdh: OPENGL_COMPOSITING: force_enabled by user: Force-enabled by pref
16:46MrCooper: so it's still enabled
16:46udovdh: WEBRENDER: opt-in by default: WebRender is an opt-in feature
16:47Venemo: udovdh: anyway, on that laptop, it turned out that the driver of the wifi card (ath10k) had a nasty bug which meant that it would freeze the system any time the AP switched between 20MHz and 40MHz mode.
16:47Venemo: so without seeing the logs, it is hard to say what the problem is. but it could be "anything".
16:47udovdh: WEBRENDER_QUALIFIED: blocked-device-too-old by env: Device too old (whahahaha!!)
16:47udovdh: no laptop here
16:47MrCooper: webrender is disabled, but HW acceleration is enabled
16:47udovdh: WEBGPU: disabled by default: Disabled by default
16:48Venemo: I'm just saying that the same symptom can be caused by multiple different problems, and it is not necessarily a graphics issue.
16:48udovdh: so I will disable the Use recommended performance settings
16:48udovdh: I am not suggesting that although I am leaning towards that.
16:48Venemo: anything's possible
16:48udovdh: also capturing /var/log/messages on a serial terminal looks doubtful; sometimes the data should survive for me to see after a hang?
16:49udovdh: layers.acceleration.force-enabled is now off I guess
16:50Venemo: i'm not suggestiong to capture /var/log/messages
16:50Venemo: I'm suggesting to use the kernel boot parameter
16:51Venemo: which will make the kernel essentially send out the dmesg on a serial port on its own
16:53udovdh: as it is a console...
16:56Venemo: the system will still freeze but you will at least see some hint on the serial port about what happened
16:58udovdh: hopefully yes...
17:02udovdh: thanks, I'll let you know when I find out more