00:06 alyssa: (('imax', ('isub', a, b), 0), ('usub_sat', a, b)) -- wonder if this helps anything (came up in code review)
00:07 alyssa: [For machines where sub_sat has the same perf as sub]
00:11 imirkin: assuming no wrap-around...
00:12 alyssa:grumbles
00:12 alyssa:chants nsw/nuw and jumps ship to llvm =p
00:12 imirkin: yes, that'll solve everything
00:14 alyssa: =D
01:02 Kayden: alyssa: don't you know? there's already a solution to *all problems*, if only those silly linux developers would get on board with that exciting reality! why, the other day I heard LLVM had a fully bundled midgard driver and compiler already, just waiting for people to realize how amazing it was!
01:02 Kayden: eheheh, sorry, couldn't resist the trolling
01:02 Kayden: don't mind me (:
01:07 robclark: does mali blob use llvm as well? adreno blob does (but ofc their backend is not upstream llvm)
01:07 alyssa: robclark: yep
01:08 alyssa: so does apple but that one's obvious
01:08 alyssa: I am not aware of a single non-LLVM shader compiler outside of Mesa..
01:14 robclark: fun
01:33 alyssa: "Rosenzweig has been involved in the analysis of the Mali GPU installed in the Arm Cortex release and the development of the open source driver ’ nouveau ’ for NVIDIA GPUs"
01:33 alyssa: TIL!
01:33 bl4ckb0ne: gz
01:33 alyssa: 🙃
01:34 imirkin: alyssa: waiting for the patches!
01:34 alyssa: imirkin: :>
01:40 ccr: :)
02:02 Kayden: https://gitlab.freedesktop.org/mesa/mesa/-/commit/a62123572099cfa173804146771e76dae3637eab
02:02 Kayden: technically correct (the best kind of correct)?
02:04 alyssa: ha
02:07 ccr: "with this one WEIRD TRICK (commit) you can become a Nouveau developer."
02:08 HdkR: "You may not like it but this is what peak Nouveau development looks like."
02:09 HdkR: Hm, that one may have a bit of mean feels tied to it
02:38 milek7: I'm getting quite bad performance from persistently mapped GL buffers on amdgpu, is this expected?
02:39 HdkR: Depending on what you're doing, it can be
02:42 HdkR: Need to be careful with where the main expected usage is, and GL_CLIENT_STORAGE_BIT
02:43 HdkR: plus coherent versus explicit flushing
02:44 milek7: I'm testing new openttd builds that use opengl, what they are doing is just mapping GL_PIXEL_UNPACK_BUFFER, using that mapping in old cpu 2d blitter, and updating texture from it and drawing single quad
02:46 milek7: yeah, it works fine with GL_CLIENT_STORAGE_BIT
02:50 milek7: thanks
02:53 HdkR: Careful with that. It changes where the buffer is resident in memory at. Although if you're only having the GPU read it once then it is probably fine
03:21 milek7: yes it's just single copy to texture
03:21 milek7: curious it's fine on other platforms, eg. windows nvidia
03:22 milek7: guess they just ignore the hint and have their own heurestics?
03:22 HdkR: Nvidia has all the heuristics in the world to move the buffer if the user hecked up its location
03:24 HdkR: I believe they may also do some sort of faulting mechanism to quickly move full pages across the boundary
08:49 MrCooper: milek7: what access mode is passed to glMapBuffer, and does the "old cpu 2d blitter" code do contiguous writes only to the buffer?
08:55 MrCooper: anholt: hey, how's life back in 2020? ;) (you really need to start paying attention to the year when bumping image tags :)
10:15 hakzsam: dcbaker: can you cherry-pick https://gitlab.freedesktop.org/mesa/mesa/-/commit/856fd4750daf23ac3f8f40278cf685f36661c19f please? dschuermann forgot to add mesa-stable
10:16 dschuermann: and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8260/diffs?commit_id=cd870d1b6aa43daa65f1e6c9763e5bdd7139acc9
10:16 dschuermann: sorry, I thought Cc: 21.0 would be enough
10:25 MrCooper: I suspect LIBGL_ALWAYS_SOFTWARE now possibly resulting in zink instead of an actual software rasterizer might be too surprising
10:26 HdkR: LIBGL_ALWAYS_EMULATION? :)
12:09 mripard: pinchartl: vsyrjala: could you review https://lore.kernel.org/dri-devel/20210121163537.1466118-10-maxime@cerno.tech/ ? it's the last one to get the rest of the series in
12:31 pinchartl: mripard: you know I haven't reviewed the whole of the other patches, right ? ;-)
12:46 mripard: pinchartl: oh.
12:46 mripard: well, you can review all the others as well then :D
12:48 pinchartl: :-)
14:04 karolherbst: jenatali: ehh.. the spirv translator has threading issues :/
14:29 jenatali: karolherbst: I didn't realize it had any global state...
14:30 karolherbst: yeah....
14:30 karolherbst: not sure, but tsan complained
14:30 karolherbst: some map stuff
14:30 karolherbst: in SPIRV::OCL20ToSPIRV::transWorkItemBuiltinsToVariables
14:31 karolherbst: jenatali: SPIRSPIRVBuiltinVariableMap
14:32 karolherbst: uhh
14:32 karolherbst: there are a bunch of maps with static accesses
14:34 jenatali: Oh it's magic statics
14:35 jenatali: karolherbst: Magic statics are required to be thread-safe
14:37 karolherbst: not if you add data while reading from them
14:37 jenatali: Sure, but that doesn't happen, all those maps are const
14:37 karolherbst: tsan disagrees
14:37 karolherbst: jenatali: https://gist.github.com/karolherbst/20a0cc32c06f2afeb9b3933b422c50d3
14:37 karolherbst: the stacktrace misses entries because the translator is not built with tsan
14:37 karolherbst: but..
14:38 karolherbst: maybe it's a false positive
14:39 jenatali: How did you build the translator? I wonder if there's a switch that disables thread-safety of magic statics
14:39 jenatali: I know MSVC has one
14:39 karolherbst: no clue
14:39 karolherbst: default options
14:39 jenatali: GCC?
14:40 jenatali: https://en.cppreference.com/w/cpp/language/storage_duration, section on "staitc local variables" - If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once
14:43 karolherbst: yeah.. sure
14:43 karolherbst: but its not a static local variable
14:43 karolherbst: it's static global state :p
14:43 jenatali: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/ff9babe1a88054b55bc20a7bf2e9a34a75c5d07b/lib/SPIRV/libSPIRV/SPIRVUtil.h#L108
14:43 karolherbst: and it's not a problem of the init path
14:44 karolherbst: but normal static methods
14:44 jenatali: Your tsan trace had constructors in it
14:44 karolherbst: jenatali: that's not local
14:44 jenatali: Sure it is, it's inside a function
14:44 karolherbst: uhm.. wait
14:44 karolherbst: this one is
14:44 karolherbst: but I meant the other ones
14:45 karolherbst: mhhh
14:45 karolherbst: maybe it is..
14:45 karolherbst: ehh wait
14:45 karolherbst: no
14:45 karolherbst: :p
14:45 karolherbst: emphasis on "initialize"
14:46 karolherbst: but yeah.. I think it's worth a closer look
14:46 jenatali: I'm not sure what you're getting at with that. The constructor calls the init() function which populates the map, so it should be completely unchanged by the time it returns from initialization
14:46 karolherbst: what does the init method has to do with initialization?
14:47 jenatali: I just meant that all of the map specializations do all of their work (actually populating the map) in a specialized function called init()
14:48 karolherbst: yeah... mhh, which should be called from within the constructor
14:48 karolherbst: let me make it more verbose
14:50 karolherbst: ahhh
14:50 karolherbst: jenatali: now it's gone :D
14:50 jenatali: False positive then?
14:50 karolherbst: ohh it's back
14:50 karolherbst: mhh different places
14:51 karolherbst: why does all of this have to be such flaky :p
14:51 karolherbst: *so
14:51 karolherbst: I give up
14:52 jenatali: Dunno, I wouldn't trust tsan personally, just because I don't know anything about how it works, and that sounds like the kind of thing that'd either be rife with false positives or negatives. Threading is hard
15:38 emersion: so in the case of a split display/render engine, there will be two unrelated drmDevices right?
15:39 emersion: and if i allocate buffers on one, i'll be able to import these buffers on the other device and they'll just work?
15:40 emersion: is there a good way to know when i should try this, and when i need to fallback to a software renderer?
15:40 emersion: is there a way to prevent mesa from using a software renderer, so that i can use mine, which is more optimized for my use-case?
15:41 emersion: cc daniels pq maybe ^
15:52 imirkin: emersion: you can detect it since one device will be display-only, and one will be render-only
15:52 imirkin: emersion: there's a "renderonly" meta-driver in mesa which helps with some of this
15:53 emersion: well, if i have an nvidia render-only card and a completely unrelated displaylink device, it'll look the same
15:53 emersion: but i won't be able to use both together without explicit copies
15:54 emersion: yeah, i know about kmsro, hm...
15:54 emersion: kmsro works with the display-only device right?
15:54 imirkin: iirc yes
15:55 imirkin: and it secretly opens the render-only device behind your back
15:55 emersion: so, if the display-only device is e.g. displaylink, kmsro won't kick in and instead i'll get llvmpipe
15:55 imirkin: correct
15:55 emersion: which i really don't want
15:55 imirkin: you can detect it, but it's not ideal
15:55 emersion: yeah, and there are a bunch of other software renderers
15:56 imirkin: (GL_RENDERER, etc)
15:56 imirkin: right
15:57 emersion: vulkan has a bit to detect software renderers… but GL doesn't have that
15:57 imirkin: could add an ext
15:58 bnieuwenhuizen: GLX_MESA_query_renderer -> accelerated ?
15:58 bnieuwenhuizen: not sure if there is an EGL equivalent
15:58 emersion: yeah, GLX has it too, but ajax said it should be a GL ext rather than an EGL ext
15:59 imirkin: could add a EGL_context_no_swrast or something, which lets you request an accelerated thing
15:59 imirkin: and have it fail to create the context if it's not there
15:59 emersion: my recent attempts at submitting a new vulkan extension are… sub-optimal, so not sure i want to start doing a GL one :S
15:59 imirkin: could be mesa-only
16:00 imirkin: not a lot of other swrast's i think?
16:00 ajax: gl extensions are fairly low-friction if you want them to be
16:00 emersion: ajax: what do you think about something like EGL_context_no_swrast? would make sense, or would be better as a GL query?
16:01 emersion: ok, maybe i'll try then
16:01 ajax: GL_MESA_query_renderer perhaps
16:02 ajax: have it take all the same tokens and use corresponding api, but it applies to the GL context not the winsys state?
16:02 ajax: well, let's back up. presumably you want to avoid creating a pointless swrast context if you don't have to.
16:03 ajax: (i'm a bit confused reading through the backscroll, what's the scenario here?)
16:03 emersion: so: let's say i have both a GL renderer and a Pixman renderer
16:04 emersion: i want to use the GL renderer if it's not llvmpipe or some software impl, because Pixman would be faster
16:04 emersion: but because split render/display devices exist, it's not easy to choose between GL and Pixman just looking at the drmDevices
16:05 emersion: i don't really mind the wasted context creation that much, if that matters
16:06 ajax: how would you feel about a context creation attribute that let you add a constraint there? "give me a context for this device but only if it'd be { GLX_RENDERER_ACCELERATED_MESA, GL_TRUE }" ?
16:06 emersion: yeah, works for me
16:07 bl4ckb0ne: that would be nice
16:07 emersion: side note about prior art: Vulkan has VkPhysicalDeviceProperties.deviceType == CPU
16:07 emersion: … which would somewhat map to an EGLDevice query
16:08 emersion: (but would make it an EGL ext instead of a GL one, sigh)
16:09 ajax: that's fine tbh. if you're thinking about that comment i put in mutter about detecting swrast that's as much a comment about matching mutter's internals as anything else
16:09 emersion: i guess the idea about the context attribute would also be EGL
16:10 emersion: yeah, i was thinking about this comment
16:10 imirkin: that's what i was implying with EGL_context_no_swrast :)
16:10 imirkin: it would specify some new context attrib.
16:11 ajax: yeah, what i was getting at there was "properly this _is_ a query you make of the winsys but as there is no EGL extension presently and i'm not writing one for it today, let's do this other thing instead that happns to match mutter's internal api"
16:12 emersion: to expand on that EGLDevice idea: it could be something like eglQueryDeviceAttribEXT(dev, EGL_DEVICE_TYPE, &type)
16:57 imirkin: anyone else have issues connecting to google? e.g. 8.8.8.8 or www.google.com? i'm seeing crazy ping times, checking to see if it's just me
16:58 emersion: https://github.com/KhronosGroup/EGL-Registry/pull/121
16:59 bl4ckb0ne: imirkin: pings good here (canada)
16:59 HdkR: imirkin: Pings are 4ms here in California
16:59 imirkin: i'm seeing 200+ and dropped packets from nyc
17:00 bl4ckb0ne: 8ms on my side
17:01 imirkin: (and other things are fine, so it's not just me being totally hosed)
17:01 emersion: fun fact: "1.1" is a valid IP address, if you want to save 4 keystrokes
17:01 emersion: (pings cloudflare)
17:15 dcbaker: hakzsam, dschuermann: I've been meaning to replace the `cc: <mesa-stable` tag with just a `stable: X.y X.y` tag. I 'll get those pulled as well
17:16 dschuermann: dcbaker: yeah, I've been quite confused about the many(?) different ways to write that
17:17 dcbaker: originally there was a stable mailing list where all patches for stable went, but then patches got pulled into the stable tree that got rejected from the main tree
17:17 dcbaker: Emil added support for fixes (which is awesome)
17:18 dcbaker: I think it might be time to just kill the stable list
17:31 imirkin: aha. not just me. https://www.washingtonpost.com/technology/2021/01/26/internet-outage-east-coast/
18:01 xexaxo1: dcbaker: you're welcome (re fixes)
18:02 xexaxo1: one moot point on "stable:" is that the developer has to know which stable branches are active and affected.
18:03 dcbaker: I think that's a feature, because half the time CC: stable is just used to blindly throw things backwards without checking that they apply or are needed
18:03 xexaxo1: "apply" or "suitable"?
18:04 dcbaker: both
18:04 dcbaker: It feels like, especially toward the end of the cycle, CC patches always carry me finding all the patches that patch depends on and pulling them in too
18:04 xexaxo1: in my experience the latter was very unlikely.
18:05 dcbaker: s/carry/mean
18:05 xexaxo1: I can see your goal here. Not sure if it'll pan as you expect.
18:05 dcbaker: I don't konw either, it's the fun of developing human facing software! :)
18:06 xexaxo1: program the programmers :-P
18:07 xexaxo1: emersion: your MR seems to be missing the spec itself. is that intentional or forgot to git add?
18:07 kisak: there used to be a window of days/weeks where a pull request is marked cc: XX.Y mesa-stable and didn't get updated right after a new release branchpoint and things got missed because it doesn't instantly soak in that a new release has started. That's not as common in recent history
18:08 dcbaker: From my point of view `fixes:` is infinitely better, I have a script that handles that and it basically just works (there's a few annoying corners I need to fix)
18:09 emersion: xexaxo1: no, i wanted to get feedback before typing the spec text (see PR description). if this is likely to be accepted, i'll reserve the ext and write the spec text.
18:09 xexaxo1: dcbaker: yup, that's why I borrowed it from the kernel ;-)
18:14 xexaxo1: emersion: is one to eglQueryDeviceAttribEXT() on a device from eglQueryDevicesEXT(), eglQueryDisplayAttribEXT() or both?
18:14 emersion: any EGLDevice should work
18:15 xexaxo1: using eglQueryDisplayAttribEXT() should be fine, but for eglQueryDevicesEXT() one needs a ton of work (for mesa) or we'll just lie ... badly
18:16 emersion: hm, shouldn't libglvnd relay the eglQueryDisplayAttribEXT call to the right driver?
18:16 xexaxo1: vendors can implement this trivially if they choose to.
18:17 emersion: hm, no, i mean the eglQueryDeviceAttribEXT call
18:17 xexaxo1: you know the driver at eglInitialize time and not before.
18:18 xexaxo1: one can guess, but that would be hit and miss experience.
18:18 emersion: so anything using eglQueryDevicesEXT should be driver-agnostic in mesa?
18:18 xexaxo1: not sure I get that.
18:19 ajax: hrmph, compilers. i get warnings at -Og that i don't get at -O2.
18:20 emersion: oh, but wait. we have EGL_MESA_device_software
18:20 emersion: ohhh, that's exactly what i want
18:22 ajax: wonder if we shouldn't set -Doptimization=g in one of the -Werror builds in CI
18:22 xexaxo1: emersion: so you want to use or exclude software drivers?
18:22 emersion: i want to detect them and exclude them
18:23 xexaxo1: the software device is always at the end of the list - if the user asked for all.
18:23 emersion: should i just eglQueryDeviceStringEXT(EGL_EXTENSIONS) and match EGL_MESA_device_software, to detect a software device?
18:23 xexaxo1: plus you currently cannot get away from the "oops the HW driver failed, trying swrast" scenario
18:23 daniels: emersion: there's no guarantee that if you allocate on one, it will successfully import on the other; the only guaranteed path is if you use GBM, which has specific glue to make this work
18:24 xexaxo1: emersion: from memory - yes that should do it.
18:24 emersion: cool
18:24 xexaxo1: daniels: we could finish the specific egl device/display combo ajax started.
18:25 emersion: daniels: and i need to create the gbm_device on the primary node?
18:25 anholt: apologies to everyone who's had freedreno flakiness marging this last week. adding piglit really destabilized things, we should restabilize a bunch with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8722
18:25 daniels: xexaxo1: totally
18:25 daniels: emersion: yep
18:25 emersion: ok
18:25 xexaxo1: think the Nvidia folks were finally on board, there was some inflexible proposal/additions initially.
18:25 emersion: xexaxo1: what is the "specific egl device/display combo"?
18:26 xexaxo1: emersion: https://github.com/KhronosGroup/EGL-Registry/pull/23
18:26 anholt: (turns out the work I did stabilizing it became moot when we had to work around piglit's process-isolation-false being unusable)
18:26 emersion: ah, nice
18:27 ajax: anholt: ugh, whackamole sucks
18:28 xexaxo1: emersion: the Nvidia devs were asking for extra API listing the driver/native_platform combination ahead of eglInitalize time.
18:28 xexaxo1: emersion: which as said before isn't quite possible. and even if implemented would be rather slow/buggy
18:29 emersion: xexaxo1: hm, but mesa's platform support doesn't depend on the driver, or does it?
18:29 anholt: ajax: the good news is it's pointing at some important weaknesses in our driver (deqp testing of clip planes is poor, piglit helps), but it has not been fun.
18:30 hakzsam: what should I do about https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6897629 ? arm64_a630_piglit_shader
18:30 anholt: hakzsam: restart the job, reassign to marge.
18:30 xexaxo1: emersion: it did last time I've looked.
18:31 hakzsam: anholt: I did that one time, those are flakes?
18:31 anholt: I've added it to our tracker.
18:31 emersion: ok, maybe i'm just confused and there's a gallium/classic split or something
18:31 anholt: hakzsam: yes. some clip stuff is flaky when run in parallel, and the fix to avoid piglit's process isolation bugs means we're running more clip tests now.
18:32 hakzsam: okay, let me try again
19:18 robert_mader: Hi there. Getting a bit lost in mesa source code, thus trying it here: is there any reasonable chance that the r600 driver returns a wrong result when calling `glGetString(GL_RENDERER)` on EGL? Specificly returning "llvmpipe", while on GLX returning "AMD JUNIPER ..."?
19:19 robert_mader: I mean without actually using llvmpipe
19:22 robert_mader: Unfortunately I don't have the hardware to test, thus would be super grateful if anyone here could give me a hint if there's any difference in the implementation (I presume not much?) or even had the hardware to test it.
19:26 anholt: you're just loading a software driver. EGL_LOG_LEVEL=debug may help you figure out why, but egl's pretty bad at driver setup debug.
19:29 robert_mader: alright, so I assume there's little chance of mesa-internal confusion here.
19:29 anholt: none that I can think of
19:29 anholt: but something leading to load a swrast driver is very, very likely.
19:31 robert_mader: thanks
20:18 airlied: jekstrand: you likely want someone with more python reviewing that MR than me, though I can give it a go :-P
20:33 jekstrand: airlied: lol
20:34 jekstrand: airlied: I'm not super worried about the python part. Mostly about the C it generates.
20:34 jekstrand: airlied: That said, I also think that several people porting their drivers without problems gives pretty solid evidence that the code generates something mostly corret.
20:54 ajax: https://tiny.distro.builders/workload-dependencies--sst_graphics_infrastructure-codecs--fedora-empty-base--repository-fedora-eln--x86_64.html
20:54 ajax: ^ why is vorbis-tools listed as a dependency, of nothing?
20:55 anholt: for anyone else who has as much of a branching problem as I do: https://coderwall.com/p/jhucga/git-the-last-10-branches-you-ve-worked-on
20:55 jekstrand:doesn't understand the great mysteries of package management.
20:55 ajax: erk, wrong channel entirely
20:56 jekstrand: anholt: I'm not sure 10 is enough. 🙃
21:36 zackr: ajax: do you guys remove the .modinfo section on your xorg drivers? vmware_drv.so on fedora seems to be missing the .modinfo section (i just noticed that while trying to get a version number from that binary)
21:42 kisak: airlied: mildly dumb question, why do I regularly see "Skipping Vulkan 1.0 adapter: llvmpipe (LLVM 11.0.1, 256 bits)" lines in Proton logs instead lavapipe as the adaptor name?
21:43 cmarcelo: dcbaker: I noticed that only the first patch from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8706/commits appeared in staging/20.3, I think both should be there, not sure if it is ongoing or was not picked up by the scripts.
21:43 bnieuwenhuizen: kisak: random guess, still using the wine dxgi which uses GL?
21:44 bnieuwenhuizen: IIRC the dxvk dxgi isn't default yet
21:46 kisak: dxvk was the default for Proton until vkd3d integration started
21:49 kisak: I suppose it doesn't hurt anything to be a near miss for naming.
21:49 ajax: zackr: not explicitly, but the debuginfo stripping code might do that
21:52 bnieuwenhuizen: kisak: AFAIU has a d3d9/10/11 impl which is the default in proton. it also has a dxgi implementation but that is not default in proton
21:52 bnieuwenhuizen: (and vkd3d-proton just uses the dxvk or wine implementation of dxgi)
21:53 kisak: right, I understood what you ment with dxvk's dxgi vs wine's dxgi, and I do recall that wine's dxgi is opengl-oriented
22:30 idr: robclark: I have a question about nir_lower_amul... and I guess maybe the imul24 instruction.
22:30 robclark: sure
22:30 idr: Does the result of that instruction have to fit in 24 bits or do just the sources have to fit?
22:31 robclark: iirc it ignore the top 8b of the srcs
22:31 idr: But it produces a full 32-bit result?
22:31 robclark: I believe so.. maybe I wrote some notes somewhere
22:32 robclark: yeah, it has to be 32b result, because sign extension
22:32 idr: Shouldn't that pass look at the length of the array?
22:32 idr: It looks like it only cares about the size of the elements in the array.
22:32 robclark: I believe it does.. or at least was meant to
22:33 robclark:needs to look at it again
22:33 idr: There's an unused max_slot field in lower_state... maybe that was used for that purpose?
22:34 robclark: err, hmm..
22:35 robclark: I guess for arrays, you just need to know that the element size and array length are both less than 24b
22:40 idr: So... I bet if we made a test with a UBO containing `vec4 x[0x1000001];` and `x[0x1000000] == expected`, it would access element 0 instead.
22:42 robclark: I guess we should be looking at the array length if it is known.. we aren't considering that the array index could be > 24b
22:42 idr: That was my thought.
22:43 anholt: hmm. 72-threaded virgl deqp on top of radeonsi was perhaps ill-advised.
22:43 idr: Looking at the places that can generate amul, it seems like the element size is always a constant.
22:46 imirkin: anholt: you probably know this already, but i wouldn't advise it on top of nouveau either :)
22:54 mattst88: jekstrand: do you have an opinion on where code that would change the tex coord src on a tex operation to half-float should go?
22:54 robclark: mattst88: it shouldn't be the tex coord, but the samp/tex args
22:55 mattst88: e.g., say I've got vec2(f2f32(a@16), f2f32(b@16)), and I want to just feed the half-float (a, b) coords directly into the tex
22:55 robclark: (err, well, I guess the coord could be fp16, but only sapm/tex must be)
22:59 mattst88: robclark: ah, okay. I'm looking at shaders/glmark/25-2.shader_test FWIW
23:00 anholt: robclark: pretty sure we're talking about the tex coord here.
23:00 robclark: ok.. glmark is pretty sloppy about precision, and probably just using mediump everywhere, even when it shouldn't
23:00 anholt: the glmark mediump's been significantly fixed up
23:00 mattst88: maybe I'm misreading the assembly, but it looks like after ir3_cf() the texture ops are consuming 16-bit tex coords
23:00 robclark: anholt: oh, ok.. I originally thought it was just samp/tex
23:00 anholt: the issue is that at the glsl/nir level we suck at actually using mediump everywhere.
23:01 robclark: I have some 3dmark shaders which I *think* should end up using a lot more fp16 than they do, fwiw
23:03 mattst88: jekstrand: I'd think nir_opt_copy_propagate.c is the right place, but I would kind of hate to foul up the copy_prop_src helper with tex-specific stuff
23:06 anholt: mattst88: I think I'd be tempted to put it in a new pass. it'll want to do image intrinsic coordinates too, I think.
23:06 mattst88: anholt: yeah, that's a nice idea
23:29 airlied: kisak: currently lavapipe in theory could support non-llvmpipe backends (like swr) so llvmpipe ends up in the name, but maybe I should just call it lavapipe and change it the backendi s different
23:32 kisak: ah cool, by design and not an error is fine by me