06:09 goutersean: Well GUD could do second display connector too or clone to any of the crtc's. But i think this patent/license jam is more related to driver signing and so called HDCP hw crypto, which is to say is creapy at best or malicous event to start with, considering project ultraviolet and such. Probably cable contains a flashable controller hw under the umbrella to protect media or content. But
06:09 goutersean: judges they build precedences as to how they want. But the code or IR of entire program that lives in registers will without cloning dump the key in none verbatim form though with a lot of effort but laws there are missing to blame anyone who did such event in theory, however during my life i learned that judges interpret the things however they want during trials i.e from the POV of who
06:09 goutersean: pays more.
07:00 travisgordon: and your logs at cbrill... on desktop browsers malfunction, they display at raw logs, but on android browsers also at main logs. The theory was fundamentally approved juridically correct in practice taken from Shors work, although your guys did not develop this method, however shor himself seems fine person,but I did, your quasimodo old farts stalked people , placed bombs, threattened to
07:00 travisgordon: knock me down, and suicidally scared away female and male customers from travelareas. I do not have to kill them off , chain of procecution could be ordered and place them closed doors, where they get anal so bad where their asshole is size of watermelon.
11:33 karenw: Is there a "dummies guide to using libdrm" anywhere on the internet? (Dummy being relative, I know a lot of GL/VK stuff, but very little drm/dri stuff)
11:43 Ermine: karenw: here's a talk on libdrm by emersion: https://www.youtube.com/watch?v=haes4_Xnc5Q (took that link from drm kernel docs)
11:45 karenw: Ermine: Thanks. Ill take a look! Like most low level things, documentation is scattered about and half my problem is not knowing what questions to ask of google.
12:11 Ermine: karenw: you may want also to read mesa code and how they utilize libdrm, for rendering side of things
12:12 zmike: bbrezillon: have you had time to look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31425
12:14 javierm: karenw: https://gitlab.freedesktop.org/daniels/kms-quads was also useful to me
12:19 bbrezillon: zmike: nope, sorry, I'm looking at it now
12:19 zmike: thx
12:21 zmike: bbrezillon: fwiw PIPE_CAP_VERTEX_ATTRIB_ELEMENT_ALIGNED_ONLY is the cap
12:24 nano-: zmike: Hope you're the correct person. Is it possible to statically link a native macOS (non-X11) application with zink and moltenvk to gain access to higher OpenGL version with -framework Metal as the dynamically linked part? Where does the gl-prefixed function versions come from? Is there any sample project that utilizes this?
12:24 zmike: I have no idea
12:24 zmike: I know nothing about macs, sorry
12:24 nano-: Ah, maybe the wrong zmike then :) Thought someone earlier pointed to a zmike :)
12:24 zmike: I'm the only one
12:24 zmike: but the person earlier might have assumed
12:28 karenw: nano-: AFAIK you really shouldn't statically link to MoltenVK and should get it working via the vulkan loader. (I have no idea on the zink side of things though, sounds like it would work in theory, but a lot of things work in theory)
12:29 nano-: Currently my entire app is statically linked with the help of vcpkg to avoid the bs with bundling stuff, so was hoping to keep it that way.
12:31 nano-: With mesa now building, in addition to libzink.a I also get a libglapi.dylib with all the gl symbols without the gl prefix which sounds a bit like loader-territory. A bit in the dark in this corner.
12:32 nano-: Not sure what parts I need to link to, no matter if dynamic or static :)
12:33 bbrezillon: zmike:that one is set to 1, but it doesn't seem to be the one you're testing
12:33 zmike: hmmm
12:33 bbrezillon: you seem to test PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY now
12:33 zmike: oh
12:33 bbrezillon: caps->buffer_stride_unaligned =
12:34 bbrezillon: !screen->get_param(screen,
12:34 bbrezillon: PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY);
12:34 zmike: huh.
12:34 zmike: ok
12:34 zmike: interesting
12:34 zmike: thanks for checking
12:34 bbrezillon: maybe add a caps->attrib_component_unaligned to the if () check you're dropping in the patch
12:35 zmike: I'm gonna have to do more investigation
12:35 zmike: maybe the patch is wrong
12:38 dliviu: hello, what's the best way to handle https://lore.kernel.org/r/20240920102802.2483367-1-liviu.dudau%40arm.com? Commit 641bb4394f40 got merged in -rc1
12:38 dliviu: should I push it to drm-misc-fixes?
12:50 karenw: nano-: By the loader I lean libvulkan.so (or whatever the equivlent of a .so is on macos). Staticly linking libvulkan is not supported. Linking directly to drivers link MoltenVK is also not supported. But "not supported" and "doesn't work" aren't the same thing so do whatever you think best. (If you need help with the moltenvk/vulkan setup side, you could pop onto the khronos discord. Although we know little about GL and Zink)
12:51 karenw: *drivers like
12:53 soreau: nano-: I have no idea about your setup but maybe you can dlopen the .dylib and look up the functions minus the prefix or something
12:58 travisgordon: it really does not matter what the platform like OS for any of the drivers is, because they stuffed EGL to the kernel, where all OSes collaborated to implement it. Arguably some desktop extensions would not work where as ES would , but api translation is easy, in my world, i am underwent huge depression and have not been productive enough on this code, but it is very simple.
12:58 travisgordon: am/have
13:05 zmike: bbrezillon: no, wait, the check for attrib_component_unaligned is above that
13:05 zmike: it is checked
13:16 travisgordon: the compression i developed is out of this world, it works very nicely, the idea was to keep the capacity of the hash hierarchies to yield invariant results of smaller weighted powers format. This puts the design of EGL based vulkan or openglES into prime position. Why angle so far does not translate this way around is ES glsl precision qualifiers being lower that of desktop GL, but
13:16 travisgordon: there is core exension texture float , and mixed with real code of mine that way translation is desirable, so technically it's very simple to get all vulkan opengl directx games running ontop of EGL and opengl ES or vulkan. To store a compressed format variable , there is a proof system and triple error avoidance by summing 440+443=883 adding third time index 115 to measured preallocated
13:16 travisgordon: power gives 26 and there is a table where linear algebra of 3 samples taken gives opportunity to eliminate one value of two previously separated, so that way millions of high precision values can be stuffed into hash and sent to display controller through a texture instruction.
13:18 travisgordon: It's just the technology is legit, but i do not want to piss off game companies, EA sports or whatever companies invest millions into gaming strategies, and it's really their choice if they want to offer their games on smartphones or not, not mine.
13:22 vsyrjala: pinchartl: did list_is_null() die in a bikeshed?
13:34 pinchartl: vsyrjala: I think so. I still like it though
13:34 pinchartl: if you'd like to resurect it, please be my guest :-)
13:34 pinchartl: maybe it's been long enough and whoever disliked it will have forgotten their opinion
13:34 vsyrjala: i thought i had a use for it, but after second thought maybe not. sounds like a reasonable thing to have though
13:42 karenw: So, if I am a normal X/Wayland application, and I want to create a drm buffer to pass to the compositor... If I understand right this can't be done in a gpu-driver agnostic way? (well, there's dumb buffers, but that looks like SHM with extra steps)
13:42 nano-: karenw: MoltenVK build system supports static linking at least. I'll mess around with some smaller test app to get more familiar. Thanks for the comments.
13:42 nano-: And should dig around a bit in the khronos discord as well, ty for that, didn't know of it.
13:49 Ermine: karenw: from what I understand there's some part of GEM API which is shared among drivers, but more sophisticated stuff will be GPU-specific
13:49 Ermine: (And I guess that sophistication will involve rendering, which is GPU-specific anyway)
13:49 emersion: karenw: normal X11/Wayland apps shouldn't use dumb buffers
13:50 emersion: dumb buffers are designed for KMS
13:51 Ermine: karenw: btw there's drm-memory(7) man page
13:52 karenw: emersion: Yeah, like I said, wl_shm exists for that
13:52 MrCooper: karenw: what's the motivation for allocating directly from DRM, instead of from Vulkan/EGL/GBM/... ?
13:52 karenw: MrCooper: Purely academmic
13:52 karenw: *academic
13:52 MrCooper: then yeah, there's no generic DRM API for this
13:53 emersion: there are driver-specific IOCTLs to allocate GPU memory
13:53 emersion: it's basically what GBM/Vulkan/etc end up doing
13:54 linkmauve: What does /dev/udmabuf improve over that btw?
13:54 MrCooper: nothing really?
13:54 linkmauve: Why did it get merged then?
13:55 MrCooper: it's just a generic way to get a dma-buf backed by system memory
13:55 MrCooper: it's useful for software rendering
13:55 linkmauve: So exactly like dumb buffers?
13:55 MrCooper: except usable for APIs which require a dma-buf fd
13:56 linkmauve: Ok.
13:58 emersion: dumb buffers are not necessarily system memory
14:00 MrCooper: right, in fact they normally aren't if the device has local memory
14:00 pq: I'd even say that dumb buffers are rarely ever system memory, and can often be slow for CPU access, especially for read access. The dumb buffer memory pool may also be more limited than others.
14:02 pq: I think even for UMA systems, they may have different CPU caching that normal system memory?
14:03 pq: *than
14:03 MrCooper: possibly, since they're primarily intended for KMS scanout
14:09 karenw: Exactly what is DRM, what is DRM-mode, what is GEM, and what is KMS all seems to blur a little the more I learn. All interlinked. :)
14:10 Ermine: So, all common APIs (dumb buffers, common part of GEM) can only allocate system RAM?
14:12 emersion: drm_mode is KMS
14:12 emersion: KMS is Kernel Mode-Setting
14:13 emersion: KMS is a part of DRM
14:13 pq: karenw, https://keyj.emphy.de/files/linuxgraphics_en.pdf seems to be an old decoder ring, and probably ok even if it has lots of old things.
14:15 MrCooper: Ermine: per above, dumb buffers aren't necessarily backed by system RAM
14:16 karenw: Ermine: There is no common DRM_IOCTL_GEM_CREATE afaict. You have to call IOCTL_RADEON_GEM_CREATE or equivlent.
14:20 zmike: bbrezillon: I think panfrost is still setting one of those caps improperly 🤔
15:50 bbrezillon: zmike: could be
15:51 zmike: unfortunately I don't have any ARM hardware or I'd test
16:19 bbrezillon: zmike: I'll have a look tomorrow morning
16:19 zmike: cool thanks
17:13 karenw: So, what exactly is a DRM-Buf? Term keeps popping up. Something more general than dri?
17:14 zmike: bbrezillon: 💪
17:14 zmike: and yeah I hate pipe caps
17:16 zmike: a good cleanup would be to go through all the drivers and delete all cases where drivers unconditionally export the defaults from u_screen
17:16 zmike: then at least we could easily see which drivers actually use caps or if they can be deleted
17:19 zmike: I'll make an issue and maybe people will reply...
17:19 K900: Do you mean DMABUF?
17:21 karenw: Yes I do, I appear to have acronym exhaustion trying to understand this stuff
17:21 karenw: Too many TLAs starting with D around linux graphics.
17:22 alanc: I wonder how much of https://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf still applies 12 years later
17:24 zmike: mareko: re-ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31425
17:27 karenw: alanc: I can't tell you as fd.o is exploding
17:27 karenw: I will file it in my "to read when fd.o stops exploding" pile.
17:29 alanc: yeah, I seem to have been lucky in loading it and not getting timed out
17:40 karenw: Seems accurate to what I know so far, with the bigg exclusion of not mentioning Wayland at all. (Also links have bitrotted, I don't think the author wanted to linux-fbdev.org to be gambling ads)
17:59 Company: karenw: an important thing from the client side is that dmabufs are the handles that clients use to exchange references to VRAM
18:00 Company: both in-process between different libraries and inter-process (the Wayland example but also VMs and browsers)
18:01 Company: which has been a development in the last 1-2 years I think
18:01 Company: where it is replacing GL texture ids for in-process and shm (mostly I think) for inter-process
18:27 karenw: But there's no device-agnostic way to create those buffers. But from e.g. a wayland compositor's pov they are device agnostic to be scanned out to the screen/composited image?
18:27 nano-: This time around I tried to replicate https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/.github/workflows/macos.yml .. it unfortunately depends on a number of x11 things, but I'm just exploring. It first failed due to a bad include guard around dri_common.h in glxext.c which was easy enough to fix given the guards on function calls further down, but later on it fails in kopper_allocate_textures which
18:27 nano-: calls missing loader_dri3_get_pixmap_buffer which source file is not enabled on macos. Also feels like a bad corner, I don't want x11, but I somehow want gl-prefixed functions and this configuration would produce egl according to config output which I think would do that.
18:28 karenw: (At least with common formats, there could be device-specific formats or modifiers but an application can only make those with consent)
18:39 Company: karenw: yes, you need some kind of device to create them - there's /dev/udmabuf these days that we recently started using in Gnome CI after llvmpipe gained support for it
18:41 Company: dj-death: I am curious about the Intel GL driver, maybe you can tell me: I did an optimization to avoid flushes to speed up llvmpipe in GTK - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7753 - and did some general benchmarking afterwards
18:42 Company: dj-death: and the Intel driver was one that saw absolutely no change, even though radeonsi and asahi do see slight gains. Have you guys optimized flushes so much?
20:26 dj-death: Company: not really the area I'm most familiar with
20:27 Company: you know who might know?
20:27 Company: in the end I'm just curious, it's not important in any way
20:27 dj-death: maybe Kayden
20:28 dj-death: not quite sure why uploading causes flushes tbh
20:29 dj-death: as long as you don't read back you can keep everything pipelines
20:29 dj-death: pipelined
20:29 airlied: not sure llvmpipe handles buffer replacement that well
20:29 Company: no idea, that's a question for you guys
20:30 Company: but it benefited radeonsi and asahi, too
20:31 Company: this is just my attempt at replacing VkPushConstants
20:32 dj-death: but this is GL?
20:32 Company: yeah, it's my GL emulation of push constants
20:33 dj-death: ah okay
20:33 dj-death: oh yeah
20:33 Company: I think the original code was copied from some website where people claimed it should just work with small buffers
20:33 dj-death: Kayden did a bunch of work for suballocations
20:33 dj-death: maybe that helps
20:33 Company: so I was wondering if Intel maybe optimized that
20:34 dj-death: we suballocates 2MB buffers in Iris I think
20:34 dj-death: but that was for a different reason
20:35 Company: but I have no idea how many engines use push constants and want a GL equivalent
20:35 Company: because the few Vulkan people I've talked to in recent times all went "omg, don't use push constants, nobody optimizes them"
20:36 dj-death: huh
20:36 dj-death: you spoke to AMD people?
20:36 Company: hehe, no
20:36 Company: Android and GStreamer people
20:36 dj-death: Intel has special bits of HW for push constants
20:37 dj-death: it's only on DG2+ where compute/mesh/ray-tracing doesn't have it
20:37 dj-death: but the other stages still do
20:38 airlied: nobody optimises them because they are already fast :-P
20:38 Company: I might be looking into doing that buffer thing for Vulkan, too - maybe that speeds things up on some drivers
20:39 Company: airlied: in that case, maybe gallium should use them for small buffers?
20:39 airlied: the problem isn't the small buffers, it's the overwriting of the contents of the small buffers
20:39 airlied: while those contents are in use
20:40 airlied: I think we often try to pipeline those operations, but I'm guessing we don't always
20:40 airlied: the hw that is used for push constants is used by GL drivers for UBOs usuall
20:41 Company: that is a UBO
20:43 Lynne: is there still no way to trigger an rgp trace for compute-only programs?
20:44 ccr: somehow I read that as "RGB trace" and wondered what that could be
20:51 Company: airlied: I just figured out why the asahi numbers are so bad in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7753
20:52 Company: airlied: apparently llvmpipe doesn't spawn enough threads to make the M2 Ultra go into performance mode
20:52 Company: airlied: with LP_NUM_THREADS=32 on the 8 + 16 core machine, llvmpipe does 120fps instead of 80fps
20:53 Company: is that an llvmpipe problem or a kernel power management issue?
21:01 jannau: does the benchmark application take a significant amount of time for submission? i.e. is the CPU utilization of the llvmpipe threads significantly less than 100%
21:07 airlied: Company: likely a bit of both
21:12 Company: jannau: it's slightly above 50% apparently
22:04 Kayden: Company: hmm. that is a bit surprising
22:05 Kayden: asahi doesn't seem to have u_threaded_context unless I'm missing something
22:05 Kayden: iris and radeonsi both use that, and u_threaded_context has some promotion of things to async maps
22:05 Kayden: and automatic replacement of the backing storage when you overwrite the entire buffer
22:06 Kayden: iris should do that with GALLIUM_THREAD=0 too, since I'd implemented it first
22:07 Kayden: radeonsi has fancier buffer handling than iris - it has callbacks for detecting idle buffers and reusing objects. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18880 implemented that for iris 2 years ago but nobody ever reviewed it
22:07 Kayden: not sure I ever saw any improvements from it either
22:08 Kayden: radeonsi also has CPU-side storage for buffers in some cases, which...I remember alyssa and I looking at a few corner cases of, and being uncomfortable with the idea, so we never did it
22:08 Kayden: so I guess I could see the results being different between the three drivers, at any rate
22:09 Kayden: but yeah if you were overwriting an entire buffer object, we've long allocated new storage to avoid stalls there
22:09 Kayden: or even a range you had never written anything to (so the existing contents cannot matter)
22:10 Kayden: (in that case we'd promote to async mappings)
22:10 Company: makes sense
22:11 Company: any idea what the best emulation for vk push constants is with GL?
22:11 Company: in a general GL sense I mean, not specific to any drivers (or even Mesa)
22:11 dj-death: ubos should be promoted to push constants
22:13 Company: yet apparently only Intel gets that right
22:14 Company: (or I suck at measuring, which is also a possible option, because my benchmarks are nowhere near perfect and I'm basically just looking at GALLIUM_HUD)
22:22 Kayden: hmm, yeah, Intel promotes UBOs to push constants
22:22 Kayden: but maybe others don't
22:23 Kayden: I know i965 did better for regular glUniforms because it had to upload them
22:23 Kayden: so it could just decide to go push
22:23 Kayden: whereas UBOs are already uploaded
22:23 Kayden: but I don't think I'd recommend using those, they're kinda legacy and terrible
22:24 Kayden: not sure what other drivers do for push constants. we have a dedicated thing that pre-loads registers with data on thread spawn
22:43 karolherbst: at least on nvidia none of this matters, because there are only ubos
23:35 Company: karolherbst: does that mean on Vulkan I might want to use that one-buffer-for-all-globals thing, too and avoid push constants?
23:42 karenw: Disclaimer: I am a hobby vulkan dev and not a dri dev. My understanding is on nvidia you have UBOs which are faster than read-only SBOs, and push constants are just implemented as UBOs. On other hardware you do have push constants (small but extremely fast) but UBOs have no perf advantage over readonly SBOs.
23:47 Company: I think I'll just try it when I get around to it, just to see what happens
23:53 karenw: As I often end conversations on the Khronos Vulkan Discord. "tl;dr: It Depends; Profile It"