<mupuf>
that being said, a warn from an atomic *commit* should never be allowed. Atomic check are supposed to detect all potential issues and fail. Warning is never allowed. agd5f, any idea where this may come from, before I file a bug? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/11595246#L2596
<xcube>
imirkin: I set the window resolution to 512, 512 and it 'fixes' my problem.
<imirkin>
yeah, i sorta figured it might be a NPOT-related issue, but couldn't really figure out how in my head
<xcube>
I still need to get the average value and use it in a fragment shader somehow. I know that the proprietary drivers for windows don't have this bug, but I have not tried the proprietary linux driver.
drawat has joined #dri-devel
<xcube>
Fixing that bug would likely provide better mipmap quality even below the max levels from what I observed. I will add a comment to that issue report when I have time.
<imirkin>
doesn't seem like a bug necessarily. i think it's within the spec.
<xcube>
I know the shaderpack I am fixing was written for drivers that are very friendly to broken opengl code (all the hacks that Nvidia puts in there drivers for example).
<xcube>
A side by side comparison of mipmap levels from a 512x512 image vs the same image with a tiny bit sliced off making it 511x511 might be interesting to look at (might be a better example than the code posted in the issue).
gpoo has quit [Quit: Leaving]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
danvet has joined #dri-devel
sravn has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
i-garrison has quit [Read error: No route to host]
i-garrison has joined #dri-devel
Duke`` has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
adjtm has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
hch12907 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
NiksDev has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
pekkari has joined #dri-devel
gouchi has joined #dri-devel
rasterman has joined #dri-devel
aigleroy881 has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
pcercuei has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
adjtm has joined #dri-devel
anujp has joined #dri-devel
GreatGodvin has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
GreatGodvin has quit [Quit: WeeChat 3.2]
aigleroy881 has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
<ishitatsuyuki>
does cache hit reduce VMEM load latencies? I thought it did, but then I remembered that "VMEM loads return in the order they were issued" so that would mean the latency won't change
<jekstrand>
If they all hit, they're all faster
<ishitatsuyuki>
I see
<jekstrand>
And "order they were issued" can be a funny thing. What spec are you reading?
<ishitatsuyuki>
AMD RDNA ISA?
<ishitatsuyuki>
Section 4.4 "VMEM loads return in the order they were issued, but loads and stores are unordered
<ishitatsuyuki>
with each other"
<jekstrand>
I might be missing what VMEM means in this case
<ishitatsuyuki>
vector memory, everything about (divergent) image loads and buffer loads
<jekstrand>
Right, so that's going to be only with respect to a single thread, I think.
<jekstrand>
You need those sorts of ordering guarantees in order to write non-racy software
<ishitatsuyuki>
single warp/wavefront, you mean?
<jekstrand>
Yeah, probably
<ishitatsuyuki>
guess you're right
<jekstrand>
They compiler may be able to re-order things but if you've got hardware re-ordering reads behind your back, things get nasty fast.
<ishitatsuyuki>
on Rust for Vulkan: does that involve integrating Rust into Mesa?
<jekstrand>
Probably
<jekstrand>
I didn't say it was easy, yet. :) Just more plausible than it used to be.
<ishitatsuyuki>
coincidentally I'm also working on something that uses a Rust crate inside the NIR optimizer
<glennk>
rusts "abi" scares me a little
<jekstrand>
glennk: What ABI?
<ishitatsuyuki>
it's still prototype so I just manually put the object files together but I wonder what would be the way forward with meson integration
<ishitatsuyuki>
glennk: C ABI is used for linking/FFI
<jekstrand>
ishitatsuyuki: meson+rust is a hard problem.
<ishitatsuyuki>
yeah
<jekstrand>
It's one of the top 3 things that makes me not want to write Rust code in Mesa
<ishitatsuyuki>
I saw the previous effort last year and realized nobody have a solution yet
<ishitatsuyuki>
it has got so much potential for extra optimizations so I want to try that regardless of whether integrating Rust works
<glennk>
jekstrand, exactly, what happens if the app has linked in one version and mesa another? i don't think rust has anything defined to handle that, it mostly assumes everything is linked into a single blob, or at least did last i checked :-)
<jekstrand>
glennk: I don't know
<ishitatsuyuki>
one version of what? like libc?
<glennk>
one thing i think would make sense would be running the shader compiler in a separate service process, that can be written in rust
<ishitatsuyuki>
using IPC might be OK but probably is wasteful of resources
<ishitatsuyuki>
libc is dynamically linked anyway so it's no problem
<ishitatsuyuki>
the only case where linkage can cause trouble is when globals are involved, but outside of libc that's rarely an issue
<ishitatsuyuki>
Cargo would happily link multiple versions of a crate anyway, so I don't really think the static-link-everything design would cause trouble
<glennk>
i'm not sure what happens across .so boundaries when different versions of the same crate are used, or even different versions of rust are mixed
<ishitatsuyuki>
as long as they don't have the chance to interfere with each other, it's fine
<ishitatsuyuki>
I'm assuming that they won't because any calls between the two should be done in C ABI with well defined compatibility
<ishitatsuyuki>
and also globals and libc are not issue as I said above
camus1 has quit []
pekkari has quit [Ping timeout: 480 seconds]
pekkari has joined #dri-devel
adjtm has joined #dri-devel
nsneck has joined #dri-devel
heat has quit [Quit: Leaving]
heat has joined #dri-devel
<orbea>
glennk: the way distros like fedora and debian package every crate as a system version makes multiple versions of the same crate seem execeptionally painful
nsneck has quit [Remote host closed the connection]
nsneck has joined #dri-devel
karolherbst_ has joined #dri-devel
mbrost has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: Quitting]
anujp has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
aigleroy881 has joined #dri-devel
sdutt has joined #dri-devel
Guest1160 has joined #dri-devel
gouchi has quit [Remote host closed the connection]
aigleroy881 has quit [Ping timeout: 480 seconds]
pekkari has quit [Quit: Konversation terminated!]
sdutt has quit [Remote host closed the connection]
karolherbst_ is now known as karolherbst
phomes has quit [Quit: Page closed]
sdutt has joined #dri-devel
mlankhorst has joined #dri-devel
sdutt has quit [Remote host closed the connection]