02:54 DrNick: does nvidia keep GL ID's densely packed? i.e. if you generate three texture IDs, delete the second, and then generate a fourth texture ID, will the fourth ID have the same value as the second ID?
02:56 DrNick: and the same question for AMD on Windows and Apple
03:04 HdkR: DrNick: You can't ever rely on that
03:04 DrNick: oh, I know, I'm asking if they do that
03:08 HdkR: I don't believe there is much ID reuse there but I haven't explicitly tested
03:09 HdkR: GL compatibility allows some terrible acts around texture IDs though, watch out there
04:07 jpark: bnieuwenhuizen: opened a merge request to clean up some warnings. let me know if there are any problems with it.
07:28 ManDay: Following up on https://bugs.gentoo.org/717352 - does this problem exit upstream or does Gentoo not configure mesa correctly?
07:29 ManDay: I.e. does MESA correctly export EGL_NO_X11 in the right configuration?
08:38 sravn: pinchartl: any plans to merge "Converter R-Car DU to the DRM bridge connector helper"? Except for a few details in the last patches it looks ready. Maybe land the first 22 patches now?
09:25 ManDay: any comment on EGL_NO_X11 ?
13:36 pinchartl: sravn: I was thinking of sending a new version to address the minor issues, and then sending a pull request for the whole. already merging the firts 22 patches seems like a good idea, would you like to push them ?
16:59 sravn: pinchartl: Will take a closer look tonight. "[PATCH 08/27] drm: rcar-du: lvds: Convert to DRM panel bridge helper will have to wait - as it is missing review and I expect you to apply rcar-du patches in the rcar tree anyway
17:53 jpark: looking at the mesa vulkan overlay layer, is it thread-safe to call QueueSubmit on graphic_queue if it's not equal to present_queue? i wouldn't think it is.
18:19 dj-death: jpark: thread-safe relative to what?
18:20 dj-death: jpark: or you mean having the layer internally calling QueueSubmit on a different queue than the one given to QueuePresent?
19:00 jpark: yeah, the application/game could potentially be using that queue at the same time.
19:02 jpark: dj-death: the present queue should be safe because it's passed in as a parameter to vkQueuePresentKHR, which guarantees that it was externally synchronized.
19:03 jpark: but interally calling QueueSubmit on any other queue seems problematic
19:24 airlied: jpark: i agreeseems dangerous
20:20 sravn: pinchartl: had to do something non-Linux, maybe tomorrow
20:23 jenatali: jekstrand, karolherbst: Thought you guys might like to know, I decided to try to hook up printf using the 2-src approach and a pointer-to-struct for the args. Works quite well and wasn't much code at all, either for emitting or lowering
20:24 karolherbst: cool
20:25 pinchartl: sravn: no hurry. and it's Sunday, you shouldn't even be here
20:25 pinchartl: (neither should I...)
20:54 sravn: pinchartl: On a workday I then to do more work stuff, Linux stuff is pure hobby
21:43 jpark: airlied: thanks, i filed an issue for it.
23:20 karolherbst: ehhhh
23:20 karolherbst: I couldn't merge this branch: Merge request was rejected by GitLab: 'Branch cannot be merged'
23:20 karolherbst: heh?
23:20 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5576
23:20 bnieuwenhuizen: karolherbst: retry
23:20 karolherbst: right
23:20 karolherbst: but what went wrong? :D
23:20 airlied: gitlab bug
23:20 karolherbst: ahh
23:21 airlied: current fix is to just retry :-P
23:21 karolherbst: at least the retry is fast
23:51 clever: ive created my own drmModeModeInfo on the stack, filled in all of the fields, and passed it to drmModeSetCrtc, but i get EINVAL back, how can i debug it further?
23:52 imirkin_: check dmesg
23:52 clever: [ 15.195201] [drm] Cannot find any crtc or sizes
23:53 clever: 1631 if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
23:53 clever: 1632 DRM_INFO("Cannot find any crtc or sizes\n");
23:55 clever: imirkin_: hmmm, but that error doesnt repeat when i run drmModeModeInfo again, it may be unrelated, or it may be problems at boot with the driver, what should i check next...
23:59 imirkin_: that error is probably on load though
23:59 imirkin_: not when you run your program