00:00 imirkin_: it's not a real problem
00:00 imirkin_: it's just informational
00:00 imirkin_: means you don't have any monitors plugged in
00:00 clever: yeah
00:00 imirkin_: so it doesn't know what the default fbdev size shoudl be and just guesses
00:00 clever: ive confirmed the firmware to setup a 100x100 DPI display, and to advertise a 100x100 framebuffer to linux
00:01 clever: and i can see a single crtc/connector/encoder in libdrm
00:02 clever: s/confirmed/confirmed/
00:03 clever: imirkin_: https://gist.github.com/cleverca22/f57832f0b3a0ac63ad809ad7af576612 is the src and output
00:05 imirkin_: clever: unfortunately i have no idea
00:05 imirkin_: maybe flip drm.debug to like 0x1e
00:05 imirkin_: you can do it "online"
00:05 imirkin_: via /sys/module/drm/parameters
00:06 clever: yep, already in that dir
00:06 clever: root@raspberrypi:/sys/module/drm/parameters# echo 0x1e > debug
00:06 imirkin_: i.e. echo 0x1e > /sys/.../parameters/debug
00:06 imirkin_: and run your program again
00:06 imirkin_: and check dmesg
00:06 clever: [ 1110.891620] [drm:vc4_fkms_connector_detect [vc4]] connector detect.
00:06 imirkin_: maybe it'll have more info
00:06 clever: that msg is repeating on its own at regular intervals
00:06 imirkin_: oh -- i think that lowest bit is the core messages. i never have it on.
00:06 imirkin_: try 0x1f
00:06 imirkin_: iirc it's a LOT of junk
00:06 imirkin_: but perhaps useful here
00:07 clever: gist updated with the logs
00:07 imirkin_: [ 1140.489936] [drm:drm_mode_setcrtc [drm]] Invalid mode (ret=-22, status=H_ILLEGAL)
00:07 clever: yep, definitely giving better errors
00:07 imirkin_: no clue what any of this stuff means
00:07 clever: how do my H params on lines 159-162 look?
00:07 imirkin_: illegal ;)
00:08 clever: what should they look like?
00:08 imirkin_: legal!
00:08 imirkin_: duh
00:08 clever: lol
00:08 clever: so at least 18 in every field?
00:08 imirkin_: you'll probably have to rtfs to see what's legal and what's not
00:08 imirkin_: probably has to be a multiple of 8 or so?
00:08 clever: the hw itself can already support 0 front/back, 1 sync, and 100 display
00:09 clever: ive already configured that at the firmware level, and the hsync/vsync are doing exactly that
00:09 clever: https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c
00:09 clever: this driver then implements KMS ontop of the firmware's internal stuff
00:10 imirkin_: i think the core just doesn't support these
00:10 imirkin_: perhaps without any good reason
00:10 imirkin_: check the core code
00:10 imirkin_: see where H_ILLEGAL is set
00:10 clever: ../drm_modes.c: return MODE_H_ILLEGAL;
00:11 clever: hdisplay must not be zero, syncstart must be less then display, end < start, total < end
00:11 clever: hmmmm, i think i see something
00:12 clever: hsync_end must be > htotal
00:12 clever: is hdisplay the pixel to start on, or the number of pixels in a line?
00:16 clever: [ 1737.463544] [drm:drm_mode_setcrtc [drm]] Invalid mode (ret=-22, status=V_ILLEGAL)
00:16 clever: that looks like progress!
00:17 clever: [ 1769.751367] [drm:drm_atomic_add_affected_planes [drm]] Adding all current planes for [CRTC:52:crtc-0] to 134112f5
00:17 clever: [ 1769.751404] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:52:crtc-0] mode_valid() failed
00:17 clever: [ 1769.751480] [drm:drm_atomic_check_only [drm]] atomic driver check for 134112f5 failed: -22
00:17 clever: ok, it cleared drm_mode_validate_basic i believe
00:18 clever: 1241 .mode_valid = vc4_crtc_mode_valid,
00:18 clever: this is probably whats upset now
00:23 clever: imirkin_: would it be possible to attach a framebuffer to a connector, without changing the mode?
00:32 clever: 520 ret = drm_crtc_mode_valid(crtc, mode);
00:32 clever: 522 DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode_valid() failed\n",
00:32 clever: [ 2597.970717] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:52:crtc-0] mode_valid() failed
01:11 imirkin_: clever: probably, yeah, esp if you're not using the atomic APIs
01:28 ddevault: is there a room specifically for AMDGPU?
01:28 airlied: ddevault: #radeon covers it usually
01:28 ddevault: j #radeon
01:29 ddevault: gah
01:29 ddevault: thanks airlied
14:49 clever: imirkin_: ok, thats interesting, if i increase the resolution, kms starts reporting it as a valid mode
14:50 clever: i think the driver is reporting a single FIXED_MODE, but then kmscore rejects it as invalid (as seen by yesterdays logs)
14:50 clever: and you must use that mode, because the driver cant switch modes
15:24 dj-death: jpark: I don't know that it is an issue (the vkQueueSubmit thing), it just code wrapping the driver API
15:25 dj-death: jpark: ah yeah I think I see the issue now
15:25 dj-death: jpark: well I guess we can deal with the synchronization in the layer
15:26 dj-death: quite unfortunate, but should be easy enough...
15:26 imirkin_: clever: yeah, if the driver supplies a bogus fixed mode, you're in trouble
15:29 dj-death: jpark: filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/3159 to not forget about it
15:30 clever: imirkin_: i'll have to investigate mode, to see why drm thinks the mode is bogus, because its definitely capable at the hw level
15:31 clever: more*
16:27 clever: drmModeSetCrtc: No space left on device
16:27 clever: imirkin_: ok, now i'm confused, lol
16:28 clever: [ 6180.086146] [drm:drm_framebuffer_check_src_coords [drm]] Invalid source coordinates 50.000000x2000.000000+0.000000+0.000000 (fb 100x100)
16:28 clever: ah, thats probably it
16:33 clever: i think i see why now, i was hard-coding to 100x100, but the screen is now 50 wide
16:54 agrisis: Hello, not sure if this is the appropriate place to ask this but I'm getting: MESA-LOADER: failed to open rockchip (search paths /usr/lib/xorg/modules/drivers)
16:56 anholt_: looking in xorg modules? sounds like you've got something busted in your configuration.
16:57 agrisis: anholt_: agreed, I was surprised by this as well
16:58 agrisis: to be transparent, my system is aarch64 and I installed armv7hf binaries + libs in a custom root (/usr/arm)
16:58 agrisis: all 32bit apps work except for this particular one that needs gl
16:59 anholt_: sounds like you're maybe trying to build things from scratch. i would recommend looking at the package configuration of your preferred distro as a baseline instead of cooking your own.
17:00 agrisis: anholt_: I will, thanks
17:00 agrisis: fwiw, if I chroot /usr/arm then the app does load fine
17:01 agrisis: I suspect something is expecting certain paths to be available
17:01 agrisis: I'll keep digging and thanks
17:34 kallisti5: any takers to ack https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/78 ?
17:53 anholt_: tomeu: given you've done desktop GL testing now, have you looked at EGL/GLX CTS support in CI?
18:47 mdnavare: hwentlan: What is Nicholas's nick on IRC?
18:50 mdnavare: hwentlan: danvet: agd5f_: https://patchwork.freedesktop.org/series/78671/ This series has a r-b from Nich on amd/display patch along with patch 2/3 which is a drm core patch, how should the merging of these 2 patches happen?
18:51 clever: anholt_: i am seeing some weird bugs with vc4_firmware_kms.c, it doesnt consider some DPI modes valid, and the hdmi is wonky when DPI is active
18:51 anholt_: clever: vc4_firmware_kms is some awful stuff I had to write to support the rpi foundation's mixed closed/open stack. don't use it, it's bad.
18:52 clever: anholt_: its also the only supported mode on an rpi4
18:53 clever: more just reporting bugs it has
18:53 clever: i suspect that you can use the proper DPI driver on even an rpi4
18:53 anholt_:has no interest in bug reports on that code (or rpi modesetting in general at this point, I haven't worked on rpi in a year)
18:53 clever: ah
18:53 clever: i do have it generating uart style waveforms, over the DPI interface
18:54 anholt_: I'm trying to help mripard's pi4 support get in the kernel, and that's as much as I have to give for pi at this point.
18:54 clever: upstream kernel?
18:55 anholt_: pi's downstream kernel is also something I only reluctantly did anything on while I was getting paid.
18:55 clever: did you have access to any of the internal documentation then?
18:56 anholt_: I did at the time. (I still have some NDAed access for specific purposes)
18:56 clever: ah
18:56 clever: one thing i'm a bit stuck on with DPI, is turning the sync pulses off
18:56 clever: vsync is a bit in the way
18:57 clever: 73 # define DPI_VSYNC_DISABLE BIT(2)
18:57 clever: maybe?
18:57 clever:tries
18:58 dschuermann: jekstrand: may I ask you to quickly check if https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5207/diffs?commit_id=1518da40a1314850f296853604b99ca3162313fb is alright now?
19:02 clever: hmmm, that at least stops the vsync pin from toggling....
19:03 jekstrand: dschuermann: rb
19:03 jekstrand: for that one patch, that is
19:04 dschuermann: perfect, thx
19:04 dschuermann: pendingchaos ^
19:06 clever: anholt_: hmmm, but the data pins still go low during the vsync and hsync periods
19:09 clever: anholt_: do you know who is actively working on the display stuff now and could answer more?
19:09 anholt_: clever: mripard, as previously mentioned.
19:09 clever: ah, and i see him in the channel
19:09 jekstrand: anholt_: Did my explanation of load_descriptor make sense?
19:10 anholt_: jekstrand: kind of -- feels kind of like our ir3 descriptor intrinsic we were inserting
19:10 clever: 9pm for him though, i'll wait until its a more reasonabl time
19:11 jekstrand: anholt_: It's quite possible that it's more-or-less exactly that intrinsic
19:11 anholt_: jekstrand: now I just need to figure out the transformations that the various addressing modes do on things so I can pick the right ones.
19:11 jenatali: karolherbst: This was fun to debug :P https://gitlab.freedesktop.org/jenatali/mesa/-/commit/cd5bbc2986a9af8a70b50dc5bcac72c5f3780730
19:12 karolherbst: jenatali: ufff :/
19:12 karolherbst: I thought I fixed default swizzles...
19:12 karolherbst: maybe I missed that spot
19:12 karolherbst: jenatali: the address sanatizer should be able to spot that stuff
19:12 jenatali: No worries, I eventually found it
19:12 jenatali: ?
19:13 karolherbst: -Dsanitze=address
19:13 karolherbst: uhm
19:13 karolherbst: -Db_sanitize I think
19:13 karolherbst: jup
19:13 jenatali: Nah, it's in an initialized array, it was just missing entries so they were all 0
19:13 karolherbst: jenatali: compiling against libasan with this and this is essentially like valgrind just in fast and reliable
19:13 jenatali: Resulted in a .abcdaaaa swizzle
19:13 karolherbst: ohhhh
19:14 karolherbst: annoying
19:14 jenatali: Yep :)
19:15 clever: anholt_: would you or maybe mripard be interested in getting full and proper kms/drm support, without any aid from the firmware?, thats something ive been tryign to get working on an rpi3
19:15 karolherbst: do we actually have int8/16 and fp16 extensions in OpenGL? I could use those to kind of get that stuff working for nouveau as well...
19:16 anholt_: clever: I spent a long time working on that, and have no personal energy to put toward assisting in it.
19:16 imirkin_: karolherbst: yes
19:16 imirkin_: there's an esp nice one, which lets you do whatever you like
19:16 imirkin_: let me find it...
19:16 karolherbst: jenatali: ever worked on fixing int8/int16 stuff? essentially we need this full stuff lowered for nvidia
19:16 clever: anholt_: ah, i'll have to ask mripard next time i see him active then
19:16 clever: i suspect DPI may just work, since its in the audio power domain
19:17 karolherbst: jenatali: but I guess dx12 supports it natively
19:17 clever: HDMI and DSI are the problematic ones
19:17 jenatali: karolherbst: Yeah, our CL backend has passes for lowering int8 and I just added int16 (optional in DX12) today
19:17 clever: VEC i still dont fully understand how to control manually
19:17 jenatali: One of bbrezillon's comments on the MR was to consider moving into a core nir pass for upstream
19:21 imirkin_: gah, can't find it... it was such a great ext
19:22 imirkin_: karolherbst: GL_EXT_shader_explicit_arithmetic_types
19:22 karolherbst: cool
19:23 imirkin_: don't think there's mesa support
19:23 imirkin_: there might be for INTEL_shadeR_integer_functions2 though?
19:38 eric_engestrom: Zeising: fyi, since you were asking about the commands to run in meson for the translations: they're gone now with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5440 being merged
19:38 Zeising: eric_engestrom: Yeah, I saw the merge. Thanks! :)
19:39 eric_engestrom: sure :)
19:42 eric_engestrom: lordheavy, tjaalton, and anyone else packaging mesa: see ^
19:42 eric_engestrom: mattst88: are you managing the gentoo package? I don't remember anymore
19:45 jenatali: karolherbst: This is the 16-bit change, which shows you all the places we were already dealing with 8bit: https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/153
19:45 jenatali: Though loads and stores of smaller-than-32 are dealt with elsewhere
19:45 eric_engestrom: (mattst88: answering my own question: yup, I checked the log and you, FireBurn and someone I don't know are managing the gentoo package)
19:53 airlied: karolherbst: generic pointers are the hard thing right? :), intel sycl compiler seems to be wanting them
19:53 mattst88: eric_engestrom: yeah, I'm the x11@ gentoo maintainer, which includes Mesa
19:54 mattst88: FireBurn occasionally sends pull requests, but he's not a maintainer
19:54 karolherbst: airlied: uff...
19:55 eric_engestrom: mattst88: ack
19:56 mattst88: eric_engestrom: the tl;dr is that gettext should no longer be required by mesa, right?
19:58 eric_engestrom: yup, and that the various `ninja xmlpool-*` commands are no longer needed (and will error out)
19:58 airlied: where do I get my translations now :-)
20:01 eric_engestrom: airlied: I'm assuming you're kidding ;)
20:03 airlied:isn't sure, just whenver someone removes something that someone else added, I assume they've done the research into why that person added it in the first place
20:03 agd5f_: mdnavare, however you want to take them is fine with me.
20:04 airlied: but yeah if we aren't updaing them then it sucks
20:10 Lyude: danvet: any chance you might be able to review https://patchwork.freedesktop.org/patch/372013/?series=74805&rev=5 ? I redid the vblank worker stuff using wait queues and seqcounts
20:11 eric_engestrom: airlied: I haven't done much research into the history tbh, but the state over the last 10-15 years was completely unusable, and if nobody complained in that much time, then nobody used it in the first place
20:12 Lyude: (or anyone else, if they want to unblock nouveau crc support :)
20:12 bnieuwenhuizen: airlied: to be fair I think a lot of the original intent of mesa settings has been somewhat neglected. I think these days it is all workaround and perf tuning, no? I think with that change we shouldn't really expect end-users to touch it unless they know what they're doing well enough to also know english
20:12 danvet: Lyude, ping me again tomorrow in case I forgot, it's a bit late
20:12 Lyude: np
20:12 danvet:trying to get some apricot tart going, then should probably sleep
20:12 Lyude: vsyrjala: if you're interested as well ^
20:12 Lyude: danvet: good luck with the tarts! :)
20:13 danvet: Lyude, btw the performance drop vsyrjala reported, gone as statistical noise?
20:14 Lyude: danvet: no, there was definitely a drop when using normal workqueues. I did some testing and surprisingly I'm pretty sure my kthread_worker version was the fastest one (although it and the kthreadd version were very close)
20:15 danvet: ah yes a drop with work_struct is kinda expected
20:15 danvet: that thing shares kthreads underneath
20:15 danvet: so might have the odd latency spike
20:15 Lyude:finds stats page she made
20:16 Lyude: here we go https://people.freedesktop.org/~lyudess/archive/05-07-2020/vbl-work-benchmarks.pdf
20:17 Lyude: tbh, I wouldn't be super surprised if the difference between the kthreadd version and kthread_worker was just something silly, like the fact I had the kthread_worker version using a dedicated spinlock instead of sharing &drm_crtc_vblank.vbl_lock
20:35 mdnavare: agd5f_: since the amd display patch depends on the drm core patch, can i merge them both through drm-misc?
20:48 airlied: bnieuwenhuizen: is there wsi validation layers, that could warn apps around bad minimage usage?
20:49 bnieuwenhuizen: airlied: what about *the* validation layers? IIRC hakzsam said they caught the minimage badness
20:49 airlied: bnieuwenhuizen: oh they do catch it, then app devs suck :-P
20:49 airlied: but I suppose they have to test on X11
20:50 bnieuwenhuizen: airlied: that said if the driver reports 2 instead of 3 then the app does everything "correct"
20:51 bnieuwenhuizen: airlied: so if they only tested on windows where to don't have to deal with the current semaphore/syncobj constraints it wouldn't help them find it
20:51 bnieuwenhuizen: where they don't*
20:53 danvet: bnieuwenhuizen, oh btw timeline syncobj for radv?
20:53 danvet: last time I looked wasn't there yet
20:53 bnieuwenhuizen: danvet: correct, was just working on them today ...
21:59 agd5f_: mdnavare, works for me