01:11 <imirkin> how does textureOffset work, esp in the context of linear filter and/or mipfilter?

01:13 <imirkin> or is this one of those "don't do that" situations?

02:31 <mareko> it's just added to the final integer coordinates

02:37 <HdkR> Also fun that the spec mandates offset be constants while the Nvidia blob just happily consumes non-constant :P

02:52 <imirkin> mareko: final integer coordinates of what?

02:53 <imirkin> if you have e.g. miplinear interp, you're going to have "integer" coordinates from multiple levels

02:53 <imirkin> does that mean that +1 is applied in both levels (and in level N+1, a +1 is effectively a +2 in level N)?

03:00 <jenatali> imirkin: Yeah, pretty much

03:00 <imirkin> so it'll end up filtering together things which make no sense

03:00 <imirkin> aka "don't do that"? :)

03:15 <jenatali> Yeah, I seem to recall getting asked to document recently that doing fixed offset + mip filtering doesn't make any sense

03:21 <anholt_> Venemo: so, collabora's lab has been having some trouble with overloaded dispatchers which should be resolved soon. your run had a series of timeouts, likely due to the nfs not responding, then eventually one of your retry runs didn't even get as far as saying it was starting a test (again, probably nfs), so deqp-runner decided things were really busted.

03:25 <anholt_> I should probably throw a nicer error message when that first happens. making a note.

04:14 <imirkin> jenatali: ok. good to know i'm not crazy :)

05:44 <imirkin> does anyone know offhand if nir will generate texelFetch's for samplerBuffers with sampler == texture, or sampler == 0?

06:55 <Venemo> anholt_: thanks. Let me know when I can try again

19:00 <robclark> karolherbst: any idea where to get LLVMSPIRVLib 13.0 for f35? This was working before I upgraded.. hmm, but I guess it was using LLVMSPIRVLib 12.0 and the problem is now fedora has llvm 13 but not the matching LLVMSPIRVLib?

19:01 <karolherbst> robclark: I guess somebody forgot to update it

19:01 <karolherbst> I think airlied manages the package

19:02 <karolherbst> robclark: rawhide is on 13 though so you might get away by installing the rawhide version locally

19:02 <karolherbst> mhh although that is build afainst final, not rc1 ..

19:03 <robclark> hmm

19:03 <karolherbst> ehhh

19:03 <karolherbst> the translator is on 13 on the f35 branch...

19:03 <karolherbst> worst case build the rpm locally...

19:03 <karolherbst> git clone https://src.fedoraproject.org/rpms/spirv-llvm-translator.git

19:03 <karolherbst> git checkout f35

19:04 <karolherbst> fedpkg mockbuild

19:04 <karolherbst> but I guess it's in the pipeline somehwere

19:04 <karolherbst> update was on Tue Oct 26 17:16:39 2021 +0200 though

19:05 <karolherbst> maybe airlied indeed knows the answer here

19:06 <robclark> I suppose I should have waited a bit longer to update to f35.. I guess I can poke around to see if there is a build somewhere, or build it mysefl

19:06 <karolherbst> yeah.. just use fedpkg mockbuild for it

19:06 <karolherbst> it generates rpms

19:06 <karolherbst> and builds inside a chroot

19:07 <karolherbst> took like 5 minutes here

19:07 <karolherbst> well.. it's still in the progress but nearly done :D

19:07 <karolherbst> and then you can do "dnf upgrade *.rpm"

19:08 <karolherbst> or uhm.. install

19:08 <karolherbst> guess it ... ehh wait

19:09 <karolherbst> built it from the wrong branch

19:31 <robclark> karolherbst: that seems to have worked, thx

19:31 <karolherbst> np

19:43 <robclark> hmm, swr ofc doesn't build w/ llvm.. although I guess there is an easy solution there..

20:19 <airlied> robclark: should be in updates-testing

20:23 <robclark> oh, hmm.. yeah, I guess I don't have updates-testing enabled

20:24 <airlied> yeah just do a one off

20:24 <airlied> sudo dnf --enablerepo=updates-testing upgrade spirv-llvm-translator

20:27 <robclark> I already made a mock build, which should hold me over until it lands in main repo

21:00 <airlied> danvet: fyi linus reply to my last PR

22:49 <imirkin> anholt_: "ERROR - Failure getting run results: parsing results: Reading from dEQP: timed out waiting for fd to be ready" -- this is over nfs. any way to increase timeout? i've gotten that a couple times, the qpa file itself is fine.

23:44 <mareko> imirkin: buffers and images don't have a sampler state (it wouldn't have any effect), only tex,txb,txl,txd,lod,tg4 use it

23:45 <imirkin> mareko: that doesn't prevent the hardware from exploding

23:45 <mareko> let's call them hw bugs

23:45 <imirkin> sure.

23:46 <imirkin> still means i have to sort it out.

23:46 <imirkin> probably forcing sampler -> for such ops would be the most reliable thing to do

23:46 <imirkin> sampler -> 0

23:46 <mareko> there are many cases like that which drivers have to work around, nothing new

23:46 <imirkin> yes.

23:47 <imirkin> i wasn't asking "why is there no sampler uploaded"

23:47 <imirkin> i was asking what the expected nir behavior was.