00:00airlied: karolherbst: and those values seem to be the index into the sampler views
00:00airlied: maybe I thought (wrongly) that they could be repeated or come out of order
00:01karolherbst: imirkin: well, you can have 128 textures inside one kernel
00:01karolherbst: so clover would bind 128 sampler views
00:02airlied: and that's fine if you fix the driver
00:03airlied: and don't expose 128 to mesa ever
00:03karolherbst: as I said: worst case only gallium needs fixing, and not st/mesa :)
00:03airlied:would be happy to see 1 image :-P
00:03karolherbst: I am quite close actually
00:04karolherbst: I think
00:04karolherbst: airlied: I thought ~90 passes and ~10 fails in the basic tests is way too high, so I enabled images :p
00:05karolherbst: the remaining fails are super annoying bits
00:05karolherbst: like enabled memcpy
00:05karolherbst: and other random stuff
00:10karolherbst: mhh sadly vtn just assumes you have pointers... mhhh
00:45karolherbst: "vec4 32 ssa_21 = txl ssa_0 (texture_offset), ssa_3 (sampler_offset), ssa_19 (coord), ssa_20 (lod), 0 (texture), 0 (sampler)" :)
01:06jekstrand: karolherbst: I think we'll likely need a sampler intrinsic for immutable sample4rs
01:07karolherbst: jekstrand: why? It's not the samplers being immutable
01:08karolherbst: but yeah.. we might need it for the image/texture part.. but right now Iby treating it like ssa values, I just ignore that bit
01:09jekstrand: I thought OpenCL had inline samplers...
01:09jekstrand: Maybe I'm wrong?
01:10karolherbst: there was something, but I don't know if that actually matters... let me check
01:11karolherbst: jekstrand: ahh, right.. sampler_t is essentially an enum of stuff
01:14karolherbst: but clover still creates a normal pipe_sampler_state if it's an kernel arg
01:17karolherbst: and I think in kernel samplers should just get extracted as compilation output and just binded via the API as well
01:17karolherbst: at least that would be the most straightforward way
01:18jekstrand: Yeah, that's what I was thinking as well.
01:18karolherbst: "A variable of sampler_t type declared in the program source must be initialized with a 32-bit unsigned integer constant"
01:18karolherbst: so it has to be constant anyway
01:18jekstrand: So what's the other issue with samplers/images?
01:18karolherbst: jekstrand: vtn just deals with that stuff complelty different
01:18karolherbst: that's probably the main problem
01:19karolherbst: it assumes vtn_pointers for sampler/texture, but with CL we kind of have offsets
01:19karolherbst: not a big deal, just a bit annoying
01:19jekstrand: It assumes a pointer back to a descriptor
01:19jekstrand: Because that's the way it works in GLSL (sort-of) and is required to work in SPIR-V for Vulkan.
01:20jekstrand: What are these offsets that SPIR-V does?
01:20karolherbst: jekstrand: ABI of clover
01:20karolherbst: implicit numbering of args
01:20jekstrand: Can we just add nir_intrinsic_spirv_image, nir_intrinsic_spirv_sampler, and nir_intrinsic_spirv_imm_sampler, all of which return pointers?
01:20karolherbst: and as the args are opaque you shouldn't take any input space actually
01:20karolherbst: jekstrand: why not just load_const?
01:20karolherbst: seems simplier
01:21karolherbst: I just deal with it inside the kernel wrapper
01:21jekstrand: We could but it requires re-plumbing spirv_to_nir
01:21karolherbst: sure... but I already did the work
01:21jekstrand: Hrm... Maybe not...
01:21jekstrand: How many special cases did that take?
01:21karolherbst: other annoying bit is that it requires new glsl_types as in spirv the OpTypeImage gets created with void :)
01:22karolherbst: jekstrand: not much
01:22jekstrand: OpTypeImage gets created with Void?
01:22jekstrand: What do you mean
01:23karolherbst: base type
01:23karolherbst: it's void :)
01:23karolherbst: ehh, "Sampled Type"
01:23karolherbst: the type is set by the actual operation
01:24karolherbst: the patch isn't that ugly surprisinly
01:24jekstrand: Yeah, that's a new thing in SPIR-V
01:24jekstrand: Vulkan is going to start doing that too
01:24karolherbst: ohh, okay
01:25jekstrand: I think we should already handle that
01:25jekstrand: Well, Vulkan sort-of does
01:25karolherbst: well.. apparently not
01:25anarsoul|2: austriancoder: you may want to fix this warning: https://gitlab.freedesktop.org/anarsoul/mesa/-/jobs/1878830#L1947
01:25karolherbst: maybe it looks different in vulkan
01:25jekstrand: Vulkan gets its signedness from the operation but it's int/floatness from the sampler type
01:25karolherbst: yeah well
01:25karolherbst: in CL you get everything from the operation
01:25jekstrand: That's fine. For texturing, everything's on the operation in NIR anyway
01:26karolherbst: for some things, yes.. I saw that
01:26jekstrand: Not so much for images but that shouldn't be too terrible to handle.
01:26karolherbst: but I still hit some errors,
01:26karolherbst: anyway, the patch shows what I needed to change
01:26karolherbst: and it isn't all that much actually
01:27karolherbst: that "bool sampled;" thing is dead code btw
01:27karolherbst: maybe I should send a clean up patch for that :)
01:28jekstrand: I'm not sure I want it gone.... I kind of want to use it for ImageQuerySize and ImageLoad
01:29jekstrand: I guess it's only needed for QuerySize
01:29karolherbst: well.. right now it's not used at all.. so
01:29jekstrand: Yeah, it isn't
01:29jekstrand: That's because of history, mostly.
01:30jekstrand: Initially, I was trying to use glsl_type for everything and so I made the distinction between sampled images and storage images using the image2D vs. sampler2D types but that doesn't actually match the GLSL -> SPIR-V translation.
01:31jekstrand: The GLSL -> SPIR-V translation only uses sampler2D for combined image samplers
01:33karolherbst: airlied: ehh.. running into issues at runtime now :(
01:33jekstrand: FYI: I'm pretty sure your function parameter handling is going to break Vulkan quite badly
01:35karolherbst: jekstrand: fyi, the spirv looks like this: https://gist.githubusercontent.com/karolherbst/0f0202e00a1c91c9f233309fa8135d58/raw/2ded3970e906a3768224cb595538554803da9094/a.spv
01:36karolherbst: but I guess called functions would look similiar in regards to image/sampler args? dunno if there is a way to actually tell those apart
01:36jekstrand: karolherbst: Uh, yeah, that's very GLSL bindless isn't it?
01:37karolherbst: yeah... but at the same time it isn't
01:37karolherbst: :( it just sucks
01:37jekstrand: Yeah, best option may be to do something similar to what you did.
01:37karolherbst: jekstrand: the part which kills bindless is, that sampler and image args are opaque and shouldn't take away from the kernel input storage
01:37jekstrand: Oh, that sucks
01:38jekstrand: I mean, it could be worse, but it really kind-of sucks.
01:38jekstrand: I guess that implies a binding model where your binding table is basically indexed by argument position.
01:38karolherbst: well.. it'st just 128+16 args in the worst case and you might have enough storage to have some hidden storage for stuff like this
01:39jekstrand: Which is fine, TBH, but it does mean thinking about things differently in spirv_to_nir
01:39karolherbst: the painful part is just how things get into the kernel
01:39karolherbst: which is already annoying
01:39jekstrand: One option which is kind-of terrible but kind-of not would be to just make a uniform variable per input and just pass pointers around.
01:39jekstrand: That's the nicest CL -> GLSL type mapping
01:40karolherbst: yeah... probably
01:40karolherbst: but you still need to set the constant value somewhere
01:40jekstrand: But allowing images and samplers to just be SSA values is also advantageous
01:40karolherbst: maybe nir opts could actually optimize all of that away.. dunno
01:41jekstrand: I have a very old branch somewhere which reworks NIR to work in a more bindless way where you have a load_deref on the sampler pointer and the result of that load_deref is passed into the nir_tex_instr.
01:41karolherbst: I already see that a offsets -> index opt could be useful
01:42jekstrand: With the assumption that in a non-bindless shader, 100% of nir_tex_instrs would be such that you could chase the SSA value to the deref.
01:42karolherbst: jekstrand: the problem is, what if your hw doesn't support bindless and you really need to end with offset or index
01:42jekstrand: The bindless handle can, in theory, be anything.
01:42jekstrand: In particular, it can be a 32-bit index
01:43karolherbst: just at some point we still need to know if it's an bindless handle or just indirect texture/sampler reference
01:43jekstrand: I'm not sure it's worth it though
01:43jekstrand: For this, likely something akin to what you've done is the most pragmatic choice.
01:44jekstrand: OpenCL actually seems pretty simple. Just count the images/samplers and do one index each.
01:44karolherbst: maybe I give it some thoughts and find a better solution... I mean, in the end it shouldn't matter if the deref points to an uniform or an actual constant
01:45jekstrand: I actually kind-of like the idea of creating one uniform for eac
01:45jekstrand: However, I suspect we'd actually need an array of images or something like that
01:45jekstrand: And that could get messy
01:45karolherbst: mhh, I could just create a function_temp var and start from there...
01:45karolherbst: or something
01:45jekstrand: Just doing it with straight indices isn't terrible though
01:45jekstrand: Given what the OpenCL SPIR-V looks like
01:45karolherbst: if I have the var, set it to a constant and pass the deref into the function, nir should be able to optimize it to a simple constant offset
01:46karolherbst: or not?
01:46jekstrand: After function inlining, yes.
01:47karolherbst: that might be a solid alternative then
01:47karolherbst: I don't know how much indirection CL allows here
01:47karolherbst: but I guess you could select a sampler from an array.. maybe
01:47karolherbst: and then we would need something like that anyway
01:48jekstrand: Yeah, I don't know what CL's rules are either
01:48jekstrand: I suspect they basically don't exist. :(
01:49karolherbst: let's see what nvidia allows :)
01:50imirkin: sounds like it's probably DX's rules if they allow 128 textures and 16 samplers
01:50karolherbst: heh.. error: array with image or sampler element type is not allowed
01:50imirkin: nvidia hw allows indirect on both texture and sampler binding unit
01:51imirkin: basically you pack a 32-bit int with the sampler id and texture id in some bit layout
01:51karolherbst: not even casting is allowed
01:52karolherbst: jekstrand: I guess nvidia doesn't allow indirect samplers...
01:52imirkin: (that's def the kepler way, but i'm 99% sure that works on fermi too. no indirection on DX10 of course.)
01:52karolherbst: same for images
01:52jekstrand: karolherbst: Heh...
01:52karolherbst: maybe CL really doesn't know indirection here
01:52karolherbst: which.. is good for us
01:52imirkin: or maybe it was added in later CL?
01:53imirkin: i suspect even CL 1.2 is targeted at DX10-era hw
01:53karolherbst: even in CL2.0 mode it doesn't work
01:53imirkin: i.e. tesla / pre-evergreen r600
01:53imirkin: you could make images work on tesla with much blood sweat and tears
01:53karolherbst: but nvidias CL2.0 implementation isn't complete.. so
01:54karolherbst: imirkin: why?
01:54imirkin: coz there's no support for images
01:54karolherbst: I thought in compute shaders there are
01:54imirkin: but there is support for gmem
01:54imirkin: and the images *are* stored in gmem *somewhere*...
01:54imirkin: so ... like i said, blood sweat and tears :)
01:54karolherbst: I could check what they do on an cuda with tesla...
01:54imirkin: i think curro did a good chunk of the work to make it happen though
01:55imirkin: i forget if it was merged ... probably not
01:56jekstrand: karolherbst: The more I think about it, the more it looks like your approach fits current NIR the best.
01:56jekstrand: We could possibly do something different going forward but I'm not sure if it's worth it
01:56karolherbst: well I kind of still like the function_temp idea
01:57jekstrand: Feel free to give it a try
01:57jekstrand: I'm just saying that you've convinced me that my gut reaction of "OMG, we must have pointers!" was likely an overreaction. :-)
01:58karolherbst: imirkin: ufff
01:58imirkin: having ops which do this for you is a lot more convenient :)
01:59jekstrand: That code looks annoyingly familiar....
02:00imirkin: written *by* someone annoyingly familiar? :)
02:03jekstrand: Well, that too. :-)
02:03jekstrand: But the code we carry today, I've rewritten at least twice.
02:04jekstrand: So we're not using curro's original code anymore. We're using basically his code only translated to NIR.
02:04karolherbst: well.. we still have enough fun with images even on latest gen :/
02:04karolherbst: really.. what's the point of having hw ops if you still end up doing a lot of the stuff yourself :(
02:05jekstrand:always wonders that
02:05jekstrand: I thought images "just work" on recent nvidia HW
02:05karolherbst: heh.. apparently the CPU doesn't like 0 % 0
02:05karolherbst: big surprise
02:05karolherbst: jekstrand: ... well... ufff
02:07jekstrand: Oh? What's busted about them?
02:08karolherbst: mostly the coordination stuff I guess
02:08karolherbst: and we do some format conversion
02:09karolherbst: oh yeah.. and 2d layers of 3d image bound are pain as well
02:09karolherbst: so you might think the hardware would know how to handle that, especially with all the tiling around
02:09karolherbst: but no
02:09karolherbst: nvidia just disables tiling on the z axis and passes in the 2d layer as an offset into the 3d image :)
02:09karolherbst: but that comes with runtime costs of.. you know, detecting the application doing that
02:11jekstrand: Having the hardware be able to do format conversion would be nice...
02:13karolherbst: I guess you can spend the transistors on more usefull things.. and kind of optimizing the conversions with the code around might even give you more benefits..
02:23airlied: karolherbst: ah yes I vaguely remember hitting the void thing as well when I gave up last time :-P
02:24karolherbst: airlied: seems like clover passes in a reference for the image, but not for the sampler... ehh
02:24karolherbst: anyway.. I crashed my GPU context often enough so nouveau got stuck :(
06:05lrusak: any chance to import P010 in mesa like it does with YUV420 by using shaders?
06:05lrusak: or YUV420p10
08:21pq: airlied, emersion, jadahl, fstat... so what does fstat on a dmabuf fd return today for the device major/minor?
08:22pq: hm, not easy to check with the shell, since /proc/<pid>/fd/## is just a broken symlink for dmabuf
08:24jadahl: pq: the check would happen in some gstreamer or pipewire pipeline rather than the shell in this case
08:26pq: jadahl, yes
08:27pq: I mean, what else could the major/minor returned by fstatting a dmabuf fd return than the device that allocated it - seems like a good fit, unless it already has a different meaning
08:30ascent12: pq: st_rdev is 0.
08:30ascent12: So major/minor is 0.
08:31pq: ok, sounds like N/A
09:23anarsoul|2: daniels: looks like fdo-packet-m1xl-1 is out of disk space
09:37hakzsam: MrCooper: are you fine with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4044 ?
09:52MrCooper: noticed a couple more things I'm afraid
09:52hakzsam: thanks, I will update
10:08MrCooper: hakzsam: please cancel the pipeline (still no idea why others can't do so for your project?)
10:09hakzsam: why should I cancel it?
10:09hakzsam: I don't know either why you can't
10:10hakzsam: ok, it wasn't rebased on recent master, should be ok now
10:19MrCooper: in your project settings under "General" => "Visibility, project features, permissions", is the "Pipelines" switch enabled? And what's selected in the combo box to the right of it?
10:19linkmauve: pq, fd symlinks in /proc aren’t actually broken, you can still open them and then do stuff with them.
10:20pq: linkmauve, ohh
10:23pq: looks like the stat command is not to be trusted on them though, for a dmabuf it says 'Device: 5h/5d' which is the same it says for the fd directory too.
10:24MrCooper: hakzsam: did you see my question above?
10:26hakzsam: MrCooper: it's enabled and it's "Everyone with access"
10:26linkmauve: pq, it’s especially useful when you’ve inadvertantly deleted a file and it’s still open by another process; you can then recreate a hardlink and it won’t be deleted anymore.
10:32MrCooper: hakzsam: hrm, and what's selected for "Project visibility" at the top of that section?
10:36hakzsam: MrCooper: "Public" and the checkbox below isn't checked
10:36MrCooper: k, then I'm out of ideas again
10:37hakzsam: I think we already checked last time :/
10:41MrCooper: ah, I think it's because you restricted access to the Git branch
10:43MrCooper: "Repository" in that section maybe?
10:44hakzsam: same as the Pipelines section
10:51MrCooper: did you define any protected branches on the Repository settings page?
11:07hakzsam: MrCooper: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1885960 crashed again maybe we need to rm ppc64el as well?
11:08MrCooper: sounds like a shot in the dark; I'd try it with a local podman/docker first
11:59daniels: anarsoul|2: fixed thanks
12:20tpalli: MrCooper seems like something wrong with panfrost CI jobs
12:21tpalli: MrCooper getting stuck/timeout failure
12:32daniels: tpalli: yeah, that's my fault and not his :P
12:32daniels: the fd.o runner which executes those jobs was dead because its disk was full (an ongoing saga we're fixing for good this week but still not done yet)
12:32daniels: if you retry them the runner will pick them up, but they'll take longer than normal to complete because there's now a backlog
12:35tpalli: daniels ok thanks!
12:41kazlaus: mdnavare: it's not part of the spec, but realistically you aren't going to get a good experience on panels that have a range of that or less
13:37MrCooper: tomeu: is there an MR yet for making the meson-arm* artifacts smaller? They currently generate an order of magnitude more egress traffic than other artifacts
13:43daniels: MrCooper: i guess the underlying issue is that they also contain the kernel + modules, which is great for traceability but less great for egress ... we almost certainly want to implement a transparent cache on the LAVA side, which anholt already did for the db410c before they abandoned that iirc
13:45MrCooper: that would still mean up to 200 MB * number of caches of egress per pipeline
13:49daniels: there'd be 2 caches, and presumably we could cache the rootfs separately, but yeah, this would point to us needing to do something smarter
14:22mripard: airlied: yeah, sorry, I meant rc5
14:51imirkin_: tpalli: dunno if you want to do an audit, but basically every driver should have PIPE_CAP_MIXED_COLOR_DEPTH_BITS enabled. nv30 is what i added that cap for, to try to avoid applications from picking obviously-bad things
14:52tpalli: imirkin_ ok cool, I know we have some exceptions with old gens but those are not supported in iris anyway, was that r-b?
14:53imirkin_: tpalli: sure, r-b (although you may want someone from intel to sign off?)
14:53imirkin_: tpalli: i'm pretty sure even gen4 supports this. maybe i915 would be equally unhappy? dunno.
14:54imirkin_: basically on nv30, the hw must have these things match. a competent driver would do fallbacks + blits to support the API, but even in such a case, why invite the badness :)
14:57tpalli: imirkin_ right I think we have some issues with 565, there at least i965 has some gen specific things where 16bit depth is also expected
14:58imirkin_: ha! that's surprising
14:58imirkin_: but nice to know i'm not the only one who suffers
14:59imirkin_: on nv30, the solution to that problem is "don't bind depth buffer"
14:59imirkin_: which isn't ... perfect
14:59imirkin_: better than gpu hangs, but worse than correct rendering
15:02tpalli: right, 565 is sort of rare but there still seems at least android games that want it
15:02imirkin_: well - a lot more common in GeForce FX times
15:02imirkin_: (which is the nv30 generation)
15:24hakzsam: MrCooper: btw, I can't debug this locally because I don't have access to any s390x arch
15:24MrCooper: that's irrelevant, all of this runs on x86
15:24imirkin_: few people do :)
15:25imirkin_: can't just go to best buy to pick up one of those...
15:25MrCooper: code for cross-built architectures is executed by qemu
15:25MrCooper: and it's qemu which crashes
15:25hakzsam: wow, will be a pain to debug :P
15:27MrCooper: yeah, but you can certainly try other workarounds
15:27hakzsam: before installing more i386 packages it worked, that's a start
17:40pinchartl: sravn: thanks
17:56hakzsam: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1891806 --> no space left on device
18:02daniels: i do wonder why the disk is filling so quickly :\
18:02daniels: obviously it's not fully properly fixed to have full capacity and a real storage runner yet
18:02daniels: but it's filling >400GB in a few hours
18:02daniels: which is surprising
18:03MrCooper: baobab/du/... to the rescue?
18:04hakzsam: that's huge
18:06linkmauve: ncdu is nice, when you’re on a server without GTK+ installed.
18:08daniels: ah yes, it's because that one host is pulling all the ARM builds, as well as doing x86 builds + tests, and has also recently put through some Android builds
18:08daniels: makes sense
18:08daniels: hakzsam: they have 2.8TB in total but the RAID is not yet provisioned and enabled
18:09daniels: anyway, cleared out for now
18:09daniels: RAID will be provisioned as soon as we can
18:13anarsoul|2: austriancoder: jekstrand: any opinion on moving https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4126/diffs?commit_id=3e21b2554b86a7039f7b55914fca0b744444208f from !4126 into nir_opt_algebraic?
18:16anarsoul|2: also kusma ^^
18:16jekstrand: anarsoul|2: Is that actually cheaper?
18:16anarsoul|2: jekstrand: yes for lima
18:17jekstrand: The one in nir_opt_algebraic is only about 5 instructiosn
18:17jekstrand: None of which are multiplication
18:17jekstrand: Unless sel is stupid expensive
18:18anarsoul|2: sel takes 2 slots
18:18anarsoul|2: on Utgard GP
18:19jekstrand: Given that etnaviv and lima are the only drivers setting lower_ftrunc, I don't personally care about the perf trade-offs.
18:19jekstrand: I'm fine with it bein in nir_opt_algebraic
18:19jekstrand: It's also fine for it to be driver-specific
18:19anarsoul|2: etnaviv probably won't like it since they need to lower fsign
18:20jekstrand: Sure, but you can do 'options->lower_ftrunc && options->lower_fsign'
18:20anarsoul|2: good idea
18:20anarsoul|2: let's do that
18:21jekstrand:is still skeptical that it's actually faster
18:21jekstrand:also doesn't care
18:21anarsoul|2: jekstrand: we get less instructions with this lowering on lima
18:21jekstrand: I guess that is the metric
18:23anarsoul|2: jekstrand: sel takes both mul slots on GP, so we end up with one less op available and it makes scheduler job harder
18:24jekstrand: Yeah, that makes sense, I suppose
18:25jekstrand: anarsoul|2: Why does the new lowering use ffloor(fneg(x)) rather than ffloor(fabs(x))?
18:25anarsoul|2: jekstrand: because we don't have fabs :)
18:26anarsoul|2: it's lowered to fmax(a, -a)
18:26anarsoul|2: while fneg is essentially free, it's just a modifier on an operand
18:26kusma: anarsoul|2: it it's not universally faster, I think it's fine to have it in the driver.
18:27kusma: anarsoul|2: I just wondered if there was another reason
18:27jekstrand: anarsoul|2: Ah...
18:30anarsoul|2: guess I should move fabs lowering to nir_opt_algebraic as well. It makes no sense to keep it in backend
18:34flto: anarsoul|2: for etnaviv the lowering in nir_opt_algebraic optimizes to 2 instructions (floor + sel, since sel can do compare with 0 for free, and abs/neg are free modifiers), yours would be 3 instructions
18:35karolherbst: fabs as 3 instructions?
18:36anarsoul|2: flto: I see. So I guess I'm keeping it in lima.
18:37anarsoul|2: karolherbst: 1 for lima, but with 2 operands and taking one of acc slots.
18:38karolherbst: sounds weird enough
18:38anarsoul|2: basically ffloor(fneg(x)) is 1 op (not to be confused with instruction)
18:38karolherbst: yeah right.. but source modifiers are quite common and this kind of looks like it
18:38anarsoul|2: ffloor(fabs(x)) is 2 ops. Could be 2 instructions if there's no 2 free acc slots in current instruction
18:39karolherbst: I see
18:39anarsoul|2: https://gitlab.freedesktop.org/anarsoul/mali-isa-docs/-/blob/master/Utgard-GP.md if you're curious about vertex shader ISA on Utgard
18:39karolherbst: no clue why fabs would be more expensive than fneg.. but okay
18:40anarsoul|2: karolherbst: that's easy, likely no bits were left for fabs modifier
18:40flto: anarsoul|2: lower_ftrunc was added specifically for etnaviv.. if there was a 3rd user of lower_ftrunc and yours was better for that hardware I think it would make sense to change nir_opt_algebraic
18:41anarsoul|2: instruction is 128 bits and every bit is used
18:41karolherbst: you have very long instructions
18:42karolherbst: but I guess being a vectorized ISA means you need more bits for general stuff
18:42anarsoul|2: flto: I'm not sure how to add it into nir_opt_algebraic to avoid regression on etnaviv.
18:42anarsoul|2: karolherbst: it's scalar ISA
18:43flto: anarsoul|2: I'm saying if it was more than just lima that wants this change, then etnaviv could have its own custom lower_ftrunc instead
18:43anarsoul|2: flto: ah, right.
18:44karolherbst: anarsoul|2: I got confused by the xyzw values, but I guess an instruction can only operate on one channel at the time?
18:44anarsoul|2: karolherbst: operation in instruction can operate on one channel, that's correct
19:02melissawen: Hi, my name is Melissa. I am a master's student at the University of São Paulo (Brazil), and I am interested in participating in gsoc this year. So, I am currently trying to understand a little more about the drm and work with some igt tests and I recently sent some simple patches to the drm.
19:02melissawen: siqueira, I saw a project proposal for vkms that also includes working with igt, and I would like to apply for it :)
19:04melissawen: I would like to discuss a little more to understand well the proposal and also have some guidance
19:09Lyude: mupuf: ^ maybe you can help point them in the right direction?
19:11Venemo: daniels: I'm having issues with the panfrost ci again. I retried it already and it failed again.
19:11Venemo: daniels: https://gitlab.freedesktop.org/Venemo/mesa/-/jobs/1892716
19:32siqueira: melissawen Hi! First of all, thanks for your interest in VKMS project, I have seen some of your patches and emails in the mailing list. If you take a look at https://www.x.org/wiki/SummerOfCodeIdeas/ you will see that I added some basic info and also some directions.
19:33siqueira: From your emails, I know that you are trying to reproduce some a bug and also fix the alpha issue. In my opinion, you are in the right direction and if you need any help during your work feel free to ask me here or via email.
19:34siqueira: Btw, if you have time could you change the behavior of `enable_cursor` for making it always enable and just disable if we use `disable_cursor`? These days, I think there is no reason to keep cursor disable by default on VKMS.
19:55daniels: Venemo: I think this is a general gitlab-runner issue which can affect all jobs, I'm trying to understand what it is but I may not be able to fix it for you tonight
19:56pepp: Venemo: you should rebase your MR on master. That way the panfrost CI wouldn't run for your MR
19:56Venemo: oh, I see. thanks pepp
19:56Venemo: will try
19:57daniels: that would also help tbf
20:36airlied: mripard: sorry fell of my list yesterday, will backmerge today
20:39melissawen: siqueira, thanks! Yes, I can work on this issue about cursor. I think it would also help my tasks as I am working on some igt tests related to it.
20:41siqueira: melissawen thanks, don't forget to CC me
20:42Venemo: pepp, daniels I now rebased on latest master and assigned it to marge and the ci failed again
20:47pepp: Venemo: looks like https://gitlab.freedesktop.org/mesa/mesa/issues/2505
20:47gitbot: Mesa issue 2505 in mesa "cache_test intermittently fails" [Ci, Glsl, Opened]
21:20mripard: airlied: thanks
21:31imirkin_: Venemo: you're like the lightning rod for this stuff
21:41jcdutton: Hi. Are there any open source opencl test suites ? I have an opencl application that if not working right, and hoping that I can get it to fail a particular standard opencl test, to help with debugging it.
21:42robclark: jcdutton: https://github.com/KhronosGroup/OpenCL-CTS
21:44agd5f: jcdutton, someone had started an opencl piglit as a GSOC project one year. Not sure it ever really took off though
21:45karolherbst: jcdutton: mind sharing which CL application that is? I might look into it and fix it
21:45karolherbst: and mind telling what driver?
21:45karolherbst: But I'd assume r600
21:47airlied: karolherbst: get any further with images?
21:47karolherbst: not yet
21:48karolherbst: I mean.. it should work, there is just some random stuff failing on a runtime level
21:49jcdutton: karolherbst, the problem app is opencv
21:50karolherbst: ehh, I see
21:50karolherbst: jcdutton: any way to launch it from a defaul installation to make it crash?
21:51jcdutton: karolherbst, I will try the KhronosGroup tests, if they all pass, then I will just need to debug my app. I think the problem might be trying to multithread calls to opencv
21:52karolherbst: they won't pass all
21:52airlied: or even close :-P
21:52karolherbst: and you will get random fails so any report will be useless in regards to opencv
21:52jcdutton: Is opencv just too buggy ?
21:52karolherbst: no, mesa is
21:52karolherbst: well, clover
21:53jcdutton: karolherbst, I am using rocm with a vega 56.
21:53karolherbst: ohh, then you are in the wrong channel to report this issue :p
21:53karolherbst: we don't care about propriatary software here :p
21:53karolherbst: well.. actually we do, like games, but I mean propraitary implementations
21:54jcdutton: karolherbst, I know, the AMD binary blob inside ROCM is buggy as hell.
21:54karolherbst: right, but not our problem :)
21:56HdkR: Does this just mean that everyone's OpenCL implementation is buggy? Take of pick of which bugs you want to deal with? :D
21:57karolherbst: HdkR: well, if in the occurance of this bug mesa would be involved I would kind of care
21:57karolherbst: but as it seems it's not
21:58karolherbst: but... it also never sounded like jcdutton was actually asking us to help out :) but yeah, running the OpenCL CTS _might_ help
21:58karolherbst: but implementations are also supposed to pass the test
21:58HdkR: ah right.Rocm Sock'm opencl
21:58karolherbst: the tests isn't great though
21:58karolherbst: and I know a lot of bits they are not testing
22:05Venemo: imirkin_ :D
22:05Venemo: imirkin: I had a good laugh at that comment :)
22:06imirkin_: happy to help any way i can!
22:15jcdutton: Can clover run opencl on a vega ?
22:18ajax: i believe so. it works on polaris, at least, i don't imagine it fails to support vega too.