ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
xcube has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
<xcube> I have a GLSL post processing shader that uses `textureLod(previous_render, vec2(0.5, 0.5), high_lod_number)` to get the average value of the entire frame before the final post processing step. It is used to adjust the final exposure.
<xcube> This seems to work on Nvidia and AMD's proprietary drivers at least (and at least on windows), but there is something odd about glGenerateMipmaps() on mesa that is causing things to flicker.
<xcube> To be more specific, the shader in question from the SEUS shaderpack for Minecraft (it normaly does not work on linux/mesa, but I have a personal version that I patched up and it 99% works now. Just this one final bug to work out.)
<xcube> I have an AMD RX580 and am digging around in the mesa source code to find the algorithm used for glGenerateMipmaps() but I am vary rusty/unfamiliar with mesa debugging.
camus1 has joined #dri-devel
<imirkin> xcube: radeonsi doesn't use the generic mechanism for this
<imirkin> i guess it sorta uses the generic mechanism since it still calls util_blitter_generate_mipmap, but it does some "other" things too
camus has quit [Read error: Connection reset by peer]
<imirkin> xcube: try setting PIPE_CAP_GENERATE_MIPMAP to false in si_pipe.c to see if the generic mechanism makes it work
<xcube> imirkin: I will try that. Is _mesa_meta_GenerateMipmap the function that gets used on radionsi?
<imirkin> meta is not it
<imirkin> maybe if all else fails, _mesa_generate_mipmap falls back to that? not sure.
<imirkin> definitely not the "first" thing it would do.
<imirkin> no... _mesa_generate_mipmap does it super-by-hand (see src/mesa/main/mipmap.c)
<xcube> That is the software fallback right?
<imirkin> yeah, if it's a non-renderable format
GloriousEggroll has quit [Quit: Death is life's way of telling you you've been fired.]
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
anujp has quit [Ping timeout: 480 seconds]
<xcube> imirkin: I can't seem to find were PIPE_CAP_GENERATE_MIPMAP is defined (not in si_pipe.c). Grep found some usages but they all read it.
<anarsoul> xcube: try egrep -R PIPE_CAP_GENERATE_MIPMAP src/gallium/drivers/
<xcube> anarsoul: Oops, I overlooked it. It was in src/gallium/include/pipe/p_defines.h
<xcube> I still can't find what sets it to true for radionsi though.
<anarsoul> xcube: I think imirkin meant to change src/gallium/drivers/radeonsi/si_get.c to return 0 for PIPE_CAP_GENERATE_MIPMAP
Lightkey has quit [Ping timeout: 480 seconds]
<xcube> I think I found it :)
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<xcube> Anyway, I rendered textureLod(previous_render, coords, 7) to the screen to see what it looked like (about 8x8 large pixels) and it seems like instead of averaging the base level pixels, it feels like it is picking one or a sparse number of them (causing the flickering when the camera rotates just slightly).
Lightkey has joined #dri-devel
mbrost has joined #dri-devel
<imirkin> xcube: it's supposed to do linear filtering :)
tarceri has joined #dri-devel
<xcube> imirkin: When it generates the mipmap levels, generating level 7 should use level 6 and not level 0 right? Even if its not a perfect average, it should still work?
<imirkin> right.
<xcube> I wonder if it is using nearest instead of linear when generating the smallest mipmap levels. (when lod is 0 to 4 it seems ok, but past that, the issue is noticeable)
<imirkin> shouldn't be!
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
sdutt has quit [Remote host closed the connection]
<xcube> In si_pipe.c radeonsi_debug_options has a lot of useful looking stuff. What environment variable do I use to activate some of them?
sdutt has joined #dri-devel
<xcube> I tried GALLIUM_PRINT_OPTIONS=info but that did not seem to do anything
boistordu_old has quit [Ping timeout: 480 seconds]
<imirkin> xcube: did you try setting that PIPE_CAP to 0?
<xcube> imirkin: If the RX580 has_3d_cube_border_color_mipmap it is set to 1 (I am forcing it to 0 right now, but it would be nice to get it to print out that info)
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
xcube has quit [Remote host closed the connection]
Company has quit [Read error: Connection reset by peer]
xcube has joined #dri-devel
anujp has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
xcube has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
itoral has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
tzimmermann has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
ngcortes has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
camus has quit []
camus has joined #dri-devel
mbrost has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<HdkR> Oh nice, I see the release calendar was updated. rc1 on the 14th :)
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Danct12 has joined #dri-devel
Danct12 has quit []
anujp_ has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
danvet has joined #dri-devel
anujp_ has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
rsalvaterra_ has quit []
rsalvaterra has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
flto_ has joined #dri-devel
<tzimmermann> danvet, looking at it
flto has quit [Ping timeout: 480 seconds]
<danvet> tzimmermann, it smells a bit like THIS_MODULE refcount gone wrong at very first look
<danvet> since we don't even get into drm/vgem code before we die
<emersion> pq, is ti fine to confuse SRGB and UNORM vulkan formats like it's done in this MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11778
<emersion> it*
<emersion> i suppose it's fine without the color management protocols?
<emersion> and once we have color management, then we can tell the compositor the difference?
frieder has joined #dri-devel
lemonzest has joined #dri-devel
pcercuei has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
lynxeye has joined #dri-devel
Ahuj has joined #dri-devel
mlankhorst has joined #dri-devel
NiksDev has joined #dri-devel
<pq> emersion, first, I don't know what Vulkan means with SRGB and UNORM. :-)
jernej has quit [Ping timeout: 480 seconds]
<emersion> afaik UNORM = linear, SRGB = non-linear
jernej has joined #dri-devel
flto has joined #dri-devel
flto_ has quit [Ping timeout: 480 seconds]
<pq> emersion, thanks for the link, now I know UNORM and SRGB...
<pq> emersion, would it be possible to claim support for SGRB formats *only*?
<pq> because that would be the right thing to do without any color management protocol
<emersion> pq, according to this, it doesn't seem like it… https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11598#note_984389
<pq> wait, "colorSpace" is a separate Vulkan attribute that defines *also* the non-linear encoding? How does that work with SRGB pixel format then?
<emersion> VkSurfaceFormatKHR contains both a VkFormat and a VkColorSpaceKHR…
<pq> oh, maybe I get it...
<emersion> encoding vs. primaries/white-point/transfer function?
<pq> no
<pq> VkColorSpaceKHR defines the chromaticity properties *and* encoding.
<pq> VkFormat defines how the translation between the raw pixel value and the interpreted value your app actually works with.
<pq> so SRGB in format only means that all access to the pixel goes through the sRGB non-linear de/encoding functions.
<emersion> hm. so as far as wayland is concerned, we shouldn't care about UNORM/SRGB in VkFormat, these look the same to us?
<pq> you can have a VkColorSpace with linear encoding, and if you access that through SRGB format, you get what you ask for: the linear raw value is linearized a second time, IOW, scrambled.
<pq> emersion, exactly.
<pq> UNORM/SRGB is only about how Vulkan interprets the raw pixel value bits
<pq> if the user knows the underlying DRM_FORMAT_*, they could use *any* Vulkan "numeric format" and just compute the value accordingly.
<emersion> i see
<pq> the translation between DRM and Vk formats is a reinterpret_cast
<emersion> what does that mean?
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
<pq> I'm referring to the C++ reinterpret_cast, or the plain C cast.
<pq> hmm, no, not C cast. C reinterpret through a union.
<HdkR> std::bit_cast is the officially blessed C++ way to do this :)
<pq> The thing I'm not clear about is, what's the idea with the Vk formats.
<pq> HdkR, sorry, my C++ is stuck in the 2006.
<pq> :-)
xexaxo_ has joined #dri-devel
<HdkR> Luckily this was added in C++20
<pq> emersion, maybe I can talk about fragment shaders here? Like, in frag shader you have a float r, g, b values that you write as destination color.
<emersion> right
<emersion> VkFormat SRGB/UNORM is about these
<pq> if your target VkFormat is UNORM or SRGB, then values from outside [0.0, 1.0] are "impossible". I suppose they just get clamped.
<pq> with UNORM, the float value is trivially converted to, say uint8_t if it's 8 bpc.
<pq> with SRGB, the float value goes through sRGB inverse EOTF function before trivially converted to uint8_t.
<emersion> ok. so you write a linear value to the shader float, then vulkan de-linearizes it to SRGB
<pq> yes - *if* your shader indeed computes a linear value
<pq> it up to the app whether the float is linear or non-linear value
<emersion> if it doesn't, you get wrong values and nothing else, i guess?
<pq> but to get the expected result (non-linear value written), it needs to choose betweed UNORM and SRGB
<emersion> ok. so in theory an app could use a nonlinear SRGB colorspace, with a UNORM format, and do the delinearization itself in the shader?
<pq> yes!
<pq> VkColorSpace says what the pixel values represent (encoding), and VkFormat is just a helper to convert your floats into what is needed.
<pq> and only, the app, knows how the float in the frag shader is encoded, linear or non-linear
<pq> *only you, the app
<pq> I believe the same applies to OpenGL SRGB stuff.
<emersion> makes sense
<emersion> thanks for the explanation
pnowack has quit [Quit: pnowack]
<emersion> it's kind of unfortunate that shader details are leaked into WSI stuff
<pq> Let's hope my reasoning matches... well, reality might be flawed, but the Vulkan spec writers'. :-)
illwieckz has quit [Remote host closed the connection]
<pq> yes
pnowack has joined #dri-devel
<pq> I presume UNORM/SRGB apply in both directions: texture sampling and render target writing
<emersion> i hope so :^)
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
<tzimmermann> danvet, found it. i'll send a fix later today
vivijim has joined #dri-devel
<danvet> tzimmermann, awesome, thx a lot
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
rasterman has joined #dri-devel
angerctl has joined #dri-devel
<nroberts> can I start the CI for a branch in a personal repo? I see it has made a pipeline but if I click the play button it says an error occurred while making the request https://gitlab.freedesktop.org/nroberts/mesa/-/pipelines/356288
<MrCooper> nroberts: weird, there should be a play button for each container job; maybe check the CI/CD settings in your project for anything that might differ from the default
<nroberts> oh, I wasn’t signed in 🤦 I am an idiot, sorry for the noise :)
<MrCooper> ah, cool
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
illwieckz has joined #dri-devel
iive has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
jernej has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Read error: Connection reset by peer]
xexaxo_ has joined #dri-devel
pochu has quit [Ping timeout: 481 seconds]
Company has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Guest292 has joined #dri-devel
jernej has joined #dri-devel
pochu has joined #dri-devel
gpoo has joined #dri-devel
Peste_Bubonica has joined #dri-devel
nirmoy has joined #dri-devel
Guest292 has quit [Ping timeout: 481 seconds]
itoral has quit []
aigleroy881 has joined #dri-devel
raket has left #dri-devel [#dri-devel]
jewins has joined #dri-devel
<swick> pq, emersion: yes, the vk srgb formats linearize on read and delinearize on write. reason for those formats to exists is that (some?) ROPs have this build in so it's basically for free.
<swick> and it's not really leaking into the WSI, it's just another vulkan format which maps to the same wl format
<emersion> this bit of information is never relevant for the WSI
<emersion> would make more sense imho to make it a flag when creating shaders, or something
<swick> well, vulkan has multiple formats which have the same pixel layout which is the only thing that matters for wl formats
<swick> it's not the shader doing the srgb conversion though
<emersion> flag to VkImageView or even VkImage then
<pq> swick, does Vulkan so the literally asked but nonsensical thing when you have a linear color space and use SRGB format?
<pq> *do
<pq> no effect on WSI, just curious
<swick> yeah, no way to know what the user computes/stores
<swick> if you ask for it, you get it
<pq> good, so no surprise special cases there
frieder has quit [Remote host closed the connection]
camus has joined #dri-devel
<swick> emersion: not completely sure but i think attachments only take a format and you then after the pipeline was created you assign VkImageViews to those attachments and sine the srgb load/store thing is part of the pipeline state it can't be a VkImage(View) flag
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<jekstrand> swick: That's incorrect. sRGB encode/decode is part of the VkFormat in the VkImageView
<jekstrand> There is no pipeline flag for it
<jekstrand> Or maybe that's what you were trying to say? I'm having trouble parsing.
xexaxo_ has quit [Read error: Connection reset by peer]
xexaxo_ has joined #dri-devel
xexaxo_ has quit [Read error: Connection reset by peer]
xexaxo_ has joined #dri-devel
anujp_ has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
iive has quit []
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
aigleroy881 has quit [Ping timeout: 480 seconds]
<danvet> tzimmermann, oh just realized you didn't cc intel-gfx, so can't easily confirm with CI whether it's fixed there now too
mattrope has joined #dri-devel
anujp_ has quit [Ping timeout: 480 seconds]
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
vivijim_ has joined #dri-devel
<tzimmermann> danvet, i'll send it out again with intel-gfx
mattrope has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
apteryx_ has quit []
camus has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
pochu has quit [Ping timeout: 482 seconds]
GloriousEggroll has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
xexaxo_ has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
sdutt 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]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
aigleroy881 has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
mbrost has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
<swick> jekstrand: the image views of a framebuffer must have the same format as the attachments of the render pass. pipelines can only be used with framebuffers of a compatible render pass. render passes are compatible if the format of the attachments is the same. therefore the format and sRGB decode and encode of attachments is pipeline state.
<swick> what am I missing?
<jekstrand> swick: Correct
<jekstrand> swick: I thought you were saying there was a pipeline create bit for it.
<jekstrand> Drivers have the information in case they want to do it in the shader (a lot of mobile does) but it's specified as an image format.
<jekstrand> Maybe I just misread what you'd typed?
<swick> maybe I just wrote nonesense?
<jekstrand> Maybe both?
<swick> could be
<jekstrand> Anyway, I think we agree. :)
<swick> yeah
hch12907 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Bennett has joined #dri-devel
<jekstrand> Does tg4 take derivatives?
<jekstrand> I think it does for LOD, right?
<jekstrand> But there's no explicit LOD version so that's weird
rsalvaterra_ has quit []
<jekstrand> Oh, no, it's always lod0
rsalvaterra has joined #dri-devel
<jekstrand> Crazy AMD extension....
<jekstrand> Oh, right. This is the especially stupid one...
<jekstrand> *sigh*
aigleroy881 has quit [Ping timeout: 481 seconds]
anujp has joined #dri-devel
gouchi has joined #dri-devel
pnowack has quit [Quit: pnowack]
<jekstrand> kusma, jenatali: Could one of you take a look at the D3D fails in this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11775
<jekstrand> That and some AMD machines falling off a cliff seem to be the only remaining problems.
<kusma> jekstrand: I don't have time until Monday, but I can take a look then if it's still a problem. But maybe you'll have to remind me ;-)
xexaxo_ has quit [Read error: No route to host]
<jekstrand> kusma: Ok, I can pester. :)
<jekstrand> kusma: I'm not in too much of a rush. I'm waiting for cwabbott to give me a final ok anyway.
xexaxo_ has joined #dri-devel
flibitijibibo has quit [Quit: Leaving]
pnowack has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
flibitijibibo has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 481 seconds]
gouchi has quit [Remote host closed the connection]
sravn_ has joined #dri-devel
<dschuermann> jekstrand what do you mean with "falling off a cliff" ?
sravn has quit [Ping timeout: 480 seconds]
<jekstrand> dschuermann: I mean the machine is dying. It has nothing to do with Mesa. There's aparently some kernel problem.
bluebugs has quit [Remote host closed the connection]
cedric has joined #dri-devel
<dschuermann> kernel problem with amd? never heard of that :P
cedric is now known as bluebugs
<dschuermann> tomeu: mupuf: ^ (in case you weren't aware)
<jenatali> jekstrand: I'm out of town until Thursday. If you haven't gotten to the bottom of it by then I can help take a look
<jekstrand> ok
rasterman has quit [Quit: Gettin' stinky!]
ppascher has joined #dri-devel
nirmoy has quit []
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
vivijim_ has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Read error: Connection reset by peer]
xexaxo_ has joined #dri-devel
sravn_ has quit []
danvet has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
loki_val has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
pcercuei has quit [Quit: dodo]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Quit: Leaving]
pnowack has quit [Quit: pnowack]