00:05 alyssa: airlied: why is bind a thing if mesa/st freely ignores it
00:09 zmike: airlied: sure seems that way to me, hence my patch
00:12 airlied: alyssa: the problem isn't that mesa/st ignores it, GL ignores it, not leaving anyone else much choice
00:12 airlied: though maybe mesa/st should just bind all flags
00:13 alyssa: airlied: why is bind a thing if GL freely ignores it
00:13 airlied: when creating buffer objects
00:13 airlied: alyssa: I think it cames from vmware initial design, there's been a few talks of dropping it I think
00:13 airlied: imirkin: usually remembers this better than me
00:14 alyssa: so much of Gallium seems to be "OpenGL and DX11 in the same driver" and then the DX11 st didn't happen..
00:14 airlied: alyssa: dx9
00:14 alyssa: what's that? ;)
00:14 airlied: and later dx10, not sure the dx9 code is used anymore
00:15 airlied: but yeah removing bind might be an idea
00:15 airlied: zmike: the problem with your patch is it bandaids one test
00:15 zmike: sure does!
00:15 airlied: whereas it just leaves the pitfalls all over
00:16 zmike: well it fixes uniform texel usage across the board
00:16 zmike: some of the other usages like storage I have better fixes for in 100-200 patches down the line
00:41 imirkin: alyssa: the gallium API mirrors DX. however the reality is that any GL buffer can be bound as anyting, so if you rely on resource->bind, that's a bug.
00:41 alyssa: yeah..
00:44 airlied: imirkin: yeah the question is why do we have resource->bind at all :-P
00:44 imirkin: airlied: because it mirrors DX. and also because e.g. with textures, some formats may be texturable but not renderable
00:44 zmike: well it IS right a pretty substantial amount of the time
00:45 zmike: because a ton of resources are just created for internal gallium use
00:45 imirkin: zmike: because in practice, people don't rebind PBO's to index buffers
00:45 imirkin: but they totally could.
00:45 zmike: sure, the pbo case is an outlier though
00:45 imirkin: i just picked one at random :)
00:45 imirkin: also it was less of a thing in earlier GL versions
00:45 airlied: yeah that test pretty much uses GL_COPY_BUFFER for an arbitrary bind point
00:46 imirkin: and probably seemed like a better idea
00:46 airlied: it could just have easily used the pixel unpack buffer
00:46 imirkin: moral of the story is that relying on pipe->bind for PIPE_BUFFER's is a bug waiting to happen
00:47 airlied: I do wonder if we should just fix the st to alway pass a bunch of them
00:47 imirkin: for e.g. textures it has some more teeth, but even there - you can end up with a texture being attached to a framebuffer object
00:47 imirkin: and if it's not renderable, then redering fails and then people say "but it works on nvidia, so your driver is broken"
00:47 airlied: or maybe have some sort of fallback path to rebind a new buffer for the insane ppl
00:47 zmike: for textures all you need to know is that SAMPLER_VIEW actually means YOLO
00:48 zmike: airlied: currently the lack of rebinding in the driver is why there haven't been more patches fixing bind usage
00:48 zmike: uniform texel is one of the safe cases where adding it doesn't break anything
00:48 imirkin: depending on how a buffer is bound, various hw needs to do diff things though
00:48 imirkin: like we keep track, in nouveau, whether a buffer is currently bound as a constbuf
00:49 imirkin: and if it is, we have to do things differently for it
00:49 imirkin: but that has nothing to do with its ->bind value
00:49 zmike: bind is supposed to be the likely usage
00:49 zmike: for things like u_blitter creating samplers
00:49 imirkin: aka "you can't rely on it"
00:50 zmike: the problem is just for resources that originate from GL
00:50 zmike: and not from gallium internal
00:50 imirkin: i.e. the majority of resources
00:50 zmike: it's not the majority though
00:50 imirkin: it should be
00:50 zmike: there's tons of internal resources
00:50 imirkin: uhm
00:51 imirkin: depends on the application, and depends what additional things you're bolting on
00:51 imirkin: i can't think of a single source of "internal" resources with nouveau
00:51 zmike: well I'm zink, so I'm bolting on all the additional things
00:52 imirkin: but i wouldn't exclude the possibility that it exists
00:52 airlied: I think for zink vkBufferCreateInfo should get all the flags unfortunately
00:52 airlied: and just ignore bind
00:52 imirkin: e.g. maybe something like cso_draw_arrays or some such. would have to check.
00:52 zmike: airlied: that's not viable
00:52 zmike: I've tried
00:52 zmike: look at the date on the MR
00:53 zmike: it's not a new issue :)
00:53 imirkin: zmike: it's undesirable. but the only alternative is you guess one, and then copy resources around when you guess wrong
00:53 imirkin: some drivers keep track of a "usage history"
00:53 zmike: no, it's vulkan, so I can just create using a default path and rebind later if I need additional usage
00:54 zmike: which I've already done
00:54 imirkin: so what's the problem then?
00:54 zmike: there is no problem
00:54 imirkin: cool
00:54 zmike: I did get to learn a lot about nouveau internals once again though
00:54 zmike: which is always eye-opening
00:54 alyssa: lol
00:55 imirkin: alyssa: fwiw there was a dx11 st, but it was never upstreamed
00:55 imirkin: or it was part-there and then removed
00:55 imirkin: (due to its partial-ness)
00:57 airlied: yeah it was upstream for a while, then the primary author ghosted mesa
00:57 airlied: zmike: so the code to rebind later is in wip somewhere?
00:57 zmike: yes
00:57 alyssa: Boo.
00:58 zmike: it requires invalidate
00:58 zmike: which I didn't tackle until just before tc
00:58 alyssa:still needs to fix invalidate
03:11 airlied: anholt: I epxect your deqp fails are due to surfaceless egl
03:26 airlied: anholt: though maybe not
04:00 airlied: kusma, zmike : I don't think the current zink/lvp ci is working on zinkj at all
04:02 zmike: airlied: hahaha
04:02 zmike: I have printfs in my wip branch now just so I can always make sure I know
04:02 zmike: this is a very relatable problem
04:03 airlied: it prints GL4.5 which is llvmpipe not zink/lavapipe which should be GL 3.2
04:05 zmike: huh but what about those xfb tests that were crashing?
04:05 zmike: didn't they stop once kusma's lvp null buffer thing went in?
04:06 airlied: I'm not sure but so far I'm not seeing how it tests it
04:06 zmike: it's the uhhh gl 4.2 enhanced layouts tests
04:06 zmike: I think
04:07 zmike:is at absolute minimum brainpower
04:07 airlied: like the logs are showing GL 4.5 which can't be true
04:07 zmike: hmmm
04:07 zmike: maybe worth adding a printf to zink when ZINK_USE_LAVAPIPE is set just so we can easily determine?
04:08 zmike: (obviously doesn't fix a problem here but since it seems to be hard to detect...)
04:13 vpandya_: Hello, for vulkan wsi_image how does WSI layer know bytes per pixel?
04:17 airlied: vpandya_: it gets a format?
04:17 vpandya_: sorry I am totally beginner
04:21 vpandya_: @airlied not sure which field stores format https://www.irccloud.com/pastebin/fFgEMCDn/
04:23 airlied: vpandya_: it's part of the vkimage
04:23 vpandya_: oh okay
04:23 airlied: why do you need it?
04:24 vpandya_: actually I am trying to implement SW rasterizer taking reference from https://github.com/baldurk/visor
04:24 vpandya_: for now I am able to show black/white screen but not sure why it is not showing colors
04:25 vpandya_: may be it has something to do with image format
04:27 airlied: vpandya_: okay, we already have a working swrast, so it should be possible to copy it from
04:28 vpandya_: I know, but with my 0 experience with mesa code base I struggled to read swrast
04:28 vpandya_: but thanks for reminding I will take a look again
04:29 airlied: writing a swrast is a lot harder than reading one :-P
04:29 vpandya_: yes I agree, mesa devs are very good developers :)
05:23 airlied: anholt: next bet is the vulkan loader is too old
06:13 airlied: anholt, zmike : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9185
06:13 airlied: now zink has some working CI
07:32 dj-death: mareko: feeling like merging https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7896/ ?
07:32 dj-death: mareko: I got tagged on it, I have no idea why :)
13:03 emersion: thanks bnieuwenhuizen
13:04 emersion: what is the process to apply for mesa commit rights?
13:06 bnieuwenhuizen: emersion: have something like 25 commits, poke a maintainer of the project, get someone to vouch for you if the maintainer asks for it
13:08 bnieuwenhuizen: https://docs.mesa3d.org/repository.html#developer-git-access
13:12 emersion: ah, thanks, i missed that page
13:15 alyssa: pendingchaos: "NSA MIMG" r u spying on us with ur gfx driver???????
13:15 alyssa: ;P
13:18 bnieuwenhuizen: NSA = non sequential access I think
13:19 bnieuwenhuizen: Basically instead of texture instruction inputs being in like 14 consecutive registers they are now spread around
13:19 pendingchaos: non sequential address
13:20 zmike: airlied: nice!
13:21 alyssa: bnieuwenhuizen: so u r spying on my gnu/linux machine
13:21 alyssa: ;P
13:21 alyssa: Joking aside, that does sound nice, 14 consecutive register RA isn't the most 'fun' thing
13:23 alyssa: I guess the upshot is that we can gaurantee those long inputs are bblock local so we can assign them in a linear-time prepass.
13:24 alyssa: dschuermann: ^^ In general I'm interesting in seeing how partial-SSA form (i.e. SSA unless a phi would be required <===> output from nir's out of SSA) lends to hybrid RA
13:25 alyssa: [Linear scan the SSA stuff, graph colour the non-SSA, or something like that. And we can bound the register pressure by (register pressure of SSA parts) + (total number of graph nodes) which can help.]
13:38 dschuermann: alyssa: I don't think precoloring large variables really gives an advantage over regular live-range splits
13:39 dschuermann: I thought about it as well, but if you don't have accurate intervals or graph-color everything, you end up having to evict a ton of variables from the precolored registers
14:01 alyssa: Hm.
14:08 zmike: can I get a quick rb on a piglit patch https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/479
15:53 zmike: robclark: were you doing the gallium foreach_bit rewrites or do you want me to?
15:53 robclark: zmike: I've got it.. will push something in about 30sec
15:53 zmike: cool
15:54 zmike: thanks!
15:55 robclark: zmike: https://gitlab.freedesktop.org/robclark/mesa/-/commits/zmike/mesa-foreach_bit
15:56 robclark: I figured I should do it since freedreno counted as half of the remaining private foreach_bit()s :-P
15:56 zmike: much appreciated :)
15:57 robclark: np
15:57 robclark: thx for the cleanup
15:57 zmike: 👍
15:57 kisak: Friendly note that I'm going to be pushing an irregular mesa PPA build while we wait for mesa 20.3.5. Here is what's getting fast tracked https://dpaste.com/9UXQ369H7 . It's a mix of mostly game and show stopper fixes. All are already lined up for the next 20.3 release except 58e43594f which I've previously mentioned to anholt. Let me know in the next hour or so if anybody wants anything else fast
15:57 alyssa: The problem with the cleanups is it creates rebase hell for anyone bringing up a new driver that's not ready to be upstreamed ...
15:57 kisak: tracked or if I should hold for some MR.
15:59 robclark: alyssa: deduplicating all the foreach_bit() macros shouldn't be rebase painful
16:00 zmike: you can just add an #undef foreach_bit
16:05 pendingchaos: kisak: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8835 might be interesting
16:05 pendingchaos: besides the reports mentioned in the MR, I think it also fixes issues with eFootball PES 2020/2021
16:05 pendingchaos: I thought there wasn't going to be a 20.3.5? it's not present on https://docs.mesa3d.org/release-calendar.html
16:07 kisak: the release calender is outdated, the usual pattern is one point release past the release of the next series
16:10 pendingchaos: there's also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8807 + https://gitlab.freedesktop.org/mesa/mesa/-/commit/f0074a6f0532196f5d9d2be00a9d884100401816?merge_request_iid=8446
16:10 pendingchaos: which fixes a few issues with Overwatch
16:43 kisak: thanks pendingchaos, I've queued all three and it passed the local build test.
16:53 alyssa: robclark: not this in particular, the more invasive ones
16:55 Venemo: alyssa: we were already spying on you, but we are now also spying on behalf on a 3-letter organization :P
16:56 imirkin: alyssa: didn't you just push e.g. a rename of the d3d11-imported tessellator code for no reason?
16:57 imirkin: not likely that anyone is working with that code or it's getting many changes, but we make big changes all the time...
16:57 jenatali: Can confirm cleanups make rebasing non-upstream drivers more difficult :)
16:57 jenatali: Doesn't make them not worth doing though
16:57 imirkin: moral of the story: upstream early, upstream often.
16:58 jenatali: Indeed
16:58 jekstrand: Yeah, I don't think we should block clean-ups on out-of-tree drivers. There is always out-of-tree code. The solution is to get that code in-tree.
16:59 jekstrand: I mean, if someone posts a "here's a new driver MR" and someone responds with "let me rework the universe", that's a bit cruel.
16:59 jekstrand: But there is always out-of-tree code
16:59 imirkin: jekstrand: race conditions suck :)
16:59 jekstrand: Yup
16:59 imirkin: both in the computer as well as the real world
17:00 jekstrand: I generally try to make my refactors such that they don't compile if you didn't do the refactor.
17:00 jekstrand: Replacing a boolean parameter with a bitfield in the same spot where the old thing isn't the first bit, for instance, is pretty mean.
17:00 imirkin: yes. esp if the old thing is a "boolean"
17:00 imirkin: which used to be typedef char.
17:01 imirkin: ;)
17:01 jekstrand: lol :)
17:05 alyssa: jekstrand: Better question, then, is how early is too early for a new driver to come upstream?
17:05 Venemo: depends on how early you want to see phoronix articles about it
17:06 alyssa: touche
17:10 imirkin: yeah, phoronix is the unfortunate downside of the "upstream early and oftne" policy
17:10 imirkin: so you basically have to suck it up and ignore it completely
17:10 imirkin: and then it's fine
17:10 Venemo: it's not a downside, if you appreciate the advertisement
17:10 imirkin: that's true. in my experience, most people don't
17:10 jenatali: Yeah, news (not necessarily Phoronix...) is the reason our driver was downstream for so long - and by the time we were open to upstreaming the refactorings had already made it tough
17:11 imirkin: jenatali: your company carries a slightly larger profile than a few people hacking in their basements...
17:11 Venemo: then I guess it's "rebase early, rebase often"
17:11 jenatali: Venemo: Yeah that probably would've been the right call, though with multiple people working on a codebase, rebases are tricky
17:12 Venemo: yeah, sure
17:12 Venemo: rebases can be tricky even if it's just me working on something
17:12 alyssa: with phoronix factor out though,
17:12 alyssa: I assume a driver that can't even run its first triangle is way too early
17:13 keithp: maaybe
17:13 alyssa: but maybe glxgears/vkcube resp is the threshold ;p
17:13 jenatali: Probably too early for CI at least, but I could see an argument for upstreaming anyway
17:13 alyssa: right, yeah
17:14 imirkin: alyssa: i dunno, i don't see a reason that half-working half-baked code can't be upstream. just needs to be marked appropriately.
17:14 Venemo: on a more serious note, I'd say that it's more or less okay if the architecture doesn't change that much anymore. ie. when you don't feel like refactoring half the code base every day
17:14 imirkin: and with a notice that if the author disappears, the whole thing gets dropped
17:14 imirkin: which is the danger in such cases
17:14 Venemo: good point, imirkin
17:14 jenatali: Yeah, agreed
17:14 alyssa: In our case [corporate author] that part doesn't apply
17:15 imirkin: sure it does
17:15 alyssa: Even if th author disappears _somebody_ will be around to get blamed :p
17:15 imirkin: and if they're not interested in continuing development, the thing gets dropped.
17:18 Venemo: we've seen companies that disappeared
17:18 jenatali: Speaking of refactorings... I'm curious about opinions around Erik's comment on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9165#note_812900 for naming. Think it's worth a large rename?
17:18 alyssa: + // XXX this is wrong but i'm done for the week, toodles
17:18 alyssa: ^ this is not the comment i wanted to arrive to monday morning
17:19 imirkin: yeah, you should fix it with s/week/year/
17:19 Venemo: :D
17:20 imirkin: i tend to be the exception, but names really don't bother me at all. something can be named wrong, and i just don't care.
17:20 imirkin: it's all just "a, b, c, d" in my head anyways
17:21 Venemo: as long as there is a way to understand what the names mean, it's okay
17:21 alyssa: ("which is eta and which is zeta again?")
17:21 imirkin: alyssa: nobody writes those upper-case letters in script. an uppercase zeta is written as a latin Z according to my greek friends.
17:23 Venemo: however if a name is misleading, then that's worse than "a, b, c, d"
17:25 imirkin: yeah
17:25 imirkin: that's the exception i suppose
17:25 imirkin: if it's actively wrong, then it's bad. but if it's just confusing, then wtvr
17:25 Venemo: with "a, b, c, d" at least you know you have to read through it and think hard to understand, but with a misleading name you think you understand but don't
17:26 imirkin: if it's confusing, then it's probably a weird thing anyways you'll have to look at the definition of
17:39 alyssa: *FADD.f32.clamp_m1_1 r0:t0, r0.neg.abs, u0.w0.abs.neg
17:39 alyssa: I like modifiers :p
17:43 imirkin: modifiers are nice. until you find out that you can IADD a, -b, you can IADD -a, b, but you can't IADD -a, -b
17:44 alyssa: yeah, we have some pretty awful edge cases like that
17:48 imirkin: the encoding works, but it becomes a+b+1. probably not what you wanted :)
17:49 imirkin: i think those encodings are there to help with some opencl things
17:57 jenatali: Does anyone know if Mesa cares about Windows support for pre-Vista?
17:58 alyssa: Doubt it
17:59 jenatali: I assumed as much, just wondering if anyone would scream if it broke
18:00 imirkin: jenatali: check with the vmware folks
18:00 imirkin: they're the ones who care about windows
18:01 imirkin: i don't know if they have to keep supporting pre-vista windows ... i'd feel very sad if they did, but i feel sad frequently, so ...
18:01 jenatali: They're not here, right?
18:01 imirkin: not the three who i'm familiar with
18:01 imirkin: (nicknames sroland, jrfon<tab>, and brianp)
18:08 dcbaker: Iirc, last i talked to them XP still mattered to them. But that was a couple years ago
18:09 jenatali: Alright, I'll reach out
19:10 anholt: oh, wow. original counterstrike is all begin/end? today I learned.
19:10 anholt: (well, ui looks like it's vertex arrays. no vbos, though)
19:11 imirkin: quake 3 too, i think
19:13 anholt: I thought q3 was all about the EXT_compiled_vertex_array
19:14 alyssa: jekstrand: Bifrost's bitwise ops are 3-src with a shift (a | (b << c)), (a & (b << c)) and rshift variants
19:15 imirkin: anholt: hmmm maybe. i could be thinking of a diff one then.
19:15 alyssa: Do you know if any other hardware does that? If so it might make sense to pipe into NIR, if not it's easy for me to handle in the backend.
19:16 imirkin: alyssa: that's nice for packing e.g. 2x16 -> 32 and such
19:17 pendingchaos: GCN/RDNA has a | (b < <c)
19:17 alyssa: pendingchaos: figures, starting to think Bifrost is just smol gcn :p
19:19 alyssa: imirkin: Indeed it is :)
19:34 anholt: oh, great. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/7494159 so I can't merge my assert to mesa core because which of the gl-2.0-edgeflag cases crash depends on which one runs first and gets its shader in the disk cache.
19:37 alyssa: blink
19:38 bnieuwenhuizen: wit, why does the shader get into the disk cache if the compilation fails?
19:38 anholt: compilation doesn't fail
19:38 bnieuwenhuizen: if it isn't the compilation why are they not both crashing
19:38 anholt: it's "you take a different path if you load from cache, and that path gains the assert it should have had all along"
19:38 bnieuwenhuizen: ah
19:39 bnieuwenhuizen: oh is this the nir cache?
19:39 anholt: st/mesa nir caching
19:39 anholt: and uniform linking
19:39 anholt: and uniform optimization
19:39 bnieuwenhuizen: right, that makes sense
19:39 anholt: it's definitely not easy to trace through.
19:46 zmike: Narrator: It was hell, but after so much time spent there, he called it home.
19:47 alyssa: Relatable noises.
19:52 jenatali: Hooray, I don't have to care about XP
19:56 alyssa: XP
19:56 alyssa: is an emoticon
19:57 imirkin: jenatali: what about windows 2000? :)
19:57 jenatali: imirkin: I sincerely hope nobody is using 2000 these days...
19:57 imirkin: ;)
19:58 imirkin: i think i actually used 2000 for some short time ... dual-booted back in those days
20:02 alyssa: Is alpha-to-coverage defined for formats without alpha? (e.g. R8_UNORM)
20:02 MrBIOS: imirkin I still run Windows 2000 on my SGI Visual Workstation 320 :P
20:02 MrBIOS: but that's because the only other option is NT4 ;)
20:05 anholt: alyssa: I believe yes, you have to use the alpha emitted from the shader before mapping to an RT format
20:05 alyssa: anholt: er, if the shader doesn't emit any alpha
20:05 alyssa: layout (location = 0) out float col0;
20:05 anholt: I believe in that case the alpha would be undefined.
20:06 alyssa: alright, thanks :)
20:06 alyssa: spec is surprisingly unclear here
20:21 imirkin: alyssa: iirc alpha-to-cov isn't allowed with blending
20:21 imirkin: but ...
20:21 imirkin: if you do like out vec4 col0
20:21 imirkin: even though you have a R8_UNORM surface bound
20:21 imirkin: in that case, alpha-to-cov is defined
20:22 mareko: alpha-to-cov doesn't depend on the color buffer, it's reall alpha to sample mask
20:22 mareko: really*
20:22 imirkin: mareko: right, but you need some way to supply the alpha value
20:23 imirkin: so if the output is a float, then fail
20:23 imirkin: (unless it's an alpha texture output. those are extra fun. i forget how they're handled.)
20:23 imirkin: (i think we just don't allow those for rendering... problem solved)
20:24 alyssa: 'fun'
20:33 imirkin: MrBIOS: that's the NT variant which has an x86 emulator in it?
20:34 imirkin: i know there was one for alpha
20:37 mattst88: imirkin: the SGI VW320 is a weird x86 (PIII) system, not MIPS
20:37 imirkin: oh
20:37 imirkin: coming from MrBIOS i assumed not-x86
20:37 mattst88: heh, yeah :)
20:38 imirkin: (and too lazy to look it up myself)
20:53 MrBIOS: imirkin the SGI Visual Workstation 320 is basically the love child of an O2 and a Pentium 3
20:53 MrBIOS: ARCS-based, but dual-proc x86
20:54 MrBIOS: it uses the same UMA CRM graphics subsystem as the O2 did, aka "CRIME"
20:55 imirkin: hehe
20:55 imirkin: p3 was when intel decided to do the slots right?
20:56 MrBIOS: yes. Slot 1 :)
20:56 imirkin: good times.
20:57 MrBIOS: though near the end of the P3 line, they switched to socket 370.
20:57 imirkin: right
20:57 imirkin: that was the last compatible socket with amd iirc?
20:58 MrBIOS: I'm not sure AMD ever made any Socket 370 CPUs.
20:58 MrBIOS: VIA made the C3, which was available as a Socket 370.
20:58 imirkin: wikipedia agrees
20:59 imirkin: socket 7, that was the last one.
21:00 imirkin: lol, apparently even alpha jumped on the slot bandwagon. didn't know that. what a terrible idea.
21:01 MrBIOS: imirkin there were technical reasons why it made sense at the time, both thermally and because the ability to put L2 cache "really close" to the die was limited by process tech
21:02 imirkin: at least that was the official reason
21:02 imirkin: but i feel like there's a 95% chance AMD did it because intel was doing it
21:03 MrBIOS: thats entirely possible, although its worth pointing out that AMD was up against the same technological limits at the time. Slot One was released in 1996.
21:03 imirkin: of course, but they were _way_ behind in terms of perf at that time
21:03 MrBIOS: things had changed a lot by 1999, when Intel went back to Socket 370.
21:54 jekstrand: jenatali: Does clang automatically add CL_VERSION_1_0 etc.? What about __LITTLE_ENDIAN__?
21:56 jenatali: jekstrand: No to the version macro. I think it does do __LITTLE_ENDIAN__
21:56 jenatali: jekstrand: https://github.com/microsoft/OpenCLOn12/blob/master/src/program.cpp#L892
21:56 jekstrand: jenatali: Ok. Might be useful to have some magic in any shared CLC code for macros, I think.
21:57 jenatali: jekstrand: Yeah, note that the OPENCL_VERSION macro is about the API version, not the kernel language version, so IMO that should come from Clover/CLOn12
21:57 jekstrand: jenatali: Yeah
21:58 jekstrand: jenatali: I'm thinking we want to take an OpenCL API version in the compile args struct and scan the text args provided for -cl-std and sort out the actual CL C standard and the version #defines from that.
21:59 jenatali: jekstrand: What do we need to do with -cl-std?
21:59 jekstrand: __OPENCL_C_VERSION__
21:59 jekstrand: Or does clang do that for us?
21:59 jenatali: Clang does that
21:59 jekstrand: Oh, ok.
22:00 jekstrand: So we just need to take an API version and throw in whatever -D flags are needed for that.
22:00 jenatali: Yeah, which is just the one
22:01 jekstrand: Where does CL_VERSION_1_0 come from, then?
22:02 jenatali: jekstrand: If you look at unifying our invocation with Clover's, IIRC all the stuff that Clover does for setLangDefaults can be removed if you just pass the "-cl-std=" bit into Clang's command line parsing
22:02 jenatali: Uh... let me look
22:02 jekstrand: jenatali: I'm not trying to kill that windmill today.
22:05 jenatali: jekstrand: https://github.com/llvm/llvm-project/blob/e123cd674c0209c80bc6225bb9e3a2d1d2ee418b/clang/lib/Frontend/InitPreprocessor.cpp#L429
22:08 jenatali: jekstrand: Also https://github.com/llvm/llvm-project/blob/e123cd674c0209c80bc6225bb9e3a2d1d2ee418b/clang/lib/Frontend/InitPreprocessor.cpp#L1122 which fills out extension-support macros, and image support is assumed for SPIR
22:39 Venemo: jekstrand: do we have a NIR pass that lowers system values to I/O variables?
22:40 Venemo: I looked at nir_lower_system_values but that only lowers some system values to other system values
23:03 jekstrand: Venemo: What do you mean?
23:03 jekstrand: jenatali: 👍
23:04 Venemo: jekstrand: instead of load_tess_level_outer, I want to see a load_input
23:05 jekstrand: Venemo: No, there's no NIR pass for that.
23:06 jekstrand: Venemo: We've got a few SPIR-V options to let us choose system value vs. input for a few things
23:06 jekstrand: view index and frag coord, to be specific.
23:07 Venemo: I think there is an option for tess levels too
23:07 Venemo: at least I'm pretty sure that RADV never gets any load_tess_level_* ever
23:07 Venemo: however, RadeonSI seems to implement those, and I'm wondering how best to get rid of them there
23:08 jekstrand: Rewriting system values to inputs should be easy
23:09 Venemo: to be honest, I'm not even fully sure that they ever occour there, or it's just a remnant from the past
23:11 Venemo: I think glsl_to_nir and spirv_to_nir both have some options to lower some things either as sysvals or variables
23:11 jekstrand: Yeah
23:11 jekstrand: There might be something to be said for having a nir_lower_system_values_to_inputs pass and deleting the GLSL/SPIR-V options.
23:12 Venemo: that's probably a hard-to-swallow pill that I don't wanna take right now
23:12 jekstrand: That's fair
23:13 jekstrand: But if you wanted tess levels as inputs, I guess I'd rather see the start of that pass than more SPIR-V options.
23:13 jekstrand: Then we could fix the other two later as-needed.
23:14 Venemo: if I'm lucky, then it's already an option
23:14 jekstrand: There isn't for SPIR-V. I'm looking at it now.
23:18 Venemo: jekstrand: okay, as far as I see spirv_to_nir always emits tess levels as inputs
23:18 Venemo: that is good
23:19 Venemo: not sure about glsl
23:20 jekstrand: Uh...
23:20 jekstrand: That's because they're only ever inputs in GLSL, I think.
23:20 jekstrand: I'm not sure
23:21 Venemo: then what is it that produces load_tess_level_* ?
23:21 jekstrand: Looking at shader_enums.h, the varyings are only supposed to be for TCS outputs and the system values for TES inputs.
23:22 Venemo: aha
23:22 Venemo: there is
23:22 Venemo: if (this->state->ctx->Const.GLSLTessLevelsAsInputs) {
23:22 jekstrand: Oh
23:22 Venemo: builtin_variable_generator::generate_tes_special_vars()
23:23 jekstrand: Looks like we set that in i965 so probably in iris too
23:23 Venemo: also PIPE_CAP_GLSL_TESS_LEVELS_AS_INPUTS
23:23 jekstrand: yup
23:23 Venemo: so I guess this is what I need, then
23:24 jekstrand: probably
23:25 Venemo: thanks
23:28 Venemo: for us, tess levels in TES are just another input loaded from VRAM, which doesn't need special handling
23:32 jekstrand: ah
23:33 jekstrand: dcbaker: Is there any way to make meson invoke a command to get a list of files?
23:34 dcbaker: When? At configure time or build time?
23:35 jekstrand: Probably configure
23:35 jekstrand: Hrm... Maybe I can do this differently
23:35 dcbaker: You could pass the output of a run_command to files()
23:36 jekstrand: Each GRL file has a bunch of CL files
23:36 jekstrand: Well, usually one or two CL files and a bunch of entrypoint names
23:36 jekstrand: And I'd like ninja to parallelize for me
23:37 dcbaker: So you want to list the cl files at configure time, then generate a job each?
23:37 jekstrand: Yeah
23:38 Sachiel: yeah, that's going to be fun
23:38 dcbaker: Yeah run_command() is what you want then, that runs at configure time, then you can create a custom target or generator invocation from that
23:38 jekstrand: Ok
23:39 dcbaker: I can help with that tomorrow if you want
23:39 jekstrand: What I want run_command to do is dump out a set of filename, entrypoint tuplies
23:39 dcbaker: It's going to dump a string and you'll have to parse that
23:40 dcbaker: I keep meaning to add a json module to Meson, maybe I should get on with that
23:41 jekstrand: That's ok
23:42 jekstrand: I think I can take it from here. Just need to pull in Sachiel's parser and get it to extract my CL/name tuples
23:42 Sachiel: oh, yeah, I wish I had done something else there
23:42 Sachiel:feeling more useless every day
23:42 jekstrand: Sachiel: No worries
23:42 jekstrand: I'm just following my nose and hacking as I go right now
23:42 jekstrand:has no idea what he's doing
23:43 HdkR:has no idea ever about what he's doing
23:44 airlied: uggh CL IMAGE1D_BUFFER, why oh why would you bother
23:44 jekstrand: airlied: We must have all the things GL has?
23:46 HdkR: Isn't this the whole thing of 1D tiling being "better" than 1D linear for someone?
23:46 airlied: jekstrand: GL doesn't have this though, it's like a cross between BUFFER and 1D
23:46 jekstrand: airlied: Uh... what?
23:46 airlied: yeah it's like a typed buffer
23:46 jekstrand: so, like a storage texel buffer?
23:46 jenatali: airlied: It maps pretty close to D3D at least
23:47 jekstrand: 'cause that's totally a thing in GL
23:47 jekstrand: and Vulkan
23:47 airlied: llvmpipe explodes becaues gallium buffers are byte sized only
23:47 airlied: but I think I can map it to 1D texture all the time and it'll be happier
23:48 airlied: I suppose it's the noly one you can read_write
23:48 airlied: which make it a typed ssbo
23:48 jenatali: Yeah, it's like a typed ssbo
23:48 jekstrand: So, like a storage texel buffer
23:48 jekstrand: :P
23:49 jekstrand: Sachiel: python yacc is weird....
23:49 airlied: except when it's read only :-P
23:49 jekstrand: airlied: Oh, so a texel buffer then?
23:50 imirkin: the real question is whether you can do filtering
23:50 Sachiel: weird in what way?
23:50 imirkin: and/or whether you can have mipmaps
23:50 jenatali: imirkin: No, no filtering, no mips
23:50 jekstrand: Sachiel: Lots of global variables and functions that I'm sure do something but are never referenced anywhere.
23:50 jekstrand: Sachiel: I assume it's doing some magic in yacc
23:50 Sachiel: oh, yeah. I think it tries to be as close to yacc as it can. That parser is the laziest thing too, you can put those in different modules and be less dirty about globals
23:51 Sachiel: I think the yacc part can even be a class
23:52 zmike:pushes up glasses
23:52 zmike: jekstrand: ackchuahlly that'd be a uniform texel buffer
23:52 jekstrand: zmike: :P