10:51 <ad__> hi, i think i have finally etnaviv/coda up and running on 5.4, how can i test it ?

10:52 <ad__> on /dev/dri i see by-path/ card0 renderD128

11:03 <mntmn> ad__: kmscube for example

11:03 <mntmn> ad__: but normally you should have two cardX files... one for the display and one for the gpu

11:04 <ad__> mntmn, ok, i suspected is not up properly. so i miss the cardX for the displau seems

11:05 <mntmn> ad__: do you have any display output, do you have /dev/fb0?

11:05 <mntmn> ad__: on imx6 if i remember correctly the display driver is ipuv3

11:05 <ad__> no, i am on imx6, do i still need fb nodes in devicetree ?

11:06 <mntmn> depends on what kind of display you're using

11:06 <ad__> board has 2 displays, main is lvds, second (backup) hdmi

11:06 <mntmn> so, do you have output on lvds or hdmi?

11:06 <mntmn> this is independent from gpu

11:06 <mntmn> you should have a basic framebuffer up

11:20 <ad__> mm my understanding is that a drm/dri driver is different from framebuffer, correct ?

11:23 <lynxeye> ad__: Yes, two different things. But if you have DRM_FB_EMULATION enabled in your config, the kernel will provide a framebuffer device on top of the DRM one.

11:24 <lynxeye> For i.MX& you need IMX_DRM for the display side and at least DRM_IMX_LDB for LVDS and DRM_IMX_HDMI for the HDMI youtput.

11:32 <ad__> lynxeye, i am in kernel 5.4, don't see any CONFIG_IMX_DRM, but DRM_IMX_IPUV3 DRM_IMX_HDMI

11:33 <ad__> both are enabled

11:33 <ad__> DRM_IMX_LDB is "n" maybe i miss that

11:36 <lynxeye> ad__: imx-drm is a composite device. The DRM device will not be exposed to userspace until all the parts of the display pipeline listed as enabled in your board DT have a driver probed. So if LVDS is enabled in the DT, you need the LDB driver.

11:43 <ad__> lynxeye, thanks. Adding DRM_IMX_LDB worked but getting now a kernel panic

11:43 <ad__> https://pastecode.io/s/ca5x9muu

11:46 <lynxeye> ad__: Hm, I don't recognize that one. I know that we had some issues with DRM object lifetime in the past, but don't know when it was fixed. BTW: why are you running an ancient 5.4 kernel?

11:46 <ad__> it's something required from some constrains

11:47 <ad__> i can't easily move to upgrade

12:19 <ad__> lynxeye, video is up and running now

12:19 <ad__> thanks

12:19 <mntmn> ad__: how did you fix the panic?

12:20 <mntmn> (just curious)

12:23 <ad__> a generic lvds panel driver was missing

12:23 <ad__> (meuconfig) in theory i think kernel should not crash in this way, but ok

12:24 <mntmn> i see, cool

12:24 <ad__> so now i need to adapt yocto side for etnaviv in place of vivante

20:01 <pbaggett> Hi all! I'm working on a RG350M handheld (GC860) and I was wondering if I can disable waiting for the vblank using DRM_MODE_PAGE_FLIP_ASYNC.

20:02 <pbaggett> Using drmModePageFlip() with DRM_MODE_PAGE_FLIP_EVENT seems to work, but changing it to DRM_MODE_PAGE_FLIP_ASYNC doesn't.

20:03 <pbaggett> That is to say, I'm OK with tearing and I'd rather not wait.

20:09 <sravn> pcercuei: ^

20:40 <pcercuei> pbaggett: use the atomic API

20:56 <pbaggett> The atomic API allows tearing buffer swaps?

21:13 <pcercuei> it allows you to queue commits asynchronously

21:16 <pcercuei> Then I think your DRM commit will happen on the next vblank

21:16 <pcercuei> But you don't have to wait for it

21:18 <pbaggett> Hmm...ok. I think I need to take a step back. I noticed that my game runs at ~30 FPS on the RG350M when using the 640x480 @ 60 Hz mode, then 25 FPS on the 50 Hz mode. If I don't draw as much stuff (even if trivial), I get ~60 / ~50 FPS.

21:19 <pbaggett> This makes me think that there is either some kind of internal driver stalling or a vsync wait that is taking too long.

21:19 <pbaggett> To narrow it down, I wanted to disable vsync in my rendering.

21:20 <JohnnyonFlame> pbaggett: what is "too much stuff" here

21:21 <pcercuei> Are you using SDL1? SDL2?

21:21 <pbaggett> OpenGL ES 2.0 + GBM

21:22 <JohnnyonFlame> if you don't batch draw calls a simple text UI can easily add 70ms to your frametime

21:23 <pcercuei> I guess you can disable vsync in GBM, no?

21:23 <pbaggett> I have a couple of static VBOs / IBOs. No changes to data. I have about 15-19 glDrawElements() calls per frame.

21:24 <pbaggett> I implemented psuedo instancing to reduce the draw calls from an absurd number of small meshes (220-250) down to these 15 or so.

21:24 <pbaggett> I have n copies of a mesh with position.w as the instance id. The instance id acts an index into the transform matrices.

21:24 <pbaggett> Mesh here means like 10-15 triangles.

21:25 <JohnnyonFlame> okay, that's very good

21:25 <pbaggett> What I can't understand is why I get either 30 FPS /or/ 60 FPS

21:25 <JohnnyonFlame> oh

21:26 <JohnnyonFlame> enable vsync completely

21:26 <pbaggett> the 60 FPS is only if I disable those 15 glDrawElements() calls

21:26 <JohnnyonFlame> I've seen this behavior on SDL2's implementation - it will drop frames if you dont

21:27 <pbaggett> what does "enable vsync completely" mean though?

21:27 <JohnnyonFlame> /s/complety//

21:27 <JohnnyonFlame> brain farted

21:28 <pbaggett> I still don't follow.

21:28 <pbaggett> I have used drmModePageFlip() -- shouldn't that wait for the vblank?

21:28 <pcercuei> JohnnyonFlame: he wants to *disable* vsync

21:28 <JohnnyonFlame> can you do that on KMS?

21:29 <pcercuei> You can do async updates

21:29 <JohnnyonFlame> I recall trying and reading some discussions claiming that this is an unfortunate design issue, and recommending triple buffering instead

21:30 <JohnnyonFlame> at least with triple buffering vs double it won't lock to factors of your refresh rate

21:31 <pbaggett> I actually don't know how to implement triple buffering with the GBM API, but it sounds like something I can try.

21:31 <pbaggett> Can there be any other reason that you can think of why I might be seeing a stall like this?

21:32 <JohnnyonFlame> I can think of reasons for it dropping under 60, but not for locking to factors of your refresh rate

21:34 <JohnnyonFlame> idk if it helps you, but in SDL1.2 we're using this implementation for triple buffering: https://github.com/OpenDingux/SDL/blob/SDL-1.2/src/video/kmsdrm/SDL_kmsdrmvideo.c#L681

21:37 <pcercuei> pbaggett: how do you call drmModePageFlip()?

21:46 <pcercuei> You probably want DRM_MODE_ATOMIC_NONBLOCK, but that's only for the atomic API

23:07 <pbaggett> I started DRM_MODE_PAGE_FLIP_EVENT + waiting on vblank event. I changed to DRM_MODE_PAGE_FLIP_ASYNC and got invalid arg.

23:08 <pbaggett> I've also tried drmModeSetCrtc() but it doesn't seem to have any notable difference in my app compared to drmModePageFlip() + DRM_MODE_PAGE_FLIP_EVENT.