00:03 airlied: alyssa: yeah not sure, maybe robclark has an idea
00:03 airlied: like glamor has some slowness, but urxvt is probably not on the things people who care about glamor care about
00:04 robclark: I don't think I've ever used urxvt
00:05 robclark: it's possible that things like that hit gmem bypass path on freedreno
00:06 alyssa: Indeed
00:07 alyssa: What bothers me is that disabling glamor (and doing it all in s/w) is faster
00:08 alyssa: I guess s/w is closer to immediate mode but even so
00:10 HdkR: Tell them to please upgrade to Alacritty or Kitty? :)
00:10 robclark: IME glamor is reasonably okayish.. better than previous xs+exa since it wasn't hitting sw fallbacks.. but I could see it sucking if hit some really slow path in gl driver
00:11 anarsoul|2: alyssa: lima does
00:11 anarsoul|2: (struggle with urxvt + glamor)
00:11 alyssa: anarsoul|2: okay, that's helpful
00:11 alyssa: (I mean, it's not but it's helpful to know)
00:12 anarsoul|2: same with hexchat, it's text renderer is weird
00:12 anarsoul|2: compositor doesn't help in either case
00:13 robclark: iirc glamor does glFinish() in idle hook.. so sounds like you have some app that makes rather bad use of x11 drawing cmds that turns into *really* bad use of gl :-(
00:14 robclark: I'd be inclined to call it an app bug and move on to things that don't involve x11
00:14 anarsoul|2: :)
00:41 alyssa: robclark: Fair enough, yeha
06:33 danvet: airlied, nouveau modifier regression fix still wip?
07:10 airlied: danvet: oh i should chase that up I suppose
07:10 airlied: skeggsb: please chase up a bit :-P
07:10 airlied: danvet: that and the sparc fbdev are the ones I currently nkow about
07:30 danvet: hm right sparcfb still in flight too
07:30 danvet: sravn_, ^^ ?
07:51 MrCooper: eric_engestrom: in a nutshell, my point is: if you want to get a benefit out of CI for the stable branch, it needs to be gating; if you don't want that, then it might be better to disable CI for the stable branch, otherwise it's mostly wasting time & resources
11:19 Venemo: gcc now segfaults while building mesa
11:20 Venemo: ../src/gallium/drivers/softpipe/sp_tex_sample.c:3862:1: internal compiler error: Segmentation fault
11:21 Namarrgon: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3242
11:22 Venemo: I don't remember enabling LTO
11:24 FireBurn: I think someone else said they stumbled upon this without lto too
11:24 FireBurn: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3237
11:24 Venemo: also, I'm not doing a 32-bit build, but a 64-bit one
11:24 FireBurn: https://bugs.archlinux.org/task/67229
11:24 Namarrgon: the gcc bugtracker has a couple of fresh lto-ICEs but none for this particular issue
11:25 Venemo: like I said I don't think I enabled LTO, unless it is now enabled by default
11:25 Venemo: if it is, how do I disable it?
11:26 FireBurn: It's not enabled by default
11:26 FireBurn: People have encounted this bug without lto
11:27 Venemo: has anyone reported this upstream yet? I don't see it in the gcc bugzilla
11:27 karolherbst: does anybody have local fixes to fix the gl cts integration in piglit?
11:27 FireBurn: I'm not going anywhre near the gcc bug tracker again after https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763
11:27 Venemo: what does that have to do with this?
11:28 FireBurn: It seems unless you have the know how to create a small test case or know GCC internals, you're not welcome
11:28 FireBurn: It's why I've not reported it upsteam
11:30 Venemo: I wonder how did this pass the CI
11:31 FireBurn: Differnt compiler version, different flags?
11:31 FireBurn: Seems it's just gcc 10.1
11:32 FireBurn: But folk have triggerd the ICE with differnent things, for me it was LTO, for that arch user it was NDEBUG
11:32 FireBurn: If you have the know how, report it to the GCC folk
11:35 Venemo: dunno
11:35 Venemo: my GCC tells me report this to RH
11:36 Venemo: so, https://bugzilla.redhat.com/show_bug.cgi?id=1855742
11:44 FireBurn: What distro?
11:45 Venemo: fedora 32
11:46 FireBurn: makes semse
11:46 FireBurn: *sense
11:55 ccr: anyone else having problems pulling (or so) from https://gitlab.freedesktop.org/mesa/mesa.git at the moment? gotten connection aborted few times.
11:55 ccr: oh .. and now it worked. nevermind.
11:55 ccr: the magic of complaining on irc
12:31 Venemo: FireBurn: it also happens after I downgrade to 10.0.1
12:34 FireBurn: Err this is no gcc 10.0.1 - that's a beta / rc build
12:35 Venemo: it's gcc (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0.11)
12:35 FireBurn: My statement still stands
12:39 FireBurn: There's probably only a few patches difference between that 10.0.1 build and 10.1 that was released shortly after
12:39 Venemo: but I don't remember seeing this segfault sooner
12:41 FireBurn: Yes it's only shown up since 18cb8f23222422c7fb9764362e659d15ec0b64eb was commited to mesa
12:45 SolarAquarion: for some reason this occurs "../mesa/src/intel/dev/gen_debug.c:37:10: fatal error: 'git_sha1.h' file not found"
12:45 Venemo: try a clean rebuild
13:38 sravn_: danvet: I am not too happy with the sparc64 fix, and the build-bot agrees with me. Will poke a bit more on it tonight.
13:38 sravn_: The fix is fine on sparc64, but I am concerned about other archs - as tzimmermann also pointed out
13:39 sravn_: I cannot just set a falg in the driver, as the driver may be used by other archs than just saprc64 and then the framebuffer may not reside in iomem
13:39 sravn_: s/falg/flag
13:49 FrankyCyborg: *sigh* no matter what combination of flags to libdrm and mesa, I always hit the same issue: https://apaste.info/Nigs for some reason, the configure stage of mesa seems to require the amdgpu module !?
13:49 imirkin: because you're requesting an amd driver, presumably
13:49 FrankyCyborg: but where.. !?
13:50 FrankyCyborg: dri-drivers='' and gallium-drivers=swr
13:50 imirkin: in the default options which you're not overriding
13:50 imirkin: -Dvulkan-drivers=
13:50 FrankyCyborg: ah ok - I'm still not used, that there is also vulkan nowadays..
13:50 FrankyCyborg: might take another 10 years
13:51 imirkin: i wish the defaults had *no* drivers
13:51 imirkin: so people didn't run into this stuff
13:51 imirkin: presumably if you're building it yourself you sorta know which drivers you want
13:52 FrankyCyborg: yeah - so, in my case I guess I would select "intel" ( this is most likely a virtual machine environment on this hosting ISP ) ?
13:54 imirkin: the driver should match the graphics card hardware
13:54 imirkin: if there is none, then you just want swrast
13:54 imirkin: (or swr, if your application is extremely vertex-heavy)
14:10 MrCooper: FrankyCyborg: to be clear, you can also literally pass '-Dvulkan-drivers=' to build no Vulkan drivers at all
14:10 FrankyCyborg: ah, that would be useful
14:22 agd5f_: danvet, vsyrjala so currently drm is limited to 32 encoders. It took me a while to figure that out trying to track down the fix for the warnings in drm_mode_object_add after dropping the driver load/unload callbacks
14:22 agd5f_: prior we used to dynamically allocate/deallocate encoders for MST
14:22 danvet: agd5f_, why did load/unload removal change anything with that?
14:22 danvet: uh yeah you can't do that
14:23 agd5f_: what's the issue with that?
14:25 agd5f_: 32 just seems kind of limiting. If you have GPUs with 6-7 real encoders and 6 fake encoders, you can run out pretty quickly. 3 GPUs and you are over the limit
14:26 danvet: agd5f_, uh this should be per-drm_device
14:26 danvet: wrt don't hotplug encoders:
14:26 danvet: - kernel locking doesn't cope
14:27 danvet: - userspace probably doesn't cope (I mean they have a hard time with connector hotplug already)
14:27 danvet: - possible_encoders bitmask
14:27 agd5f_: ah, if they are per driver, that's not as bad
14:28 danvet: I was assuming you'd do the i915 fake encoder trick of num_crtc x num_mst_capable_ports
14:28 danvet: but that's a bit overkill
14:28 agd5f_: danvet, that is what I did
14:28 danvet: you only need a fake mst encoder per crtc
14:28 agd5f_: and we went over
14:28 danvet: yeah that goes over 32 easy with amdgpu hw
14:28 danvet: iirc you're 6 pipes and 6 ports?
14:29 agd5f_: yup 7 encoders on some asics
14:29 danvet: yeah that's too much for the dumb approach
14:29 danvet: oh to clarify: the possible_encoders is in uapi structs
14:29 danvet: huh no
14:30 danvet: connector has a full list of encoders
14:30 danvet: it's only possible_crtcs that's in uapi structs
14:30 agd5f_: IIRC, i915 allocated num_crtc fake encoders per connector
14:30 danvet: agd5f_, it /might/ be possible to lift this past 32 for encoders
14:31 danvet: agd5f_, yeah, but that's a bit overkill
14:31 agd5f_: yeah, I just created num_crtcs global fake encoders per asic
14:31 agd5f_: which works
14:32 danvet: hm we do have a drm_encoder_mask which is u32
14:32 danvet: but it's not used that often, so should be fixable
14:33 danvet: but if you can just do the num_crtc fake encoders across all outputs, that's a lot simpler
14:34 FrankyCyborg: wow - it finally builds, but not after I had to re-install wayland-protocols, because it put its pkgconfig file in /usr/share/pkgconfig instead of /usr/lib/pkgconfig ... *grumph*
14:35 imirkin: you could of course have also altered the PKG_CONFIG_PATH...
14:36 FrankyCyborg: I find it not useful, if the files are scattered around the filesystem
14:36 emersion: pkgconfig should look up both by default
14:38 ajax: and /usr/share is "the right place" since none of the definitions in it are platform-dependent
14:38 ajax: matter of taste, i suppose
14:38 imirkin: FrankyCyborg: yeah, everything should just live in /
14:39 FrankyCyborg: !? you are not helpful, unless you want to be sarcastic
14:41 imirkin: you were complaining about scattered files?
14:41 imirkin: that just gets them all in one place to avoid confusion
14:41 FrankyCyborg: pkgconfig files - you have to talk within the context
14:41 ickle: if only there was a filing system to organise them
14:41 ickle: now that's sarcasm
14:42 imirkin: can't compete with a brit...
15:02 robclark: danvet: btw is there a good reason in igt that it is intel_dp_compliance.c and amd_hdmi_compliance.c? Both look 99% driver agnostic.. abhinav is planning on adding msm support for dp compliance, and I suppose a 2nd nearly identical copy of intel_dp_compliance.c isn't the desired outcome?
15:04 danvet: robclark, probably not
15:04 danvet: aside from "originaly typed by intel people"
15:05 danvet: doing the same we've done to the crc infrastructure sounds like a good idea imo
15:05 danvet: if there's any need for that aside from dropping the intel_ prefix and a few intel-isms
15:05 danvet: like I have no idea what this thing expects wrt kernel interfaces
15:05 robclark: iirc the intel-isms were setting domain to gtt, and some debugfs file paths..
15:06 danvet: if it does have some debugfs expectations, maybe good to move those to drm_* files
15:06 robclark: at least that is what I spotted from a quick look
15:06 danvet: yeah, so sounds about same work needed like for converting the crc stuff originally
15:07 robclark: possibly debugfs path stuff could be handled by first checking "generic" name, and then "intel_" name.. the set_domain stuff is probably easily enough abstracted
15:08 danvet: yeah that's what we've done for the crc transition too
15:10 robclark: ok, maybe that can re-use an existing helper then
15:21 FrankyCyborg: hmph - the code in src/util/futex.h is plain wrong; just because HAVE_LINUX_FUTEX_H is defined, doesn't mean, that FUTEX_WAIT_BITSET is also defined .. (at least not my (old) remote machine) therefore the build fails
15:32 tomeu: anholt__: was looking at also having the baremetal tracie jobs upload artifacts, but there's a problem with the clock in those boards being off: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/3555636
15:32 tomeu: for lava, we pass an approximate date via the job definition
15:32 tomeu: don't know what would be the best way of doing this with baremetal
15:38 SolarAquarion: Venemo: i can build mesa with clang?
15:38 Venemo: SolarAquarion: I didn't try with clang
15:44 dcbaker[m]: SolarAquarion: should work
15:45 SolarAquarion: hmm, i did a clean build on arch and it keeps on giving me "../mesa/src/intel/dev/gen_debug.c:37:10: fatal error: 'git_sha1.h' file not found"
15:46 dcbaker[m]: That sounds like a dependency ordering bug
15:47 dcbaker[m]: That just happens to be getting hit with clang
15:52 orbea: SolarAquarion: does this happen with -j1?
16:03 ajax: anyone happen to have an nvidia blob machine running and can test something for me?
16:04 karolherbst: ajax: depends, but potentially yes
16:04 ajax: karolherbst: can you turn on the unofficial GLX protocol - per http://us.download.nvidia.com/XFree86/Linux-x86_64/440.82/README/glxsupport.html - and tell me what glxinfo reports for an indirect context?
16:04 ajax: curious if they manage to expose beyond gl 3.0
16:05 karolherbst: seems like I need to change the X config.. okay, let me see if I am able to get this right :D
16:06 dcbaker[m]: SolarAquarion: there's a bug in src/Intel/dev/meson.build. the source list needs to have sha_1 without quotes
16:07 karolherbst: ajax: what do I have to do to get glxinfo to report the indirect context stuff?
16:08 karolherbst: ohh, -i I guess
16:08 ajax: yeah
16:08 karolherbst: mhhh
16:08 karolherbst: fails to create a context
16:08 ajax: and then you may also have to enable iglx contexts because...
16:09 karolherbst: maybe I messed up with the x config..
16:09 ajax: which is Section "ServerFlags" \n Option "IndirectGLX" "true" \n EndSection
16:09 karolherbst: ohh I see
16:10 SolarAquarion: orbea: yes. it happens with -j1
16:10 ajax: just pastebin the whole glxinfo output would be best
16:11 karolherbst: ajax: http://pastebin.test.redhat.com/883418
16:11 dcbaker[m]: eric_engestrom you might be interested in my last comment (not sure who else is fixing meson bugs these days 😃)
16:12 karolherbst: ehhh...
16:12 karolherbst: nvm
16:12 ajax: just 3.0, right on
16:12 ajax: karolherbst: thanks!
16:12 karolherbst: np
16:30 Shibe: does anyone here know what exactly microsoft's "hardware-accelerated gpu scheduling is"? do DRM drivers like AMDGPU already do something like this?
16:32 jenatali: Shibe: Did you see https://devblogs.microsoft.com/directx/hardware-accelerated-gpu-scheduling/ ?
16:41 SolarAquarion: dcbaker[m]:huh. Fun
16:44 SolarAquarion: dcbaker[m]: i don't see sha_1 with or without quotes
16:47 Shibe: jenatali: yeah but that dev blog doesnt go into a lot of detail about how it works and whatnot
16:47 Shibe: it does sound pretty neat though
16:47 Shibe: hope they don't have some kind of patent on it
16:48 jenatali: Nah I don't think there's a patent
16:48 jenatali: You're right the blog's light on details though
16:49 jenatali: High level, there was a CPU kernel worker thread handling GPU scheduling, that got moved to a GPU processor
17:04 MrCooper: dcbaker[m] eric_engestrom: ../meson.build:472: WARNING: dri3 option "true" deprecated, please use "enabled" instead. ← this warning seems outdated according to meson configure <build dir> | grep dri3
17:08 anholt__: tomeu: when I get back I could look into adding an ntpdate, I guess. thanks for looking into uploading the artifacts!
17:29 dcbaker[m]: MrCooper: you can't change options stored in meson's stored state from inside meson.build, so you'll get that warning on each reconfigure unless you change it
17:44 Shibe: jenatali: if you were to guess, how does that reduce latency?
17:45 jenatali: It doesn't necessarily reduce *input* latency, but it does reduce latency between the GPU finishing one chunk of work and starting the next, since it doesn't have to round trip back to the CPU
17:46 jenatali: Oversimplifying of course, it wasn't always a full round trip, but still
17:47 alyssa: jekstrand: I'm looking into adding the concept of integer saturates into NIR
17:48 alyssa: basically to support OpenCL's convert_*_sat family
17:48 alyssa: On Midgard, we literally have outmods on integer ops for (un)signed integer saturate, so we can do things like "i2i16_sat" in one op
17:48 karolherbst: alyssa: slowly I start to think we need a conversion instruction type :/
17:48 alyssa: karolherbst: Perhaps..
17:49 jenatali: daniels: ^^
17:49 alyssa: I think the least intrusive way to represent this, though, is a pair of new ops, isat/usat
17:49 karolherbst: or we end up with like 500 alu instructions just for conversions :D
17:49 alyssa: well
17:49 alyssa: {i,u}sat{8,16,32} I guess
17:49 karolherbst: and rounding modes
17:49 alyssa: with the semantic of `CLAMP(MIN_INT, MAX_INT)`
17:50 karolherbst: sat isn't just for ints
17:50 alyssa: for midgard we can just pick that off with the fancy mod stuff and fuse it into the op
17:50 alyssa: karolherbst: we already have fsat? :P
17:50 alyssa: ---right
17:50 karolherbst: isn't that doing something else?
17:50 alyssa: blah
17:50 Shibe: jenatali: thanks for the explanation. i guess we'll learn more if we ever see something like this in drm though
17:50 alyssa: karolherbst: regardless I am not writing an OpenCL driver right now :p
17:50 karolherbst: :p
17:50 alyssa: trying to support pure int framebuffers
17:50 karolherbst: have fun with that :p
17:51 alyssa: can't find a spec reference but dEQP seems to want saturate behaviour for e.g. RG16I
17:51 alyssa: where the input is a highp int that's out of range, wrapping causes it to fail but clamping to 32767 is fine
17:51 karolherbst: yeah... I had to deal with some blit issue where didn't clamp the values correctly
17:52 karolherbst: uint -> int conversion?
17:52 alyssa: karolherbst: int32 -> int16
17:52 karolherbst: right.. I just expect this area is just annoying to deal with :p
17:53 karolherbst: doesn't anybody do CTS CI stuff?
17:53 karolherbst: :/
17:54 alyssa: anyway for now I can probably just insert clamps manually, but it's worth discussion
17:55 karolherbst: fun.. more crashes/regressions to track down
17:57 alyssa: usat is just a umin 2^n - 1, that's easier to chew through
17:57 karolherbst: yeah
17:58 alyssa: Failed: 0/36 (0.0%)
17:59 alyssa: that's more like it :^)
17:59 alyssa: Manhattan's still broken, of course ;-;
18:01 jekstrand: alyssa: Uh... Yeah.....
18:01 jekstrand: alyssa: The problem is that integer saturate assumes all your integer ops happen with an extra bit of precision
18:01 jekstrand: For mul, you need the full 64-bit result for a 32x32 mul_sat
18:02 alyssa: ugh, right
18:03 jekstrand: So, while it's fine if someone's back-end can do a 32x32 imul_sat (I think Intel can), representing it in NIR as two instructions gets tricky
18:05 alyssa: on further thought, blend shaders are inherently slow, will deal with this later ;P
18:05 alyssa: thanks tho
18:09 daniels: yeah, and the rounding interactions ...
18:12 sravn: pcercuei: Frida FRD350H54004 patches, do you expect these to land in -next or -fixes?
18:13 pcercuei: sravn: first one is definitely a fix
18:13 pcercuei: second one is not
18:13 pcercuei: so... maybe one in each? ;)
18:14 sravn: pcercuei: OK
18:15 pcercuei: but they cannot apply in parallel, though
18:15 pcercuei: so I believe -next then
18:18 sravn: pcercuei: patches do not apply, they contains vrefresh which is gone. As the second patch overwrite the first as a single patch?
18:19 pcercuei: ah, where did vrefresh go?
18:19 sravn: vrefresh is redundant. Can be calculated. So it was better to drop it
18:21 pcercuei: vrefresh is still here in -fixes, that's where I based my patchset
18:21 pcercuei: I can rebase on top of -next and resend
18:26 sravn: pcercuei: Yes, on top of -next please. The second patch is not -fixes material. And unless you see any good reasons then the fix can way a kernel release I think
18:49 sravn: danvet: Who is the "postmaster" behind dri-devel? I am annoyed that subjects are mangled. dt-binding patches have a space added after the "," which is not nice when they are part of a filename
18:50 danvet: sravn, #freedesktop
18:53 sravn: danvet: thanks
20:01 sravn: pinchartl: ping on "drm/bridge: support chained bridges + panel updates"
20:03 ajax: does anyone have an example of an app using NV_multisample_coverage and/or heard of any interest in it?
20:13 imirkin: is that where the msaa mask is stored in depth?
20:15 imirkin: oh, no. this is a different thing.
20:22 imirkin: fwiw i don't think anyone's seriously RE'd the csaa stuff in nvidia. i think amd gpu's support flexible setting of some of this stuff, but not sure if it's identical
20:23 karolherbst: I guess games tend to make use of this...
20:24 karolherbst: ajax: maybe it would be interesting for wine?
20:24 karolherbst: dunno if that's wired up at all, but it sounds like something usefull there
20:24 zf: do you mean NV_framebuffer_multisample_coverage?
20:25 zf: it's not wired up, but I think it could be
20:25 karolherbst: ohh there is NV_framebuffer_multisample_coverage as well
20:25 ajax: i meant https://www.khronos.org/registry/OpenGL/extensions/NV/NV_multisample_coverage.txt
20:25 karolherbst: well.. if that's useful for wine and people are interested in supporting it from mesa, I guess it would make sense
20:26 ajax: which is sort of a pre-fbo version of the same idea
20:26 karolherbst: I guess you pretty much won't both extensions, no?
20:26 karolherbst: *want
20:26 ajax: yeah
20:27 karolherbst: I don't know which windows games make use of CSAA but I think there are quite some
20:27 ajax: i suppose if i have the fbo one in my EGL i can implement the other one in GLX...
20:28 karolherbst: seems like CSAA is a "better" MSAA or so
20:28 ajax: just doing an audit of the gaps between nvidia's glx and what we've got working in mesa
20:28 karolherbst: yeah..
20:29 karolherbst: but I think it makes sense to implement it if wine wants to use it
20:29 karolherbst: there are soooo many AA variants :/
20:30 imirkin: there's also the variant where you store the sample mask alongside depth/stencil
20:30 karolherbst: SMAA maybe?
20:30 imirkin: no
20:30 imirkin: starts with a V
20:31 imirkin: and you only store a single color/depth/stencil per pixel
20:31 imirkin: so it's "worse" in terms of quality, but better in terms of perf
20:32 karolherbst: sure it starts with V?
20:32 imirkin: and it's identical if you're doing regular MSAA. but it's worse if you're doing per-sample shading
20:32 imirkin: VCSA or something
20:32 imirkin: maybe not
20:32 karolherbst: nvidia added TXAA at some point, but no idea what this one does :D
20:33 ajax: temporal AA
20:33 ajax: revenge of t-buffers
20:34 karolherbst: txaa is supposed to be quite good though
20:34 karolherbst: and much faster than ssaa
20:36 karolherbst: implementing TXAA would be a good idea as well
20:36 karolherbst: but.. I think it has a lot of software side stuff
20:37 karolherbst: mhh MLAA is the AMD variant of TXAA
20:37 ajax: at some level i'm not super interested in *aa features that you could write yourself in the shader if there's not hw to accelerate it
20:37 karolherbst: well
20:38 ajax: (to clarify: unless there's hw accel for it, who cares about implementing it)
20:38 karolherbst: TXAA and MLAA are basically MSAA + post processing as it seems
20:38 ajax: right
20:38 karolherbst: but.. I don't know to what degree they depend on hardware
20:38 ajax: if your resolve hardware knew about the extra buffers, that'd be one thing
20:38 karolherbst: and if a driver needs to support it
20:38 turol: MLAA, TXAA, SMAA and CMAA are all post-processing
20:38 karolherbst: maybe you just link against a lib and are done with it
20:39 turol: of them only smaa uses (optionally) msaa
20:39 turol: FXAA not TXAA
20:39 turol: txaa is nvidia's proprietary thing
20:39 turol: which might or might not use temporal filter
20:39 karolherbst: turol: right, but it still uses MSAA features, even though you don't have a TXAA+MSAA option ;)
20:40 turol: combining post-processing with msaa is tricky because post-processing generally requires detecting edges
20:40 turol: and msaa blurs those
20:40 karolherbst: yeah. but then you might need driver support for it
20:40 karolherbst: that's the whole point of the discussion
20:40 turol: so at least smaa t2x and 4x need to separate the subsamples first
20:41 karolherbst: if for implementing TXAA you need some driver side support because of those details it needs a GL/VK extension to expose it, etc...
20:41 turol: i think just explicit multisample loads would do
20:42 karolherbst: anyway CSAA seems to be one having GL extensions
20:42 turol: which already exist
20:42 karolherbst: right..
20:42 bnieuwenhuizen: turol: I also thought a lot of those were suppposed to be "a cheaper MSAA" (especially with deferred rendering), and mixing it with MSAA kinda destroys that benefit
20:42 karolherbst: wine devs would know if TXAA is useable :p
20:42 karolherbst: bnieuwenhuizen: TXAA isn't cheaper :p
20:42 turol: coverage sampling is a separate thing
20:42 turol: and i though nvidia deprecated it
20:42 bnieuwenhuizen: karolherbst: talking about the post-processing ones
20:42 karolherbst: TXAA has post processing elements
20:43 karolherbst: it's really not that simple anyway...
20:43 karolherbst: sure FXAA is full post processing and just operates on the result
20:43 karolherbst: but the others ones are a bit smarter
20:44 turol: bnieuwenhuizen: deferred rendering + msaa was not possible on pre-dx10 hardware because multisample load wasn't a thing yet
20:44 turol: and even with it it's expensive since you have to shade a fragment multiple times
20:45 karolherbst: anyway, at this point we lack the information to make any definite statement on the topic if a driver implementation is required
20:45 karolherbst: except CSAA
20:45 karolherbst: and FXAA I guess :p
20:45 karolherbst: (and SSAA and MSAA)
20:48 karolherbst: uiui https://docs.nvidia.com/gameworks/content/gameworkslibrary/postworks/product.html
20:50 karolherbst: okay.. so it seems like TXAA is just something wrapping around MSAA and you sue this library to use it.. okay
20:51 turol: absolutely proprietary.jpeg
20:51 karolherbst: yep
20:52 imirkin: so i think the thing i was talking about is indeed CSAA
20:52 imirkin: basically you store a coverage mask in addition to the thing
20:52 imirkin: but i guess you can *also* have multiple "real" samples in the process
20:52 imirkin: and afaik yes, it's outmoded
20:54 karolherbst: it seems like that CSAA is "better" than MSAA though
20:55 karolherbst: but can't find any comparisons so far
20:56 karolherbst: ohhh wait
20:56 karolherbst: is this CSAA also this stuff on top of MSAA?
20:57 imirkin: yes
20:57 imirkin: it's MSAA + extra coverage mask
20:57 karolherbst: ahhh, I see
20:57 turol: as i understand it csaa just uses multiple coverage samples to more accurately resolve the msaa samples
20:57 imirkin: but depending on how you have it configured, you could just do the coverage
20:58 karolherbst: I see
20:58 imirkin: well, the mode i'm thinking of stores the coverage in the zeta surface (i.e. depth + stencil + coverage)
20:58 karolherbst: interesting
20:58 karolherbst: those are the weirdo MSAA modes we have I guess?
20:59 imirkin: and then yeah, you could use that coverage value for whatever you wanted :)
21:01 airlied: and now we have VRS to deal with next
21:02 imirkin: VRS?
21:02 turol: i'm guessing variable rate shading
21:02 karolherbst: variable rate shading
21:02 imirkin: so nvidia supports doing per-sample shading at e.g. 4x rate on a 8x msaa surface
21:02 karolherbst: makes sense for 4k/8k displays, so ... not much of an interest for nouveau at this point :p
21:02 karolherbst: mhhh
21:03 karolherbst: maybe compositors could make use of it though?
21:03 imirkin: but this is where the rate is directed by something else presumably and dynamically?
21:03 airlied: mostly for VR appliacation
21:03 karolherbst: higher rates on areas with shadows
21:03 karolherbst: and lower rates everywhere else :p
21:03 airlied: like you don't need to render outside the lens area
21:03 airlied: but rednering it black at 8xMSAA is definitely pointless
21:03 karolherbst: but games do use it though
21:04 karolherbst: airlied: but VRS isn't about AA, is it?
21:04 karolherbst: I thought you just render tiles at lower resolution compared to the screen
21:04 airlied: karolherbst: it just feeds into the AA
21:05 karolherbst: like you could render blurred areas in crappy quaity as it doesn't matter :p
21:05 airlied: https://microsoft.github.io/DirectX-Specs/d3d/VariableRateShading.html
21:05 karolherbst: ohh, interesting
21:06 karolherbst: but still, I think you can use that without any AA and have a 4x4 rate on the tiles essentiallyt
21:31 bnieuwenhuizen: karolherbst: the real fun is when you enable VRS and MSAA at the same time :P
21:33 karolherbst: ufff
22:04 emersion: is it fine for dmabuf planes to have a zero size/height/stride?
22:13 bnieuwenhuizen: emersion: heh, you saw my MR :P
22:19 emersion: yeah :)
22:19 bnieuwenhuizen: the context is that I'm looking at a dummy plane just to prevent X doing frontbuffer rendering
22:20 emersion: daniels: thoughts?
22:22 bnieuwenhuizen: the other issue I found was that EGL in mesa reject stride == 0, though AFAICT that is an implementation choice and not specified in the EGL_EXT_image_dma_buf_import spec
22:25 daniels: emersion, bnieuwenhuizen: uhhhhhh ... no
22:25 daniels: bnieuwenhuizen: don't you actually have multiple actual planes for DCC anyway?
22:27 bnieuwenhuizen: daniels: yes, but prefer to handle it in the driver for simplicity and for those cases where you'd like to have 5 of them
22:27 daniels: are all five really completely independent or can they be stored in fewer than five?
22:28 bnieuwenhuizen: daniels: yes I can store them in 1 plane even. See how we got here? :P
22:29 bnieuwenhuizen: (4 out of 5 in the worst case could be really plane-like, though in effect you don't have any choice in stride anyway ...)
22:29 daniels: heh
22:29 daniels: I need to go to bed now but let's pick this up later