00:09 airlied: jekstrand: one question, we now have a generator that spits out both c/h in one go, and one that spits them out in two passes, any reason?
00:29 jekstrand: airlied: I thought I was consistent on that
00:30 jekstrand: mattst88: Uh... Is that even a thing we can do in general?
00:30 jekstrand: mattst88: Intel can't, at least not for everything.
00:32 airlied: jekstrand: anv_entrypoints vs anv_extensions_c + anv_extensions_h
00:32 jekstrand: airlied: anv_extensions is going to be going away eventually
00:33 jekstrand: So I could "fix" it but I intend to do so by deleting it eventually. :)
00:33 zmike: the best type of fixing imo
00:33 airlied: jekstrand: ah cool, just wanted to make sure it was known inconsistent :-P
00:34 jekstrand: airlied: Yeah. I've been trying to make things more consistent as I go
00:35 jekstrand:is looking forward to no longer having any python in src/intel/vulkan
00:35 jekstrand: Well, until I drop in a bunch of python for dealing with RT stuff
00:35 jekstrand: ....
00:36 bnieuwenhuizen: jekstrand: what are you using the RT python for?
00:36 jekstrand: bnieuwenhuizen: Didn't you know? Our RT HW is python-based. :-P
00:38 jekstrand: Actually, we're most likely toing to have some python involved in the build process for the BVH building kernels.
00:39 jekstrand: I've not gotten that 100% sorted yet but python seems likely.
00:39 Lyude: is it really? is this related to the open hardware talk that happened at XDC that talked about that python based VHL?
00:39 Lyude: or VHDL, the hardware language thingy
00:39 Lyude: whatever it's called
00:40 jekstrand: Lyude: Sorry. IRC doesn't have a sarcasm font. :P
00:40 imirkin: Verilog is the cool new thing
00:40 Lyude: ah lol
00:40 imirkin: and by 'new', i mean '20 years old'
00:41 zmike: jekstrand: I tHoGhT mIxEd CaSe WaS ISO sTaNdArD?
00:44 jekstrand: imirkin: Shhh... Don't talk about the FPGPUA project!
00:46 anholt: if you thought llvm was slow, wait till you start trying to build verilog in your shader compiler.
00:53 jljusten: place and route pixel
00:54 imirkin: anholt: presumably you were doing this in a simulator ... i think verilog has some built-in simulation things which makes it much faster than it otherwise might be. aka still super-slow, just ... don't have to simulate the universe.
02:48 mattst88: jekstrand: no, I'm only aware of vc* and freedreno being able to do this
06:07 airlied: jekstrand: is therer a way to get the number of samplers a shader users after lowering is done to sampler_index and vars rae removed?
06:09 airlied: hmm maybe clover needs to do a shader gather info before lowering
06:17 mareko: robclark: would you please do something with CI failing regularly on freedreno? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6912783
06:19 airlied: anholt: ^ though I thnk you mentioned you had some plan
06:28 mareko: imirkin: does it really simulate the universe? :)
06:46 airlied: Kayden: did you mention wanting to fix num_textures vs textures_used etc in nir before?
07:25 Kayden: I know I've done stuff with that in the past
07:25 Kayden: nir->num_* are pretty meaningless most of the time
07:25 Kayden: oh, that's in shader_info
07:25 Kayden: yeah, I think num_textures there is pretty useless
07:26 Kayden: I made gl_nir_lower_samplers_as_deref set textures_used
07:28 airlied: Kayden: yeah for clover where samplers and textures are different things and are > 32, none of the fields work well :-P
07:30 airlied: CL has a minimum of 128 read only images views which pretty much map to textures
07:36 Kayden: oof
07:37 Kayden: yeah, I think GL and VK only have 32 of each typically
07:37 Kayden: we could advertise more, but nobody does IIRC
07:38 Kayden: (actually, it would have been useful to advertise more than that on GL...because wine can get 32 textures and 32 samplers in DX and mix-and-match them...while GL glues those together, so you can end up with more than 32 glued-combos)
07:38 Kayden: (but now everybody uses DXVK, where they're separate and it maps well, so...)
07:39 Kayden: the main issue with num_textures was that...
07:39 Kayden: a shader might have 1 texture, but it's binding point 15
07:39 Kayden: we usually use util_last_bit(textures_used) to get the highest binding point
09:23 pq: emersion, split display/render IP; yes, two completely unrelated DRM device nodes. However, Mesa may contain internal driver magic to automatically open the other when you initialize with one of them (I'm not sure which way though).
09:23 emersion: yeah, kmsro. it seems like it works with the display one
09:24 pq: emersion, display-link is a display-only device. You'll see it by it having enough KMS properties that you can light up an output, but if you try EGL on it, you get a software renderer.
09:24 emersion: yup
09:26 pq: emersion, looking at GL_RENDERER or whatnot is exactly how Mutter avoids using a software renderer when it really does not want one from Mesa.
09:26 emersion: yeah, i found a better way in the meantime
09:26 emersion: EGL_MESA_device_software
09:28 pq: emersion, ajax, what is the mutter comment you referred to?
09:29 emersion: hm, grep mutter for llvmpipe :P
09:29 emersion: pq: https://gitlab.gnome.org/GNOME/mutter/-/blob/master/cogl/cogl/driver/gl/cogl-util-gl.c#L306
09:39 Sumera[m]: I am trying to add a virtual_hw mode to vkms by bypassing the vblank simulation. Since that means we don't need to race with the vblank hrtimer, I tried to write a separate vkms_composer function without a worker queue for the same here https://paste.ubuntu.com/p/ZPk9hXfrqZ/
09:39 Sumera[m]: what I am not able to figure out is how to handle wb_pending here. How exactly would writeback get affected of I am not using the vblank simulation?
09:39 Sumera[m]: melissawen: ^^
09:40 Sumera[m]: My hunch is that even if we are not racing with the vblank timer, the writeback job queue still stays/works the same way and therefore, the locking behaviour around wb_pending should not change but I am not really sure with this. What would be the best approach here?
09:47 pq: emersion, ah, that mutter comment. Thanks.
09:51 melissawen: Sumera[m], yes, I think you still need to use the wb_pending in the composer_worker to sync with writeback; in addition, you should set crtc_state.no_vblank to true (if I am not confused)
09:53 melissawen: siqueira could give us a hand where ^^
09:53 melissawen: here*
10:07 karolherbst: can we use _Atomic yet?
10:07 karolherbst: :p
10:08 karolherbst:has no mercy for compilers not supporting C11
10:09 karolherbst:will continue to mention C11 at least a month
10:09 karolherbst:*once
10:11 ccr: a compiler that does not support C11? .. which one could it be ..
10:12 hch12907: one that supports a subset of C99..
10:13 HdkR: Maybe one could just use clang on that platform instead? :)
10:15 karolherbst: maybe we should just enable C11 for mesa and wait who screams
10:15 karolherbst: (and remove 50k of loc to show that we want to get rid of a bunch of code)
10:43 Kayden: hmm...looks like this a6xx machine is kinda toast... https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6916658
10:44 Kayden: of course as soon as I say that it finishes running
10:45 Kayden: yeah, okay...log full of kernel timeouts is just a thing, it's eventually a mundane piglit change that's making it fail the job :)
10:45 Kayden: which...isn't my patches, since they're entirely in iris, but, oh well
11:06 pepp: Kayden: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8735 should prevent running freedreno (and others) tests for intel-only changes
14:27 zmike: @all I've created a new MR to disable the flaky glcpp tests in CI https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8738
14:27 zmike: comments appreciated
15:06 xexaxo1: zmike: mildly curious - is it a recent break? did anyone look for the offending commits?
15:06 xexaxo1: they used to work fine, quite some time ago.
15:06 zmike: no, it's been going on for a while
15:06 zmike: and it only fails in ci, so bisecting locally is not feasible
15:07 xexaxo1: I see that's the key piece - works locally, fails on CI
15:08 ajax: would be cool if when meson shoots down a test timeout it would take a backtrace to show you where it was stuck
15:08 zmike: it would
15:09 xexaxo1: sounds like a really cool feature. any meson hackers around :-P
15:15 MrCooper: xexaxo1: it's really mysterious; those glcpp tests normally finish within about a second, but occasionally they time out after 60s
15:17 xexaxo1: 1-2 seconds sounds familiar. thinking out loud - could it be filesystem related? some strange interaction with overlayfs or alike?
15:18 alyssa: looks like pack_unorm_4x8 lowering is broken for vector backends
15:18 alyssa: I guess that's not surprising, I don't think any of the vector backends in-tree support ES3.2
15:18 alyssa: will look into what goes wrong
15:19 xexaxo1: MrCooper: out of curiosity: one can download the container to run tests locally right? I'm not volunteering, simply asking if it's an option.
15:20 MrCooper: it is, but I suspect the problem might be specific to the shared runners
15:30 alyssa: never mind, ignore the above, backend bug
15:30 alyssa: misread the NIR
16:24 jenatali: karolherbst: Regarding C11, I think you might actually be clear to do it. Looks like the MSVC version in CI is actually new enough. There's an old SDK causing some pain but that can be worked around
16:27 karolherbst: jenatali: even if it broke I wouldn't care :p
16:27 karolherbst: MS can do this,because people play along their shit
16:27 karolherbst: languages like rust and so on show how the future looks like
16:30 jenatali: I know you wouldn't care, but I would :P
16:32 jekstrand: airlied: No, not really
16:33 jekstrand: jenatali: We've also got VMware people building Mesa. Not sure if they're on the latest or not.
16:33 jenatali: True, good point. I'd hope so?
16:34 jenatali: Though they mostly stick to MinGW, don't they?
16:34 imirkin: no, they use msvc
16:34 jenatali: Ah ok
16:34 jekstrand: Much to our chagrin...
16:36 jenatali: The C11-suporting MSVC was released in November, so that seems okay to me to depend on
16:36 imirkin: of which year?
16:36 imirkin: i'm pretty sure they use something released not after 2000
16:36 jenatali: 2020
16:37 jenatali: Oh..
16:37 imirkin: (ok, *maybe* i'm exaggerating...)
16:37 jekstrand: imirkin: I think they're on 2016 or something like that
16:37 jekstrand: imirkin: Last I checked, they weren't building for DOS. :P
16:37 jenatali: That's... less than ideal
16:38 imirkin: jekstrand: Visual C++ 1.52 supported Win32 iirc. and that was 90's :p
16:39 jekstrand: imirkin: I've got a copy of borland around here somewhere. Maybe we should put that in CI. :)
16:39 imirkin: jekstrand: Turbo C!
16:39 jekstrand: tig
16:40 imirkin: because every company should put out two separate compilers with incompatible sets of bugs...
16:40 jenatali: On a more serious note, has anyone tried to compile Mesa with ICC? Just wondering
16:40 jekstrand:looks around and hope no one sees icc over there.
16:40 jenatali: :P
16:40 jekstrand: jenatali: Nope. Never tried. I doubt anyone cares.
16:41 dcbaker: Yes
16:41 dcbaker: I have
16:41 dcbaker: Swr at least works
16:42 jekstrand: dcbaker: You would...
16:42 dcbaker: That was the request when we moved to meson anyway. Haven't tried for a long time
16:45 dcbaker: Someone from kitware had a customer that wanted swr with icc and icl
16:45 dcbaker: I've always kinda suspected Intel was that customer, lol
16:45 jekstrand: lol
16:46 jekstrand: I kind-of doubt the Intel drivers would build with ICC. At least in ANV, we use quite a few GCCisms.
16:46 bl4ckb0ne: isnt icc built on top of gcc?
16:46 dcbaker: I965 built and worked back in the day
16:46 dcbaker: Icc tries really hard to be gcc
16:47 dcbaker: The new version is clang based, but I've never gotten around to wiring that up in meson
16:48 jekstrand: Oh, then that should be ok
16:48 bl4ckb0ne: regarding the gccism, is there a non glibc build in the ci?
16:49 dcbaker: There's an msvc build
16:49 imirkin: i'm guessing he meant more like musl ;)
16:49 bl4ckb0ne: yes
16:49 dcbaker: Last i knew mesa didn't work with musl
16:49 dcbaker: We relied on implementation details of glibc's thread local
16:49 bl4ckb0ne: i compiled it a few time on my laptop without any issue, but only a small set of features because i dont have much power
16:50 dcbaker: Maybe that's changed
16:50 bl4ckb0ne: i know musl shares a few things with glibc, maybe that thing is inthere
16:52 bl4ckb0ne: i could run a full build later on today to see, would you be interested in adding that in the ci?
16:54 jenatali: Doesn't seem worth spending the CI cycles on it unless there's a customer that actually wants to use it
17:00 jekstrand: I think mesa is used with musl quite regularly
17:00 jekstrand: Google Fuschia uses musl, I thought.
17:00 jekstrand: And they run mesa
17:05 bl4ckb0ne: ill see as it goes on my dev setup then
17:09 dcbaker: I seem to remember things compile fine, but don't always run okay. Maybe it was with GLX? I don't remember now
17:47 xexaxo1: IIRC the musl issue is not that it won't work, but that some workloads barf.
17:48 xexaxo1: although newer musl has a partial implementation of our tls needs. as used by glx and egl
17:49 dcbaker: I only have vague recollections of the problem, something about the size of tls that glibc makes things work, but musl provides a different (valid) size
17:49 dcbaker: and we're really using the wrong tls model anyway, but the glibc stuff works and none of the people who complained wanted to fix it
17:50 dcbaker: s/glibc/glibc provides/
17:52 xexaxo1: something like that yes. musl bumped their numbers and things work for now :-P
17:52 dcbaker: lol, nice
17:53 xexaxo1: the more in depth - IIRC Nvidia devs introduced a tls model variant, which was implemented by glibc. initially musl were unhappy since that required dynamic allocation for the tls.
18:05 hakzsam: dcbaker: can you please backport 3c03fa5801ceccd2f9e408cc42f1dfad57b234d9 ("radv: Only enable sparse features on Polaris and newer.") to staging/21.0 please?
18:05 xexaxo1: skimming through the code - windows & free/openbsd & old androids still use the old tls codepath
18:09 Venemo: dcbaker: speaking of 3c03fa5801ceccd2f9e408cc42f1dfad57b234d9 did I mess up the Fixes tag somehow? I don't see what's wrong with it but maye you do
18:09 kisak: hakzsam: looking at staging/21.0's .pick_status.json and the commit in question, everything is in order for the script to pick that commit up, it's just newer than the last time the maintainer script was run
18:11 dcbaker: yup, it's staged now
18:11 Venemo: thx
18:11 hakzsam: ah ok, so it's probably fine, I thought only something like "Fixes: 9f43b44bf06 ("radv: Enable sparse buffer and image support.")" was accepted by the script
18:11 dcbaker: the ("commit message") is just helpful for humans
18:12 Venemo: gitlab will show you the message either way
18:12 Venemo: if you hover over it
18:12 dcbaker: the script just looks for `fixes: [a-f0-9]+` (or roughly equivalent)
18:12 dcbaker: well, we borrowed the syntax from the kernel
18:12 dcbaker: :)
18:15 hakzsam: ok, makes sense :)
18:22 jenatali: Hm, what's the difference between the old & new TLS paths? I suspect Windows could probably support something similar to the new one, and maybe I can take a look at that
19:05 jenatali: Ah, looks like the difference between using TLS APIs vs compiler-assisted TLS. Yeah I should try to hook that up at some point...
19:08 Kayden:reads the scrollback and laughs :D
19:08 imirkin: that's what it's there for!
19:09 Kayden: pepp: nice, thanks for doing that!
19:10 Kayden: it amuses me to no end that we've had to hold back on using C99 features for years because of MSVC, in almost every project I've worked on, and now it turns out they support C11, and we can just do whatever, because everything is fine :)
19:11 Kayden: and, now we have jenatali from microsoft being like "nah, it's no problem at all", and it's just VMware's corporate toolchain being stuck on 2013 or 2016 or whatever at this point :)
19:11 Kayden: never thought I would see the day
19:11 Kayden: and it's a great day :)
19:12 mareko: and C++ templates are coming to common code
19:12 jenatali: It feels nice to not be one of the bad guys these days
19:14 Kayden: :D
19:14 HdkR: I can take up that mantle. I'll be the baddy :P
19:17 dcbaker: I don't know, I suspect Apple is going to end up being the "you can't use nice things unless their *our* nice things" people now
19:22 jekstrand: They've always been those people
19:25 Venemo: what, MSVC supports C11? that's news to me
19:27 dcbaker: VS2019 supports a subset of C11
19:27 imirkin: C89 is a subset of C11 ;)
19:28 dcbaker: lol
19:30 jenatali: dcbaker: The latest VS2019 has full (required) C11 and C17 support
19:30 dcbaker: ooh, that's nice
19:30 dcbaker: tbf I haven't checked in a while
19:30 dcbaker: I wonder if my patches to sort that out in meson ever landed...
19:30 jenatali: https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
19:30 jenatali: They did, AFAIK
19:31 dcbaker: I don't think we konw about c17 though, should probably get around to adding that...
19:31 HdkR: The optional features of C11 are kind of eh anyway if I remember?
19:31 HdkR: So those missing sounds fine :D
19:31 jenatali: I thought I saw C17 support in Meson for MSVC when I was skimming the code the other day...
19:32 dcbaker: maybe it is
19:32 bl4ckb0ne: anyonymous uniions are a lifesaver in c11
19:32 dcbaker: I know we'd add c11 at one point
19:32 jenatali: It looks like it's just spec bugfixes though, so if you're going to use C11 you might as well use C17
19:32 dcbaker: and then ran into bugs because we were letting people put whatever the heck they wanted for msvc c standards...
19:32 dcbaker: and glib relied on that...
19:32 dcbaker: sigh
19:33 jekstrand: Now if only we can convince the C++ committee to make designated initializers for POD types work.
19:33 jenatali: Do they not?
19:33 dcbaker: C++20
19:33 bl4ckb0ne: c++20 yeah
19:33 jenatali: Yeah, C++20 added that
19:33 jekstrand: Oh, did it?
19:33 bl4ckb0ne: yup
19:33 jekstrand: Sorry, I'm not up on the very latest
19:34 HdkR: C++20 has some quite nice features added to it. I recently upgraded my project to it just to use bit :P
19:34 bl4ckb0ne: https://en.cppreference.com/w/cpp/language/aggregate_initialization
19:34 dcbaker:is still waiting to see if modules work out
19:34 HdkR: I'm not touching modules. Too many open problems
19:34 bl4ckb0ne: ^
19:34 dcbaker: but we still didn't get std::expected
19:35 dcbaker: HdkR: Oh, tell me about it, lol
19:35 bl4ckb0ne: iirc there's patches available around for modules
19:35 dcbaker: at least MS, Clang, and Gnu all agreed on a format for reporting module dependencies
19:35 dcbaker: though microsoft agreed then implemented something else last I checked
19:35 HdkR: dcbaker: Sadly I don't remember the details. I listened to someone ranting about its problems for like an hour and decided I wouldn't touch it yet :D
19:36 dcbaker: The problem is it's basically fortran's modules
19:36 jenatali: I think one of the bigger problems with module at the moment is lack of support in any of the meta-build systems (Meson, CMake, etc)
19:36 HdkR: That is a huuuuuge issue
19:36 dcbaker: Meson has some very preliminatry support
19:36 jenatali: And I seem to recall that adding them was hard because it required running the compiler on the code to generate the interface, in order to be able to build the build system
19:37 dcbaker: ninja can now understand the interfaces
19:37 dcbaker: we have some code to tell ninja to sort out the dag for us, but I don't think it's upstream
19:37 dcbaker: but the other problem is that modules have a way of making your build completely un-parallelizeable
19:39 dcbaker: I'm hoping we all get it sorted out, but it's slow moving
20:32 emersion: xexaxo1: i think i'm hitting the mesa limitation you were talking about earlier: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4178
20:38 xexaxo1: emersion: hmm funky. brain is a little fried atm, so can you add some extra details...
20:38 imirkin: mareko: is there a piglit (or other test) which exercises smooth point/etc settings in the presence of multisampling? i want to see if your recent change in that area breaks nouveau
20:40 xexaxo1: emersion: ... are you using implicit or explicit gbm dpy, what's the fd, etc.
20:40 xexaxo1: s/dpy/device/ I think is the proper name
20:40 idr: imirkin: It seems unlikely. Most of the "smoothing" tests in the old CTS wouldn't run with multisampling.
20:40 idr: If I recall correctly.
20:41 imirkin: hm ok. i guess if it was very unlikely for those to be set together in the first place, then it probably works OK
20:41 imirkin: my concern is whether the hw might be expecting those bits to be set for msaa to work properly
20:42 idr: I think it's just hard(er) to test, and people were lazy... or saw little ROI or whatever.
20:42 imirkin: can you think of tests that ensure that it works correctly for msaa ignoring those bits?
20:43 imirkin: i.e. that msaa has smooth point rast, for example
20:43 idr: Probably... but I'll have to remember how it all works first.
20:44 emersion: xexaxo1: added these details in the issue
20:44 imirkin: idr: i meant like existing tests, not new ones i'd have to write. if i have to write them, i'd rather just assume it works fine :)
20:44 idr: Oh...
20:44 imirkin: if i don't know it's broken, it must be working
20:44 imirkin: ;)
20:54 idr: imirkin: My grep skills found nothing in any of the old, closed-source CTS code that would hit GL_POINT_SMOOTH and MSAA.
20:57 imirkin: idr: presumably you mean GTF?
20:58 idr: Yeah... there's two things that go by GTF, and I looked in both.
20:58 imirkin: i guess i was thinking piglit or dEQP might have something
20:59 idr: One is the stuff that came from SGI for OpenGL 1.2 conformance, and the other is the stuff that came from OpenGL ES CTS that became the later OpenGL CTS.
20:59 idr: Oh... I assumed you had already grepped the public stuff.
21:00 imirkin: i was hoping someone just knew of a test offhand :)
21:00 imirkin: e.g. one that was used to test the change in question
21:01 idr: I don't... but hopefully mareko had something... maybe?
21:04 imirkin: that was my hope :)
21:05 karolherbst: curro: starting to fix some multithreading issues in clover and was wondering if you know about a nice way of making a std::map thread safe, but I guess I should jsut throw in some locks
21:06 imirkin: std::map is not thread-safe...
21:07 karolherbst: I know, but maybe there are nice wrappers or something stupid
21:09 jenatali: I've hand-rolled a simple wrapper multiple times with a .get_locked()->do_stuff() interface, but if you're returning entries from inside the container you're better off just explicitly using locks
21:09 curro: karolherbst: std::lock_guard is a pretty convenient way to do it i've been using to protect other multithreaded data structures in clover
21:09 karolherbst: yeah, already used the same
21:10 karolherbst: ehh.. race in nir_opt_algebraic
21:10 karolherbst: "ASSERT_TABLE_IS_COMMUTATIVE(table);" ehhh
21:10 karolherbst: yeah...
21:10 karolherbst: so...
21:11 karolherbst: idr: I think we need to make the range analysis stuff thread safe :p
21:12 jekstrand:likes lock_guard
21:12 dcbaker:can't imaging going back to c style locking...
21:12 jenatali: karolherbst: If you're running debug you'll also run into stuff like NIR_PRINT checking not being thread-safe, won't you?
21:13 karolherbst: no clue :D
21:13 karolherbst: probably?
21:16 idr: karolherbst: If you're not building with -O0, those shouldn't generate any code.
21:16 karolherbst: I guess
21:17 idr: At this point, we should just delete them. They've been more trouble than they could possible be worth.
21:19 curro: karolherbst: lolz, obviously the compiler needs a giant lock like the kernel used to have in the good ol' BKL days ;)
21:19 karolherbst: sure
21:23 karolherbst: uff...
21:23 karolherbst: it takes quite a while to make tsan happy
21:24 karolherbst: especially with CL where the spec is saying "everything is thread safe besides APIs modifying kernel state"
21:26 idr: A lot of Vulkan users / developers would show up at our door with pitchforks and torches...
21:26 jenatali: I mean, easy enough to just wrap up everything in a nice big lock, but that kind of defeats the purpose...
21:27 dcbaker: Instead make everything atomic! that'll make everything just work™, right?
21:28 jenatali: Atomic shader compiles, what an idea!
21:29 mareko: imirkin: I have no tests for that
21:34 imirkin: mareko: ok. do you know of any tests which just check msaa point rast, ignoring the smoothing point?
21:34 imirkin: if not, i'll poke around
21:44 bl4ckb0ne: could somebody merge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8638 please? it has already been reviewd
21:45 imirkin: ajax: --^
21:46 airlied: bl4ckb0ne: assinged to marge
21:47 bl4ckb0ne: thanks
21:50 mareko: imirkin: no tests for msaa points, no tests for smooth points
21:50 imirkin: mareko: cool. sounds like a good feature ;)
21:51 karolherbst: idr: CL_MESA_API_unsafe and state "nothing is safe now" :p
23:24 airlied: anholt: did your last merge stall out marge?
23:25 airlied: oh no seems fine, just taking longer than I expected
23:35 anholt: airlied: hopefully things settle down a bunch now that we're not spamming retries. I should have given up and disabled at least two days ago.
23:43 aphysically: I've been working on getting vaapi decode -> vulkan filter -> vaapi encode in hardware without a swdownload working in ffmpeg
23:43 aphysically: while it works encoding for a few frames, eventually I will get a quit with this error:
23:43 aphysically: MESA-INTEL: error: ../src/intel/vulkan/anv_queue.c:402: timeline timeout: No such file or directory (VK_ERROR_DEVICE_LOST)
23:43 aphysically: does this mean anything to anyone? I'm running debian bullseye
23:44 imirkin: check dmesg
23:44 imirkin: device lost = some sort of error which is most likely reported in dmesg
23:45 aphysically: yeah, dmesg was empty :\
23:46 aphysically: I tried journalctl -b and couldn't find anything relevant either
23:50 aphysically: it does actually work for encoding for a few frames - I can encode entire (very) short videos if the error doesn't trip
23:52 bnieuwenhuizen: aphysically: are you using timeline semaphores?
23:54 aphysically: oh geez, I think the vulkan hwcontext does but I'm not sure the specifics offhand
23:54 aphysically: (in ffmpeg)
23:58 aphysically: I know there's some bug with the syncing in ffmpeg's vulkan hwcontext, but I was expecting something more like out of order frames if that was an issue
23:58 jekstrand: aphysically: That looks like a timeline semaphore deadlock
23:59 jekstrand: aphysically: Or some other misuse of timeline semaphores