02:35 jenatali: Anybody have opinions on Xbox support in Mesa?
02:41 airlied: my opinions can only be bought with Xboxes
02:41 HdkR: I think it would be fun to see Geforce 3 support indeed :P
02:42 airlied: (in case my corporate ethics are watching along, that was a joke, only be bought with playstations)
02:42 jenatali: :P
02:42 HdkR: That Pentium 3 might be a bit slow these days though
02:43 daniels: jenatali: what disbenefit would it bring to make us turn down the legitimacy it would confer?
02:43 jenatali: I guess, to be clear, someone's using Mesa on an unmodified modern Xbox, not trying to run Linux on the original one. Mainly just wondering if anybody wants to ack/review/nak that work for any reason
02:43 jenatali: daniels: Uh... in English please? :)
02:44 HdkR: I like it
02:45 daniels: jenatali: legitimacy from doing Xbox is good. what’s the bad part which would make us reject it?
02:45 HdkR: But my opinion doesn't matter, back in the emulation hole I go
02:46 jenatali: daniels: Ah got it. I dunno, just don't want to ruffle any feathers in case people do have some reasons that I couldn't think
02:46 jenatali: of
02:48 daniels: tbh you might be light on the ground for community review, but I’d say go for it :) it’s less niche than, say, Haiku
02:48 jenatali: Yeah, I wasn't planning to wait for acks, it's pretty self-contained so I just wanted to see if there were legitimate grievances on philosophical grounds
02:48 kisak: HdkR: so it'll matter to you once you're thunking mesa-in-xbox-game-in-totally-legit-emulator-on-ARM to host system mesa?
02:49 HdkR: For that next generation Snapdragon Xbox
02:50 daniels: HdkR: oh, so _that’s_ what really funds Proton-on-FEx!
02:50 HdkR: :D
02:50 daniels: jenatali: I can’t see it as being worse than DX12, or tbh, svga
02:51 jenatali: Yep, fair
02:54 HdkR: I'm pretty happy today that there is a commit that adds x86 code to Turnip. This mad world we live in :P
02:58 jenatali: Oh geez I sparked another Phoronix article, fun
02:59 daniels: jenatali: just wait for the Xbox one!
03:00 jenatali: Heh, yeah, I was wondering if they'd already covered it which is why I looked
03:01 jenatali: Reading the comments on the dzn one (which I really need to stop doing...) people are already theorizing it's about Xbox so that's going to be fun when that article drops :P
03:01 zmike: you have to start a blog so you can lead the narrative
03:02 zmike: then you can open the post with "this is not for xbox"
03:02 jenatali: https://devblogs.microsoft.com/directx/, but it's hard to talk about implementing Vulkan before you're technically adopters without getting into trouble >.>
03:03 zmike: use code phrases
03:04 zmike: "the interface" "the abstraction layer" "the building blocks of graphics"
03:04 jenatali: Brilliant
03:05 zmike: or get even fuzzier
03:05 zmike: "the project"
03:05 zmike: "the great undertaking"
03:05 zmike: "our labor"
03:06 daniels: *labour
03:07 zmike: daniouls
03:07 daniels: zung
03:08 zmike: yeah I got you good
03:14 airlied: zmike: one quick fix in 20662
03:15 zmike:refreshes harder
03:15 zmike: I thought that one was in the original MR? 🤔
03:18 airlied: zmike: so did I, I must have rebased one time too many
03:18 zmike: I hate it when that happens
03:18 zmike: lesson learned: never rebase, squash all patches into one
03:18 airlied: zmike: also never listen to review comments :-P
03:19 zmike: that goes without saying
03:19 airlied:awaits the great marge babysitting
03:54 zmike: 💪
03:57 tarceri: What flags do I need for llvmpipe clover driver?
03:58 airlied: LP_CL=1
03:58 tarceri: I've got gallium-opencl=icd and gallium-drivers=swrast
04:00 airlied: oh to build you need opencl-spirv
04:00 airlied: -D opencl-spirv=true
04:07 tarceri: installed dependencies and built but still cam't seem to get it to work
04:08 tarceri: mesa.icd just contains libMesaOpenCL.so.1 is that right?
04:10 marcan: airlied: re xbox, hey I added PS4 support to mesa at some point :p (IIRC it didn't take much other than adding the PCI IDs though)
04:10 marcan: even AMDGPU-PRO worked with no patches
04:11 marcan: the kernel side did need a bunch of patches though, mostly due to weirdo quirks of the frankenstein firmware involved
04:11 marcan: I don't think any of that ever got upstreamed though...
04:13 marcan: amusingly enough the vendorfw stuff we're pushing for Asahi would have been the *perfect* mechanism to use for that too, in a production setting. I hope we can turn it into some sort of standard...
04:18 airlied: tarceri: yes you need libclc install and spirv-llvm-translator
04:22 airlied: tarceri: make sure the icd file is /etc
04:22 airlied: not in the <prefix>/etc
04:22 airlied: you may need to set LD_LIBRARY_PATH
04:25 tarceri: thanks setting LD_LIBRARY_PATH seems to have gotten me further along now
04:30 tarceri: although that just found the amd gpu opencl devices not llvmpipe
04:31 tarceri: grrr. Things were so much easier when CI didn't exist lol
05:07 airlied: Lynne: got the short form intel decoder to stop hanging, not decoding anything yet, but not crashing :-P
05:18 Lynne: nice!
05:19 Lynne: remind me, what was the short vs long form again, and why was it needed?
05:20 airlied: though I might have screwed up the packets so it might start hanging again :-P
05:20 airlied: long form is slice level decode, short is frame level
05:35 airlied: bleh back to hanging
05:36 Lynne: is short mode used much nowadays?
05:55 airlied: Lynne: so vaapi has a mode for it VA_DEC_SLICE_MODE_NORMAL and VA_DEC_SLICE_MODE_BASE
05:55 airlied: I think the intel vaapi media driver exposes both modes, but the mesa vaapi code only supports the NORMAL mode
05:56 airlied: NORMAL is long, and BASE is short
05:59 Lynne: (I am suggesting there may be a silicon bug/rot if it's underused)
06:02 airlied: yeah I do wonder myself :-P I'll keep throwing tyres on the fire and see
08:47 tzimmermann: danvet, you asked to be reminded on talking to airlied about the removal of the legacy drivers: https://patchwork.freedesktop.org/series/111602/
08:49 danvet: airlied, ^^ iirc you said "no" last time around or something like that
08:49 airlied: burn it all!
08:50 airlied: yeah maybe we are getting to the set dri1 on fire time
08:52 airlied: will at least shake out if anyone cares
08:53 airlied: i ex0ect the openchrome dude
08:53 javierm: maybe one option is to move it to drivers/staging ?
08:54 javierm: although probably not trivial since all the helpers that drivers use...
08:54 javierm: s/since/due
09:01 danvet: javierm, ime if you want to find anyone left using stuff, best to delete it :-)
09:02 danvet: I think as long as we keep the legacy core code around for a year or so (maybe a bit more, we missed the last lts) then I think we should be fine
09:04 danvet: airlied, you'll reply on list or should I?
09:09 javierm: danvet: agreed on deleting to see if someone cares :)
09:12 javierm: is strange that there isn't a CONFIG_DEPRECATED or something that's not CONFIG_BROKEN but something that distros could disable it
09:13 javierm: danvet: maybe that's another option, make dri1 drivers depend on DRM_DEPRECATED and have that default n, that way if in a year or so nobody complains it can be deleted
09:14 danvet: javierm, well we had that with DRM_LEGACY already?
09:16 javierm: danvet: sorry, I missed that. And I see that fedora kernel config doesn't enable it for some time, probably most distros have disabled it too
09:17 danvet: javierm, yeah so next step is deleting
09:17 javierm: danvet: yeah
09:22 airlied: danvet: you can! not near email
09:22 danvet: ok
09:24 HdkR: win 13
09:26 tzimmermann: can we please have a Burn-it-all tag? :D
09:27 tzimmermann: javierm, no drm drivers in staging allowed
09:27 tzimmermann: just kill it
09:28 tzimmermann: i'll keep the legacy core in place for a few more releases, so we can restore any drivers easily
09:28 tzimmermann: there's some small legacy code in nouveau that serves an ancient userspace. hopefully that can be removed as well
09:28 tzimmermann: or at least integrated into nouveau
09:29 javierm: tzimmermann: makes sense
09:29 tzimmermann: can i apply the patchset? please please please
09:44 danvet: tzimmermann, dropped a reply with acks
09:44 tzimmermann: sure
09:44 danvet: i.e. go ahead with those :-)
09:45 tzimmermann: i'll take care of it witihn the next workdays. i also volunteer to deal with the fallout (restoring drivers and later cleaning up the core)
09:47 danvet: tzimmermann, also I'd say we should wait until the lts with this stuff has hit distros or so
09:47 danvet: so more 1.5 years
09:47 danvet: just because of timing
09:47 tzimmermann: yes, of course
10:11 hakzsam: eric_engestrom: is the branchpoint delayed btw?
10:12 eric_engestrom: hakzsam: dcbaker is doing 23.0; when I talked to him yesterday he intended on making the branch, but I don't know if he got busy with other things or if something blocked making the branch
10:12 hakzsam: okay, thanks and sorry for the ping :)
10:14 eric_engestrom: no worries :)
10:33 Kayden: [20:27] <dcbaker> curro: at this point I’m going to cut it first thing in the morning
10:34 Kayden: think it got delayed today by people trying to cram in last minute bug fixes - not sure why - bug fixes are easily cherry-picked...
10:34 Kayden: but yeah, should be happening tomorrow.
10:34 hakzsam: sounds good
10:47 danvet: mripard, btw plans to move vc4 over to dma_resv_lock as the buffer lock?
10:47 danvet: helpers are ready now I thought
11:40 pepp: anyone up for reviewing the small util_snprintf change from !20643?
11:50 danvet: tzimmermann, javierm uh just realized that CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is default y
11:51 danvet: maybe we should switch that arond to default n and depends DRM_LEGACY?
11:51 tzimmermann: danvet, true
11:51 danvet: instead of the current select
11:51 danvet: for existing .config it should all stay the same
11:51 tzimmermann: i'd first ask if nouveau devs would consider removing it entirely
11:52 javierm: danvet: agreed
11:52 tzimmermann: AFAIU that is ancient and userspace has moved on
11:52 tzimmermann: maybe they are willing to drop it
11:52 danvet: hm the userspace fix is only from 2015
11:52 tzimmermann: hmm, not so ancient
11:53 danvet: nah, wrong commit
11:53 tzimmermann: do you have a pointer to the commit?
11:53 tzimmermann: :D
11:54 tzimmermann: my point here is that something similar happened when i915, radeon, et al droppped support for userspace modesetting. that reaised the minimum version for userspace
11:54 tzimmermann: karolherbst ^
11:54 danvet: nah we're good
11:54 danvet: see c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
11:54 danvet: libdrm 2.4.33 was release March 2012
11:55 danvet: so 11 years ago
11:55 danvet: we should be able to safely nuke this
11:55 danvet: maybe just ditch the Kconfig for now and 3 lines in nouveau
11:55 danvet: and then just garbage-collect it all together with the other legacy stuff
11:55 danvet: in 1.5 years
11:56 danvet: tzimmermann, ums dropping was different, because we had a transparent fallback to the vesa userspace driver
11:57 danvet: and that actually worked, as in people didn't notice they fell back to that + cpu rendering
11:57 danvet: (because people stuck on this old stuff just don't care about gpu features as long as they can see something)
11:57 danvet: but this one is different, nouveau still loads, but then dies
11:57 danvet: and you get black screen
11:58 tzimmermann: 2.4.33: i was looking at that as well
11:59 tzimmermann: danvet, nouveau uses only very few legacy ioctls and functions. this could be moved entirely into nouveau, i think
12:00 tzimmermann: before nuking the legacy core
12:04 danvet: tzimmermann, I think we should just drop it together with dri1 drivers
12:04 danvet: moving this more if not needed seems a waste of time for me
12:04 danvet: you're already typing a patch?
12:04 tzimmermann: i'll send something
12:21 karolherbst: tzimmermann: CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set in fedora, and I'm not aware of any issues
12:21 karolherbst: danvet: so yeah.. we can either default it to n or drop it
12:22 karolherbst: not sure why we even have it there
12:22 tzimmermann: karolherbst, that sounds good
12:22 karolherbst: let's see what it's even doing
12:22 karolherbst: ahh.. DRIVER_KMS_LEGACY_CONTEXT
12:22 tzimmermann: i'll send you a patch
12:23 karolherbst: sure
12:24 tzimmermann: someone would need a modern kernel with a decade-old userspace. i wonder if that would even work easily
12:30 karolherbst: yeah...
12:30 karolherbst: I mean.. if you want to remove DRIVER_KMS_LEGACY_CONTEXT then we can just drop that option in nouveau
12:30 karolherbst: I don't even know what would need it
12:55 danvet: karolherbst, see git history, enough people complained that we had to revert
12:55 danvet: but that was 8+ years ago :-)
12:55 karolherbst: uhhhh
12:55 karolherbst: try again?
13:01 danvet: karolherbst, yup
13:01 danvet: also nothing functionally needed it
13:01 danvet: there was just some ums code that was still run (and unfortunately errors checked)
13:02 danvet: so worst case we can fake an implementation that pretends everything works while doing nothing
13:02 danvet: (maybe at least, not sure tbh)
13:07 tzimmermann: danvet, can driver-feature bits be removed or are they somehow exported to userspace: https://elixir.bootlin.com/linux/v6.1/source/include/drm/drm_drv.h#L52
13:08 tzimmermann: asking because this one will now become unused: https://elixir.bootlin.com/linux/v6.1/source/include/drm/drm_drv.h#L148
13:08 danvet: theire' entirely internal
13:08 tzimmermann: ok
13:08 tzimmermann: thanks
13:12 mripard: danvet: I wasn't aware it was something we were moving to, so I didn't have any plans to do so
13:12 mripard: but I guess I do now :)
13:37 shsrfud: Hi everyone, what is (preferably vulkan related) work that I can do get started with mesa? Two ideas are VK_EXT_descriptor_buffer for Intel and reimplementing descriptor sets in terms of descriptor buffers, but I have no idea how much work either of these tasks will take. In terms of hardware, I have Intel HD 605 and an RX 470.
13:44 ishitatsuyuki: Might not be a helpful advice, but lots of people starts with fixing what they found broken in a game or something else
13:45 ishitatsuyuki: descriptor buffer would be nice to have, sure, but I think they will involve some nontrivial tricks on Intel and isn't exactly the best fit for beginners
13:45 ishitatsuyuki: If you want to do Intel some favor, try finding bug reports about games not running or rendering incorrectly, there should be a lot of them on the issue tracker
13:49 zmike: I've been told VK_EXT_dynamic_vertex_input on intel should be relatively simple
13:58 dj-death: zmike: lol
13:59 dj-death: I'm looking at EXT_descriptor_buffer
14:08 shsrfud: Mike, thanks for the tip, I will take a look at it.
15:06 gawin: do these old kernel drivers require some regular conservation? (probably main use case is testing old hardware if it is still working)
15:25 rodrigovivi: @mattst88 @seanpaul_: Apparently the series for improve anti-preemption is entirely reviewed but stuck... it probably needs just a rebase and resend for CI... and the series for Allow error capture without request needs to be respinned to gets Tvrtko's feedback addressed and also someone with deep guc knowledge to confirm that there's no risk of GuC Fenix back from the dashes in the middle of the capture... I put the
15:25 rodrigovivi: request to our GuC team here to get that moving and will monitor progress
15:30 FLHerne: in the abstract, I'll be sad to see r128 go because that was my first ever GPU under Linux
15:31 FLHerne: but I don't even have the card anymore so eh
15:39 siddh: Hi, can anyone review the remaining patches of https://lore.kernel.org/lkml/cover.1673269059.git.code@siddh.me/
15:39 siddh: The last 3 patches in series have already been merged. Thanks.
16:04 Ristovski: Is there like a DB with apitraces anywhere?
16:05 daniels: breakfast
16:05 daniels: hmm, no.
16:05 daniels: https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db
16:06 Ristovski: daniels: thanks!
16:07 daniels: np!
16:08 Ristovski: Oh interesting, Valve gave permission. Maybe I could contribute some TF2 traces?
16:08 mattst88: rodrigovivi: I think the anti-preemption series is upstream already? (https://patchwork.freedesktop.org/series/100428/ -- 568944af44e7538ed5d1389dabf56e938afdaf4f c3bd49cd9a1043b963331e7fd874b380bed3f2bd 47daf84a8bfbc0ff7342b75fa2175591b64ef8d7 and d7a8680ec9fb217987a9569aba1abeed886805f0 in 6.2-rc1)
16:08 mattst88: is there more?
16:10 mattst88: https://patchwork.freedesktop.org/series/111224/ the the "Allow error capture without request", but I saw that there was a v2 at the end of November (but I couldn't find the patchwork link for it)
16:35 anholt: Ristovski: yes, TF2 trace would be welcome. There are instructions in the repo for how to trim appropriately
16:38 Ristovski: anholt: Are the guidelines "One trace per game"? bgfx has a trace for every demo, so I assume its mainly due to size concerns (as those are small, compared to a full game)
16:44 macromorgan: dumb question (I hate to be so basic but I'm still a c newbie) but I'm trying to make an argument optional in a function. The function is `drm_of_get_dsi_bus(struct device *dev, struct mipi_dsi_device_info *info)`.
16:44 macromorgan: is it as simple as seeing `if (!info)` or not to see if I either received a NULL or a valid argument?
16:45 DavidHeidelberg[m]: Ristovski: use apitrace, trim trace to one frame (and one initial frame). Also test ~ 150 loops if the trace will work for performance testing
16:46 DavidHeidelberg[m]: s/initial/setup/
16:50 anholt: Ristovski: we have some different traces for different settings, but I can see if there are different important frames to capture, we might want more than one trace
16:51 anholt: lots of traces-db is just a judgement call
17:02 gawin: talking about useful traces does amd own rights for ati tech demos? there were quite many of them, but some were made by 3rd party
17:18 macromorgan: how does a kms driver suspend? Are there driver specific hooks... does it destroy and create planes/crtcs? I'm trying to troubleshoot a driver (rockchip_drm_vop2.c) that doesn't suspend/resume correctly and I'm lost.
17:19 macromorgan: neither the HDMI port nor the DSI port output video after resume/suspend
17:20 macromorgan: I can run a test pattern to the DSI controller directly and that still works after resume
17:25 daniels: macromorgan: yep, 'if (!info) { }' will trigger if info is NULL
17:25 macromorgan: and if (info) will trigger if it's not, right?
17:25 macromorgan: cool
17:26 daniels: yep :)
19:43 anholt: mupuf: could I be added for the valve runners? I'd like to be able to run jobs for ci maintenance stuff. (currently looking at filling out zink+radv testing)
19:49 anholt: sergi: I'm running zink-anv-tgl-full job in one of your kernel 6.1.5 pipelines because I've been curious about if the uprev would help
19:52 mupuf: anholt: you have been trusted since day 0
19:54 mupuf: Wait, I thought I did, but didn't
19:54 mupuf: I'll fix that tomorrow
19:54 mupuf: Thanks for letting me know
19:55 mupuf: this is the current list: https://gitlab.freedesktop.org/mupuf/valve-infra/-/blob/master/ansible/gateway.yml#L64
21:05 alyssa: do we have any noob (i.e. me) friendly docs on how to use glvnd?
21:06 alyssa: for the use case of a mesa devenv with cross builds
21:07 alyssa: to replace scp'ing around gallium_dri.so and LIBGL_DRIVERS_PATH'ing it