00:00jenatali: On the topic of pkg-config from a Windows dev perspective, I hadn't even heard of it before starting to take a look at Mesa
00:00jenatali: Nor had anybody else on our team :)
00:02HdkR: Whoa. That's some mega Windows entrenchment to never have heard of pkg-config :)
00:02dcbaker: the cmake guys proposed a thing called cps, (not child protective services) and I think it has potential to be a huge improvement, but I couldn't seem to get that moving forward
00:02airlied:has no idea how the cmake Find stuff started, but it is definitely out of hand
00:03dcbaker: cps is json, so declarative, and they talked about replacing all of their find stuff with it
00:03dcbaker: which would be awesome
00:03airlied: like I vaguely get why pkg-config on windows is a pain, but I don't see how cmake crappy find files fixes it
00:03airlied: just seems to be a way of saying we gave up do whatever you want and hide it in this file
00:03jenatali: airlied: Yeah I don't think it does. Pkg-config has been nice on Windows once I figured out how to specify search paths
00:04airlied: that won't work if you copy it into another project
00:05airlied: I would think pkg-config files you just copy to a cmake shared dir would work fine :-p
00:06airlied: the problems I assume ppl have with pkg-config on windows is a lack of central storage for the pkg-config files
00:06jenatali: Yep, exactly that
00:06xexaxo1: dcbaker: got a link to cps - considering the name I cannot find anything
00:06dcbaker: also there's stuff about encoding the right CRT and some other stuff
00:06dcbaker: that's very MSVC/windows specific
00:07dcbaker:might have spent a little too much time in build system land...
00:08jenatali: Yeah that's fair. On Linux you just get the right version for your specific system, where Windows can have multiple on the same system
00:08jenatali: Or else you just get source
00:10Sachiel: debian alternatives comes to mind
00:10dcbaker: yeah, those are another big problem
00:10dcbaker: debian/kfreebsd is really differen than FreeBSD/kfreebsd
00:10imirkin:misses the old days when you could just pass paths in and not worry about broken auto-detection
03:54airlied: jenatali: can you push the regex fix you wrote to an MR?
03:56jenatali: airlied: yeah, I'll get to it in a bit
03:57airlied: jenatali: cool, nearly have the win32 lvp bits landing, but now can't build :-P
03:58jenatali: If I'm too slow for you (not at a PC atm) feel free to grab it yourself
04:01airlied: jenatali: I'll push it through the regex mr
04:02jenatali: airlied: sure sounds good
05:04jenatali: airlied: Thanks for pushing. I thought about pushing just straight to that MR but still prefer to err on the side of not overstepping just to be safe
09:10danvet: mlankhorst, maybe 3 more patches to cherry-pick from tzimmermann's -fixes pull
09:10danvet: or just rebase -fixes and pull that into -next-fixes
09:11tzimmermann: danvet, i'm slightly confused. i thought i have to send out -misc-fixes until -rc1 is out
09:11danvet: tzimmermann, you've done 5.11, right?
09:12danvet: new one is 5.12 for maarten
09:12tzimmermann: no wait, i did 5.10
09:12danvet: that's at least how the handover happened in the past, you own the release
09:13danvet: there's lots of -fixes pulls from you for 5.11
09:13danvet: tzimmermann, so at v5.11 release your time off starts
09:13danvet: until you send the first next pull for 5.14 right after 5.13-rc1 comes out
09:14danvet: and maarten needs to double-check that committers didn't push any patches to -fixes during the merge window that he needs to include
09:14tzimmermann: yes, that would be now. but i thougth time off starts that 5.12-rc1
09:14mlankhorst: I thought I just sent out the -fixes branch separately?
09:14mlankhorst: so both get merged?
09:14danvet: mlankhorst, airlied said "nope, ugly backmerge"
09:14tzimmermann: ok, i got it sort-of
09:15mlankhorst: ok so cherry-pick drm-misc-fixes to drm-misc-next-fixes?
09:15danvet: so if you merge this without cherry-pick, you get the ugly merge in drm-misc-next-fixes
09:15danvet: mlankhorst, yeah, and then rebase -fixes onto -rc1 or so to kick out the dupes
09:16danvet: tzimmermann, there's always a bit a wobbliness around merge window, so whatever works for you folks
09:16danvet: tzimmermann, personally I'd not give up on 2 weeks of my break :-)
09:17tzimmermann: danvet, :D i love drm-misc maintainance so much, i just cannot get enough
09:19mlankhorst: ok, pushed drm-misc-fixes to drm-misc-next-fixes
09:25tzimmermann: danvet, if you have a minute, could you connect on the latest udl fix. we just got the first bug report about this and putting some weight behind it might help with merging. i hope greg is happy with this
09:25mlankhorst: ok, sent!
09:36danvet: tzimmermann, replied
09:37danvet: still thinking that you're making this hack look way too pretty, so asked for a massive FIXME instead of kerneldoc
09:37danvet: imo "sharing good code" > copypasting > "sharing bad code that papers over issues"
09:40danvet: the problem with sharing bad code is that it often makes the cleanup work much harder
09:40danvet: since you then can't do it user-by-user anymore
09:40danvet: plus it hides the problem and makes the code look better than it is
09:41danvet: but that's also a bit a bikeshed, so big FIXME as a warning is fine too
09:42ccr: huge blinking neon red letters FIXME?
09:43tzimmermann: danvet, np about the big FIXME. i see your point about code sharing. OTOH i fear that new drivers would get it even more wrong; each in its own way. with the workaround we restore exactly the old status quo.
09:43tzimmermann: ccr: if there a markup comment for this, count me in
09:48danvet: tzimmermann, yeah for this one shared code doesn't sound too bad
09:48danvet: and yes it can also result in N different ways of getting things wrong
09:49danvet: I still think that's better than everyone feeling like the problem is solved
09:49danvet: or at least not their problem
10:59danvet: still looking for review for my two drm/compat fixes
10:59danvet: one of them is a security fix (information leak) ...
11:06emersion: pq: fyi https://gitlab.freedesktop.org/mesa/drm/-/issues/60
11:09pq: emersion, I dunno... I think I'm happy with the abstraction Weston has.
11:09emersion: yeah. except everybody needs to re-do what weston has.
11:09emersion: not saying weston should switch. just a way to make it easier for everybody else
11:10pq: Do you want to lift the Weston abstraction to libdrm or invent something else?
11:10emersion: especially e.g. kodi/gamescope, which just hardcode property enum values instead
11:10emersion: i don't know yet
11:11pq: I don't remember the Weston details myself etiher, how generic is it
11:11emersion: in other words: with the current abstraction it's very tempting for clients to hardcode enum values, and we said it's not find
11:11emersion: so should definitely have a better way for clients to *not* hardcode values
11:12pq: yes, I like the idea, but it all comes down to the details
11:12emersion: i think one pain point is that the mode_property struct is generic. so it's not easy to find out what the fields mean depending on the type
11:13emersion: iirc sometimes it's enum values, sometimes bitshifts, sometimes object types
11:14emersion: i'm talking about drmModePropertyRes
11:15emersion: oh, and there's also the drm_property_type_is mess
11:15emersion: that one is pretty embarassing -- it could've just been drm_property_get_type
11:16emersion: and naming isn't consistent with the rest of libdrm for some reason
11:44emersion: tbh i think i'll just continue hardcoding enum values anyways
11:45emersion: there's really no benefit to this complexity
11:46emersion: and i don't really care if that makes the kernel devs angry
11:58krh: emersion: it is unfortunately way overcomplicated...
12:02pq: with driver-specific and downstream-added properties, yes
12:03emersion: i don't see what this has to do with the complexity, pq
12:03pq: if there was a standardisation body allocating enums, maybe we didn't need string names in that case
12:04emersion: i thought vendor-specific props were being banned from the kernel nowadays?
12:04pq: nowadays, yeah, I guess
12:05pq: If three different groups add three different properties, and everyone pink enum value N+1 to name their property, that's practically a guaranteed conflict as pre-allcating enums is not a thing.
12:05pq: with string names, it's much harder to conflict
12:06krh: you still have to agree on a unique string prefix for vendor names
12:06pq: and unlike upstream would like, downstreams do ship and run downstream patches
12:06krh: and if you can agree on a string prefix, you might as well agree on a sub range of enum values
12:07pq: krh, I don't think that happens, or even can happen as upstream would just nak everything.
12:07pq: as emersion said
12:08pq: anyway, this is be kernel ABI today. It probably made a lot of sense when it was invented. Today, maybe less.
12:08emersion: side note, i've only seen vendor properties, not vendor enum entries
12:09pq: emersion, oh you meant hardcoding *only* enum values, not property ids?
12:09emersion: adding a vendor enum entry to a standard prop just sounds like trouble
12:09emersion: oh, yeah, property IDs cannot be hardcoded
12:10emersion: they're dynamically allocated by the kernel, i think
12:10pq: then nevermind, I was talking about proeprty IDs
12:10emersion: and much less of a pain than enum values
12:10pq: "enum" being kind of ambiguous here, me thinking "C enum", not "KMS property with value type enum"
12:11emersion: yeah, i'm talking about KMS enums, not C enums :P
12:11pq: anyway, is there some problem with lifting something like what Weston does into libdrm and forget about all this complexity in KMS apps?
12:12emersion: it's still complexity
12:12emersion: you can't just set a property to say ROTATE_180|FLIP
12:13emersion: you need to get that property in particular, get the enum values, OR the result
12:14emersion: and you get to deal with the enum entries not existing
12:14pq: Ok. I'll stop caring at this point. Sorry.
12:15emersion: my main gripe is that it allows two properties with the same name to have different enum values, i guess
12:16emersion: e.g. plane 42 has a "rotation" prop with the "rotate-180" entry which has the value 0x1
12:16emersion: and plane 43 has "rotation" "rotate-180" whcih has the value 0x2
12:16emersion: the KMS API allows this, so user-space needs to handle it…
12:22zzag: at quick glance, the current string based property value api solves a problem that doesn't exist. does any driver actually create enums with the same name but different values?
12:25emersion: the kenrel literally has an internal `enum` with these values exposed to user-space
12:26emersion: (as discussed in the email thread, i really don't see a use-case for different values for the same enum item name)
12:27pq: Is haswell graphics incapable of rendering to half-float color buffers?
15:19vsyrjala: pq: at least the hw can do it
15:21imirkin_: pq: fp16 RTs are definitely supported in GL by any DX10+ hw. did you mean displaying?
15:23danylp: I’m implementing VK_KHR_buffer_device_address for Turnip, and since it doesn’t support 64bit types I’m using software int64 emulation for address calculations. However, it seems to be a bit wasteful since the upper part of the address is always the same and I don’t think we have a plan for advertising 64 bit support.
15:23danylp: Does it make sense to do calculations only with lower 32 bits of the address in such case? If so, does it make sense to add yet another address format, something like “nir_address_format_vec2_global” and do calculations only with second channel?
15:25vsyrjala: imirkin_: display support is there as well
15:25vsyrjala: since gen4
15:26imirkin_: vsyrjala: yeah, sorta assumed that'd be the case. it's there since DX10 on nvidia as well (and gen4 is ... "dx10" with heavy quotation)
15:27imirkin_: (did intel put out a dx10 driver for gen4?)
15:28ajax: FL10_0 before gen6
15:28imirkin_: and gen6 got you 10.1?
15:28imirkin_: (that's cube arrays, texture query lod, maybe some other minor stuff)
15:28ajax: yeah, and then gen1 was dx11
15:28ajax: excuse me, gen7
15:29ajax: the less said about gen1 the better
15:30imirkin_: ajax: it'll be back when people benchmark the various intel add-on card gpu offerings ;)
15:32pendingchaos: danylp: if the upper part is always the same, maybe you could use nir_address_format_32bit_global?
15:38danylp: pendingchaos: I worded it badly. It's just that a single buffer wouldn't have addresses with different upper bits. Two different buffers may have different upper addresses
15:39imirkin_: danylp: how do you know that?
15:39imirkin_: let's say it starts at 4GB - 4K...
15:41danylp: hmmmm... it should be indeed possible
15:41imirkin_: it's annoying that for 99.99999% of buffers that won't be the case
15:41imirkin_: and you're doing all this pointless work for them
15:41danylp: blob driver does actually checks for wrap around as far as I see
15:41danylp: but it doesn't do full 64bit math
15:42imirkin_: but presumably if you're messing with pointers, you're going to use them to access memory at some point
15:42imirkin_: and the cost of accessing memory eclipses any little address calculation
15:43danylp: I agree, and emulation addition/subtraction isn't that bad...
15:48danylp: There is also a matter of registers usage
15:56imirkin_: want to get some opinions -- ARB_ssbo and ARB_shader_image_load_store require supporting these features in fragment shaders (i.e. they have a min images/buffers of 8). nvidia's DX10 GPUs can support compute shaders, but they can't support these features in frag shaders. would it be reasonable to expose those exts anyways (and report 0 for images/buffers in frag, out of spec)?
16:19kherbst: imirkin_: do you trust applications to check for that?
16:20imirkin_: sorta? it's a good question... i don't know of any concrete applications which use these features in frag shaders
16:21kherbst: yeah.. dunno either
16:21kherbst: probably some random games?
16:21imirkin_: i don't want to base decisions based on hypotheticals though
16:21kherbst: let's see
16:27kherbst: yeah, checking the shaders I have here
16:28kherbst: yeah, checking the shaders I have here
16:28kherbst: imirkin_: found a game using ssbos in fragment shaders
16:28kherbst: but it seems to require 4.2 anyway
16:28imirkin_: does it have a name?
16:28kherbst: tower of time
16:28imirkin_: ok, if it requires 4.x, then nv50 is "out" :)
16:29imirkin_: i suspect most games that use these advanced features will also use other advanced features
16:29kherbst: could also be some version check and using GLSL 420 depending on advertised version..
16:29imirkin_: and thus end up not running on nv50 (or use a different version of the renderer which doesn't use those features)
16:30kherbst: superhot as well.. let's see
16:30kherbst: but insie a vp
16:30kherbst: also declared with 4.2
16:30imirkin_: vertex shaders aren't even guaranteed to allow those iirc
16:31imirkin_: (doesn't stop a game from relying on it, of course)
16:31kherbst: but yeah.. most games would run too slow on nv50 anyway
16:32kherbst: but there are a bunch of games using those. Just mostly 4.2+
16:32kherbst: but there can always be that random game hitting it
16:33kherbst: maybe ask intel folks if they can check inside their db or if they know something?
16:43danvet: mripard, can you pls review my two drm/compat: patches?
16:43danvet: happy to look at some of your stuff too
16:49mripard: danvet: done :)
16:49mripard: I don't really have anything pending
16:49mripard: I can't get a proper drm-tip merge, even from a clean state
16:49mripard: so maybe you can help with that :)
16:50danvet: mripard, j4ni is looking into that already I think
16:50mripard: oh, great then
16:50danvet: and thanks for taking a look
16:52mripard: np :)
16:59j4ni: mripard: danvet: I've just pushed out drm-tip with the sound tree held back to v5.11. they'd moved their trees forward to Linus' tree in the middle of merge window
17:00j4ni: I'm test building it atm, no harm done if you update to that too and test yourself
17:00j4ni: my feeble lappy is no speed demon
18:22emersion: danvet: reading https://github.com/KhronosGroup/Vulkan-Docs/pull/1001#discussion_r434663103
18:22emersion: but i don't get it
18:23emersion: my unprivileged client can enumerate card devices just fine
18:25imirkin_: emersion: you have permissions on /dev/dri/card* then?
18:26emersion: > getfacl /dev/dri/card0
18:26imirkin_: but if you didn't, then you couldn't enumerate card devices
18:26imirkin_: e.g. if you only had renderD*
18:27emersion: the compositor wouldn't be able to do that either
18:27imirkin_: the compositor could have special privs
18:27emersion: not with logind/seatd
18:27imirkin_: (think setgid, or fancy stuff which gives it stuff)
18:27imirkin_: so then that's not "locked down", per danvet's definition
18:28imirkin_: presumably they went with the practical approach
18:29emersion: i mean, it's just the defaults
18:30imirkin_: which aren't locked down
18:30imirkin_: not surprising ... locked down = annoying to use
18:30imirkin_: (or at least highly restrictive, as the name might suggest)
18:30emersion: then how bad would it be to allow any wayland client to ls /dev/dri/card* via a protocol?
18:31imirkin: that's above my paygrade :)
18:41airlied: emersion: that would be called dri2
18:42airlied: emersion: and I don't think we want to recreate dri2
18:49imirkin: jenatali: re 3955dd077b6 -- draw is used to handle some annoying fallback cases in GL. without llvm, those are extra slow. dunno if those matter to you -- it's glRenderMode() handling, which was the pre-xfb xfb (sorta).
18:50jenatali: imirkin: Yeah, I'm aware. Super slow for already-slow cases is probably fine
18:50jenatali: I had asked around here when we were considering making that change and got the same answer, but thanks for confirming :)
18:50airlied: not sure if blender still uses those paths
18:50airlied: it was the use case for a long time
18:50imirkin: airlied: i believe it does not
18:51jenatali: imirkin: We're talking 25MB per architecture (100MB for ARM64) - that tradeoff vs maybe Blender is a little slow sometimes seems okay to me :)
18:52imirkin: jenatali: well, i think it was also popular in other CAD software
18:52airlied: it's not a little slow
18:52imirkin: but i suspect they've all migrated to more, uh, modern (i.e. 10yr old) technologies
18:52airlied: it's unseable to useable
18:52jenatali: Eventually I'd maybe like to see about sharing our LLVM stuff between the CL compiler DLL and the GL ICD, and then we can turn it back on, but that's... much more invasive surgery of Mesa's overall architecture I think
18:52airlied: yeah I think "professional" applications also use it
18:53jenatali: Since MSVC doesn't like arbitrary interfaces between DLLs
18:53airlied: just make it one DLL
18:53airlied: 90% of it will be llvm anyways
18:53jenatali: Hm... yeah that's not a bad idea
19:00danvet: emersion, you don't just need ls, you need to be able to open and do ioctl
19:00danvet: otherwise you can't know what's actually connected, and what's actually useful for direct display
19:01danvet: and with DRI3 there's really no reason for allowing anyone else but compositors access to dri3
19:01emersion: i don't really want to write a KMS-over-wayland protocol
19:01danvet: card* nodes I mean
19:01danvet: emersion, that's not how it works on X11 either
19:01emersion: direct display folks want to get access to the EDID
19:01danvet: that much you need to provide
19:01emersion: and potentially other KMS props
19:01danvet: plus filter it for only the displays you're allowing to be used through kms leases
19:02danvet: emersion, not sure the x11 proto needs any of that
19:02danvet: keithp knows
19:02emersion: ah, i remember now. the x11 protocol gives access to much more than just the EDID
19:03imirkin: a bunch of kms props are passed through
19:03imirkin: (by many drivers)
19:03jenatali: airlied: Also side note, if LLVM stuff is used to JIT, when we look towards enabling ARM64EC (can be loaded in x64 process, but instructions are ARM64), it means we don't have to try to enlighten the JIT about it to have it emit ARM64 code, and we don't end up with double-JIT (LLVM putting out x64, then we have to re-JIT as ARM64)
19:04danvet: imirkin, yeah if it's just built on top of xrandr (which it iirc is) then you get all props by default
19:04emersion: gah it's a mess
19:04danvet: *all connector props
19:04imirkin: danvet: i think you have that backwards. the ddx driver supplies properties, xrandr just reads them out. many ddx drivers pass through some/all kms properties.
19:05emersion: yeah the lease proto is just built in xrandr
19:05danvet: imirkin, that's what I mean for -modesetting
19:05imirkin: right. modesetting does. nouveau does. presumably amdgpu does. dunno about s3virge ;)
19:05danvet: emersion, I guess what you could do is make a lease protocol that only hands out leases
19:05danvet: and direct display then asks for lease, reads props, drops lease
19:06emersion: we basically have that
19:06emersion: we create an empty lease
19:06danvet: which is another kind of suck
19:06emersion: give it to the client
19:06danvet: yeah empty lease gives you no properties
19:06emersion: let it enumerate everything
19:06danvet: it's all filtered
19:06danvet: or there's some serious bugs in the kernel
19:06emersion: ah, not an empty lease then… an unprivileged DRM primary node FD
19:07danvet: that's worse
19:07danvet: I think when systemd is in charge you can't get at these even?
19:07danvet: also what do you do with multi gpu where both have outputs
19:08emersion: hm, that's not right
19:08emersion: ah, no. that's right
19:08emersion: "non-master fd for this DRM node"
19:08danvet: yeah even if it works right now it would still be horrible
19:09danvet: I think if you want minimal protocol
19:09danvet: do the option of a connector lease only
19:09danvet: then it's all just leases
19:09danvet: and you can also revoke them anytime
19:10emersion: yeah we already have connector-only lease requests
19:10danvet: btw are you including planes explicitly in your leases?
19:10danvet: X11 is cheap on that one
19:10emersion: but a connector lease would allow the client to change props right?
19:10danvet: not that there's much you can do with just the connector
19:11danvet: and there's always revoke
19:11danvet: and as part of your revoke you need to restore all properties anyway
19:11danvet: so you're not really an additional problem
19:11danvet: *missing words :-)
19:12emersion: creating a lease just for getting connector props doesn';t sound that bad for xwayland. but the compositor can't know if it's for displaying or querying stuff
19:12emersion: so it needs to include a crtc and a plane in the lease as well
19:13emersion: for pure wayland clients, we probably want to allow clients to do the filtering before asking for a lease
19:14emersion: which… sigh
19:14danvet: well Xwayland would need to support the xrandr lease protocol I guess
19:14danvet: so it could grab the connector-only leases from wayland internally, for enumerating
19:14danvet: and then toss that and upgrade to the full lease when needed
19:14danvet: native clients could essentially do the same
19:14danvet: so not seeing an issue here?
19:15danvet: wrt crtc/plane, I think that would need to be up to the compositor
19:15danvet: maybe some proto revisions if you want additional planes, dunno
19:16emersion: i don't want to allow random clients to have write access to connectors
19:16danvet: well direct display is for HMD only
19:16danvet: you're not going to use those in your compositor
19:16danvet: or at least that's the idea
19:16danvet: but maybe games want this in general, dunno
19:16emersion: from a security PoV, would be better to have clients filter connectors they're interested without grabbing any lease
19:17emersion: then, once they've picked a connector, get a lease for it
19:17danvet: we could also do read-only lease in the kernel, shouldn't be hard to implement
19:17danvet: then compositor could essentially give them a lease with anything they have to offer
19:17danvet: and client can pick
19:17emersion: would be nice
19:17danvet: read-only lease also wouldn't need to be exclusive
19:18danvet: that part is more work to type probably
19:18danvet: plus igt testcase
19:18emersion: is a read-only lease really better than a non-master DRM FD?
19:19emersion: i guess you get less info
20:04danvet: emersion, yeah we could limit things even more
22:42LaserEyess: I seem to have a very interesting issue with the interaction between amdvlk and radv, and I'm really unsure if I'm getting a bug in mesa, the kernel, or amdvlk
22:42LaserEyess: I'm tring to debug this https://code.videolan.org/videolan/libplacebo/-/issues/129#note_93317 and I'm getting that amdvlk timesout for this test, but radv apparently does not
22:43LaserEyess: however, the results are not at all consistent, if I force a driver with VK_ICD_FILENAMES I can sometimes get amdvlk to fail, sometimes get radv to fail
22:43LaserEyess: sometimes, when I run radv first, then amdvlk, and then run radv again, I think I get a gpu reset and my wm freezes completely
22:43LaserEyess: this does not happen at all when amdvlk is completely uninstalled
22:44LaserEyess: I feel kinda crazy asking this but is it possible that amdvlk is somehow affecting radv?
22:53LaserEyess: ok well I might be a little crazy but radv seems to actually be performing differently when amdvlk is installed
22:53LaserEyess: trying to get some logs of this...
23:00LaserEyess: yes I am getting a hang when amdvlk is installed, which sometimes makes me have to reboot, sometimes just hangs and I can kill the test
23:03LaserEyess: https://0x0.st/-KNR.txt radv w/o amdvlk installed
23:03LaserEyess: https://0x0.st/-KN7.txt radv w/ amdvlk installed
23:05LaserEyess: oh hmm, does this have to do with the shader cache maybe?