00:00airlied: happy to not do CL_RGB 3 channel sucks :-P
00:10karolherbst: the CTS does an aligned malloc
00:11karolherbst: and if the alignment is npot...
00:11karolherbst: no idea why nobody hit this before :p
00:14karolherbst: much better now :)
00:14karolherbst: airlied: mhh.. how well do 3d images work with llvmpipe?
00:15karolherbst: mhh 1d array and 2d array also causing issues..
00:15karolherbst: probably my fault
00:15airlied: karolherbst: it's GL compliant, not sure after that
00:15karolherbst: heh 3D to 2D works
00:15airlied: and vulkan compliant
00:15karolherbst: but 3D to 3D is broken
00:15karolherbst: same as 2D to 3D
00:16karolherbst: FAILED 525 of 825 sub-tests. :/
00:16karolherbst: oh well...
00:16karolherbst: more debugging
00:16karolherbst: but tomorrow!
01:40jekstrand: karolherbst: Did you notice the new nir_opt_uniform_atomics pass that pendingchaos wrote? It's exactly the thing we were talking about a month or two ago about trying to optimize atomics.
01:45airlied: jekstrand: ever see any wierd corruption in block predecsesors?
01:46airlied: I'm calling finalize nir from clover now for radeonsi, and it sometimes crashes in the first validate inside finalize_nir
01:46airlied:is having some wierd C++/C interaction ideas but not sure, valgrind, asan come up blank
01:52jekstrand: airlied: Not usually
01:52jekstrand: airlied: You sure someone didn't accidentally delete the shader?
01:53airlied: yeah I'm wondering if there is some hidden C++ destructor happening
01:53airlied: but I just pass the ptr to the C callback
02:19airlied: wierd it sees a deleted entry
02:24airlied: the set deleted_key is changing
02:24airlied: oh no
02:24airlied: this is you've linked mesa in twice you failed
02:24airlied: okay cna't finalize nir from the frontend then
02:26jekstrand: airlied: That should be solved by going through serialization
02:26airlied: jekstrand: yeah the problem is I was trying to finalize pre-serialization
02:27airlied: since that's how the other state trackers do it
02:27airlied: but I guess I don't get to haave that cake :-P
02:31jekstrand: airlied: Or you could just git rid of pipe-loader and make clover link like a sane driver.
02:33airlied: jekstrand: yeah this is tempting me to just make a mega drivers
02:34jekstrand: airlied: Do it!
02:37jekstrand: airlied: I want clover to call into brw_preprocess_nir before it does lowering
02:56linkmauve: f/w 160
04:04airlied: okay finally have a reasonable approx of a radeonsi nir cl path
08:21pq: bshah, lynxeye, always just get the DRM resources and check if it has at least one crtc, encoder and connector each. Guessing based on device node path is unnecessary.
08:57karolherbst: airlied, jekstrand: before making clover static, need to convince curro: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/833
09:52karolherbst: airlied: mhh.... llvmpipe and clover disagree on strides :/
09:53karolherbst: so if the application doesn't provide one, clover sets the stride to the row size
09:53karolherbst: but when llvmpipe actually creates the texture storage, it just calculates stuff internally
09:53karolherbst: we can't do that :/
09:53karolherbst: but I am also not too deep into llvmpipe in order to fix it
09:54karolherbst: this issue is hit with the clFill test
12:01melissawen: danvet_, just to let you know that I tested v2 here, and it works well
12:02danvet_: melissawen, thx
12:02melissawen: also, a nice cleaning with default ops :)
13:02danvet_: melissawen, yeah the helpers we have are really nice!
14:08karolherbst: imirkin: were there any patches one needs to use apitrace on big endian?
14:08karolherbst: it seems totally busted
15:06j4ni: has anyone seen a display using DisplayID v2.0 in the wild? the v2.0 spec no longer has the "Appendix B: DisplayID as an EDID Extension" section from v1.3. so is it a more fundamental replacement for EDID?
15:08j4ni: also, ISTR some patches abstracting the displayid parsing in drm_edid.c to be more generic
15:08j4ni: but can't find them
15:25jekstrand: karolherbst: Yeah....
15:28karolherbst: also.. not working apitrace makes debugging stuff really painful :/
15:29jekstrand: karolherbst: I thought I'd fixed most of the stride problems already, though.
15:30karolherbst: jekstrand: I meant buffer strides
15:30jekstrand: karolherbst: Though maybe only row stride and not image stride?
15:30jekstrand: karolherbst: What is a buffer stride?
15:30karolherbst: I thought you meant shader stuff..
15:30karolherbst: no, the issue is more annoying
15:30karolherbst: soo.. let's say you create a 652x692 image
15:30jekstrand: That's a terrible image size but sure. :)
15:31karolherbst: for whatever reason llvmpipe internally allocates a 704x692 buffer for it
15:31karolherbst: and strides the row with 704
15:31karolherbst: which.. I guess is fine
15:31karolherbst: clover doesn't know about it
15:31karolherbst: and once you map the texture, clover maps it as 652x692
15:31karolherbst: or well
15:31karolherbst: reports 652 back to the application
15:32karolherbst: not 704
15:32karolherbst: _but_ if you fill
15:32karolherbst: llvmpipe strides it with 704
15:32karolherbst: so the CTS reads 652 pixels per row and on the second row it collides with the expected result
15:33karolherbst: but it seems like the application can only supply its own stride with a host ptr
15:33karolherbst: so clover really just need to read it back from somewhere I guess
15:34jekstrand: karolherbst: CL lets you directly map textures?
15:34jekstrand: Oh.... That's problematic
15:34jekstrand: The gallium mapping APIs don't allow for specifying a stride
15:34karolherbst: image_row_pitch and image_slice_pitch are outputs
15:34karolherbst: we just need to report the correct values back
15:34jekstrand: Ok, that's fine. You can get that from clover
15:35jekstrand: It's in the pipe_transfer struct
15:35karolherbst: I think I didn't see it there
15:35karolherbst: but maybe clover screwed up
15:35karolherbst: will take a look when I've dealt with the other issue I am working on :D
15:35jekstrand: Clover makes a lot of assumptions about image strides. That's why I had to fix copies. :-)
15:36karolherbst: it's all working on nouveau at least
15:37karolherbst: glxgears broken on s390x with a 16 bit color depth :) that's fun :p
15:46dschuermann: I cannot merge because getting flakes all the time: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5003626
15:50daniels: dschuermann: thanks for the heads-up, sent that board into maintenance for a health check now; the others look totally fine
15:51daniels: just spectacularly bad luck that you managed to land on the one broken board (of 6), three times in a row :\
15:51dschuermann: thx for the quick response :)
18:04airlied: karolherbst: sounds like clover bugs tbh, we have queries to get details about the image
18:04jekstrand: karolherbst: Looking at the mapping code, it shouldn't be hard to fix. We're just dropping all the stride info on the floor today.
18:04airlied: the get_resource_info callback or the transfer
18:06karolherbst: will look into it later :)
18:06karolherbst: but that's somethign I want to fix before we merge the image patches
18:07jekstrand: karolherbst: The image stride information is in the mapping object, it's just that the helpers used by the EnqueueMap throw it away
18:54jekstrand: anholt: Threw you some comments on the TTN patches. Sorry it's taken so long. :-(
19:15airlied: karolherbst: probably esaier to rewrite in rust that persaude curro :-P
19:27curro: airlied: as i said on the discussion with karolherbst i'm not vetoing static CL or anything like that, it just seems strictly inferior to me than the current solution
19:28curro: even been playing around with the idea of using the dynamic pipe loader for GL :P
19:29airlied: curro: would be very messy, and I think mareko would veto it
19:29airlied: not being able to optimised nir before serialisation is going to be a problem in the long run
19:30airlied: granted dealing with large shaders properly is going to be a problem anyways
19:30jekstrand: If the only real problem is the stupid glsl_type singleton, maybe we should get rid of that.
19:31curro: could be messy maybe, but it would give us greater space savings than megadrivers, because the same pipe driver .so files could be re-used for all gallium frontends
19:31airlied: jekstrand: no it's not that
19:31airlied: it's the fact that we load two copies of the util code
19:31airlied: curro: no better than mega-mega-drivers then
19:31airlied: though I dislike mega-mega
19:31airlied: just because it links clang to the GL driver
19:31airlied: and I don't think anyone wants that
19:32curro: airlied: right, it gives you the binary reuse of mega-mega without the dependency hell
19:32curro: airlied: i'm not sure why you say that optimising nir before serialization is not possible with the dynamic loader
19:32airlied:isn't as interested in space savings as I am in being able to not have two copies of util in memory
19:33airlied: curro: you want the driver to be involved
19:33airlied: and the driver has it's own copy of util
19:33airlied: you could do some generic opts indeed
19:34curro: airlied: yes, you could stick to generic opts, *or* get the driver involved, run the whole back-end codegen pipeline and take the binary kind of like we do now for LLVM-based platforms
19:36airlied: curro: those are a large either/or :)
19:36airlied: can't not run the whole backend codegen and still have the driver involved
19:37curro: airlied: we could possibly but not with the current API indeed
19:38airlied: the other horrible option is to split util into it's own shared lib, but uggh
19:38curro: yeah, i was going to suggest that, but i doubt it's large enough to be worth doing
19:38airlied: it's not about size though
19:38airlied: it's about having it in the same address space in clover and the driver
19:39airlied: but we'd likely have to put nir in there as well
19:40airlied: doing GL dynamic loader would have the same problem
19:40curro: which IMHO is not useful enough to be worth dynamically linking any bits of it... but could be done if need be, i just doubt that the glsl_type linking issue is enough to justify it since I think there are better ways to avoid that
19:41airlied: glsl_type isn't the problem
19:41airlied: it's a problem, but util and nir are much worse
19:41curro: how so?
19:41airlied: mesa set code relies on being in one address space
19:41airlied: if you pass a set from one util code to another it will fail
19:42airlied: and I'm sure there are other hidden gems
19:42curro: why is that?
19:42airlied: same reason I assume glsl_type is an issue
19:43airlied: for set.c it's deleted_key
19:43airlied: you end up with two instances of the deleted_key static var
19:43airlied: and they have different addresses
19:44curro: ah i see, seems like it could be fixed easily
19:44jekstrand: That sounds like a design flaw in the set data structure
19:45jekstrand: But also having two copies of the same code in your address space and trying to pass data structures between them is sketchy
19:45curro: but even if we don't fix that problem in the set code, this sort of issues could be avoided altogether without changing how we link util, by using serialized bitcode for other front-ends as well
19:46jekstrand: I'll eat the disk-space cost over added runtime cost
19:46airlied: curro: yes but there's a lot of optimised investment in the GL stack totally set against doing that
19:46curro: airlied: we discussed that in depth and there isn't such a clear benefit, actually in the typical case passing around serialized NIR would be more optimal
19:47airlied: curro: did mareko agree? because he's the one that introduced nir finalisation
19:47airlied: and the whole variant handling for it
19:48airlied: I do wonder for clover if we could keep the clang bits in one address space and maybe have some common driver utility code
19:48airlied: to do all the spirv/nir processing in the other address space
19:49airlied: would likely needs loader changes
19:52curro: airlied: i don't remember mareko's opinion. the typical case i was referring to where serialized NIR would be more optimal than the current approach is where we hit the on-disk cache: assuming the shader also hits the driver's disk cache we save the deserialization and copy (since we could declare the serialized bitcode to be immutable so we could just pass a const pointer to the driver)
19:54curro: so sure we could do those linking changes but i don't think there is any real disadvantage for clover to just pass the bitcode around
19:56jekstrand: If you assume that clover->driver is entirely one-way, maybe not.
19:56jekstrand: But it's not one-way
19:56jekstrand: Well, it is now but if we want to be able to optimize pre-lowering, that gets tricky to maintain
19:57curro: it is right now. it would make sense to make it two-way with some additional interface and have the driver come back with a binary, which once again doesn't pose any problem to the current linking approach
19:58jekstrand: If we insert a [de]serialization step every time we pass it back and forth, yeah, it can be done.
19:59curro: i don't think we want to be passing NIR back and forth anyway, the two-way interface i'm thinking of involves the driver getting a serialized NIR bitcode and possibly returning a fully compiled binary
20:01curro: which fits how we do things for LLVM-based back-ends
20:02jekstrand: Yeah, but it fits horribly with the way that NIR compilers are currently structured.
20:02airlied: but then drivers need cl lowering pases
20:03jekstrand: And literally the only compelling reason to change that is so we can work around loader issues with clover.
20:03jekstrand: THat seems like desigining around a problem to me.
20:04airlied: yeah i dont think clover needs to be so distant from the drivers here
20:04curro: we were just discussing of some linking changes to allow that, but i don't see any such horrible issues you mention, going from serialized NIR to a binary seems to work just fine for current NIR compilers
20:04jekstrand: It doesn't
20:04airlied: not once you hit real shaders
20:04jekstrand: We could get rid of some of the lowering in clover and do it closer to the back-end in iris.
20:04jekstrand: And it wouldn't be so bad for iris because we have our own constant buffer handling there.
20:05jekstrand: nouveau and llvmpipe would have suffer though
20:05jekstrand: Because clover can't set up a magic constant buffer for them unless we lower constant access very early
20:05jekstrand: But we want to lower it after doing some optimization
20:06curro: and i don't see why we can't do all of that up front with the current NIR-based compilers -- and even get a binary right away
20:06jekstrand: So we either need to hook the back-end driver's optimization loop or clover needs to grow its own
20:06jekstrand: What do you mean by "up front"?
20:08jekstrand: Also, we're still desinging around a problem. How we structure the compile pipeline shouldn't be constrained by dynamic linking issues.
20:09curro: i don't think it's constrained, we were just disccussing some linking changes we could do to allow that, i'm just trying to understand the potential benefit from it
20:11jekstrand: We want to optimize before we lower
20:11jekstrand: That means we have three options:
20:11jekstrand: 1. Shove said lowering into each back-end
20:11mareko: curro: what's wrong with finalize_nir?
20:11jekstrand: 2. Call the back-end's optimization hook (brw_preprocess_nir)
20:12jekstrand: 3. Build an optimization loop for clover that's separate from the back-end's
20:12jekstrand: Option 2 gives the back-end the most control but also makes the NIR passing bidirectional
20:13jekstrand: I generally like 2. It's what we've been doing in ANV and the other Intel drivers and it works quite well.
20:14curro: jekstrand: and why would we need to change anything about linking in order to do 2.?
20:15mareko: I don't really know clover, but it looks like you are facing some multi-lib hell
20:15curro: lowering as part of the back-end sounds like a pretty reasonable approach to me honestly, gives the back-end as much if not more control
20:16jekstrand: curro: We either need to fix our multilib problems for 2 or serialize when we pass to the driver opt loop and serialize when it passes back to clover.
20:17jekstrand: curro: As far as lowering in the back-end goes, that's ok for some things but not all. In particular, it's really convenient that clover is able to handle the .data section as a magic constant buffer. Doing that without some of the lowering being controlled by clover is tricky.
20:19curro: jekstrand: serializing+deserializing seems like the most consistent thing to do if the program representation is NIR_SERIALIZED
20:19curro: jekstrand: why does clover need to get involved in laying out the data section at all?
20:20curro: the driver could just give clover a binary including the actual machine code plus whatever data section it wants
20:20jekstrand: Right now, clover is inserting the magic argument only if needed. I guess we could always insert it.
20:21curro: or we could insert it if the back-end provides a data section
20:21jekstrand: We can't insert arguments after the fact. Not easily.
20:21jekstrand: Yeah, this is quite annoying...
20:21jekstrand: On iris, it's not a problem because iris already handles it with shader patching magic
20:22jekstrand: But the idea was that clover would handle that for you to be nice to other drivers.
20:23curro: handle what exactly? adding an additional pointer to the input buffer? clover could do that still *if* the driver requests a .data buffer to be passed to the kernel
20:23curro: the back-end should be able to predict whether it has any constants in the data buffer, why is there any need to patch shaders?
20:24airlied: mareko: finalize nir would get in the way of a GL driver using dynamic gallium pipe loader
20:24airlied: not a problem now of course
20:27curro: airlied: i think it should work if the shader is represented in a format according to the pipe_shader_ir in use
20:28jekstrand: The back-end needs to know where to get the constant data pointer and do the lowering to handle it. This means means it needs to know where the argument is going to be and we would need to move the "turn load_constant into load-from-CL-pointer" pass from clover to core NIR so the back-ends could call it.
20:28jekstrand: It can all be done. It's just more work for the back-ends and completely unlike the way any of the other compiler stacks work.
20:29jekstrand: And potentially leaks clover internals into core NIR
20:29jekstrand: That or we have to start standardizing OpenCL arguments more somehow
20:30jekstrand: Or pass the list of arguments from the back-end back to clover as part of the binary and make the back-ends deal with it all. At which point, why do we have a shared state tracker again?
20:30curro: uhm, but the same goes for every other input arguments passed to the kernel... of course there needs to be a sort of ABI between the kernel and the state tracker, i don't think the data section pointer changes the picture in any fundamental way
20:31karolherbst:thinks adding ABIs is bad
20:32curro: karolherbst: we already have one, otherwise the input arguments set by the state tracker wouldn't show up in the kernel
20:32jekstrand: curro: Yes, and everything having do do with said ABI is handled internally to clover right now. All the driver gets is "here's your input data" and, by the time it sees the NIR, everything is in terms of nir_intrinsic_load_kernel_input with a byte offset.
20:32karolherbst: the shader should explain its structure itself without having to rely on a "formal ABI"
20:32jekstrand: But that assumes that clover is in control of lowering everything to load_kernel_input
20:33jekstrand: Which it isn't if we push lowering into the back-end
20:33jekstrand:feels like we're doing PPT block diagram design here....
20:33karolherbst: curro: that's not really an abi anymore
20:33karolherbst: the shader loads an uniform
20:33karolherbst: the driver binds an uniform buffer
20:33karolherbst: that's it
20:34karolherbst: no hidden implicit ordering or alignment or anything
20:36karolherbst: but clover also tells the driver what to do
20:36karolherbst: the driver doesn't have to know anything on its own
20:36karolherbst: that's more or less my point
20:37curro: karolherbst: sounds like a simple ABI? or maybe there is a better word for it
20:39airlied: i did mean to ask if we could lower load kernel inoput to load ubo
20:39karolherbst: the runtime should be explicit about everything
20:39karolherbst: airlied: maybe
20:40jekstrand: airlied: karolherbst and I would like to
20:40curro: jekstrand: what if we give the driver complete freedom to manage the final section of the input buffer in order to minimize coupling between CL and NIR, and simply provide to the kernel whatever data the back-end comes back with at the end of the input buffer?
20:40karolherbst: I also want to use pipe_constant_buffer in clvoer
20:40jekstrand: airlied: I'd like to see it lowered to cbuf0 like we do for GL
20:40karolherbst: curro: we can't
20:41karolherbst: CL has strict requiernments on how much you can put into the buffer, etc...
20:41karolherbst: so there isn't that much freedom to gain anyway
20:42curro: so allocate a larger buffer in order to hold the fixed amount of bits returned by the back-end for the data section? or pass as a separate buffer -- a constant buffer under control of the pipe driver would be a fine solution too
20:47mareko: how is calling finalize_nir different from calling create_compute_state? what difference does it make if the former is folded into the latter?
20:48curro: jekstrand: another fairly compelling thing to do may be for clover to insert a data section pointer value into the shader before passing it to the back-end (which would be calculated in terms of nir_intrinsic_load_kernel_input right now but the back-end doesn't need to know that)
20:51airlied: mareko: for ccs it would start passing serialised nir
20:51airlied: and ccs is one way
20:52airlied: finaloze would need a serialize in core, deserialize in drv on entry, and vice versa on exit
20:56curro: mareko: i think doing that with finalize_nir would be fine too, despite the additional serialization and deserialization relative to the alternative that involves folding everything into create_compute_state
20:58mareko: I'm not invested in clover, so feel free to do there what you need. It's not necessary to call finalize_nir before caching for clover (it's only necessary for GL). If you call finalize_nir for clover right before create_compute_state, that's fine too.
20:59airlied: for clover i just finalise in ccs right now
20:59airlied: this was more about a dynamic Gl
21:00airlied: doing GL using dynamic pipe loader
21:00curro: as alternative to mega-mega-drivers
21:00jekstrand: Too many conflated discussions....
21:01airlied: well just one big messy discussion :-p
21:02mareko: making the gallium interface an ABI? I wouldn't be a fan of that
21:02airlied: well it would be mesa internal
21:02airlied: you wouldnt mix and match
21:03curro: yeah, it would make sense to version it in order to enforce no mix and matching
21:03mareko: I'm more in favor of mega-mega (e.g. GL + vaapi)
21:03airlied: yeah i tend to mega mega
21:04curro: except the payoff is more limited unless you're willing to pull in Clang for GL+vaapi+CL ;)
21:04airlied: i wonder if clover loaded clang at runtime rather than linking would mega mega be okay
21:04airlied: you woukd also have to kill clover constrcutors
21:05airlied: since so much happens on library load
21:05curro: right, and make sure that no other drivers nor frontends are doing nor will ever start doing anything expensive at load time like pulling in additional dependencies
21:07airlied: exactly, no implicit construction in anything
21:08airlied: seems easier to track vs subtle address space issues
21:09mareko: is clang that big of a deal? we already link against llvm
21:10mareko: and all GL drivers need llvm for faster selection and feedback modes
21:10dcbaker[m]: mesa developers, completely different question. We should be branching for 20.3 around the start of November (3 weeks). That's coming up. I just got 20.2.1 out. That would make for a fairly short 20.2 cycle. We could push 20.3 out a couple of weeks and having a release right at the end of the year. Or we could drop 20.3 and pull 21.0 in a bit, and have an early 21.0 release. Do people have strong opinions one way or
21:10karolherbst: curro: there is cl/gl sharing anyway
21:10curro: airlied: not sure about that... the address space issue is mostly a problem regarding the data structures used in the interface between frontends and backends which may not be ready to work across a shared object boundary. the load-time overhead issue OTOH involves the internals of the components involved
21:11airlied: mareko: clang kills gdb
21:11karolherbst: airlied: since when?
21:11mareko: llvm too
21:11mareko: the trick is to strip the libs
21:11karolherbst: have more RAM :p
21:11airlied: mareko: but i like debug syms
21:12mareko: I've learned that I definitely don't need debug syms in llvm
21:12airlied: the difference in loading clang syms seems a lot longer thsn llvm
21:13mareko: if stripped clang doesn't kill gdb, then I'm fine with mega-mega
21:14airlied: dcbaker[m]: the wisdom of predictable and timed schedules is slips just mean shorter cycles
21:14airlied: not more slips
21:14dcbaker[m]: that's kinda what I was thinking too
21:14dcbaker[m]: but wanted to ask
21:15mareko: dcbaker[m]: more frequent releases would be better than less frequent
21:15jekstrand: dcbaker[m]: Just keep them ticking along
21:15eric_engestrom: airlied: a counter argument is that "next release 3 months after the last, even if the last one took 4 months" also makes sense
21:16airlied: eric_engestrom: that isnt predictable though
21:16jekstrand: eric_engestrom: Until you slip past the end of the year and then people ask what happened to 20.3
21:16eric_engestrom: airlied: fair
21:16jekstrand: At which point, I think we reply with "it caught COVID and died"
21:17jekstrand: But, yeah, just keep 'em coming.
21:17airlied: its not as if linux or llvm are predictable
21:17eric_engestrom: jekstrand: agreed, but do people really care about release numbers? they want a release with new features, they don't reallly care what it's called
21:17eric_engestrom: FYI the current schedule is: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6616/diffs
21:17dcbaker[m]: Let's plan on branching 20.3 on November 4th then
21:17airlied: eric_engestrom: we moved to timed releases
21:17dcbaker[m]: like 6616 says
21:17airlied: not feature ones
21:17ccr:builds a small bikeshed in the corner, full of version numbers. just in case.
21:18jekstrand: Consistency is a good thing
21:18airlied: if a feature misses a bus you know the time of next bus
21:18eric_engestrom: airlied: I know, I just meant that users want the new code but they don't care what name is on the package
21:18eric_engestrom: anyway, I have no preference, I was just exposing both arguments
21:19airlied: eric_engestrom: yeah like losing 20.3 vs 21.0 is probably not a problem
21:19jekstrand: Since all the people with preferences say "fork it", I say we should go with that. :-P
21:19eric_engestrom: seems the consensus is to keep november 4th as the next branchpoint :)
21:19airlied: but i dont think pulling in 21.0 because we skipped 20.3 is good either
21:19eric_engestrom: I don't think that's what dcbaker suggested
21:20dcbaker[m]: That was one option I floated
21:20daniels: dcbaker[m]: realistically, given Christmas etc, I don't think there's much benefit in stretching over December since it's not going to make much difference
21:20eric_engestrom: it was about having the next release be 3 months after 20.2, and the fact that this would put it next year and as such we'd call it 21.0
21:20mareko: can somebody explain to me why we are debating whether 20.3 should be skipped?
21:21eric_engestrom: mareko: I don't think we are, see my last message
21:21daniels: mareko: I think the rationale was all in dcbaker[m]'s original message
21:21dcbaker[m]: mareko: the question was "skip 20.3 and pull in 21.0" or "have a couple of fairly short release cycles". Everyone like optoin 2 better
21:22eric_engestrom: to me the two options are: 1) next release as planned, nov 4th, which means short cycle, or 2) next release is 3 months after 20.2, which means we push it back a few weeks
21:22jekstrand: We should just always branch in the first week of Febuary, May, August, and October
21:22eric_engestrom: jekstrand: that sounds like a good plan; let's put that in the docs
21:22Supertanker: Hey all. I have a basic DRM question. I'm researching a fuzzer for i915/DRM and I'm stuck on talking to DRM itself. Are DRM clients all supposed to run as root on a typical system (no normal users in video/render groups)?
21:23Supertanker: I've found lots of discussion on how one process (e.g., wayland, X11) is marked drm-master and all the other ones have to auth with it, but I can't figure out how the authorization flow happens when the DRM device node is usually root:video (and the render node is root:render)-writable only.
21:25jekstrand: eric_engestrom: Maybe I got that wrong... I think I meant January, April, July, October.
21:25jekstrand: eric_engestrom: It should be a three-month stride preferably timed so the release manager isn't releasing over Christmas.
21:25daniels: Supertanker: usually logind does this for you
21:25daniels: Supertanker: that's what GNOME, KDE, Weston, wlroots, Xorg, etc, all use
21:25daniels: jekstrand: not releasing over Christmas ++
21:26daniels: even if you do ruin someone's Christmas by trying it, no-one's going to notice, no distros are going to pick it up
21:26jekstrand: And, yeah, the Jaunary release is always going to be a bit light but that's ok
21:26eric_engestrom: jekstrand: yes, 1/4/7/10, and +1 on not doing rc's over christmas
21:26dcbaker[m]: daniels: yeah, usually in the past the release has fallen around the end of november/start of december
21:26dcbaker[m]: (final release I mean)
21:27jekstrand: What do we usually have? 4 rcs?
21:27dcbaker[m]: .3 the release is usually a lot less work than the others because mesa development slows down around that time
21:27dcbaker[m]: yeah, usually 4
21:27dcbaker[m]: sometimes 5 or 6
21:27Supertanker: daniels, yep, that's what I've learned so far. I want to give my own application access to DRM/i915 to fuzz it from userspace (specifically the command buffers). So far I am leaning towards giving it access to the render node since that is the least privileged entry point I am aware of. What others should I target?
21:27eric_engestrom: yeah, although lately it's been more
21:27Supertanker: I'm not expecting to have functiona display manager for this.
21:27jekstrand: Ok, so we could go as late as 1st week of 2/5/8/11 if we wanted
21:28eric_engestrom: no reason to push it, is there?
21:28jekstrand: But we should pick an "nth week of N/N+3/N+6/N+9" that the release managers like and call it a day.
21:28daniels: Supertanker: I'd definitely recommend starting with the rendernode, yeah
21:28jekstrand: Pushing the january release out a couple weeks would give more flexibility around the new year
21:29jekstrand: So maybe 2nd week of 1/4/7/10?
21:29eric_engestrom: sounds good :)
21:29FLHerne: What's best for aligning final releases with the 4/10 distro schedule for Ubuntu et al. ?
21:29dcbaker[m]: jekstrand: i like later in January better personally. I'd say week 3 or 4 would be better
21:29daniels: Supertanker: for the KMS card nodes, I'd just have a small suid helper which opens the device, drops privileges, and execs your fuzzer
21:30FLHerne: It would be bad to pick a date that results in missing by a few weeks
21:30dcbaker[m]: So many people come back from the holidays after having not done anything and do a ton of work
21:30eric_engestrom: FLHerne is right, let's check what's best for these distros
21:30jekstrand: dcbaker[m]: Then maybe it's better to branch right before they dump in a pile of regressions?
21:31jekstrand: What I care about are, in this order:
21:31dcbaker[m]: the bigger problem is they usually stop working around the start of december
21:31jekstrand: 1. Consistency
21:31dcbaker[m]: so there's not much in the .0 release
21:31jekstrand: 2. Being friendly to release managers being able to take vacation around EOY
21:31jekstrand: 3. Being friendly to distros.
21:31Supertanker: daniels, clever. I've not dealt with the kernel much (hell of an intro but I'm learning as I go). If I don't claim ownership as master before the privilege drop, should I be locked out of those capabilities (on purpose)?
21:31eric_engestrom: dcbaker[m]: is that really an issue?
21:31jekstrand: dcbaker[m]: That's ok. It's a small release. That's fine.
21:32dcbaker[m]: then week 2 is fine
21:32anholt:is of the opinion if timing the release is important, then we're not rolling normal releases often enough. with 3-month cadence, we seem to be plenty fast.
21:32eric_engestrom: I think checking what the .04/.10 distros prefer is good though
21:32jekstrand:agrees with anholt
21:33jekstrand: Hence distro preferences being at the bottom of my list
21:33eric_engestrom: anyway, /me is off for the night
21:39jekstrand: eric_engestrom, dcbaker[m], anyone else: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7149
21:39jekstrand: y'all can fight over whether or not you like Wednesday. I picked something and other places in the docs said they like Wednesdays. I honestly don't care.
21:42dcbaker[m]: can we finally start using the "approve" button instead of manually writing r-b in the comments, or is that opening another can of worms?
21:43jekstrand: dcbaker[m]: Keep that can of worms to yourself. :-P
21:43jekstrand: hehe :)
21:47mattst88: anyone notice that Jose switched mesa demos from GLEW to Glad?
21:47mattst88: I sort of just want glxgears and glxinfo to be in their own project, outside of demos
21:49mattst88: better would be glxinfo as just a wrapper around wflinfo or something like that
21:50emersion: … and maybe switch glxgears to EGL… ?
21:52jekstrand: There is already an eglgears or maybe it's gles2gears
21:52mattst88: right; would be nice to not have a bunch of separate pieces like this
21:52emersion: ah right, eglgears_x11
22:00emersion: oh, mesa-demos is still cmake+autotools
22:01mattst88: In Gentoo I run configure, but then just make -C src/xdemos glxinfo glxgears
22:01mattst88: so configure is not so amortized
22:06dcbaker[m]: mattst88: https://gitlab.freedesktop.org/dbaker/graphics-information
22:06emersion: there's also eglinfo, glinfo, and so on
22:08dcbaker[m]: what was the name of that library that anholt created for piglit dispatch (the compliment to waffle)
22:09Supertanker: thanks for the advice on my fuzzer all. I appreciate it!
22:15anholt: dcbaker[m]: libepoxy
22:15dcbaker[m]: awesome, thanks
22:15anholt: still wish we could get piglit onto it, it's so much nicer than piglit has
22:18dcbaker[m]: I had mesa demos ported to use it at one point
22:18dcbaker[m]: but there were windows bugs I could never figure out
22:18dcbaker[m]: and now I can't find the branch
22:20dcbaker[m]: glxgears has code for VMS
22:20dcbaker[m]: what is this madness?
22:21mattst88: are we claiming to support llvm-11 yet?
22:21jekstrand: mattst88: We'd better be. F33 ships with it.
22:22mattst88: I don't see anything in CI that looks like it's testing llvm-11 (or even llvm-10 for that matter)
22:22jekstrand: That seems suboptimal
22:47jekstrand: karolherbst: FYI: Updated to F33 and LLVM11 and now the async copies are busted
22:47jekstrand: Something is barfing because they use the Groups capability
22:47jekstrand: Which isn't supported by CL 1.2
22:47karolherbst:thinks sticking to f32 is the best idea then
22:48jekstrand: Could also be a new spirv-tools
22:48karolherbst: I fixed that in the translator
22:48alyssa: f33 = f32 with an extra bit of precision?
22:48jekstrand: alyssa: Yup. It's for when you do an fma
22:48karolherbst: jekstrand: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/commit/fdd19ed26164fae6eacfe1926f51c443c5ea0552
22:49karolherbst: cherry-pick it and be happy :p
22:49alyssa: jekstrand: --oh, I was joking but okay :p
22:49jekstrand: karolherbst: Yeah...
22:49jekstrand: karolherbst: Do they not have a good back-merge process?
22:49karolherbst: I think that's on me caring not enough
22:49karolherbst: but they have branches for each llvm release
22:50karolherbst: and we could ask for a cherry-pick probably
22:50karolherbst: or just do it ourselves?
22:50karolherbst: llvm_release_110 would be the branch for llvm11 ;)
22:50karolherbst: I am still at llvm_release_100 + a bunch of stuff
22:50jekstrand:pulls and re-builds
22:51karolherbst: this is the only patch I have on top
22:51karolherbst: before anybody uses clover in production we have llvm14 anyway
22:58karolherbst: okay.. strides
22:59jekstrand: anholt: Reviewed. Let's give those poor softpipe users a few more FPS. :-)
23:00anholt: jekstrand: I've still got my eyes on 10k lines of g-t-t code, that's what this is really about
23:00anholt: though, getting softpipe to be more credible increase the chances that I can nuke 23k lines of swrast
23:00karolherbst: emplace_back is also a function from hell in terms of debugging :/
23:01karolherbst: is there a "skip all std::*" mode in gdb?
23:01jekstrand: anholt: I'm up for nuking some SW drivers. :)
23:02anholt: well, we don't get to drop src/mesa/swrast until we lose software fallback classic drivers
23:02anholt: we can hopefully kill classic osmesa sooner, though
23:03jekstrand: I recall saying sometime around a year ago that we should consider forking mesa in ~1year and dropping all the classic drivers....
23:03jekstrand: Though 2020 seems like a bad year to be making that sort of change. :)
23:03karolherbst: or a good one
23:06anholt: jekstrand: err, looks like we have unsigned for instruction index, uint32_t for start/end ip. make start/end consistent?
23:06jekstrand: I prefer sized types
23:06jekstrand: Even though I know it doesn't matter
23:06anholt: me too
23:07anholt: just, we've got a split today. I don't really care which way we go.
23:07karolherbst: curro: what do you prefer: changing resource::add_map return type to clover::mapping* or adding out parameters for row/layer stride?
23:07jekstrand: anholt: I'd say go uint32_t
23:07anholt: and switch the existing field in instr? sounds good
23:07jekstrand: karolherbst: That question is why I haven't sent an MR for that yet today. :-)
23:08karolherbst: I prefer not using out params :p
23:09karolherbst: yeah... shouldn't be too bad
23:10curro: karolherbst: the former plz
23:11karolherbst: the only ugly part is that we have a std::list<mapping> maps; thing
23:11karolherbst: and retruning a pointer looks ugly :/
23:11karolherbst: but I guess that's fine
23:14curro: karolherbst: ah... right, i think that should be okay, an std::list is guaranteed not to invalidate pointers to other elements of the list while adding or removing other stuff
23:15karolherbst: yeah, and it's only used in the api and never stored anyway
23:15karolherbst: we could also return by value
23:15karolherbst: it's just 4 pointers
23:15karolherbst: and the compiler will probably opt it away? dunno
23:16karolherbst: probably not though
23:16curro: i don't think i defined mapping as copyable
23:16curro: it could be done though
23:19karolherbst: it works \o/
23:21karolherbst: CL 1.2 images is quite a lot of work...
23:22karolherbst: airlied: do you have load/store scratch support for llvmpipe somewhere?
23:22karolherbst: need it for luxmark
23:22karolherbst: clFill: PASSED 370 of 370 sub-tests. with llvmpipe :)
23:23karolherbst: now let's see if copy image works as good as that
23:23karolherbst: curro: in case you feel bored: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7069
23:24karolherbst: and there is more to come :D
23:24karolherbst: not in the best state (aka patches not cleaned up) but comments on general ideas might be helpful
23:25karolherbst: especially that inline sampler stuff
23:25curro: karolherbst: cool, will take a look
23:25airlied: karolherbst: yes in a branch
23:25airlied: karolherbst: llvmpipe-cl-scratch
23:26karolherbst: clCopyImage: PASSED 814 of 814 sub-tests. \o/
23:26karolherbst: cool that it works for two drivers now :)
23:26karolherbst: airlied: k, thanks
23:28karolherbst: the hell is nir_op_fdph
23:28karolherbst: airlied: hitting this now
23:28karolherbst: mhh lower_fdph?
23:30airlied: karolherbst: oh newer brnch
23:30peepsalot: hello, I'm looking for info/examples about making a mesa offscreen context on mac os
23:30airlied: oh wait
23:31airlied: karolherbst: no that branch should have it, just WIP
23:31karolherbst: airlied/llvmpipe-cl-img-wip should be enough, no?
23:32karolherbst: that one commit also contains stuff..
23:32peepsalot: the code I'm working on, was not originally developed by me, and currently gets a context through CGL / "Apple Software Renderer". i don't use a mac, but our CI server does and has some shader bugs that I'm trying to work around, which I think are from Apple's driver.
23:33peepsalot: so I'm wondering if mesa can be used for this?
23:34peepsalot: or has apple successfully banished opengl now?
23:34karolherbst: the latter more or less
23:35karolherbst: airlied: mhh.. it's all black :/
23:35peepsalot: my problem is specifically with GLSL function dFdy it makes a bunch of missing horizontal lines in the output. its only broken on mac. i can't stand apple incompatibility fetish
23:36karolherbst: airlied: hit nir_op_b32all_iequal3 later on
23:36karolherbst: should try to fix the benchmark on nouveau first anyway
23:36peepsalot: any possible advice, for an open source project to continue supporting mac?
23:37karolherbst: drop support?
23:37karolherbst: apples GL stack is just super broken
23:37peepsalot: karolherbst: so is there no alternative for CGL?
23:37dcbaker[m]: move to vulkan and use moltenvk
23:37karolherbst: pretty much that
23:37airlied: karolherbst: oh I have it here luxmark, I had started playing, but amd seemed better
23:38lrusak: I think I might have found a bug in the IRIS driver, who should I ping? https://github.com/xbmc/xbmc/issues/18245#issuecomment-708715272
23:38peepsalot: learning and converting the whole codebase to vulkan would be a massive undertaking for me, i don't get paid enough(at all) for that
23:38karolherbst: I should focus on getting the basics in anyway
23:38karolherbst: yeah.. it's a mess
23:38karolherbst: OpenGL is officially deprecated in macos
23:39kisak: lrusak: file a bug on mesa's issue tracker https://docs.mesa3d.org/bugs.html
23:40lrusak: kisak, thanks :)
23:40karolherbst: peepsalot: I guess your only alternative is to indeed use mesa or workaround/fix issues you found on macos
23:40lrusak: basically the gbm bo reports different modifiers than what it was created with
23:40karolherbst: at least llvmpipe is more or less confirmed to be compliant
23:41peepsalot: karolherbst: ok, that's what i'm asking then. just a basic example of offscreen context on mac I guess. sorry I'm just really confused how all the stack fits together and know nothing about macs
23:41peepsalot: i wasn't even sure if mesa works on mac, but there's a homebrew package for it at least
23:42karolherbst: yeah.. but it will be software only
23:42dcbaker[m]: just software rendering
23:42dcbaker[m]: I don't think mesa integrates with the native windows system either
23:42peepsalot: well, "Apple Software Renderer" is already software only...
23:42peepsalot: this is for headless CI tests
23:43karolherbst: sure, but people will use it on their hardware, no?
23:43karolherbst: and testing against mesa will probably just work, and show bugs on users machines
23:43karolherbst: I mean, CI will pass
23:43karolherbst: but users will see issues because of apples broken GL stack
23:43karolherbst: so testing against apple is probably "safer"? dunno
23:46peepsalot: maybe, but i guess i'm thinking it could use mesa for offscreen headless rendering and whatever apple CGL crap if non-software renderer is available?
23:46karolherbst: but then it's pointless to CI it, no?
23:47karolherbst: maybe I don't know what the software is for, but is it expected that users use it on their desktop and hence hw GL is available or is that mainly server software and off screen rendering is the norm?
23:47anholt: karolherbst: it is very common to CI software against a reproducible software renderer. it is a difference vs hardware, but it means you can do things like have exact pixel expectations of your output.
23:47peepsalot: its OpenSCAD, desktop CAD software
23:48karolherbst: anholt: mhh, right, but using an entirely different GL stack than what users use might cause also issues? but I see your point
23:49karolherbst: peepsalot: so, yeah, I mean, it will probably work, I am just curious on how much it helps with preventing issues on end users machines
23:49karolherbst: but that's probably something you will notice then
23:49karolherbst: and I guess in most cases it's going to be fine
23:49karolherbst: but it also heard like you tripped over a bug in apples stack
23:50karolherbst: anyway.. no idea if we have exmaple ocde :)
23:50peepsalot: i guess i'm just praying that its only an issue with their software renderer, and if hardware render is available then maybe it works ok
23:50karolherbst: yeah, might be
23:50karolherbst: it's probably also better than nothing
23:51karolherbst: but I guess investigating if it's a real issue on hw rendered might be a good idea