00:19 anholt: has anyone ever managed to convert a trace from renderdoc to apitrace?
00:36 imirkin: anholt: can you just apitrace renderdoc?
00:48 robclark: renderdoccmd seems to do *something* funny..
07:16 tomeu: robclark: can it be fixed in renderdoc? we're looking towards using it more and more for testing mesa
07:34 j4ni: where's the canonical source for glxgears?
07:37 arora: tlwoerner: Hey, due to corona pandemic, my classes have been suspended as of now but I don't know until when it's gonna be like this. In the application, I have to mention about my class taking, so can I leave that part out?
07:49 j4ni:finally found glxgears.c, never mind
09:37 daniels: j4ni: mesa/demos repo, right?
09:41 j4ni: daniels: correct
09:41 j4ni: not that it helped me :/
09:42 j4ni: someone's claiming glxgears reports incorrect fps, and there's some obscure kernel patch that's supposed to fix things, but I think it's a red herring
09:43 daniels: heh
11:31 danvet: j4ni, reminder about [PATCH 08/51] drm/i915: Use drmm_add_final_kfree
11:31 danvet: before you entirely disappear into glxgears :-)
11:32 arora: tlwoerner jekstrand : I have shared a draft on the GSoC website, kindly provide your feedback.
12:09 j4ni: danvet: trying to understand a bit before just slamming rubber stamp
12:09 j4ni: I haven't followed the series at all
12:56 danvet: j4ni, yeah that would be good too
12:56 danvet: I think the i915 patches are probably the worst sales pitch, better to look what this would all look like with some of the simpler drivers towards the end of the series
12:56 danvet: idea is that we could do the same magic trick of "look no unwind nor unload code" for complex drivers too
12:57 danvet: but that's a lot more a long term dream
12:59 danvet: https://patchwork.freedesktop.org/series/73633/#rev1 rev 1 cover letter should also be useful
13:00 danvet: oh and next step is to add a macro
13:00 danvet: which combines the kzalloc() + devm_drm_dev_init() + drmm_add_final_kfree() so that that bit of ugly goes away again
13:00 danvet: series was simply getting too big already
13:52 danvet: mripard, mlankhorst_ I need a backmerge of drm-next into drm-misc-next for cf9bfa3c5ce8aba8e076a6d52a05d91435160744
13:53 danvet: tzimmermann not around
14:06 mlankhorst_: oops pushed to wrong branch
14:06 mlankhorst_: how do I undo..
14:10 mlankhorst_: ok undone
14:10 mlankhorst_: hope nobody noticed
14:11 mlankhorst_: danvet: pushed to drm-misc-next, enjoy :)
14:13 danvet: mlankhorst_, not even cited the commit I need, why did I look it up :-P
14:13 mlankhorst_: I described it!
14:13 imirkin: painted a picture
14:14 mlankhorst_: be glad I didn'tmake poetry about it
14:14 imirkin: i'd kinda rather you had!
14:15 mlankhorst_: Oh commit cf9 bfa3c, how I long for thee
14:15 imirkin: see - so much nicer
14:16 danvet: mlankhorst_, totally going to be disappointed if the next one doesn't come with peotry
14:17 mlankhorst_: I have no choice now..
14:20 mripard: bonus point if it's in alexandrine
14:25 robclark: tomeu: no idea.. although it is only an issue if you are trying to get an apitrace from renderdoc
15:10 pq: danvet, I can't figure out how it is possible, but it indeed is possible that drmModePageFlip can change the pixel format on EVDI.
15:11 danvet: huh
15:11 danvet: btw what's this evdi driver?
15:11 pq: danvet, I got fix in EVDI plane atomic_update func to check the pixel format change, and that makes it correect.
15:12 danvet: pq so the check in the legacy ioctl doesn't catch this, and you need to duplicate?
15:12 pq: EVDI is https://github.com/DisplayLink/evdi
15:12 danvet: oh the " must hide blob in userspace" thing
15:12 danvet: :-/
15:12 pq: danvet, I guess, but I can't figure out why. The check in drm_mode_page_flip_ioctl() does not seem to be avoidable any way.
15:12 pq: yeah, that
15:13 danvet: pq, so you just copied the check we already have for old_fb->format != new_fb->format?
15:13 pq: not really, but the patch adds state->fb->format->format != old_state->fb->format->format check, and that seems to trigger.
15:14 vsyrjala: that check is bad btw. i made it check the format info pointer instead of the fourcc. that breaks tiling compressed scanout for skl+ since atomic was taken away from x
15:14 pq: meaning that EVDI forwards the new pixel format and things look fine again
15:14 vsyrjala: s/tiling//
15:15 vsyrjala: r-b me if someone wants to send a patch to change it back to check the fourcc
15:16 pq: wait, which way check is correct? and does it matter?
15:17 danvet: vsyrjala, imo totally ok
15:17 vsyrjala: we need to check just the fourcc. otherwise pageflip ioctl can't change compressed<->not compressed on intel hw
15:17 danvet: we never supported page-flip with incompatible CCS state
15:17 danvet: so nothing ever got broken
15:17 pq: ok
15:17 danvet: also use atomic instead
15:18 vsyrjala: it's totally broken now. no page flipping with compression at all. meaning all 3d workloads now blit
15:18 danvet: oh
15:18 danvet: why?
15:18 vsyrjala: because mesa wants to use compression, and the ddx tries to page flip and fails
15:18 danvet: shouldn't we get the same CCS format modifier as long as everything stays the same
15:18 pq: danvet, so, I just wanted to give you a heads-up since this looked odd. My issue is basically fixed now, once the patch gets into EVDI.
15:19 danvet: vsyrjala, but why is it not the same pointer?
15:19 vsyrjala: because the ddx doesn't use compression for the root window pixmap i guess
15:19 vsyrjala: dunno should it or not
15:19 danvet: oh
15:19 danvet: well yeah if page flip doesn't work you need to do a modeset first
15:20 danvet: but this always worked like that
15:20 danvet: we had some trickery I guess
15:20 vsyrjala: we always allowed tiling changes iirc
15:20 danvet: for a fairly flexible definition of always
15:20 danvet: i.e. most definitely not
15:20 vsyrjala: when did we not?
15:20 danvet: but ofc "works on my laptop, ship it"
15:21 danvet: I think anything not i915 doesn't allow much, but not sure
15:21 pq: danvet, I suppose you would want me to ensure that Mutter keeps on working with DisplayLink even if drm_mode_page_flip_ioctl() starts rejecting the pageflip like it should?
15:21 danvet: pq, yeah for legacy if you can't pageflip, you need to do a setcrtc
15:21 vsyrjala: the current check doesn't prevent all tiling changes anyway. just the one where the driver overrides the format info
15:21 danvet: which should do just a (blocking) flip
15:21 pq: right, I assume Mutter has that code already, but I guess better make sure
15:22 danvet: vsyrjala, I guess we could fix it, dunno
15:22 danvet: kinda prefer someone would fix userspace to suck less
15:22 pq: so you're not blocked from fixing the kernel
15:22 vsyrjala: i think just relaxing the check to do what it did in the past is the right choice here. the current check isn't consistent
15:24 vsyrjala: hmm. we even have an igt that tests flip w/ tiling change. but i guess it doesn't test with ccs
15:25 danvet: vsyrjala, doesn't ccs need more watermarks?
15:25 vsyrjala: any tiling change can need different wms
15:25 danvet: i.e. good potential for a bunch of "my 2nd screen doesn't work anymore" regressions?
15:25 vsyrjala: nah
15:25 vsyrjala: if the wms are broken we should fix them
15:25 vsyrjala: don't think they are that broken
15:26 danvet: so why did we have all these "modifiers break my setup" regressions then, that motivated every compositor to disable modifiers?
15:26 danvet: if it's not "run out of fifo"
15:26 danvet: if we suddenly open the back channel for this stuff again we're back to that mess
15:27 vsyrjala: if we run out of fifo then the page flip will fail. exactly like it does now
15:27 danvet: since the fixed compositors by necessity need to use atomic, and they can flip like this already
15:27 danvet: I mean a) flip to CCS b) set up 2nd screen, no workie
15:27 danvet: also I guess a bunch of compositors will go to CCS, so you'd end up with CCS on all root windows
15:28 danvet: all screens I mean
15:28 vsyrjala: ccs doesn't add much on top if y-tile wms. so it can happen just the same way today
15:28 danvet: essentially if you want CCS, you need atomic, and you need TEST_ONLY atomic
15:28 danvet: at least my understanding
15:28 danvet: so better to just tell userspace to do atomic, but right
15:29 vsyrjala: root pixmap format is what it is. compositor doesn't change that
15:30 vsyrjala: dunno why you think ccs is somehow special here. it is not
15:30 pq: looks like Mutter does fall back to modeset on pageflip EINVAL.
15:32 seanpaul: Lyude: i'm going to hopefully land the MST interleaved reply set today, mind reviewing the QUERY_STREAM_ENC_STATUS change if you have a chance?
15:33 pq: wasn't the modifier issue such that if modifiers are supported, ccs or whatever y-tile gets used, and then there is no bandwidth left to light up a second monitor?
15:33 Lyude: seanpaul: sure thing-how much work was required for the interleaved reply stuff btw?
15:33 Lyude:just curious
15:34 pq: so if a compositor TEST_ONLY sees that lighting up another monitor fails, it would need to somehow know to stop using ccs/y-tile/something on the monitor that already works?
15:35 seanpaul: Lyude: checking my time logs, i have 13 hours into it
15:35 Lyude: oh wow
15:36 seanpaul: i think most of that was trying to figure out wtf was happening
15:36 Lyude: ah, lol
15:36 Lyude: yeah mst is like that sometimes
15:37 imirkin: 13 hours of work produces 13 lines of code?
15:37 imirkin:hates those situations
15:37 seanpaul: imirkin: if i'm lucky
15:38 seanpaul: imirkin: just checked the diffstat and yeah, the delta is +13 LoC
15:38 imirkin: lol!
15:38 seanpaul: was that a lucky guess?
15:38 imirkin: completely
15:38 seanpaul: hahaha
15:38 seanpaul: amazing
15:39 imirkin: hope you don't get paid by the LoC
15:39 seanpaul: don't give $mgmt any ideas please
15:39 imirkin: before my (professional) time, but i understand it was common practice in the 90's and earlier to evaluate performance based on LoC produced
15:41 seanpaul: yuck
15:42 imirkin: thankfully i missed out on that trend
15:54 emersion: pq: correct
15:54 emersion: in wlroots we disable all modifiers if using modifiers fails
15:57 mdnavare: emersion: do the panels actually tell through EDID how much refresh rate change per frme they can handle without flicker
15:57 mdnavare: emersion: or is this something we decide based on user experience?
15:58 emersion: mdnavare: as far as i know, this info isn't exposed
15:58 mdnavare: emersion: not exposed, but do we have this info in EDID?
15:58 emersion: i haven't seen anything related
15:58 mdnavare: emersion: i know we have the range in EDID but do we have the maxshift that the panel can handle in edid?
15:59 emersion: i really hope i'm wrong, but all the people i've talked to (harry too) said there's no way to know
15:59 emersion: what i know is that:
16:00 emersion: - for low-end screens which have a narrow VRR range, usually there's no flicker
16:00 emersion: - for high-end screens which have a wide VRR range and suck, there's flickering
16:00 emersion: - for high-end screens which have a wide VRR range and don't suck, there's no flickering
16:01 emersion: or at least this is what i've collected from my users
16:01 emersion: it would be really nice to have a VRR screen maker on the line to ask these questions
16:02 emersion: have you seen my reply on dri-devel?
16:02 imirkin: so either go cheap or go expensive, but nothing in the middle? :)
16:02 emersion: pretty much :D
16:04 emersion: sadly i only have a wide choice of exactly one VRR screens to play with, so i won't be able to help a lot experimenting
16:04 emersion: amd are doing freesync certifications, it would be cool to have more details about it
16:05 emersion: though not sure amd wants this info to be public :(
16:26 arora: tlwoerner jekstrand : I have shared a draft on the GSoC website, kindly review it and provide your feedback.
16:35 Lyude: seanpaul: btw, did you already send the QUERY_STREAM_ENC_STATUS change onto the mailing list?
16:36 seanpaul: Lyude: "[PATCH v5 14/16] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message"
16:37 Lyude: seanpaul: ahhh, looking through all the patches in that series now
16:37 seanpaul: thanks!
16:38 Lyude: (note - I'll probably leave the i915-specific stuff to the intel folks)
16:39 anholt: imirkin: I had, unsurprisingly, just tried it already.
16:40 daniels: dcbaker: did you want to comment on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4304 at all?
16:47 imirkin: anholt: oh well =/
17:04 macc24: where can i learn mesa gallium driver development?
17:04 imirkin:learns by doing
17:05 imirkin: (and annoying people with stupid questions)
17:05 Lyude: macc24: find a driver that interests you, find the development channels for it and ask them if they've got anything on their TODO list that would be good for a beginner to work on
17:06 macc24: Lyude: what if driver doesn't exist yet?
17:06 imirkin: then you're in for a good time.
17:06 Lyude: macc24: ooh, I guess this would be the place to ask things then :). What kind of driver are you thinking of writing, by the way?
17:06 imirkin: which hardware?
17:06 macc24: imirkin: intel ironlake gpu, i want to write gallium driver to that
17:06 imirkin: ah
17:07 Lyude: Huh
17:07 Lyude: i mean, if you've got the time and the willingness to go down that rabbit hole!
17:07 macc24: the worst thing that can happen is me not writing that driver and learning a bit about driver dev
17:07 macc24: and opengl
17:07 Lyude: macc24: I'd ask around in #intel-gfx (unless they've got a more mesa-y channel for mesa related stuff that they use these days?)
17:07 Lyude: macc24: yep-that's the right attitude to have :)
17:07 vsyrjala: #intel-3d
17:08 Lyude: ah, yeah ^ that channel then
19:12 lrusak: any reason to think that EGL cannot handle YUV420 in IMC4 layout? https://docs.microsoft.com/en-us/windows/win32/medfound/images/yuvformats06.gif
19:12 lrusak: width=1920 height=856
19:12 lrusak: plane[0]: stride=1984 offset=0
19:12 lrusak: plane[1]: stride=1984 offset=1698304
19:12 lrusak: plane[2]: stride=1984 offset=1699296
19:13 anholt: lots of drivers would hate your offsets not being page aligned.
19:14 lrusak: yea I thought about that :/
19:15 anholt: but one could probably build a pass that on import split things off into independent planes.
19:17 lrusak: anholt, is there a mesa env variable that could help debug this EGL import?
19:18 airlied: imirkin: one employer does bonuses based on rb and sob tags in the projects they participate in
19:19 imirkin: is the bonus based on "rb - sob"? :)
19:19 airlied: it leads to some curious work flows where maintainers rebase every patch
19:19 airlied: just to keep their stats up
19:20 imirkin: i keep telling that "git rebase" is money!
19:20 airlied: id be sobbing a lot
19:20 imirkin: lol
19:27 karolherbst: airlied: ufff.... that sounds wrong on so many levels
19:32 sravn: imirkin: If one should get bonus it should be based on lines deleted - but with same functionality
19:32 imirkin: =]
19:32 imirkin: the real way to make that happen is to split a repository in 2
19:33 imirkin: and then delete half the code in each half
19:33 imirkin: that really helps the overall stats
19:33 sravn: imirkin: One of the good stories was when I was migrating some ugly .c code over to C++ and STL. From literal hundres of mallc/free to none. And 2500 loc less code. It was a good day
19:34 anholt: lrusak: would be nice. there's EGL_LOG_LEVEL=debug but I bet there's not much hooked up to it in this path
19:36 sravn: danvet: drmm_ committed and no screaming here or dri-devel so far. Good work! Looks forward for the next round of patches
19:37 lrusak: anholt, from the radeonsi debug:
19:37 lrusak: Texture:
19:37 lrusak: Info: npix_x=1920, npix_y=856, npix_z=1, blk_w=1, blk_h=1, array_size=1, last_level=0, bpe=1, nsamples=0, flags=0x7010000, r8_unorm
19:37 lrusak: Layout: size=1753088, alignment=256, bankw=1, bankh=1, nbanks=2, mtilea=1, tilesplit=64, pipeconfig=17, scanout=1
19:37 lrusak: Level[0]: offset=0, slice_size=1698304, npix_x=1920, npix_y=856, npix_z=1, nblk_x=1984, nblk_y=856, mode=1, tiling_index = 8
19:38 bnieuwenhuizen: what is IMC4?
19:38 imirkin: fixed layout of Y, U, V planes
19:39 imirkin: (sequential)
19:39 imirkin: rather than separately-floating addresses in memory
19:40 bnieuwenhuizen: lrusak: what indication do you have that it is not working?
19:40 lrusak: just a screenshot
19:40 lrusak: sec, I'll upload somewhere
19:41 bnieuwenhuizen: also, what GPU?
19:41 lrusak: https://i.imgur.com/m7PnGNi.png
19:41 lrusak: 2020-03-26 12:36:47.395 T:815111 DEBUG: VAAPI - driver in use: Mesa Gallium driver 19.2.8 for AMD VEGAM (DRM 3.36.0, 5.6.0-0.rc6.git1.1.fc33.x86_64, LLVM 9.0.0)
19:42 lrusak: whoops
19:42 lrusak: 2020-03-26 12:36:47.442 T:815111 NOTICE: GL_RENDERER = AMD VEGAM (DRM 3.36.0, 5.6.0-0.rc6.git1.1.fc33.x86_64, LLVM 9.0.0)
19:43 dostoyevsky: Any idea why I get `OpenGL version string: 3.1 Mesa 19.0.8 (git-1625c02d65)' -- just OpenGL 3.1 for Mesa 19? I am trying to use mesa3d emulated in software inside docker... but the program I want to use requires at least opengl 3.2...
19:44 imirkin: dostoyevsky: compat vs core context?
19:44 ajax: dostoyevsky: probably because you're creating a compat context
19:44 imirkin: not sure if llvmpipe exposes high-version compat contexts... it probably should though
19:45 ajax: it only supports 3.3 to this point anyway
19:45 imirkin: 4.5 is pretty close by the looks of it
19:46 seanpaul: Lyude: does this lgty http://paste.debian.net/1136831/ (in response to your review comment on the interleaved patches re: renaming sideband_msg_build() fn rename)
19:46 seanpaul: i figure it doesn't warrant a repost if you're ok with that
19:47 bnieuwenhuizen: lrusak: humor me, but can you align offset & stride to 256 bytes(64 might be enough, but lets be sure)
19:48 lrusak: bnieuwenhuizen, unfortunately I cannot control the properties of the image, it's what I get back from the widevine decrypter
19:48 bnieuwenhuizen: hmm ...
19:49 bnieuwenhuizen: is this AMD HW video decoder?
19:49 ajax: dostoyevsky: you might try setting MESA_GL_VERSION_OVERRIDE=3.3COMPAT in the environment, but there's absolutely no guarantee it'll work correctly if you do.
19:49 dostoyevsky: glxinfo | grep "OpenGL" # -> ah, so there is a core version: OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.2.8 // and then there is a compat version? OpenGL version string: 3.1 Mesa 19.2.8 # but when I stat this unity3d program it says it needs opengl 3.2... can I somehow influence whether the unity3d program will create a core or a compat opengl context?
19:49 imirkin: no
19:50 imirkin: but you can run e.g.
19:50 imirkin: MESA_GL_VERSION_OVERRIDE=3.3 MESA_GLSL_VERSION_OVERRIDE=330 foo-program
19:51 lrusak: bnieuwenhuizen, nope, it's being software decoded, into a dma-buf, I'm then handing that fd to egl to create an image
19:51 dostoyevsky: MESA_GL_VERSION_OVERRIDE=3.3 MESA_GLSL_VERSION_OVERRIDE=330 ./obstacletower.x86_64 # -> Unable to find a supported OpenGL core profile // Failed to create valid graphics context: please ensure you meet the minimum requirements // E.g. OpenGL core profile 3.2 or later for OpenGL Core renderer
19:52 danvet: sravn, thx for your careful review!
19:53 ajax: 3.3COMPAT
19:53 bnieuwenhuizen: lrusak: okay, sadly no solution there. The HW requires 64 byte alignment. The best thing to do is probably trying to do an upload into an image with PBO
19:54 krh: or fix the sw decoder...
19:55 bnieuwenhuizen: yes
19:57 lrusak: it's the black box that is widevine...
19:57 lrusak: :(
19:57 lrusak: it's not such a big deal as the path is most likely not going to be used anyways
19:58 lrusak: I have other code that uses ffmpeg sw decoding and that get's aligned properly and works fine
19:58 lrusak: 2020-03-26 11:24:14.483 T:801989 DEBUG: SetDimensions: frame layout id=4 fourcc=842093913
19:58 lrusak: width=1920 height=856
19:58 lrusak: plane[0]: stride=2048 offset=0
19:58 lrusak: plane[1]: stride=1024 offset=1773568
19:58 lrusak: plane[2]: stride=1024 offset=2660352
19:59 lrusak: works fine ^^
20:00 imirkin: lrusak: can you configure the output size?
20:01 imirkin: if so, you could just arrange that w*h/4 is a multiple of 4096
20:01 imirkin: or 256 or whatever
20:12 lrusak: imirkin, unfortunately not. the way widevine decoder works is that it gives us a format and a size (not width and height), so you need to create a buffer of that size, hand it to widevine, it fills the buffer and gives you back the stride and offset for the decoded image
20:15 imirkin: =/
20:20 lrusak: yea :(
20:20 lrusak: here is another image with V = U, so the colors are wrong but the alignment looks ok, https://i.imgur.com/XtXLHHo.png
20:24 dostoyevsky: just a dumb question, atm when I do `glxinfo | grep OpenGL' I see llvmpipe being used but I also have nvidia drivers in /usr/lib/nvidia-440/ -- shouldn't they replace llvmpipe?
20:25 imirkin: dostoyevsky: depends on a million things
20:28 dostoyevsky: $ DISPLAY=":1" glxinfo # -> unable to open display :1 ... maybe I need to explain my X server which runs on :0 these things...
20:29 ajax: nvidia's drivers require that nvidia's gpu be present, it doesn't work as a software-only renderer
20:30 imirkin: they're so picky!
20:30 ccr: amazing.
20:31 kisak:ponders if libglvnd would detect the dead driver and pick another
20:31 dostoyevsky: ajax: yeah, very picky :-( but I do have a gpu present.... otherwise I couldn't run that x server in the first place...
20:32 ajax: right, but does the thing running in docker have access to that gpu
20:33 dostoyevsky: ajax: yeah... you install nvidia docker and then there are a couple of flags...
20:33 dostoyevsky: and of course you need to have the right drivers on the host and guest...
20:41 dostoyevsky: so for the gpu you do specifiy `docker run --privileged --gpus all' and then you need to make sure you have compatible nvidia drivers in the guest but the hw access is available with these options, and I can see it e.g. in `nvidia-smi'
20:45 Lyude: seanpaul: r-b'd
20:47 dostoyevsky: so is mesa3d basically a fallback if the nvidia opengl drivers are not available? Or does mesa use the nvidia drivers when available? (Knowing this probably would set me on the right track)
20:49 imirkin: mesa is a separate stack from the proprietary nvidia driver stack
20:49 kisak: dostoyevsky: neither, mesa and nvidia's proprietary driver don't interact with each other at all. If there's a fallback going on, it's happening somewhere else
20:49 imirkin: the two are not in any way compatible nor do they interact
20:50 imirkin: mesa includes a number of hardware drivers in additional to swrast (basically all semi-modern gfx hw is supported)
20:50 dostoyevsky: so glxinfo comes from mesa... I guess it would never tell me about the nvidia drivers, right?
20:50 kisak: (maybe libglvnd or something silly in xorg-server)
20:50 imirkin: glxinfo comes from mesa-demos
20:50 imirkin: and is just a regular GL program
20:50 dostoyevsky: ah, i see
20:50 imirkin: which uses the regular GL APIs to find out various information about the driver it's running on
20:50 dostoyevsky: thanks
20:59 dostoyevsky: it's working!!!
20:59 dostoyevsky: glxinfo | grep "OpenGL" # OpenGL core profile version string: 4.6.0 NVIDIA 440.33.01 // OpenGL version string: 4.6.0 NVIDIA 440.33.01
21:03 dostoyevsky: I had to: export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/nvidia-440/"; /usr/bin/X :0
21:04 dostoyevsky: if I remove the LD_LIBRARY_PATH glxinfo goes back to llvmpipe... and the unity3d program won't start...
21:07 dostoyevsky: And with `ffmpeg -f x11grab -framerate 60 -y -t 00:00:10 -i :0 remote-host.mp4' I was also able to verify that the monitorless setup fully works...
21:07 dostoyevsky: really happy now :)
22:49 mareko: instead of talking about moving classic drivers to src/mesa_classic, I should just do it, or rather prepare the rest of the repository for 2 src/mesa directories
22:51 mareko: the most challenging part is to make src/compiler not depend on src/mesa
23:12 lrusak: sounds like fun :)
23:52 lrusak: it doesn't look like it but is there a way to import YUV420P10 into EGL? I don't see any reference to it anywhere, only P010
23:54 Venemo: jekstrand: ping. is there any reason why tess factors are added to inputs_read/outputs_written, and not patch_inputs_read/patch_outputs_written? is this just because the shader enum is unfortunately ordered in such a way that they are less than patch0, or is there a different reason?
23:55 imirkin: that definitely sounds very weird
23:55 imirkin: tess factors are most definitely patch outputs (albeit a little special)
23:58 Venemo: imirkin: yes, this is my dilemma too.
23:58 Venemo: but if you take a look at nir_gather_info, you can see they are, along with the bounding box or whatever, marked in inputs_read, not patch_inputs_read
23:59 jkqxz: lrusak: GPUs generally prefer formats which pack in the high bits, not the low bits. Still, you can use R16 and then expand the range afterwards if you don't mind a bit of extra messing around.