02:04 <hipboi> @narmstrong thanks, acs issue is resolved, now we have mainline u-boot booting on the Zero.

02:10 <hipboi> It seems the S905Y2 dram freq can only ram at 972MHz even we have 3200 LPDDR4

02:10 <hipboi> s/ram/run

06:36 <narmstrong> Not sure it supports lpddr4 3200, the freq should be close to 1600mhz, I don’t think it’s supported

07:24 <narmstrong> alyssa: the only know issue is a observed crash reported at https://lore.kernel.org/linux-amlogic/40ca11f84b7cdbfb9ad2ddd480cb204a@agner.ch/

10:25 <gru___> i have an arm64 odroid hc4. after installing docker-ce on debian i get oops in my dmesg: https://pastebin.com/jMzj93Nh

10:25 <gru___> someone knows what is wrong?

13:03 <ndufresne> benjamin545: yeah, at 4k the GPU could be limiting factor, but glimagesink is also not very optmized, it's known to do CSC in an FBO, and then FBO to display (two pass), and that consumes twice the bandwidth

13:04 <ndufresne> I really hope to be able to work on that at some point, but it looks like quite some work, I think gstgl needs some sort of reduced scenegraph (with ability to combine shader programs)

13:23 <alyssa> narmstrong: Looks plausible

13:23 <alyssa> "It seems load and/or hardware dependent since we see it on some devices

13:23 <alyssa> quite frequent (every few days), and on others it takes multiple weeks.

13:23 <alyssa> Of course the once we see it frequently are the ones in production :).

13:23 <alyssa> ---

13:24 <alyssa> I use my N2 to run the GLES conformance tests, so plenty of CPU/GPU load. And if this is network related, err, it's over Ethernet and I'm pushing giant unstripped debug builds of mesa (50MB+) over scp constantly when it's up..

13:25 <narmstrong> could be DVFS related, maybe reducing max CPU freq or switching to performance governor to reduce dvfs switchings

13:26 <alyssa> Hmm, ok

13:27 <alyssa> FWIW kernel is ffa52910faff64f2070af42c22d782c4572d889e + some panfrost patches

15:41 <benjamin545> ndufresne: what i really want is to avoid gl all together, gstreamer with the kmssink seems to be able to push NV12 frames out to the video plane of the device (speaking of 1080, i understand issue with 4k) im just stuck trying to figure out how to get the video plane out to the hdmi display

16:23 <ndufresne> benjamin545: is the display capable of 4K ?

16:23 <ndufresne> iirc, there is some limitation both VPU and display on these cheap HW

16:24 <ndufresne> benjamin545: oh, and to workaround some issue in kmssink (like the fact its using non-atomic API :-() you can add ! queue max-size-bytes=0 ! kmssink

16:25 <ndufresne> if still halving the rate, then comment out the waiting for vblank, as the amlogic driver is atomic, it already sync in the legacy compat layer

16:25 <ndufresne> there is patches pending to port to atomic API, but not yet ready to be merged (code quality is +-)

17:06 <benjamin545> ndufresne: the monitor is have connected is not 4k capable, sorry, I know i brought up 2 different things. I am ignoring 4k right now, it just brought me to the limitations of the hardware when using gl to work around the main issue I am having. what i really want to do is avoid gl all together and have the hardware decoder pass NV12 to the display hardware, the example given in the link I posted had ! videoconvert take the NV1

17:06 <benjamin545> nd turn it into BGA to put it out on the display using a non video plane. I can get gstreamer to output to a video plane directly as NV12 without using ! videoconvert, I just do not know how to get this plane to render out to the display (or I guess to even test if the data is getting to the plane at all)

17:50 <ndufresne> benjamin545: I see, that's because the primary is on top, it's pretty far in my memory how one could workaround, in an ideal world, gst would put a transparent fb onto that primary plane

18:40 <ndufresne> Just booted my le-potato, I used to move the primary plane location, but can't get that to work

19:38 <benjamin545> ndufresne: when i run modetest, it outputs some information about the planes, for the primary plane, it lists it as id: 34, crtc: 40, fb: 41. for the video plane, it shows it as id: 37, crtc: 0, fb: 0

19:38 <benjamin545> i feel like i would expect to see the video plane have the same crtc and/or fb values as the primary plane.

19:40 <ndufresne> fb: 0 means unset

19:40 <ndufresne> fb: 41 is likely from fbcon

19:40 <ndufresne> notice it's in XR24 format, so opaque

19:41 <benjamin545> so would we want to see fb set?

19:43 <benjamin545> oh, ok when actually video playing it is set set

19:45 <ndufresne> you might like the output of sudo cat /sys/kernel/debug/dri/0/state

19:46 <ndufresne> you can unbind the fbcon if it's in the way, echo 0 > /sys/class/vtconsole/vtcon1/bind

19:57 <ndufresne> benjamin545: fyi, I manage to get something visible, modetest -M meson -F plain -s 34@39:3840x2160@AR24 -d &

19:57 <ndufresne> might need to adjust for your settings, 34 is HDMI connector here, and 39 is the CRTC

19:58 <ndufresne> remaining issue, is that there is some colors in the plain pattern

20:01 <benjamin545> oh wow, that did it, i used sudo modetest -M meson -F plain -s 32@40:1920x1080@AR24 -d &

20:01 <ndufresne> here I got some film over the video, but good enough to PoC the HW capability

20:02 <ndufresne> it should not be too hard to enhance kmssink to handle that

20:02 <ndufresne> long term on HW like this, we would like to render text overlay on that primary plane, so we'llneed to find it anyway sooner or later

20:03 <benjamin545> so its playing, im using a 15mbps jellyfish sample, the colors seem washed out, like it has a transparency applied

20:04 <ndufresne> yeah, since -F plain, is not fully black

20:04 <ndufresne> and alpha blending is premult

20:05 <benjamin545> right that makes sense

20:05 <ndufresne> e.g. having alpha = 0 is not sufficient to be fully transparent on most HW composer

20:06 <benjamin545> so with this setup, is it mixing the primary and video plane?

20:06 <ndufresne> yes

20:07 <ndufresne> I lack a bit of knowledge of this specific HW to tell you the right way forward

20:07 <ndufresne> I found that by hacking my way around what I saw

20:07 <ndufresne> if fbcon had picked AR24 format, we could have done dd if=/dev/zero of=/dev/fb0

20:09 <benjamin545> ok ,so zeroing out the primary plane is not setting it as transparent, but, there should be some value that would be transparent in that colorspace?

20:12 <ndufresne> no, I mean modetest is not zero-ing out the plane

20:13 <benjamin545> oh, ok

20:13 <benjamin545> so i need to find a way to zero out the primary plane

20:14 <benjamin545> by the way, playing a 4k file worked just fine in this setup

20:16 <ndufresne> see what fill_plain does, https://gitlab.freedesktop.org/mesa/drm/-/blob/master/tests/util/pattern.c#L1092

20:16 <ndufresne> yeah, I notice it seems fine

20:17 <ndufresne> libdrm is fast to build, you could just install a compiler on target, and edit that to memset(planes[0], 0x0, stride * height);