00:20tarceri: all good figured it out
01:03Lightsword: anyone know where there aren't chip_ids for the iris driver(https://github.com/mesa3d/mesa/blob/mesa-19.3.2/src/loader/pci_id_driver_map.h#L70) it seems that mesa is trying to load the iris driver for incompatible hardware due to that being missing
01:09Kayden: Lightsword: The idea is to use iris for any 0x8086 (Intel) PCI vendor that isn't explicitly listed in i915_chip_ids or i965_chip_ids
01:09Kayden: so, future hardware
01:09Kayden: radeon does the same thing - r100/200/300/600 chip ids, then radeonsi claims everything else
01:10kisak: Lightsword: was iris getting picked for non-intel hardware?
01:10Lightsword: Kayden, what about hardware with pci vendor ID 0x8086 that is not compatible with iris, i915 or i965?
01:11Kayden: what hardware would that be?
01:11Kayden: those are the only drivers we have, so...
01:11Lightsword: Kayden, yeah, gma500
01:11Lightsword: which I was trying to get working with swrast
01:12Lightsword: but mesa kept trying to incorrectly load iris for it
01:12imirkin: Kayden: should probably check that the drm driver == i915 in the loader
01:12idr: I bet i740 would have the same problem.
01:12idr:runs and hides...
01:12kisak: Lightsword: as an immediate workaround, you can probably globally export LIBGL_ALWAYS_SOFTWARE
01:13Kayden: ok, yeah, I guess that's a problem
01:13Lightsword: unconditionally loading iris for pci vendor ID 0x8086 for unknown hardware seems kinda broken
01:13Kayden: X recently changed to do that as well
01:14Lightsword: so guess it needs to be fixed there as well?
01:14Kayden: radeon started that trend, but I guess they enumerate all hardware now
01:14Kayden: whereas intel doesn't
01:15Lightsword: the gallium swrast driver should be the best for use with gma500 right?
01:20idr: Yeah... enumerating everything /known/ would be safer in case someone boots an old distro on too new hardware.
01:21Lightsword: are all i915_chip_ids compatible with iris?
01:21Kayden: maybe https://gitlab.freedesktop.org/kwg/mesa/commit/d7b098b59d1ceacd2af2737aa29b97ec5eab6259 will help
01:22Kayden: it does imirkin's suggestion
01:22imirkin: we do something sorta-like that for nouveau
01:22imirkin: (we actually call a nouveau-private ioctl to get "more info" about the chip, and if that fails, then the whole load fails too)
01:22Lightsword: Kayden, sec, will test
01:25Kayden: imirkin: the code for that is in pci_id_driver_map.c, which...I was going to put this there, but I wanted the loader function that's static, and it's only ever included by loader.c, so....*shrug*
01:29imirkin: Kayden: yeah whatever. we have to differentiate between nouveau_vieux and nouveau
01:29imirkin: and didn't want to enumerate
01:30imirkin: (and i wanted my little hack override to load nouveau_vieux for nv3x's
01:30Kayden: alternatives here would be to enumerate all 7xx and imagination intel hardware and just say "no, go away" (seems iffy) or...enumerate all iris devices, which...honestly wouldn't be that bad
01:32Kayden: we did it this way because it was easier, but the old way wasn't really particularly painful
01:32Kayden: though I would need to rework the prefer-iris stuff if we did it that way again
01:32Lightsword: Kayden, seemed to work, it's not loading iris anymore
01:32Kayden: since right now prefer-iris=true doesn't affect iris at all, it just tells i965 to piss off
01:33Lightsword: Jan 28 01:29:15 buildroot weston: pci id for fd 12: 8086:0be2, driver (null)
01:34Kayden: ok cool, I'll run it through CI just in case and then open an MR for that
01:34Kayden: thanks, honestly had never thought about this problem :)
08:33SirCodesAlot: hello, Is it possible to build only src/dbm, and its dependencies, using meson? I am attempting to build it along with libdrm and libkms (which I have built) for raspberry pi.
08:41SirCodesAlot: I think I may have found my answer in https://gitlab.freedesktop.org/mesa/mesa/blob/master/meson_options.txt, specifically by disabling what I don't want, and enabling gbm.. .. perhaps with -Doption=value.
08:52daniels: anholt: not built-in, no https://docs.lavasoftware.org/lava/publishing-artifacts.html
09:11SirCodesAlot: cool. I think I've got the project building using anholt's instructions; after removing x11 support. just need to rebuild SDL2, my app, and verify i'm its using kmsdrm
09:17SirCodesAlot: wow gbm requires libexpat.
09:19HdkR: drirc is xml so that sounsd like it makes sense
09:21SirCodesAlot: yeah, it is for xml.. the unresolved symbols I see are all prefixed with XML_*. I suppose gbm must consume some configuration files written in xml or something.
09:43SirCodesAlot: hm. I don't see an option in meson_options.txt to change the rpath
09:58SirCodesAlot: interesting. my main loop on my test app appears to be triggered now at the refresh rate (or near it).. previously with the rpi driver and software renderer it would update as quickly as the processor could move along. I need to figure out whats going on with the runpath issue. As a work around I had to create my build directory on my rpi so my app could find lib/dri/vc4_dri.so. I guess I don't remember if libraries contain
09:58SirCodesAlot: runpaths, or just executables. Perhaps its the .la file or pkconfig/libdrm_vc4.pc that needs to be changed
09:59SirCodesAlot: anyway, its way too late for me. I think I made pretty good progress. turns out mesa is reasonably easy to cross compile :)
10:02MrCooper: SirCodesAlot: the search path for *_dri.so is controlled by the dri-search-path option (which defaults to the value of the dri-drivers-path option, which defaults to $libdir/dri)
10:03SirCodesAlot: MrCooper: ah. thanks. I see that now in meson_optionx.txt. I update that tomorrow. thanks
10:51ascent12: Is there any reason that DRM_IOCTL_GET_UNIQUE isn't allowed for render nodes?
10:51ascent12: Also, is it even a good idea to use that at all?
11:01pq: ascent12, what would you use it for?
11:02ascent12: pq: I was wondering if it was a suitable way to refer to devices in a way independent of the primary/render node, but it appears to not be.
11:03pq: I think it's a hint for which userspace driver module to load in Mesa and/or Xorg... or something like that
11:04ascent12: Yeah, it pops up in drmOpenWithType and drmGetBusid.
11:04pq: and I would hazard a guess that it has been deprecated, since userspace can have multiple different drivers for the same chip and the kernel can't know them
11:05pq: if you need to identify devices, use the udev PATH thing whatwasit, I'd say
11:05ascent12: I don't think the 'unique' property is tied to drivers though. Looking at the kernel source, it's taken from the device name. Looking at debugfs, mine is 0000:07:00.0
11:06pq: oh, huh
11:06pq: not what I guessed, then
11:06ascent12: (But it can be overridden by drivers, which virtio is the only one)
11:07pq: Have you looked into the modern device API in libdrm? The thing younger than ten years.
11:09pq: whatever you do, stay away from anything that goes to drmOpenByName() :-P
11:10ascent12: Yeah, definitely. busid/unique would've been appealing though, because you could've treated it as an opaque string, and a kernel "source of truth" would've been good.
11:11pq: aha, "get the bus id": https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L120
11:12pq: heh, read the doc above in that link :-p
11:12ascent12: Yeah, a bit of a mess. Old drm is weird.
11:14pq: I suspect busid as used there assumes it's PCI, which is not universally true
11:42ascent12: Hmm, I wonder if it's worth pushing for a serialization of a drmDevice.
11:45emersion: ah, get a path to refer to it?
11:46ascent12: something like 'pci-0000:07:00.0' that udev and other stuff already uses.
11:46emersion: i see
11:46ascent12: Obviously not tied to PCI.
11:48ascent12: If it's a libdrm function, it can easily be extended if more types of buses appear.
12:02pq: ascent12, sounds like a good idea to me.
13:23karolherbst: is there a reason we have mesa-demos example requiring GL_EXT_geometry_shader4 even though we don't support this extension in mesa at all?
13:25karolherbst: mhh, I guess nobody knows and I think we can still just ignore that extension
13:26imirkin: probably written before GL3.2
13:27karolherbst: well, it was added 9 years ago :)
13:28imirkin: GL3.2 was 2009 =/
13:28imirkin: but dunno when driver support appeareed
13:29karolherbst: I have also no idea if anything uses that extension
13:29karolherbst: probably not but...
13:30imirkin: well, i think it had been around well before 3.2
13:31imirkin: it shipped with the original G80 release (2006)
13:31karolherbst: "Is there a chance to see GL_ARB_geometry_shader4 in mesa? This is the adventage of proprietary drivers over mesa drivers. We use it in Supertuxkart for drawing shadows." .. I hope they moved over to 3.2 already..
13:31karolherbst: this comment was from 2016 though
13:31karolherbst: but I guess they use geometry shaders, not that extension
13:33karolherbst: I guess one could use that extension to expose geometry shaders on hardware not doing 3.2
13:33imirkin: mostly it's older software
16:16linkmauve: Hi, I found a typo in GL_KHR_debug: section 5.5.2 mentions that asynchronous debug output is further described in section 5.5.6, while it actually is section 5.5.7.
16:17linkmauve: Could someone with Khronos access report or fix it?
16:20kisak: looks like you can make an issue report at https://github.com/KhronosGroup/OpenGL-Registry/issues referencing https://github.com/KhronosGroup/OpenGL-Registry/blob/6f5d3d001644fcb881e862ab7a0faafc576924d8/extensions/KHR/KHR_debug.txt#L575
16:21linkmauve: Oh, I didn’t know that, thanks. :)
16:21ajax: or just go straight to a merge request
16:24linkmauve: There, thanks: https://github.com/KhronosGroup/OpenGL-Registry/pull/362
16:24gitbot: KhronosGroup issue (Pull request) 362 in OpenGL-Registry "Fix section misnumbering in GL_KHR_debug" [Open]
16:25linkmauve: So hmm, how does the application match a message (either from the log or from the callback) with a previous GL call that may have caused it?
16:25linkmauve: Or is it part of the message?
16:31ajax: mesa tries fairly hard to put the name of the provoking GL function in the message string iirc
16:32linkmauve: Do other drivers also attempt to do that?
16:32ajax: i have no experience on that point but i imagine so
16:33ajax: but (possibly even with DEBUG_OUTPUT_SYNCHRONOUS) there'll be times where either there's no meaningful API call to blame, or there could be but you get it wrong
17:22danvet: hm is there a ready made kernel thing to replace all the mmaps for a file with something that doesn't sigbus but is otherwise harmless?
20:02mareko: karolherbst: ARB_geometry_shader4 doesn't look difficult
20:03karolherbst: mareko: ohh, that's not the issue, the issue is rather if it's worth the effort ;)
20:03karolherbst: but.. I guess we could just expose it though
20:03idr: ARB_geometry_shader4 is a really broken spec.
20:04idr: I want to say... the amount of output geometry is specified via the API before the draw instead of in the shader... so you have to recompile.
20:05idr: Which is why we didn't implement it in the first place. :) Basically every other feature we did the extension version before the core API version.
20:06mareko: idr: it says that the amount has to be specified before linking
20:06idr: That doesn't match my memory...
20:07idr: ...but that doesn't mean much. :)
20:07karolherbst: well, there is EXT_geometry_shader4 as well...
20:07karolherbst: maybe that was even more stupid
20:07mareko: EXT seems to be the same
20:08idr: I know Paul looked at it quite deeply (he was very thorough), and convinced the rest of us that we should skip the ARB extension because it was going to be a lot of extra work.
20:08mareko: also needs LinkProgram
20:08idr: Anyway... I'm heading out for lunch.
20:09mareko: there just needs to be an app that uses it for an extension to be considered for implementation
21:17tlwoerner: airlied: (off topic) could you please add Brenden Gregg's blog to planet.kernel.org? http://www.brendangregg.com/blog/rss.xml
22:48airlied: tlwoerner: done
22:51tlwoerner: airlied: thanks! :-)