ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
heat has quit [Quit: Leaving]
heat has joined #dri-devel
<airlied>
hmm got a black wayland windows, where's my lvp cube output :-P
<zmike>
turn up your brightness
<airlied>
ah helps if you memcpy the right direction
Lightkey has quit [Ping timeout: 480 seconds]
<imirkin>
it should be able to auto-detect that...
<airlied>
yay lvp wayland support, if anyone from RH asks, I wrote it years ago
Lightkey has joined #dri-devel
<alyssa>
imirkin: Oh, even more lovely. Just cancel out the bugs
<alyssa>
I wouldn't be surprised if there's a bit controlling the orientation but I don't have a way to test any GL newer than GL1.1 yet.
<alyssa>
(and figuring out how to do point sprites on gl1 wasn't really appealing)
<imirkin>
alyssa: ok. there's also a GL_ARB_clip_control which allows flipping the origin
<imirkin>
alyssa: and a GL_MESA_something_cool which also allows it
<alyssa>
Yep yep.
<imirkin>
(in gles)
<alyssa>
At this point I'm content to do NIR lowerings to make gallium's conventions into metal's
<imirkin>
alyssa: yeah, i mean that's fine. esp to get going.
<alyssa>
and once everything is conformant and i can worry about optimization, poke at the GL driver to see which lowerings can go away
<imirkin>
just don't blame opengl :p
<alyssa>
(I know there's a [-1, 1] z bit somewhere but lower_halfz was easier)
<alyssa>
nah, when it comes to coordinate systems, it's always GL's fault
<imirkin>
mmmm ... how can you lower that?
<alyssa>
especially if things are upside down
<imirkin>
oh, if you don't support clamping i guess it's fine
<imirkin>
or you can just adjust it in the shader? hmmm
<alyssa>
zink uses it?
<alyssa>
zmike: if it's broken, that's on you since you told me Zink was a GL4.7 and ES3.3 driver zomg
<imirkin>
it might be fine. i always get super-confused by this stuff.
<zmike>
what
<zmike>
don't clamp me bruh
<zmike>
if you're copying zink halfz stuff you at least are at a good point in time to be doing it since that's all vaguely readable now
<alyssa>
@zmike
<alyssa>
i mean
<alyssa>
clamp(zmike, 0.0, 1.0)
<imirkin>
no, you're supposed to clamp depth at the fragment level
lmk has joined #dri-devel
<imirkin>
see GL_ARB_depth_clip
<zmike>
0.21 .041 0 0.783
<imirkin>
(which, amusingly, introduces clamping. who names these things...)
lmk has quit []
<alyssa>
incredible
<alyssa>
the zink thing does the transform on the VS output, not the FS input
<alyssa>
(better question is - does that break gl_FragCoord.z? dunno works for me)
<imirkin>
the thing is ... usually this stuff doesn't get tested together
<imirkin>
so it's easy to think some stuff is ok when it actually isn't :)
<imirkin>
but it might actually be fine to just adjust coords in shader, and rely on the usual clamping stuff
<icecream95>
The extension is GL_ARB_depth_clamp, but don't remind me about it, I'm supposed to be doing other things than making it conformant on Panfrost
<imirkin>
oh, seriously? i just misremembered and thought the name was dumb? heh
<imirkin>
my bad.
<imirkin>
yeah. oops :)
<alyssa>
in fairness to you OpenGL names are often dumb
<imirkin>
it felt like a fair assumption
<imirkin>
i guess it's the gallium api which is silly
<imirkin>
since the way clamping is indicated is with clip = false
camus has joined #dri-devel
<icecream95>
(Panfrost doesn't handle interactions between depth clamp and depth range, so it only works if the depth range is [0, 1]. Maybe it's also broken for floating-point depth buffers)
<imirkin>
NV supports arbitrary depth buffers, which makes it even more confusing
<imirkin>
we didn't expose this in mesa
<imirkin>
i think depth remains the bit of GL which has resisted my understanding it.
FLHerne_ has joined #dri-devel
FLHerne has quit [Read error: Connection reset by peer]
boistordu_ex has joined #dri-devel
<xcube>
imirkin: It turns out that the software fallback _mesa_generate_mipmap() actually works with all texture/screen sizes, however util_gen_mipmap() (that uses blit) and hardware mipmapping with pipe->generate_mipmap() do not. I feel like this might go beyond the NPOT issue I mentioned the other day.
<xcube>
Some resolutions do seem to have more effect than others. Some NPOT resolutions are actually ok.
adjtm has joined #dri-devel
<xcube>
It looks like even pipe->generate_mipmap() uses a similar looking blitter algorithm.
<xcube>
I got everything running in a C debugger to help figure this all out.
Akari has joined #dri-devel
<xcube>
Can anyone tell me what the nr_samples argument of blitter_get_fs_texfetch_depth() is (its in src/gallium/auxiliary/util/u_blitter.c)?
ppascher has joined #dri-devel
gpoo has quit [Ping timeout: 480 seconds]
NiksDev has quit [Ping timeout: 480 seconds]
<airlied>
xcube: for a multisample depth buffer
gpoo has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
gpoo has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
I have a loop like `for (uint i = 1; i < 4; i *= 2) { ...}` but it's failing to unroll. Any idea why?
sdutt has joined #dri-devel
Duke`` has joined #dri-devel
itoral has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
Hi-Angel has joined #dri-devel
tzimmermann has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
frieder has joined #dri-devel
frieder_ has joined #dri-devel
danvet has joined #dri-devel
<zzag>
how can a compositor measure how long it took to transfer a buffer from one gpu to another using dma-buf? it's a broad question in general as there are many ways to upload data from one gpu to another, e.g. read pixel data on the source gpu and upload to a texture or dumb buffer on the sink gpu, but I wonder about the case where dmabufs are used
<zzag>
MrCooper: can you please explain how !1762 works? I don't think that I follow. It seems like a texture is created before flipping buffers. Why does that produce the desired results? and how does that actually work? it looks like black magic to be honest :D
<MrCooper>
it binds the client buffer as the EGL draw buffer, then emits a timestamp query, which records the time when the GPU finishes drawing to the buffer
<pq>
MrCooper, is it actually guaranteed by anything that the query records the time when the GPU finishes the *client* drawing?
<pq>
MrCooper, what stops a gfx driver from actually submitting a new render job that only queries the current GPU timestamp instead of re-using the latest actual drawing on the buffer?
tursulin has joined #dri-devel
<pq>
zzag, also, weston's 7 ms repaint-window default value is just "err... maybe something near the middle of a 60 Hz refresh cycle might be nice? who knows." - so out of a hat.
<zzag>
pq: kwin has two sources for render times - the config and the previous render times. in the config, user can specify the preferred latency values. by default, it's somewhere in the middle of the vblank internal + safety margin
<MrCooper>
pq: conceptually, the timestamp query is part of the command stream similar to drawing commands, so it should be subject to the same synchronization
<HdkR>
7ms? That's at least better than Android's full frame default value. So 16ms on a 60hz display :P
<pq>
I thought it's completely driver and hardware specific of what the timestamp query will return, if you query without actually drawing anything.
<pq>
MrCooper, so you might get the timestamp of when the client rendering finished, or it might create a new command submission which will record the time of whenever that finishes.
rsalvaterra_ has quit []
<pq>
in between, there might be delay or not
rsalvaterra has joined #dri-devel
<MrCooper>
that's fine I think, it gives us "finished no later than"
<pq>
ok
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
lynxeye has quit []
<pendingchaos>
ishitatsuyuki: I don't think NIR can unroll loops which don't use addition to increase "i" at the moment
<pendingchaos>
there was a MR somewhere to improve this, I think
<dschuermann>
I can test how it affects other applications, but probably not before Thursday because of the upcoming branch point
<ishitatsuyuki>
thanks, works
<pq>
so... by tradition of KMS properties, when Weston sets up HDR_OUTPUT_METADATA, it should not unset it on its way out? :-p
<mriesch>
hi danvet + agd5f_ and all, still dealing with the hpd issue of the rockchip dw_hdmi. hardware setup seems to be ok as i am able to detect cable plug events using the pre-installed sdk on the eval board.
frieder has joined #dri-devel
frieder_ has quit [Remote host closed the connection]
<mriesch>
it seems that the chip is not configured to report its hpd status (always returns disconnected) at driver startup. then, the edid can not be read and the modesets are empty. as a consequence, i cannot set a certain mode and power up the chip (which would enable hpd). catch 22?!
<mriesch>
so just to clarify: the chip should enable hpd right from the start without any command from user space or similar?
Ahuj has quit [Ping timeout: 480 seconds]
itoral has quit []
<karolherbst>
why does llvm always have to be a world full of joy?
<HdkR>
That's one way to think about it
<karolherbst>
installed llvm-12-dev from the official apt repo..
<karolherbst>
"Looking for a fallback subproject for the dependency llvm (modules: bitwriter, engine, mcdisassembler, mcjit, core, executionengine, scalaropts, transformutils, instcombine, native)"
<karolherbst>
*sigh*
<ishitatsuyuki>
hakzsam: sqtt works only if I override reserve_vmid to true (https://paste.rs/hWk), otherwise the trace contains no data (400KB vs 19MB expected). any idea why? prior version of mesa also seems to be affected
<ishitatsuyuki>
the oldest kernel I could get to was 5.10.49-1-lts, which gives the same behavior
<karolherbst>
they should just fix their build system.. and everything
<ishitatsuyuki>
(continuing from above) the reason I'm asking is because I had SQTT working fine back in March, with release versions of mesa
<karolherbst>
HdkR: I also have to install libllvm12.....
<karolherbst>
because the dev package alone isn't enough....
<karolherbst>
MrCooper: apt breaks because I install a cross llvm and python has to match
<karolherbst>
but at least after getting everything installed it does work
<MrCooper>
karolherbst: broken LLVM packages, not APT's fault
<karolherbst>
I use debians packages now :)
<steev>
what cross llvm package are you installing?
<karolherbst>
for s390x
<MrCooper>
karolherbst: yes, Debian's LLVM packages are broken like that
<karolherbst>
then I blame debian :)
<karolherbst>
heck
<MrCooper>
the -dev packages spuriously require python3 from the same architecture
<karolherbst>
I even install python3:s390x
<karolherbst>
it still messes up
<MrCooper>
karolherbst: see .gitlab-ci/container/cross_build.sh for how I worked around it for Mesa's CI
<karolherbst>
yeah I saw that one
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<MrCooper>
karolherbst: installing python3 from a foreign architecture can't work due to other package dependency issues
<karolherbst>
uhhhh
<karolherbst>
MrCooper: installing python3-mako is the problem...
<karolherbst>
it reverts back to native python and removes llvm...
<MrCooper>
yep
<karolherbst>
this worked with the llvm apt repo :)
<MrCooper>
somebody should file a bug against llvm-11-tools
<karolherbst>
I am not using tools
<MrCooper>
it's a dependency of -dev, which depends on python3
<MrCooper>
that is what needs to be changed to allow for python3 to be from a different architecture than the llvm-11-tools one
<karolherbst>
MrCooper: doesn't get pulled in for me
<MrCooper>
presumably you have llvm-12-tools
<karolherbst>
nope
<karolherbst>
but at least the package site says dev depends on tools
<karolherbst>
maybe I didn't check correctly
<MrCooper>
sounds like it
pochu has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
vivijim has joined #dri-devel
<karolherbst>
MrCooper: *sigh*.. why does apt require to install python3-markupsafe:native even though python3-markupsafe:s390x is installed.. is there no way to enfore using whatever there is already?
<MrCooper>
nope, it's up to the package dependencies
<MrCooper>
packages have to explicitly allow dependencies from different architectures
robert_mader has joined #dri-devel
robert_mader has quit []
bbrezillon has joined #dri-devel
<MrCooper>
hmm or maybe the dependencies need to declare they can be used on other architectures
<danvet>
tzimmermann, I have a patch for drm-misc-fixes, can you forward to -rc1?
<danvet>
or is it someone else for this release
* danvet
never keeps track
<danvet>
tzimmermann, [PATCH 1/1] fbmem: Do not delete the mode that is still in use <- or maybe just apply this one, it has my r-b
alyssa has left #dri-devel [#dri-devel]
<xcube>
What is the 'use_txf' parameter of blitter_get_fs_texfetch_col() in src/gallium/auxiliary/util/u_blitter.c?
<robclark>
txf == texelFetch()
<xcube>
I am still trying to figure out why the blitter would give different results vs the software fallback when generating mipmaps on radeonsi. (ultimately the smallest mipmap needs to be close to the average texel value)
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
frieder has quit [Ping timeout: 480 seconds]
<xcube>
robclark: Where is texelFetch()?
<xcube>
robclark: I might be onto it... I just found where the fragment shader is generated
<xcube>
Somehow TGSI_INTERPOLATE_LINEAR is not so linear for some resolutions (at least that is my theory so far).
anujp has joined #dri-devel
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
<kusma>
Seems the panfrost CI is so slow ATM that MRs that trigger the panfrost stuff makes Marge give up before it has a chance to complete...
sdutt has joined #dri-devel
<robclark>
kusma: is one of the jobs hung / timing out?
<kusma>
robclark: doesn't seem like it... there's just not any runners that pick them up, I think?
<jekstrand>
kusma: Looks like we caught a dxil_lower_sample_to_txf_for_integer_tex
<jekstrand>
bug, then. :D
<kusma>
Yep
<kusma>
Seems nobody filled in coord_components?
<jekstrand>
Probably
<jekstrand>
Or filled it in wrong
<jekstrand>
kusma: That seems like something that could have gone in nir_lower_tex, FYI.
<jekstrand>
Seems general enough.
<kusma>
jekstrand: sure
<jekstrand>
Ugh... That thing's more complicated than it looks....
<jekstrand>
You have to deal with border color manually? Yuck!
<jekstrand>
Ok, never mind. Probably not a candidate for nir_lower_tex without good reason. :-/
<kusma>
:)
<zmike>
I'm sure we'd be more than happy to gross-ify your pristine nir passes if that's what you really want
<jekstrand>
Can D3D not sample on integer textures? Crazy.
<jenatali>
Not yet, at least. It's on my list of things we probably need to revisit
<jekstrand>
I don't know that it's all that useful, honestly.
<kusma>
jekstrand: Yeah, all the filtering texturing opcodes return floats :/
<jekstrand>
It's just surprising that we've all built hardware for it which games aparently don't need.
<kusma>
jekstrand: I don't think you actually add any notable gates that you didn't already need for txf
<jekstrand>
kusma: Maybe. A few to smash to NEAREST for integer formats but that's probably about it.
<jenatali>
D3D also can't do non-normalized coordinate sampling
<bnieuwenhuizen>
now I wonder if our HW does it correct because you just take NEAREST or what it will do when you do LINEAR filtering on a integer texture
<bnieuwenhuizen>
jekstrand: I presume the driver can set NEAREST on integer textures :)
<jekstrand>
bnieuwenhuizen: If we have combined texture+sampler
<kusma>
I would expect bad things to happen if you tried to set non-nearest filtering
* jekstrand
looks at the Vulkan spec
<bnieuwenhuizen>
jekstrand: in vulkan linear isn't even supported for integer, no?
<kusma>
(to the HW, I mean)
<kusma>
Yeah, IIRC we smash to NEAREST in zink
<bnieuwenhuizen>
kusma: that calls for an experiment :P
<kusma>
bnieuwenhuizen: Sure. But I expect you'll effectively get garbage ;)
<kusma>
probably integers-interpreted-as-float in a partial computation or something ;)
<bnieuwenhuizen>
Could always be worse
<bnieuwenhuizen>
consider e.g. a GPU hang
<kusma>
Sure, but I would be surprised in that case
<jekstrand>
bnieuwenhuizen: I can't find any VUs about it
<jekstrand>
bnieuwenhuizen: Or anything in the texture operation validation section
<bnieuwenhuizen>
so are we now supposed to do linear interpolation rounded to the nearest integer? :o
<jekstrand>
I don't think so
<jekstrand>
Integer formats + VK_FILTER_LINEAR don't mix. I just don't remember what happens if the client tries to mix them.
<jekstrand>
In particular, can we "rm -rf /*" or are we supposed to just give you garbage texture data.
<kusma>
jekstrand: it looks like just copying coord_components from tex to txf is the right thing to do?
<jekstrand>
kusma: Yes except for cube, I think.
<jekstrand>
Well, no, cube should be right too
<kusma>
Uggh.
<kusma>
OK, good.
<jekstrand>
but cube array isn't
<jekstrand>
kusma: Really, it should be whatever number of coordinates you built if your pass is otherwise correct
<jekstrand>
VK spec question solved: Integer formats don't support VK_FORMAT_FEATURES_SAMPLED_IMAGE_FILTER_LINEAR_BIT
<jekstrand>
So it's invalid usage to combine them
<jekstrand>
So we can abort()
<bnieuwenhuizen>
jekstrand: where is the VU that we only can use it when that feature is exposed for the format?
<glennk>
xcube, what format is the texture you are calling GenerateMipmap on?
camus has quit []
camus has joined #dri-devel
<xcube>
glennk: PIPE_FORMAT_R16G16B16A16_UNORM
<tzimmermann>
danvet, it's me
gpoo has quit [Remote host closed the connection]
<xcube>
glennk: util_blitter_generate_mipmap() in u_blitter.c seems to be doing most of the work generating the mipmap levels. My guess is that something odd is going on in the fragment shader that generates/accumulates bed results, resulting in the final mipmap level (1x1 pixel) being far from average.
<Akari>
I'm trying to use Mesa as an OpenGL-to-D3D12 or OpenGL-to-Vulkan translation layer on Windows for my game (because windows drivers are terrible), with the d3d12 and zink gallium backends respectively. I managed to get it to build with the msvc toolchain, however creating a context fails. Seems like WGL offers no pixel formats at all. Is this supposed to work?
heat has quit [Ping timeout: 480 seconds]
<karolherbst>
Akari: you might want to ask jenatali
<xcube>
glennk: At a resolution of 487x467 the blitter mipmap algorithm seems to massively weight pixels in the center of the screen, however the software fallback works fine.
<jekstrand>
kusma: There's a helpful `glsl_get_sampler_dim_coordinate_components()` helper
tobiasjakobi has joined #dri-devel
mntmn has joined #dri-devel
mbrost has joined #dri-devel
camus1 has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
<jekstrand>
karolherbst: Any reason why nouveau doesn't use nir_lower_tex()?
camus has quit [Read error: Connection reset by peer]
tobiasjakobi has quit [Read error: Connection reset by peer]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Read error: Connection reset by peer]
tobiasjakobi has joined #dri-devel
<karolherbst>
jekstrand: because our custom lowering makes use of hw features nir can't express
<karolherbst>
especially all that texgrad on cube lowering
<karolherbst>
we could probably use it for some simplier things though
<karolherbst>
just that there is no direct benefit of doing so atm
<jekstrand>
TBF, projectors are the stupidest texture feature
<karolherbst>
jekstrand: ahhh :D
<karolherbst>
ah yeah.. that's fine
<karolherbst>
it just doesn't change much :D
<jekstrand>
karolherbst: Mind giving it a test? I can't
<karolherbst>
yeah. I will
<jekstrand>
Does anyone support projectors in hardware?
<karolherbst>
at least I don't see why any hw would want to
<jekstrand>
Looks like some qcom hardware does. Freedreno handles it. Weird.
camus has joined #dri-devel
<karolherbst>
sounds like wasted transistors, but okay
heat has joined #dri-devel
<jekstrand>
And Zink supports it, of course. 'cause why not make the Vulkan driver lower it. (-:
<karolherbst>
:D
<jekstrand>
Grepping for nir_tex_src_projector, it looks like it reall yis just freedreno that handles it interestingly.
<jekstrand>
D3D12 does something with it in a few of its lowering passes but, IMO, they should just reorder their lowering passes.
<jekstrand>
Or maybe we should get rid of it in glsl/spirv_to_nir?
<jekstrand>
robclark: Do you care about texture projectors?
camus1 has quit [Read error: Connection reset by peer]
<robclark>
jekstrand: yeah, depends a bit on generation, but we do use lower_txp
<jekstrand>
robclark: Would you be bothered if nir_tex_src_projector goes away?
<jekstrand>
robclark: And we unconditionally lower it?
<jekstrand>
ir3 is the only driver that does anything with it at all
<glennk>
xcube, i think it uses util_make_fragment_tex_shader_writemask unless you have a msaa or depth buffer
<robclark>
it looks like on a3xx, we only need to lower_txp for 3d textures.. but I suppose it wouldn't really be a problem to lower it unconditionally
<jekstrand>
is a3xx new or old?
<robclark>
pretty old
<robclark>
2nd gen adreno, first gen using ir3
<jekstrand>
Ok, so clearly qcom thought putting those gates in was a mistake. :)
<robclark>
yeah, I suppose it isn't common enough
<anholt>
jekstrand: i915 does projectors in HW!
<jekstrand>
anholt: *sigh* Given that HW's limitations, that's almost a reason to keep it. :-(
<anholt>
(we don't use that in i915g any more since nir-to-tgsi, and I need to sort that out at some point)
<glennk>
xcube, but i think i know whats going on now
<anholt>
I've started hacking on a native nir backend for i915g, because trying to get that HW to not gratuitously suck through TGSI is hard. I could probably just recognize texture projectors in the backend and do it myself.
<jekstrand>
That's a little annoying, though.
<anholt>
(for NTT and i915g, we really need to have a custom tex instr with 1 or 2 vec4s as arguments and a backend opcode, because trying to clean up the NIR from the separate coords, projectors, and LOD means you need vector coalescing in the backend)
<jekstrand>
Carrying the NIR feature isn't terrible. It just seemed useless but if we're going to continue caring about ancient HW like i915, it's probably worth it.
<anholt>
I'd be curious how people feel about a nir_tex_src for "lowered to some sort of driver-laid-out vec4 args"
<robclark>
anholt: combine that w/ >vec4 and it could be useful for ir3
<glennk>
xcube, the hardware has limited fixed point precision for sampling textures, so instead of exactly hitting the midway point between two texels its off by up to 1/(1<<GL_SUBPIXEL_BITS)
<jekstrand>
Maybe useful for older HW if they want to do NIR lowering.
<glennk>
xcube, the software algorithm simply averages pixels, no texture coordinate interpolation is done there
<jekstrand>
I don't think I'm interested in trying to do intel/fs lowering that way, though.
<glennk>
xcube, for a typical 8 bit precision color buffer the difference is pretty minimal, but for 16 bit it can accumulate enough to be noticeable
<anholt>
intel/vec4 would probably look a lot nicer.
<xcube>
glennk: I don't know if that explains why POT (power-of-two) resolutions work fine. I think I know what is really going on... Lets say 7x7 pixels are being turned into a 3x3 mipmap. Some of the samples will not even be close to the center of tour pixels.
<glennk>
powers of two divide evenly, so the relative texel sample position is the same for each pixel
<Akari>
re the d3d12 and zink situation: turns out I had to copy the dxil.dll redistributable dll next to mesa's opengl32.dll. Now creating a context works in d3d12, though zink fails with an internal assertion
<Akari>
Assertion failed: !"Unsupported memory-type", file ../src/gallium/drivers/zink/zink_resource.c, line 194
<xcube>
Would going from 3x3 to 1x1 pixel only use the center pixel?
sdutt has quit []
<Akari>
the d3d12 backend renders a few frames of my game, and then the screen freezes... the game itself responds to input though, so it seems to be a presentation problem?
<Akari>
jenatali, maybe you could give me some pointers when you're here
sdutt has joined #dri-devel
<glennk>
xcube, it will take one bilinear filter sample from the source, so it will for 3 -> 1 miss one of the pixels
<xcube>
glennk: It turns out that my 487x467 resolution ends on a 3x3 -> 1x1. It really does feel like its only using the center pixel (and even less at that).
NiksDev has quit [Ping timeout: 482 seconds]
<jenatali>
Akari: are you using Mesa master or a release? I remember I fixed an issue like that a while ago
<xcube>
glennk: I will first try tweaking the dimension halfing to avoid such situations (maybe making it favor even resolutions for mipmap levels might work). Ultimately I will need to fix util_make_fragment_tex_shader_writemask()
<jenatali>
If you want to file a gitlab issue we can take a look when we get a chance
<jekstrand>
anholt: Sorry this phi src review is taking so long. I like the idea; I just want to make sure we get it right.
<glennk>
xcube, as far as i can tell both the software implementation in mipmap.c and the hardware one are completely GL spec compliant
<Akari>
jenatali: mesa master
<Akari>
i'll try the latest stable release. maybe it's a regression
<daniels>
Akari: you mean main rather than master, right? master is old
<jenatali>
Oh good call
<Akari>
whatever is the default branch now. i cloned it on that machine yesterday
<glennk>
xcube, the software one uses unweighted averaging, so instead of mostly sampling the center texel in the 3x3 mip level, you get 4 texels averaged
<jenatali>
But yeah if you can file an issue with repro steps, I'm happy to take a look when I get a chance
<Akari>
(god i hate this master->main rename nonsense)
<xcube>
glennk: It might be compliant, but the proprietary drivers don't seen to have this issue. I am trying to fixup a Minecraft shaderpack (Sonic Ethers Unbelievable Shaders) mostly for personal use. The exposure is adjusted based on the average (that comes from the last mipmap level of the framebuffer in post processing).
<xcube>
If you search for methods online of getting the average texel value, most (all?) of the methods I found online use glGenerageMipmap()
agd5f_ has quit [Remote host closed the connection]
<glennk>
xcube, it was a popular method a dozen or so years ago before compute shaders were widely supported and people could use better methods
<glennk>
xcube, a related not, if you are using this for adjusting exposure, this value is integrated over several frames?
<xcube>
glennk: It is not integrated, but it would be cool if it was (might add that if I need to mod that part anyway).
ngcortes has joined #dri-devel
<Akari>
jenatali, tried mesa 21.1 just now, same problem, so it's not a regression in master. Also wglgears is not affected. I'll open an issue soon
<xcube>
glennk: Can you link me an article/algorithm or something that I could use to replace the average from mipmap?
<glennk>
xcube, are you just modding shaders, or can you make changes to the minecraft engine?
<xcube>
glennk: Yes, I can make changes to all of that. made a tweaker mod for a modpack that does things like that.
<xcube>
If I do end up publishing changes that I make to the SEUS shaderpack I will need to do it in the form of a mod to apply the changes at runtime (to avoid copyright issues).
<glennk>
xcube, in a nutshell it hacks up the buffer into tiles and processes each with a compute shader invocation, then a subset of those shader invocations wait for and average the tile results
<glennk>
xcube, since you don't need actual mipmaps you can simplify it a lot
heat has quit [Ping timeout: 480 seconds]
<xcube>
glennk: I will give it a try. Given that the older method of using glGenerateMipmap is kind of prevalent, would a fix for it still be considered?
heat has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
<glennk>
xcube, as long as the fix doesn't run afoul of conformance tests i think it would be
heat has quit []
heat has joined #dri-devel
agd5f_ has quit []
agd5f has joined #dri-devel
<Akari>
jenatali: actually, after recompiling my game with full optimization settings... the problem seems to have disappeared. So I'm not sure it's a mesa/d3d12 issue now, though it's certainly weird that it only happened in this configuration so far...
vivijim has joined #dri-devel
mattrope has joined #dri-devel
<Akari>
minor stuttering aside, everything seems to render fine
<airlied>
daniels: can I convert looks mostly correct into an Ack for 11819 :-)
<airlied>
or does anyone else want to validate my wl_shm code
<jenatali>
Akari: weird. If you have a consistent way to reproduce it, I'd take a look though
<Akari>
i'll try to find one, but it seems unlikely at this point
<airlied>
jekstrand: could that d3d12 pass be used for ivybridge?
idr has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<daniels>
airlied: yeah, R-b even
<airlied>
daniels: thx!
lynxeye has quit []
lemonzest has quit [Quit: Quitting]
<daniels>
np!
<airlied>
anholt: for the context stuff I think sroland is fine with not plumbing it at all and leaving it be llvmpipe perf flags to switch to the fastpath
<airlied>
not sure driconf effort is worth it
<anholt>
that's certainly easier!
<anholt>
still scarred from my last adventures with pipe loader
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
gouchi has joined #dri-devel
<jekstrand>
airlied: Maybe?
<airlied>
dang it I just put the ivb machine away
<airlied>
it explains why nobody cared about border color ints
<jekstrand>
We've got Vulkan lowering code for it. :)
<jekstrand>
Or maybe not?
<airlied>
don't think you do
<airlied>
you probably want it there as well
<Kayden>
yeah, don't think so, I wrote all that
<jekstrand>
But I do have a branch!
<jekstrand>
wip/anv-gen7-int-border
<jekstrand>
If we wanted to make it generic, I think what we'd want is a nir_texop_border_color
* airlied
might see how horrible just pulling the ms code out is
<airlied>
since really it's d3d12/ivb, not sure how generic we need after that