00:16 SolarAquarion: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3465
00:17 SolarAquarion: this issue breaks the build on mesa git using llvm git
04:13 jekstrand: karolherbst: I suspect adding a is_cl flag to nir_alu_instr is a really bad idea.
04:14 jekstrand: karolherbst: I'm mostly worried about what it will do to nir_opt_algebraic. We need a way to reason about it that's intuative and we don't have one.
04:14 jekstrand: I also don't really see what's wrong with just saying "the rules for KERNEL are more precise"
04:14 jekstrand: And maybe setting .exact on everything
04:17 jekstrand: karolherbst: Serialization isn't the biggrst problem: nir_algebraic being able to reason about it is.
07:59 pq: melissawen, btw. I think IGT using a black FB on the primary plane is insufficient. A test cannot see if the primary plane is used in a blending test at all, of if a driver just blits the cursor image as-is on top without blending.
08:00 pq: *or of
08:04 melissawen: pq, I agree with you... I also think that colored primary and cursor (no black and white) would be more efficient. I had thought about changing that in the tests; but I ended up doing less...
08:06 pq: melissawen, as long as you are aware :-)
08:07 pq: melissawen, I suppose there could be concers about rounding pixel values that might not work the same on different hardware.
08:08 pq: melissawen, or hardware that doesn't actually support ARGB8888 cursor so has to convert to, say, ARGB4444. I can't name any hardware like that though.
08:09 pq: I'd also assume that silent pixel format conversion would only be an issue with the legacy KMS cursor UAPI
08:10 pq: which might be assumed wrong
08:14 emersion: user-space kind of assumes ARGB8888 will always work...
08:15 pq: for legacy yes, but for atomic as well?
08:16 emersion: well, our atomic compositor sure assumes ARGB8888 works :P
08:16 emersion: and yeah, the reason why igt doesn't have blending tests is rounding errors
08:16 pq: weston doesn't assume, it does TEST_ONLY commits
08:16 emersion: writeback could be used to test properly this
08:16 emersion: does weston have a list of formats?
08:16 emersion: or does it just use EGL to pick one?
08:17 pq: it gets format lists from IN_FORMATS, but if that's not there, then there are lists, I think, but it still tests atomic commits if on atomic path
08:17 pq: also the KMS plane API has format lists
08:18 emersion: cool
08:18 pq: so I think weston actually uses three tiers: IN_FORMATS, fallback to plane formats, fallback to guessing
08:18 emersion: fallback to guessing?
08:18 pq: the hardcoded lists are "guessing"
08:18 emersion: eh, so some drivers don't populate plane formats?
08:19 pq: maybe that's without universal planes?
08:19 emersion: ah
08:19 emersion: hm, could be, good to note
08:20 pq: IIRC, without universal planes, the only planes you get information on are overlays, not primary nor cursor
08:21 emersion: can't remember if universal planes is a core drm thing, or if each driver has to implement it
08:21 emersion: i think it's core?
08:22 emersion: ah, we flat out error out when universal planes aren't supported
08:22 pq: well, weston intends to work on pretty old kernels too
08:22 emersion: we used to support the case where there's no universal planes, but we removed that
08:23 emersion: yeah, wlroots has a different policy
08:23 pq: personally I'd be fine dropping the support for no universal planes, but as long as legacy modset must remains, I suppose it's not much code.
08:24 emersion: it made the code pretty alien for us
08:24 emersion: faking a cursor plane when we didn't have one
08:29 pq: oh right, the fake planes
08:29 pq: good point
08:30 daniels: yeah, I'd be happy to make universal planes mandatory and get rid of all the fake-plane code
08:30 pq: I was just about to file a Weston issue for this...
09:28 MrCooper: daniels, pq: unless I'm missing something, requiring universal planes means the radeon driver (and amdgpu without DC) is out
09:29 pq: MrCooper, it is? But universal planes is just an UAPI thing, why would it not set that up?
09:30 pq: emersion, ^
09:30 emersion: yeah, wlroots works fine with radeon
09:32 MrCooper: then I was missing something :)
09:39 cwabbott: karolherbst: yeah, I wanted to completely rewrite nir_serialize based by augmenting the basic serialize/deserialize api's to do bit-packing, so that you could serialize, say, a 5 bit field, which would let you dynamically size the bitfields
09:39 cwabbott: as-is it's very fragile but mareko didn't want to rewrite it
09:57 karolherbst: jekstrand: because it's not about "this is a kernel"
09:57 karolherbst: and how to you deal with lowerings? Because you lower fdiv to... fdiv
09:58 karolherbst: mhh.. I guess you could lower to the final result directly
09:58 karolherbst: but I am also wondering about cases where we need to support denorms at some point and there you really just wrap the operation
09:58 karolherbst: but you also have native_sqrt vs sqrt
09:59 karolherbst: the idea behind .cl was that we can mark instructions as "the result of this needs to satisfy certain API needs" and this can be lowered to the normal variant
09:59 karolherbst: and most algebraic opts still apply
10:00 karolherbst: or we skip opt algebraic for .cl and do it after we lowered all of them to the normal variants (writing a pass which just removes the flag + adding some special lowerings here and there)
10:01 karolherbst: so I only see three options really: 1. mark CL high precision alu ops 2. add cl opcodes to nir where relevant 3. deal with the lowering inside vtn
10:08 karolherbst: also.. what do you do when we do suppot those compiler options making everything faster, but we still need to not run into NaN or small/big number issues?
10:09 karolherbst: This all feels like that we really need something special which doesn't just say "stay consistent with optimization", but also tells us on how precise the actual result has to be
10:09 karolherbst: and that could be a .cl flag or ... whatever
11:23 karolherbst: EdB_: mind fixing local memory alignment for LLVM? I already fixed it for spirv, it just needs some special handing inside llvm I think: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/584664d35d973bc84c29890c6040e03e793adef8
11:24 karolherbst: fixes test_basiv kernel_memory_alignment_local
11:26 karolherbst: curro: any opinions on https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/b2510d48b49dd81fd1822f37f2840432b439a10d ?
11:29 karolherbst: jenatali, jekstrand: I'd like to get https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6433 merged soonish. I threw out patches which need more work as the other ones in there I think we should land sooner rather than later
11:58 bnieuwenhuizen: cwabbott: do you have a good multiview benchmark?
12:03 cwabbott: bnieuwenhuizen: nope, that's a TODO in the MR description
12:04 cwabbott: I need to figure out what Intel did for primitive replication
12:38 romangg: bnieuwenhuizen: Do I need to add your "Reviewed-by" to the commit message bodies in !6513? Where do I add the CC: mesa-stable, also in the commit body?
12:42 kisak: romangg: morning, yes and yes ( notes are in https://docs.mesa3d.org/submittingpatches.html#patch-formatting )
12:43 bnieuwenhuizen: romangg: yes and yes
12:47 emersion: romangg: thanks for working on this! i'll give it a try
12:51 romangg: emersion: Thanks, I tested it with vkcube where it works after sig stop and cont. But would be good if you could test it also with sekiro I think it was.
12:51 emersion: yup
12:56 daniels: MrCooper: universal planes doesn't imply atomic; only that the primary and cursor planes can be enumerated. without atomic, that's only advertisement, and not a requirement to be able to use them outside the legacy ioctls
13:10 cwabbott: bnieuwenhuizen: looks like there's a simple crucible benchmark that was originally for intel
13:11 cwabbott: err, originally added to test intel's prim rep
13:11 cwabbott:tries that on qcom
14:33 romangg: emersion: Thanks for compiling with asan. Weren't structs in C auto-nulled? Anyway I will add a zero-initializer.
14:33 emersion: it depends
14:34 emersion: in my projects i *always* calloc() structs
14:34 romangg: ah, right that was the distinction. malloc or calloc.
14:34 emersion: which allows to not have to care about it
14:34 emersion: but most people malloc() and require to pay attention to init
14:36 romangg: Great that sekiro works though.
14:42 emersion: yup :)
14:52 jekstrand: karolherbst: Most of that MR is RB me.
14:52 jekstrand: karolherbst: I don't feel like I can really review the nouveau changes.
14:52 jekstrand: karolherbst: Maybe pmoreau can?
14:52 jekstrand: karolherbst: I'm also very confused about the clover change. I might be able to review if you can help me understand it better.
15:11 karolherbst: jekstrand: it's not about alignment of the pointer but about data alignment inside CL local memory
15:11 karolherbst: so.. most of the code for arguments just align the arguments itself (be it pointers, scalars, structs, whatever)
15:12 karolherbst: but for local memory we also have to keep the actual data aligned as well
15:12 jekstrand: karolherbst: Right. So one alignment is to align the pointer parameter that we implicitly add
15:12 jekstrand: And the other is to align the data it points to?
15:12 karolherbst: so if the first local memory buffer was a char and the seoncd is a long, we need padding
15:12 karolherbst: there is no other alignment
15:13 jekstrand: For these local memory pointer things, do we create the buffer for them internally?
15:13 jekstrand: Or is it a buffer provided by the client?
15:13 karolherbst: I already discussed it with curro. I am still convinced that adding a second alignment field would be prefered, but curro said I should just set the one we have differently for local mem
15:13 karolherbst: jekstrand: well.. there is no buffer, just we have to split the available resources between whatever we got
15:14 karolherbst: *get
15:14 karolherbst: for __local* args the application tells the runtime how big the space is
15:14 karolherbst: but you can also allocate in kernel
15:15 karolherbst: CL names are really stupid btw
15:15 jekstrand: So for __local*, the semantics of clSetKernelArg is a memcpy into an internal buffer?
15:15 karolherbst: there is no buffer
15:15 karolherbst: CL local == shared mem
15:15 jenatali: jekstrand: For __local, you don't specify data, just a size
15:15 karolherbst: and you just allocate size
15:15 karolherbst: *space
15:15 jekstrand: Oh....
15:16 jekstrand: so clSetKernelArg just says "give be a blob X-sized for this pointer?
15:16 jekstrand: with, presumably, a NULL parameter
15:16 karolherbst: I think it's in byte
15:16 jekstrand: I meant bytes
15:16 jenatali: jekstrand: Yes, the data pointer has to be NULL, the size pointer indicates how big the incoming __local pointer will be inside the kernel
15:16 karolherbst: yeah
15:16 jenatali: Er, size parameter
15:17 jekstrand: karolherbst: Ok, that makes sense.
15:18 jekstrand: karolherbst: Ok, given that, I think the first hunk looks correct.
15:18 jekstrand: karolherbst: I don't know whether marg.target_align should mean the alignment of ptr or *ptr
15:19 karolherbst: yeah... I had this discussion with curro recently
15:19 karolherbst: and I think it's fine to be more local in the meaning
15:19 karolherbst: specifying the alignment of buffers doesn't make sense anyway
15:20 karolherbst: so it's really only useful for local memory and constants
15:20 karolherbst: mhh
15:20 karolherbst: constats as in args passed in by value
15:22 karolherbst: I am actually wondering why it matters for the spec how internal buffers are aligned, but I guess "cross device" is probably the reason why
15:23 karolherbst: jekstrand: you know why I don't merge the passes? Because C++ is stupid and when I (nir_var_mem_shared| nir_var_function_temp) I also have to cast it back to the enum :/
15:23 karolherbst: oh well..
15:24 karolherbst: and then somebody complains that C casts are evil and I should use static_cast
15:24 karolherbst: :D
15:26 jekstrand: karolherbst: heh. Yeah.....
15:27 karolherbst: and if I do the cast, it's annoying to break lines as somebody will complain about 80 chars...
15:28 karolherbst: ohhh... I have an evil trick
15:32 dviola: can anyone please review/ack this: https://lkml.org/lkml/2020/8/18/159
15:33 karolherbst: jekstrand: mind if we have a nir_cpp.h file to collect some functions which makes our life easier?
15:38 jekstrand: karolherbst: What kind of functions?
15:39 agd5f: is there a common drm property for color encoding? e.g., rgb vs ycbcr?
15:39 agd5f: or does every driver spin their own?
15:40 karolherbst: jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6433/diffs?commit_id=c5483a864f943639e04687b550a083dc4a81ad09
15:42 vsyrjala: agd5f: for outputting ycbcr vs rgb?
15:44 agd5f: yeah.
15:44 karolherbst: wondering if it makes sense to be able to specify those operatores on other enums via some preprocessor stuff as well.. mhh
15:44 agd5f: vsyrjala, ^
15:44 karolherbst: oh well
15:45 jekstrand: karolherbst: We could even put that inside nir.h inside a #if __cplusplus
15:45 karolherbst: yeah.. probably
15:45 jekstrand: karolherbst: Given how common |ing nir_var_mode is, it seems reasonable.
15:45 karolherbst: but I'd do it the proper way then, like having a CPP_ENUM_OPERATORS(enum nir_var_mode) thing which just declares a bunch of stuff
15:45 vsyrjala: agd5f: no standard as of yet i think. people have proposed one, but dunno if anyone really got past the "what's the usecse?" question
15:45 karolherbst: I even do | inside codegen as well..
15:45 karolherbst: I will play around with that a little and see how others are using it
15:46 jekstrand: karolherbst: Do we have other enums that we want to do that for?
15:46 jenatali: karolherbst: Windows SDK headers have exactly those definitions
15:46 karolherbst: jenatali: figures :p
15:46 vsyrjala: agd5f: what we do in i915 is use rgb by default, but fall back to ycbcr 4:2:0 if the display requires it
15:46 karolherbst: I am sure boost has as well
15:46 karolherbst: jekstrand: I was more thinking about other operators liike & and ^
15:47 karolherbst: and then you already start with macros
15:47 jenatali: karolherbst: The Windows macro is DEFINE_ENUM_FLAG_OPERATORS
15:47 karolherbst: ENUM_OPERATOR_OVERLOAD(enum T, &) ...
15:47 agd5f: vsyrjala, we do something similar, but keep getting requests from users to provide a knob. Apparently windows does.
15:47 karolherbst: jenatali: ahh
15:48 agd5f: vsyrjala, I guess some monitors look crappy and work better with an override
15:51 jekstrand: karolherbst: Oh, make a #define DEFINE_CPP_ENUM_OPERATOR(type, op) That would be pretty straightforward.
15:52 vsyrjala: maybe or maybe what they really want is ycbcr passthrough. at least for i915 i have no plans to implement that
15:52 karolherbst: yeah
15:52 vsyrjala: agd5f: ^
15:52 jekstrand: karolherbst: But, yeah, I think I'm fine with defining flag operators on enums in nir.h
15:53 ajax: i like that my one-line docs-only change failed to merge because CI was taking too long.
15:55 jenatali: jekstrand, karolherbst: Just make sure it's not already defined first :)
15:55 jekstrand: jenatali: hehe
15:58 MrCooper: ajax: sounds like probably the pipeline didn't start, because Marge didn't need to rebase?
16:00 ajax: mmm. i didn't think i'd rebased first...
16:01 MrCooper: yeah she actually did rebase, probably a rules bug
16:02 karolherbst: jekstrand: another thing I found: "(enum)0" mhhh but I doubt we should do something about that one...
16:02 karolherbst: or maybe?
16:02 karolherbst: mhhh
16:03 jekstrand: karolherbst: nir_var_none
16:03 karolherbst: nir_lower_io_options
16:03 karolherbst: was it
16:03 jekstrand: karolherbst: We can define a _none enum value
16:03 karolherbst: yeah.. probably the best solution here
16:03 jekstrand: karolherbst: Or we could stop using C++ :-P
16:06 emersion: vsyrjala: couldn't the driver decide to do ycbcr passthrough if the sink supports it?
16:06 emersion: (wouldn't it be the best thing to do in all cases?)
16:06 emersion: and yeah, the windows amd driver allows to select this
16:07 emersion: it affects badnwidth, i think
16:07 emersion: (cc agd5f)
16:08 agd5f: emersion, yeah, it affects bandwidth
16:09 emersion: i don't see an existing property for this
16:09 emersion: (in other drivers i mean)
16:13 karolherbst: jekstrand, jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6520 :)
16:14 karolherbst: wondering if I need ot add |= and co as well?
16:14 jenatali: karolherbst: I would
16:15 karolherbst: ehh.. wait
16:16 MrCooper: ajax: not seeing what's going wrong in the rules :( The .container rules are hitting the when: manual case, so *all_paths seems to match (not sure how though, it doesn't contain docs/ yet); but then why didn't it match the earlier Marge case?
16:17 jekstrand: karolherbst: C++ might auto-add those for you. I'm not sure.
16:17 MrCooper: ajax: BTW, something seems special about your Mesa project (MR pipelines still run in its namespace, whereas they run in the mesa/mesa namespace for others now), but I can't see how that would affect this either
16:21 karolherbst: jekstrand: it does not
16:22 MrCooper: ajax: please cancel https://gitlab.freedesktop.org/ajax/mesa/-/pipelines/196590 , something's seriously weird (the remaining manual jobs shouldn't exist at all in pipelines for this MR)
16:25 jenatali: karolherbst: The Windows SDK gets |, |=, &, &=, ~, ^, and ^=
16:25 karolherbst: yeah
16:25 karolherbst: those I define now all as well
16:25 MrCooper: ajax: it seems to be completely mis-interpreting the rules in Mesa's .gitlab-ci.yml for whatever reason
16:33 MrCooper: ajax: anyway, better hold off on trying to merge this MR until someone figures out why it's acting so strange (while https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6499 merged as expected)
16:51 karolherbst: jenatali: ehh.. why are assignment operators so special? :D
16:51 jenatali: Hm?
16:51 jekstrand: karolherbst: ?
16:52 karolherbst: they need to take a reference
16:52 karolherbst: ohh.. idea
16:52 MrCooper: ajax: figured it out I think, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6522
16:56 jenatali: karolherbst: FYI, this is what's in the Windows SDK: https://pastebin.com/L1jCnAbg
16:58 jekstrand: jenatali: No offence, but unless you posting it here somehow implicitly MIT licenses it, I think most people would be afaid to even click that link. :-/
16:58 jenatali: jekstrand: Right... good point :)
16:58 jenatali: That license really bugs me...
16:58 jekstrand: What license?
16:59 jenatali: The custom Windows SDK license
16:59 jekstrand: Oh, right
16:59 emersion: agd5f: anyways, let me know if you need a user-space user of that new prop :P
17:01 karolherbst: now I've implemented it correctly..
17:02 jekstrand: :)
17:04 vsyrjala: emersion: passthrough is too much work for too little gain imo, at least for intel hw
17:06 emersion: ok
17:08 daniels: MrCooper: thanks for the fixups, just had to spend some time stepping through the rule definitions and variables to untangle what's going on
17:16 bbrezillon: jekstrand: still see the exact same comment in the latest version https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6472/diffs?commit_id=350d7e5e1ac6b70a1d817569a18a3ec2653e9692#736b255bfc45bba23e92c36f2653bb19628faffc_1298_1305
17:16 bbrezillon: am I doing something wrong?
17:16 bbrezillon: or maybe it's detailed somewhere else?
17:18 anholt: python question: I have two blocking iterators returning lines from two inputs, and I'd like to make a new iterator that returns the next available line from either one. what's the laziest way to do that?
17:18 jekstrand: bbrezillon: I just pushed it like 10 seconds ago. Give gitlab another 30
17:23 jekstrand: anholt: Do you care which one it grabs?
17:23 jekstrand: anholt: Or do you want a tuple of both?
17:23 anholt: jekstrand: block until one is available
17:23 anholt: take that one
17:24 jekstrand: Oh.... Yeah, I don't know how to do that. :-P
17:24 anholt: I could spawn two threads reading from each and pushing to a new fifo, but surely there's some handy thing
17:25 jekstrand: dcbaker[m]: ^^
17:27 dcbaker[m]: anholt: you probably want coroutines for that
17:29 anholt: dcbaker[m]: do the blocking things need to be async aware, though?
17:30 anholt: oh, but since they're just queue.Queue()s, maybe that's not a thing I need to care about
17:35 dcbaker[m]: Oh, I think queue has a get with timeout
17:38 agd5f: emersion, thanks
17:40 dcbaker[m]: anholt: queue.get(block=False)
17:40 anholt: don't want to spin, though
17:41 anholt: I guess I could poll every .1s or something, but ugh. I'll just make two threads, or let both threads push to the same queue instead of separate ones
17:41 anholt: (make two more threads, that is)
17:43 bbrezillon: jekstrand: I see it know
17:44 dcbaker[m]: If you don't want to spin you need either threads or coroutines
18:38 jekstrand: karolherbst: Did you ever sort out what's going on with uniform?
18:38 karolherbst: jekstrand: not yet
18:39 jekstrand: karolherbst: Any way I can help out there?
18:39 jekstrand: karolherbst: If you can throw me your branch and a failing test case, I can try to repro on iris
18:40 jekstrand: I suspect it's something stupid and simple
18:40 karolherbst: yeah.. it's probably something stupid.. will check it out in a moment
18:40 jekstrand: karolherbst: Also, if you could give my nir_var_mem_const MR a look at some point, that'd be nice.
18:41 jekstrand: karolherbst: I've added nir_intrinsic_load_global_const as well as intel and nouveau implementations of it
18:41 jekstrand: (Mostly just adding it to switch cases)
18:41 jekstrand: So I think I'm happy with that one
18:41 jekstrand: It's also got your function_temp to scratch patch cherry-picked on top because it made tests pass :)
18:42 jekstrand: But I'm happy for that one to land as part of your current clover MR
18:42 karolherbst: jekstrand: yeah.. I am just trying to get more basics things merged so master + MR is enough to verify stuff
18:43 jekstrand: karolherbst: Yeah, I feel you there :)
18:43 airlied: oh I have to hook up the constant_ptr in llvmpipe somewhere
18:44 jekstrand: karolherbst: I'm also happy to have someone other than you review. I just want to give you the opportunity to NAK if it's going to cause problems. :)
18:44 karolherbst: jekstrand: but I think the uniform patch just broke constant args... let's see
18:44 jekstrand: airlied: Uh.... I should probably add an llvm impl for the new intrinsic.
18:45 jekstrand: airlied: Where do I find the LLVMpipe NIR translator?
18:46 airlied: src/gallium/auxiliary/gallivm/lp_bld_nir*
18:47 airlied: it might be a bit tricky, not sure it it will need to go via the soa path
18:47 karolherbst: jekstrand: huh?
18:47 karolherbst: why?
18:47 karolherbst: I already have a patch :D
18:47 jekstrand: karolherbst: Patch for what?
18:47 karolherbst: the constant buffer
18:48 jekstrand: karolherbst: I don't think we're talking about the same thing
18:48 jekstrand: karolherbst: I saw your patch. I didn't pull it in because I didn't really grok it and it looked very WIP
18:48 jekstrand: But maybe you have a newer version?
18:48 karolherbst: mhh what intrinsic did you mean, the constant base ptr, no?
18:49 jekstrand: karolherbst: No, nir_intrinsic_load_global_constant
18:49 jekstrand: karolherbst: For back-ends, it's identical to load_global
18:49 karolherbst: ohh, I see
18:49 jekstrand: The patches to implement it in fs, nv50, and llvmpipe are all trivial.
18:49 jekstrand: I think nv50 required two whol lines
18:49 jekstrand: *whole
18:49 karolherbst: yeah...
18:49 karolherbst: well.. we can do soemthing smarter with it
18:49 karolherbst: but that's a bit annoying
18:50 karolherbst: needs emiter changes :D
18:50 karolherbst: but I don't think my constant buffer patch is that much WIP anymore... I think I just need to figure out some details still though
18:50 jekstrand: karolherbst: Ok
18:51 jekstrand: karolherbst: I'm happy to get that one landed once you've got the corners filed off.
18:51 jekstrand: I don't think we actually need it for iris once !6244 lands but it doesn't hurt anything either.
18:52 jekstrand: It's actually kind-of nice for clover to handle that by magic
18:52 jekstrand: karolherbst: I want to get the nir_var_mem_constant landed mostly so that my pile for generic can shrink a bit. :)
19:01 karolherbst: ehh...
19:03 karolherbst: jekstrand: wanna guess what it was?
19:05 jekstrand: karolherbst: One of your patches didn't rebase clean?
19:05 karolherbst: anyway, !6497 is ready to go
19:05 karolherbst: jekstrand: worse.. my constant buffer patch still used shader_in :)
19:05 jekstrand: hehe
19:06 jekstrand: karolherbst: Ok, then let's marge it and we can all rebase and get rid of those issues. :)
19:06 jekstrand: jenatali is gone today, aparently
19:08 jekstrand: karolherbst: I just added your RB and assigned marge on !6497
19:08 jekstrand: karolherbst: I'll get image support sheaphearded through today as well to help trim down jenatali's pile.
19:09 jekstrand: I don't think I'll bother wiring it up in iris just yet. :)
19:18 karolherbst: :D
19:18 karolherbst: yeah... I think it's fine to merge stuff which has no in tree user, I just mainly want to wrie things up to see if there is anything making it problematic to use later on
19:18 jekstrand: Yeah
19:19 jekstrand: I'm pretty happy with the way jenatali did images, though. I don't see any issues. It's sort-of the obvious NIR way.
19:21 jekstrand: What the heck? I've got nothing better to do.....
19:21 jekstrand: :D
19:22 jekstrand: (which is totally not true)
19:22 karolherbst: :D
19:24 karolherbst: atomic lowering without CAS will be painful though :/ I suspect we need a nir_intrinsic_single_threaded and nir_intrinsic_multi_threaded or something?
19:24 karolherbst: mhhhh
19:25 jekstrand: karolherbst: Hrm...
19:25 jekstrand: karolherbst: num_subgroups == 1?
19:25 karolherbst: any idea what "__builtin_IB_eu_thread_pause(32)" is doing?
19:25 jekstrand: karolherbst: Let me see if I can figure it out
19:25 jekstrand: karolherbst: I suspect it just forces a thread-switch
19:26 karolherbst: would be strange
19:26 karolherbst: it's called directly before the cas on the lock
19:27 karolherbst: but maybe it is irrelevant and intel just uses one lock for all 64bit shared atomics
19:27 karolherbst: which kind of makes sense
19:27 airlied: jekstrand: images are obviously something better to do :-P
19:27 karolherbst: but also making it very bad
19:28 jekstrand: karolherbst: Looks like it whacks cr0
19:30 jekstrand: Hrm... No, it's something in the GRF
19:31 airlied: jekstrand: what should load_constant_Base_ptr load btw?
19:31 jekstrand: airlied: The pointer to wherever nir_shader::constant_data was put
19:32 jekstrand: airlied: karolherbst has a patch to handle that in clover. It's just still a bit WIP.
19:32 jekstrand: airlied: Current plan is that clover will turn it into a magic input
19:32 airlied: ah cool, then I'll await the clover patch
19:33 jekstrand: We can also handle it directly in iris
19:33 jekstrand: But I don't know how useful that optimization is for LLVMpipe.
19:34 jekstrand: karolherbst: The only thing the thread_pause intrinsic does is whack a "cycle counter" variable.
19:34 jekstrand: It's entirely for not messing up runtime cycle estimates or similar
19:36 airlied: jekstrand: is that where you just emit the const data after the shader and load from there?
19:36 jekstrand: airlied: Yeah
19:36 airlied: yeah I think llvmpipe can do it, just not sure it would help
19:36 jekstrand: airlied: It is somewhat necessary for CL
19:36 jekstrand: But, as I said, karolherbst will just lower it for you
19:46 jekstrand: $5 = {x = 0, y = 0, z = 0, width = 1048576, height = 1, depth = 1}
19:46 jekstrand: That doesn't look like a valid image to me....
19:49 jekstrand: Does CL assume images are never tiled?
19:49 jekstrand: Clover seems to
19:49 jekstrand: curro: ^^
19:52 karolherbst: jekstrand: clover always 1Ds all resources...
19:52 karolherbst: maybe not all
19:52 karolherbst: but mostly?
19:53 jekstrand: Yeah, that doesn't work....
19:53 karolherbst: I know
19:53 karolherbst: :p
19:53 karolherbst: radeonsi/r600 have handling for that though
19:53 jekstrand: And the image resource isn't declared 1D
19:53 curro: jekstrand: CL assumes image representations used for transfer purposes are linear yeah
19:53 jekstrand: It's a 2D pipe_resource
19:53 jekstrand: curro: Sure, so does GL
19:53 curro: karolherbst: uh? that's not intentional
19:54 karolherbst: jekstrand: clover needs some 1D handling
19:54 karolherbst: I had a patch somewhere...
19:54 karolherbst: but 1D images got added later to CL
19:54 jekstrand: Yeah, it looks like clEnqueueRead/Write just need some work.
19:54 karolherbst: curro: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/frontends/clover/api/transfer.cpp#L209
19:54 karolherbst: that happens for most mappings
19:54 karolherbst: so you map basically everything as 1D
19:54 karolherbst: and at some point that trips over drivers
19:55 jekstrand: karolherbst: I think that's fixable. I just need to add a new get() class
19:55 karolherbst: yeah...
19:55 jekstrand: Let me see if I can sort this one out
19:56 karolherbst: I tried .. but it's a bit annoying to follow
19:56 karolherbst: I hit this when looking into images as well :)
20:00 jenatali: jekstrand, karolherbst: Did I miss anything? :P
20:00 jekstrand: jenatali: Not really
20:01 curro: karolherbst, jekstrand: i don't think you need a new get() class, you just need to fix the interface of the current one to take the full origin+region vectors instead of the linearized offsets it takes right now
20:01 jekstrand: curro: Yeah. It already does take full vectors. It's soft_copy_op that does the wrong thing
20:01 jekstrand: I'm trying to sort that out
20:01 jekstrand: There's a lot of indirection in here
20:02 karolherbst: jekstrand: when ~mapping is called, the data gets transfered from the staging into the GPU buffer if I remember correctly
20:02 curro: the only indirection you need to change is _map::get AFAIA
20:02 airlied: jekstrand: it's like vulkan buffer->image done badly
20:02 curro: jekstrand: ^
20:02 airlied: using a linear 1d image instead of a buffer
20:03 jekstrand: curro: Yeah, I just need to wrap my head around the layering of abstractions. I'll get it. :)
20:03 karolherbst: or some other destructor?
20:03 karolherbst: mhhh
20:05 curro: jekstrand: i think in order to get what you want you'll also have to pass it a pitch vector so the void* specializations can continue converting vectors to a linarized offset
20:44 karolherbst: mhh... https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4340889 :/
20:45 karolherbst: jekstrand, jenatali: the uniform MR waits on that job to finish but I doubt it's going anywhere
20:45 jenatali: Looks stuck to me
20:45 jekstrand: karolherbst: Yeah, I had one of those the other days.
20:45 jekstrand: anholt, krh ^^
20:46 anholt: I'm actually working on that one at this moment!
20:46 anholt: also, please log fails like this at https://gitlab.freedesktop.org/mesa/mesa/-/issues/3437 which is where we're coordinating "make sure CI doesn't piss people off"
20:50 karolherbst: curro: quick look at this patch? https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/6167f33f1d397e39c924b355ea85f727b1c970ca
20:50 karolherbst: I could move it to a spirv specific place, but just were wondering what your thoughts are in general
20:50 karolherbst: clang sets this definition unconditionally for spir targets
20:51 curro: karolherbst: Reviewed-by: Francisco Jerez <currojerez@riseup.net>
20:51 karolherbst: thx
20:51 jekstrand: Ugh... CL allows a lot of types of buffer and image copies
20:52 karolherbst: yep
20:53 jekstrand: The code that's there works pretty well for buffers but it falls over for images
20:53 jekstrand: Making something that works nicely for images naturally doesn't work well for buffers
20:53 jekstrand: There's a compramize in here somewhere!
20:53 jekstrand: *compromise
20:54 curro: jekstrand: what's the problem you're having with images?
20:54 jekstrand: curro: There are roughly three types of things: Linear buffers, Buffers with a client-provided pitch, and Images which have an internal pitch.
20:55 jekstrand: The current code assumes everything is the client-provided pitch
20:55 jekstrand: Which is (1, 0, 0) for linear
20:56 anholt: thanks, gold. 1.5 minute arm builds in CI are pretty nice.
20:56 HdkR: anholt: Haven't switched to the supreme choice of lld + thinlto? ;)
20:56 anholt: HdkR: we're on debian stable, lld is a disaster
20:56 karolherbst: jekstrand: yeah... guess why I procrastinate images :p I don't remember the details, but I arrived at the conclusion of caring about required things first :p
20:57 HdkR: ah, that'll be a pain then
20:57 anholt: also, lto + mesa is going to bring you misery, since we're not actually strict aliasing safe
20:57 jekstrand: karolherbst: Yeah, that's fair. I'm pretty sure I'll have this cracked in a few minutes. I've just got to give it a few brain cycles.
20:57 HdkR: Time for a new issue report for making Mesa LTO safe?
20:58 curro: jekstrand: hm? i don't think there is such an assumption for everything, the transfer.cpp image functions are expected to query the pitch from the image object itself
20:58 jekstrand: curro: They do but at the wrong level
20:58 jekstrand: curro: They query the pitch from the image but the resource might have an internal tiling that causes the pitch to be different.
20:58 jekstrand: curro: The actual pitch has to come from the pipe_transfer
21:00 karolherbst:is still convinced there is no way images work right now with either r600 nor radeonsi, but is probably wrong about this
21:00 airlied: they only work on r600
21:00 airlied: never on radeonsi
21:00 airlied: and I'm not sure on r600 they are coorect
21:01 karolherbst: I mean, I am sure they worked at some point to some degree, but whenever I looked into the code I was like: no way that wouldn't blow up with more complex applications
21:02 jekstrand: I can totally believe they work somewhere.
21:02 karolherbst: but I guess in the past not having an accessible CTS made things... annoying to implement
21:02 jekstrand:wishes people would stop arguing over whether or not it's possible and just let him fix them. :-P
21:02 airlied: karolherbst: I think they passed some piglits on r600 :-P
21:02 airlied: but yeah also happy to burn r600 opencl to the ground
21:03 karolherbst: heh
21:03 karolherbst: airlied: taking the entire llvm backend path with it?
21:03 karolherbst: well.. not entire
21:03 karolherbst: guess the llvm generation bits we still need
21:03 airlied: I've got patches to move radeonsi to the nir backend
21:04 karolherbst: have fun
21:04 airlied: just need to clean those up at some point once the dust has settlted
21:04 karolherbst: ohh wait.. nir, not aco
21:04 karolherbst: :D
21:05 airlied: karolherbst: yeah aco is probably a step further :-P
21:06 curro: jekstrand: ah, damn... so is there no way for the state tracker to control the pitch of a pipe_transfer? or at least predict what the pitch will be?
21:06 jekstrand: curro: No, but I think I've got it sorted. Just needed to tweak abstractions a bit
21:07 curro: transfer interface seems kind of unfortunate to me...
21:08 bnieuwenhuizen: controllable pitch of pipe_transfer would also be awesome for Android stuff, just saying
21:08 airlied: we should just enable buffer to image transfers on gallium
21:09 bnieuwenhuizen: airlied: some people are greedy and want to directly map linear images
21:10 bnieuwenhuizen: if you add buffer<->image transfers you can't have that fastpath anymore
21:10 bnieuwenhuizen: (well, I guess we could all implement it in the app as long as we can predict whether transfers are going to give the right pitch ...)
21:12 curro: jekstrand: if you don't feel like fixing the pipe_transfer interface, i suggest changing the 'struct _map' thing to have a stride and map pointer field, then make the current get() static function into a constructor
21:12 jekstrand: curro: I've got a plan
21:14 curro: jekstrand: the pitch method should come directly from the pitch specified by the user through the CL API for the void*/buffer specializations, and from the clover::mapping object for the image specialization
21:16 jekstrand: I just have to re-learn C++ first. :)
21:18 curro: don't need to do much beyond defining a constructor and a few methods unless i'm missing something :P
21:18 jekstrand: curro: Oh, it's entirely possible. I just don't know how to write C++ code anymore. :)
21:19 curro: first step to learn C++: unlearn most of what you know about C :P
21:20 jekstrand: curro: I think I'd rather keep writing bastard C++ :)
21:20 curro: that *should* give you codee that compiles but has the same caveats as writing C :P
21:26 karolherbst:wonders if he should sow curro his latest MR
21:26 karolherbst: :D
21:27 karolherbst: unless... curro do you have a nice idea on how to deal with enums which are bitfields? I mean.. besides adding conversion operators
21:28 karolherbst: talking about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6520
21:28 karolherbst: that's probably one of the most annoying things when dealing with those enums
21:29 curro: karolherbst: yeah you need bitwise arithmetic operators if you wan't to be able to do bitwise arithmetic with them
21:29 karolherbst: right.. I was just wondering if there is a less annoying way to add this
21:29 curro: karolherbst: it would be nice to have a type traits-based templated definition of such bitwise operators so they don't have to be reimplemented for every bitfield enum
21:30 karolherbst: well.. I've added a macro for that
21:30 karolherbst: but yeah..
21:30 karolherbst: mhhh
21:30 karolherbst: let's see what std::is_enum does
21:31 karolherbst: curro: I think the idea was that we don't want to enable it for all enums at once? mhhh
21:31 curro: is_enum is definitely not going to know the enum is intended to be a bitfield
21:31 karolherbst: yeah
21:31 curro: i was thinking we could have an additional is_bitfield type trait, which the bitwise arith operators would automatically be enabled for
21:32 karolherbst: I don't think there is really a good solution here :/ you could probably have a generic template unimplemented and just add specialization having the real thing.. but that usually leads to annoying to debug compiler errors
21:32 karolherbst: mhhh
21:32 karolherbst: maybe
21:33 curro: anyway might be overkill for what you're trying to do. simply adding non-generic bitwise operators to nir.h would also be okay
21:34 karolherbst: well.. adding it for another enum is just calling one macro right now
21:34 karolherbst: and you can actually do it inside your C shared header right after the enum
21:35 karolherbst: so no need for guarding against c++ or putting it into a c++ only section
21:35 karolherbst: and I think even if there are "better" more c++ ways of doing it, I think they still fall short on those points
21:36 karolherbst: would be cool if c++ had an "magic" attribute to declare bitwise enums or so :D
21:36 karolherbst: oh well
21:36 curro: *shrug*, i find the type traits approach cleaner than ad-hoc magic attributes
21:37 curro: even if there was a magic attribute, you'd likely still have to make it conditional on the code being __cplusplus
21:40 curro: karolherbst: anyway, don't really oppose the macro approach you have in there, even though i can think of a way to do it without any macros
22:07 Lightkey: https://gitlab.freedesktop.org/mesa/mesa/commit/8ff6e7c7399822a07a3b5f1ff71a848e6e092389 This talks about ARB_texture_gather but the one marked in features.txt is ARB_texture_query_lod?
22:22 jekstrand: karolherbst: I think I have image uploads working
22:22 karolherbst: nice
22:40 Lyude: btw airlied (already cleared this with drm-misc folks a few days ago), going to send you a pull request for a topic branch with https://patchwork.freedesktop.org/series/80540/
22:54 jekstrand: karolherbst: Do the operators macros compile for you?
22:54 jekstrand: karolherbst: They don't compile here
23:16 jenatali: jekstrand: You can wrap them in an extern "C++" block
23:16 jekstrand: jenatali: Oh, really? That's a neat trick. Mind commenting with that on the MR?
23:17 jenatali: jekstrand: Yep, done
23:23 jekstrand: Well, I got an image test to execute. :-)
23:24 karolherbst: jekstrand: huh? what error do you get?
23:24 jekstrand: I'm not binding my resources yet
23:24 jenatali: jekstrand: Nice! :)
23:24 jekstrand: More iris typing in my future
23:28 karolherbst: jenatali: the enum has to be, no?
23:28 karolherbst: or the operators?
23:28 jekstrand: karolherbst: The operators
23:28 jenatali: karolherbst: Just the operators
23:28 karolherbst: ahh
23:28 karolherbst: okay.. that's easy then
23:30 karolherbst: huh...
23:30 karolherbst: mhhh
23:30 jekstrand: karolherbst: Try to add them for metadata and you'll see the bug
23:30 jekstrand: karolherbst: That's another one we probably want
23:30 karolherbst: yeah..
23:31 karolherbst: I am just trying to fix it in a slightly different way and things just mess up.. oh well.. a block it is then
23:32 karolherbst: I thought I could just add the extern directly at the operator.. but no, extern and static inline don't like each other
23:32 karolherbst: ...
23:34 jenatali: Yeah... using 'extern' as the way to declare C/C++ semantics was always weird to me
23:34 karolherbst: jekstrand: is it used for metadata already somewhere?
23:34 jekstrand: karolherbst: Probably
23:34 karolherbst: ahh, it is :)
23:34 karolherbst: cleaning it up then
23:35 jekstrand: karolherbst: My image lowering patch for clover will be another case. :)
23:35 karolherbst: :)
23:35 karolherbst: aco has a bunch of those
23:35 jenatali: jekstrand: I'm interested to see yours, to see how it compares to what we're doing for DXIL
23:36 jekstrand: jenatali: I'm guessing we'll quickly move the lowering pass to common code.
23:36 jekstrand: jenatali: At least bits of it
23:36 jekstrand: it's pretty straightforward
23:36 jenatali: jekstrand: I'm not sure, ours is a little ugly
23:37 jekstrand: jenatali: Well, I *am* currently ignoring the stupid opcodes. :D
23:37 jenatali: jekstrand: Even without that, ours ends up being pretty ugly
23:37 jenatali: https://gitlab.freedesktop.org/kusma/mesa/-/blob/msclc-d3d12/src/microsoft/clc/clc_compiler.c#L187
23:38 karolherbst: oh wow
23:38 karolherbst: src/intel/compiler/brw_fs.cpp even casts to unsigned before
23:40 jekstrand: karolherbst: Is there a hard limit on the number of kernel parameters?
23:41 karolherbst: besides drivers having to support the amount of data?
23:41 jekstrand: yeah
23:41 karolherbst: don't think so
23:41 jekstrand: k
23:41 karolherbst: but why do you need to add parameters?
23:41 jenatali: I thought I found one... let me double-check
23:41 jekstrand: I just need to sort out how image parameters are going to work
23:42 karolherbst: mhhh
23:42 jenatali: https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_DEVICE_MAX_PARAMETER_SIZE
23:42 jenatali: Must support 1024 bytes, 128 args
23:42 karolherbst: yeah.. but upper limit?
23:42 karolherbst: with nouveau we have like 64k of space
23:42 jekstrand: 128 args. Oof...
23:42 jekstrand: That's what I was looking for
23:42 karolherbst: but yeah.. some devices/drivers might just expose 1k :)
23:42 jenatali: I don't see a spot you can report an upper limit of number of args, but you can report an upper limit of size, and it can be as low as 1024
23:43 jenatali: jekstrand: There's separate caps for number of images, FYI
23:43 jekstrand: jenatali: The problem is that I need to map locations (arg number) to image index
23:43 karolherbst: what storage size to image_t parameters have anyway?
23:43 jenatali: jekstrand: We remap into 0-based in our lowering pass
23:43 karolherbst: I thought they are opaque just like in glsl
23:43 jekstrand: jenatali: Yeah, that's what I'm planning to do
23:43 jenatali: karolherbst: Yeah, undefined
23:43 karolherbst: jenatali: can you put them into structs? :D
23:44 jenatali: karolherbst: Nope
23:44 karolherbst: ahh
23:44 karolherbst: didn't make the same mistake as glsl then
23:44 jenatali: Yeah... that just seems absolutely crazy to me
23:44 karolherbst: __local image2d_t[10]; mhhhh :p
23:44 jenatali: All you can do with them is pass them as function parameters
23:44 jenatali: You can't declare variables, arrays, etc of them
23:44 karolherbst: ohhh
23:44 karolherbst: okay
23:45 karolherbst: then keeps them sane
23:45 karolherbst: jekstrand: I have an idea...
23:45 karolherbst: do you want to make images in CL way more saner than in glsl?
23:45 karolherbst: we could just make them full opaque and full direct
23:46 karolherbst: no annoying indirection
23:46 karolherbst: jenatali: wait.. not even variables?
23:46 jenatali: karolherbst: Read 'b' in https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#restrictions
23:46 karolherbst: ohh wow
23:46 jenatali: Yeah, they did it right
23:46 karolherbst: then they are full direct
23:46 karolherbst: insane
23:46 jenatali: No, sane
23:46 karolherbst: nope
23:47 karolherbst: indirects are okay ;p
23:47 karolherbst: why not indirects?
23:47 jenatali: Well, sure
23:47 karolherbst: they went too far
23:47 karolherbst: :D
23:47 karolherbst: ohh, I guess you can do the cond ? image_a : image_b trick
23:47 jenatali: Ehhh indirects weren't valid in D3D until D3D12, at the time CL1.x was around it would've been a bit messy on some hardware I'm sure
23:47 karolherbst: so.. some indirection if you want to
23:47 karolherbst: we have them in GL since... 4.0? or earlier?
23:48 jenatali: Granted, I don't know too much about the hardware implementation details, just what we've done at different points in time
23:48 karolherbst: hw could do it for a long time
23:49 karolherbst: seems like we do support indirect samplers/textures starting with fermi
23:50 karolherbst: which is GL4.6 hw actually
23:50 karolherbst: but the first nvidia made
23:50 jenatali: Which happens to be the oldest NV hardware that could do D3D12 :)
23:50 karolherbst: yeah...
23:50 karolherbst: but they jumped from 10.1 to 12 directly..
23:50 karolherbst: so no idea if some d3d11 hw can
23:50 jekstrand: Intel has supported indirect textures/samplers since Sandy Bridge
23:51 jekstrand: (first D3D11 HW)
23:51 karolherbst: ahh
23:51 jenatali: Huh, cool
23:51 jekstrand: Actually, SNB wasn't D3D11
23:51 jekstrand: It didn't have tessellation
23:51 karolherbst: jenatali: on nv that index you give in is one level of indirection anyway.. you just have a second one right after it :D at least on bindless hardware
23:52 karolherbst: so you hand in the index, which fetches the texture/sampler descriptor from a constant buffer
23:52 jenatali: karolherbst: Yeah, makes sense
23:52 karolherbst: and then the texture unit loads the actual thing
23:52 jenatali: But yeah, none of that in CL
23:53 karolherbst: and in full bindless mode you can hand in the descriptor directly which is a 32 bit value containing the sampler and texture reference packed
23:53 karolherbst: 12/20?
23:53 karolherbst: not sure on the bit sizes of each
23:53 karolherbst: so constructing that at runtime is quite trivial :)
23:53 karolherbst: jekstrand: but what do you say.. we do it like glsl and just have constant texture/sampler references?
23:54 jenatali: It's a good thing there's none of that in CL, because DXIL doesn't support a bunch of things that CL does on its samplers, so we have introduce some extra shader instructions, and we do so based on which samplers are bound to the corresponding slots at runtime
23:54 karolherbst: we don't even have the probem of loading from uniform/ubo
23:54 jekstrand: karolherbst: That's roughly my plan
23:54 karolherbst: cool
23:54 jekstrand: karolherbst: I'm lowering it to a texture index like we do in GL
23:54 karolherbst: the sampler will be annoying though
23:54 jekstrand: karolherbst: Which might be variable but probably isn't
23:54 jekstrand: Same for the sampler
23:54 jekstrand: So it should be just like GL
23:55 karolherbst: nope
23:55 karolherbst: CL samplers _are_ annoying
23:55 karolherbst: there is no way to fix it
23:55 jenatali: It's just separate from the image?
23:55 karolherbst: close.. but
23:55 karolherbst: not all of the stuff a sampler declares can be changed at runtime
23:55 karolherbst: like filtering
23:55 karolherbst: we can't select the filtering mode in the instruction
23:56 karolherbst: so we need some magic to bind 4 samplers or something
23:56 karolherbst: and deal with it somehow
23:56 jenatali: Sure, though that's relatively NV-specific?
23:56 karolherbst: coords? sure.. a bit stupid, but that works somehow
23:56 jenatali: FWIW, we lower each image to 3 images
23:56 karolherbst: ahh
23:56 jenatali: Well, up-to 3 images, depending on which formats are read from
23:56 karolherbst: might be that only nv didn't see why they should deal with such a broken spec :p
23:57 jenatali: Since DXIL has to declare the images/textures with formats in them
23:57 karolherbst: honestly..
23:57 jekstrand: I'm not sure if we need to do that or not yet
23:57 karolherbst: CL samplers are just stupid
23:57 karolherbst: jekstrand: on nv we do
23:57 jekstrand: karolherbst: We need it for some formats
23:57 karolherbst: addressing mode? no idea if we can do that in the instruction either
23:57 jekstrand: And the list of formats depends on HW
23:57 karolherbst: let's see...
23:58 jenatali: jekstrand: I'm just excited that images are getting into Clover now as well :)
23:59 jekstrand: Hrm.... Why is this sampler asking for pixel 512
23:59 jekstrand: That seems wrong
23:59 karolherbst: yeah soo...
23:59 jenatali: What're you testing it with?
23:59 karolherbst: we can't specify the addressing mode either :)
23:59 jekstrand: CTS
23:59 jenatali: karolherbst: We don't even *have* non-normalized addressing modes :D
23:59 karolherbst: :D
23:59 karolherbst: yeah well
23:59 karolherbst: you can convert at runtime
23:59 karolherbst: big deal :p
23:59 jenatali: Yeah, I know