00:10 idr: PSA: A recent patch on Mesa master causes many, many thousands of regressions on all Intel drivers.
00:11 idr: I'm currently bisecting, but it's somewhere in the top 5 to 10 commits. :(
00:17 idr: That seems... suspect.
00:17 idr: a6d31589097 mesa: don't use memset in glDrawArrays
00:19 Kayden: prim.indexed doesn't appear to be initialized
00:20 idr: How would that not break the crap out of every driver?
00:21 idr: Or does it?
00:21 idr: mareko: ^^^
00:22 Kayden: stack allocated to 0 most of the time?
00:23 Kayden: indirect_offset doesn't appear to be zeroed either, but unsure whether that matters
00:24 idr: I know in GCC you can do 'struct foo f = { 0, };' and it will do the right thing. It seems like there was issues with other compilers at one time.
00:24 idr: Was that ever sorted out?
00:24 Kayden: I don't remember. Using a C99 initializer would make a ton of sense there
00:25 anholt_: c99 initializer is the way to go here
00:25 idr: Ok. I'll submit a pathc.
00:25 Kayden: we are allowed to use those in core mesa now?
00:26 Kayden: extensions_table.c does
00:26 anholt_: ah, gallium uses ib != null instead of the indexed flag.
00:27 idr: hmm... but I also saw failures on Iris.
00:47 mareko: oh
00:47 mareko: yeah that breaks i965
00:47 mareko: I forgot about it
00:47 mareko: I have a commit that stopes using indexed in i965
00:48 mareko: i965 is the only driver using it
00:52 mareko: the easiest way to fix it is to review the first 4 commits here (at the bottom): https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3591/commits
00:52 gitbot: Mesa issue (Merge request) 3591 in mesa "glDraw & VBO perf improvements and fixes" [Gallium, I965, Mesa, Opened]
00:52 mareko: not easiest, but the most convenient
00:53 mareko: I was hoping someone would review the i965 cleanups
01:00 mareko: idr: ^^
03:43 airlied: MrCooper: tessmark requires compat context by the looks of it
03:43 airlied: unless anyone else know a hack to get it running
03:43 imirkin: mesa supports tess in compat...
03:44 imirkin: make sure you update the PIPE_CAP_COMPAT_CONTEXT value
03:44 imirkin: (not the exact name...)
03:44 airlied: ah I'll bump that and see if it works
03:46 airlied: ah it requires 400, which means I need gpu_shader5 :-P
03:50 airlied: hmm tess apps also seem to cause pathalogical behaviour in draw_reset_vertex_ids, I wonder if I can avoid that reset
03:59 imirkin: airlied: fake it?
03:59 imirkin: i bet you have most of it anyways
05:34 airlied: imirkin: nah it's a require part of splitting large amounts of vertices up
06:32 tjaalton: a new libdrm release would be nice
08:17 pq: Venemo, 'git describe' can take a considerable amount of time, try it on a kernel tree for instance. Ussing that's what git_sha1.h is based on.
08:20 Venemo: pq: but it's not always slow. it is very fast when I do a clean build. but after I change something in a file and recompile, it's slow sometimes
08:21 pq: Venemo, 'git describe' is not always slow either.
08:22 Venemo: interesting
08:22 pq: depends on what it asked for, where the HEAD is, and how far it needs to search to find a tag
08:22 pq: also disk cache
08:23 Venemo: is there a way to speed it up?
08:23 pq: I don't think there is a --search-faster option...
08:24 pq: you'll have to profile it to see what's the hold-up
08:24 MrCooper: --dont-slow-down-man
08:26 MrCooper: airlied: pretty sure I could get it to run with radeonsi before it supported compat context using MESA_*_VERSION environment variables, but I don't remember the exact incantation
09:04 remember2: I put my friends hotel computers ticking onto linux, and noticed some instability in raw drivers in the drm path and suspend, i did not have time to fix it! But had time for workarounds only,minor pm-suspend scripts containing xset dpms force off/on worked luckily!
09:05 remember2: I figured with google help that on bay trail laptop which was the one affected by bad driver bits, had the cult in form of lightdm light-locker to blame overall.
09:07 remember2: similarly new ones had touchpad inputs switching off after resume, this workaround came pretty fast too. i2c_hid removed and reloaded in post pm-suspend script for systemd worked.
09:08 remember2: unbinding and binding i915 driver did not function on bray trail too, so it is rather driver bits bugs than that of lightdm, no rush with this one though
09:11 remember2: unbinding and binding and driver suspend path worked on coffe lake computer though, this one did not have lid as it was a desktop, and another samsung laptop with using some skl stuff also worked fine
09:11 remember2: so it seems this ivy bridge based bay trail platform has those bad bits so far met only
09:13 remember2: and tested on very latest inte-next from ubuntu PPA as februaries release.
10:21 Venemo: pq: actually git describe is pretty fast here. I'm not sure why ninja is stuck on that step.
10:57 danvet: narmstrong, you did read the entire thing this quickly?
10:57 danvet: re your r-b on the drm/meson patch from me ...
10:58 narmstrong: danvet: not the entire stuff but the related stuff yes, it looked okay so far, and trivial
11:00 danvet: narmstrong, so it's clear to you why all the devm_kzalloc in drm/meson are bugs?
11:01 danvet: the series is the start to fixing that problem ...
11:03 linkmauve: Venemo, when you look at e.g. htop, do you see `git describe` being the process taking a lot of time, or do you see something else, for instance the linker or something?
11:04 linkmauve: I’ve noticed ninja doesn’t always print the last step it’s taking.
11:04 linkmauve: The other day it was with LTO.
11:04 linkmauve: Or maybe it prints the last step which completed instead.
11:06 Venemo: linkmauve: haven't checked, but you're probably correct and it's doing something else.
12:22 alyssa:trying to figure out where PIPE_SWIZZLE_* are defined
12:22 alyssa: I mean, gallium/include/pipe/p_defines.h obviously but
12:23 alyssa: They're used in util/u_format so does that mean src/util and Vulkan and such has a dependency on Gallium?
12:24 alyssa: `---So it does. I see.
12:29 pinchartl: danvet: do you have a branch with your ddrm series ?
12:29 pinchartl: (note for later, it would be useful if you could push series to a branch somewhere and include the link in the cover letter)
12:31 danvet: pinchartl, I have my pile of stuff, not really a seperate branch
12:31 danvet: I thought email is The Best (tm) :-P
12:33 pinchartl: for review, yes. to check the end result of a large series, a branch is useful
12:33 pinchartl: especially as you don't speficy the base of the series in the cover letter
12:33 narmstrong: danvet: obviously, I'll need to fix all these with drmm
12:34 pinchartl: (git format-patch --base=auto)
12:36 pinchartl: danvet: will you push a branch ? :-)
12:37 danvet: narmstrong, well atm that's not possible, last patch explains it a bit
12:37 narmstrong: I always tag the current work branch and push to github all my patchsets, to keep track within git and give a tag if needed :-p
12:38 danvet: pinchartl, https://cgit.freedesktop.org/~danvet/drm/log/ my stuff branch on fd.o
12:38 pinchartl: narmstrong: I also try to copy the cover letter to the git tag message, it's useful for future reference
12:38 danvet: but contains all kinds of things
12:38 pinchartl: danvet: thanks
12:38 danvet: I have a "pile them higher" approach to development
12:39 pinchartl: danvet: I call that "throw stuff and let other people handle the fallout" :-)
12:40 pinchartl: but how do you handle merging such patch series if you don't have separate branches ?
12:40 pinchartl: they could conflict, the patches in this particular series may not apply without what happens to be below them in your tree
12:41 danvet: I'm good
12:41 danvet: seriously, if you've played maintainer for a bit applying patches from mailing list becomes trivial
12:41 danvet: even your own
12:41 pinchartl: your series applies to neither of drm-next or drm-misc-next...
12:42 danvet: random wrong trees and conflicts aren't going to faze you
12:42 danvet: drm-tip
12:42 danvet: probably needs a few merges somewhere
12:42 pinchartl: you realize how painful you're making it ? :-)
12:42 danvet: I live for the pain
12:42 danvet: I guess I can unlazy and give you a branch on top of drm-tip
12:43 pinchartl: you can have as much pain as you want for yourself, but not inflicting it on others would be nice too...
12:43 pinchartl: drm-tip doesn't seem to be a proper base for series that you want to upstream...
12:44 danvet: make it linux-next then
12:44 danvet: cherry-picked
12:44 danvet: building now, will push out afterwards
12:44 pinchartl: neither :-)
12:44 pinchartl: the patches should be based on top of the tree in which they will be merged
12:45 pinchartl: otherwise we end up reviewing code that isn't what will be merged
12:46 ickle: we have more than one tree and not enough CI for drm-tip
12:49 danvet: pinchartl, https://cgit.freedesktop.org/~danvet/drm/log/?h=for-pinchartl
12:50 pinchartl: danvet: you could have named it ddrm, but that's fine :-)
12:50 pinchartl: thanks
13:11 danvet: pinchartl, yeah generally if the "oops this doesn't apply" case happens maintainers organize some backmerges
13:11 danvet: with a well specified reason along the lines of "$patch_series needs $commit from $tree"
13:11 danvet: so the patches you review are actually the ones that get merged
13:12 pinchartl: danvet: would you consider using the --base option to git-format-patch ? it will at least record your base in the cover letter, and I can fetch it from your tree if needed
13:12 danvet: and at least in theory their context in which they get applied /should/ be matching the context they've been develop in, on top of drm-tip (or linux-next if you need even more trees)
13:12 danvet: pinchartl, git aint doing that already?
13:13 danvet: I thought that's what the index fa53e9f73893..ac2aecfbc7a8 100644 lines is for in each diff?
13:13 pinchartl: good question indeed
13:13 pinchartl: why is there a --base option then... never really thought about it :-)
13:13 danvet: that index line is good enough for git to reconstruct the baseline and do a full 3-way assisted merge
13:14 danvet: if you do happen to have the baseline in your .git/objects/ store
13:14 danvet: but tbh I never really understood how/why it works
13:14 danvet: just that if I get a patch without that index line then applying is going to be painful
13:15 danvet: and also if it's a patch for a (rebasing) tree that I don't have, then also it's going to be painful
13:15 danvet: and afaik that's been working like this for like 8+ years when I started with drm-intel maintainering
13:16 danvet: I mean I've heard about this additional baseline argument
13:17 danvet: but if it doesn't come with a pull request url I still can't get it, so not sure what it helps really
13:17 danvet: and if you just give me a pull for your branch I obviously also have your baseline
13:17 danvet: and then the index line in each git patch is good enough
13:21 pinchartl: I'll try to investigate
13:21 pinchartl: I'd be surprised if --base was added needlessly
13:22 danvet: I followed the discussion on ksummit-discuss and tbh I didn't understand what it was for
13:22 danvet: at least I doesn't look like it's solving a problem I ever had with applying patches
13:51 danvet: pinchartl, I'm honestly confused how my code even worked
13:51 danvet: since I've loaded/unloaded 3 different drivers and all had a mix of NULL and real data pointers for their release hook
13:51 danvet: and no release hook
13:53 pinchartl: danvet: ok, so it wasn't just me :-)
13:54 danvet: yeah I mean I was sure to screw that up and was quite happy when it all looked good in the debug logs
13:55 pinchartl: looking at the code I wondered how it could have worked, so I was pretty sure my understanding was wrong
13:56 danvet: the entire "don't allocate the void * if it's NULL, just set size to 0" was an idea I added on top of devres.c
13:56 danvet: was maybe one idea too clever :-)
13:56 danvet: btw devres didn't add the &data
13:56 danvet: so that's kinda why I didn't either
13:57 danvet: pinchartl, https://paste.debian.net/1131094/ <- does this look more correct?
13:57 danvet: I haven't dared running it yet ...
13:58 pinchartl: please use &dr->data on line 21
13:58 pinchartl: it should do the same, but is more readable
13:58 danvet: well I just replied that I'm pretty sure you're wrong, but now I'm not sure how C works
14:00 danvet: pinchartl, if we do it in 21, then also in 10 I guess?
14:01 pinchartl: yes
14:05 pinchartl: danvet: given u8 array[];
14:05 pinchartl: and
14:05 pinchartl: void foo(u8 *data);
14:05 pinchartl: foo(array) and foo(&array) are the same
14:08 pinchartl: interestingly enough though, array and &array have different types
14:08 pinchartl: but they're both pointers, and both point to the same memory location
14:10 imirkin: danvet: total bikeshedding, but did you consider a drm_devm_* prefix, for better parity?
14:10 danvet: imirkin, I very much do _not_ want people to mix up devm with drmm_
14:10 danvet: totally different lifetime
14:10 imirkin: k
14:11 danvet: hence all the copypasting, we could have just embedded a struct device into drm_device and directly used all the devres.c stuff
14:11 imirkin: well the lifetime is different, as you say
14:11 imirkin: devm = device memory, drm_devm could be drm_device memory
14:11 danvet: imirkin, maybe I'm going a bit overboard, but given that we have hundred of devm_kzalloc in drm (which are all wrong, at least with a sampled review) I figured making this as separate as possible is good
14:11 danvet: yup
14:12 danvet: hm
14:12 imirkin: anyways, it's just a thought.
14:12 danvet: I expect we'll have a bunch of devm_drm_ functions
14:12 danvet: which set up some drm thing, but the release action is tied to the device
14:12 danvet: so that on unplug, your drm_device is automatically unregistered and all that
14:13 imirkin: can anything with drm really be tied to the device?
14:13 imirkin: oh hm, ok
14:13 danvet: e.g. devm_drm_dev_init has drm_dev_put as it's devm_ cleanup action
14:13 danvet: so devm_drm vs drm_devm could get a bit confusing ...
14:13 danvet: imirkin, if you look at the commit message in the last patch I have ideas for a handful more drm_devm_ functions
14:13 danvet: argh
14:13 danvet: devm_drm_!!
14:15 imirkin: hehe ok
14:15 imirkin: if devm_drm is a thing, then drm_devm should definitely NOT be a thing
14:16 danvet: pinchartl, https://paste.debian.net/1131097/ added this check on top and lets see what happens
14:24 pq: I found a case where a "trivial" rendering of a 8 bpc texture into 8 bpc target produces a few pixels whose components are one less than compared to running the same with POLRAIS11. Is that interesting?
14:25 pq: *one less with llvmpipe
14:25 pq: damn ym typoes...
14:33 pq: I'm positively surprised that compiling Mesa with ASan finds no errors ootb when running polaris11 or llvmpipe for weston.
14:46 danvet: pinchartl, since you had some questions about add_final_kfree ...
14:46 danvet: do you think it'd be worth it to add the slab allocation check to make sure the final kfree pointer actually contains the drm_device
14:46 danvet: and not some random other thing?
14:48 pinchartl: the drm_device, or the driver structure that embeds it, right ?
14:48 danvet: let me type it so we're clear
14:52 danvet: pinchartl, https://paste.debian.net/1131101/ <- this should enforce the full contract I think
14:54 pinchartl: I really think we need to find something better than drmm_add_final_kfree(). it's a hack, and it's fragile
14:56 danvet: pinchartl, you won't get past drm_dev_register without a WARN_ON if you screw it up
14:56 danvet: I can make that a BUG_ON if you thinks it's too fragile still
14:57 danvet: but BUG_ON isn't nice
14:57 danvet: also I expect that most drivers will lose their drmm_add_final_kfree again
14:57 danvet: plus I really don't have a better idea for the fundamental problem here, the final kfree is special
14:57 danvet: once we have that it's a matter of applying some polish for the common case that most drivers have
14:59 pinchartl: by fragile I mean it's awkward to use and error-prone. sure the WARN() will help, but the fact that we need those WARN() is a sign for me that the API isn't quite right
15:13 danvet: pinchartl, you can't use devm_kzalloc before drm_dev_init
15:14 danvet: and even if we could somehow use devm_kzalloc afterwards, maybe just a drmm_add_action
15:14 danvet: it would blow up on final release
15:14 danvet: and you can also not offload this to drivers, because at that point there's not driver code running anymore
15:15 danvet: I guess we could add a drm_driver.kfree_the_dang_thing_containing_drm_device
15:15 pinchartl: :-)
15:15 danvet: but that's even less fragile
15:15 danvet: *more fragile
15:15 pinchartl: (brb)
15:15 danvet: iow, it's all crap
15:15 danvet: so best I came up with is the drmm_add_final_kfree
15:16 danvet: plus a solid plan to hide it from most drivers with the next patch series
15:23 MrCooper: airlied: e.g. MESA_GLSL_VERSION_OVERRIDE=4.0 makes GiMark run with llvmpipe from master, though there are some complaints about unsupported functions getting called
15:24 MrCooper: sorry, I meant MESA_GL_VERSION_OVERRIDE=4.0
16:15 imirkin_: MrCooper: probably need MESA_GLSL_VERSION_OVERRIDE=400 too
16:15 imirkin_: otherwise #version 400 won't work iirc
16:46 neg: I'm trying to express a bayer format using a DRM fourcc but can't figure out how to do so, example the V4L2 fourcc V4L2_PIX_FMT_SRGGB10. I'm looking in drm_fourcc.h but find nothing that comes close to this, am I missing something ?
16:48 robclark: I wouldn't count on drm_fourcc.h being complete when it comes to non-scanout formats..
16:48 ajax: probably not. drm_fourcc is more an enumeration of what's been implemented
16:48 ajax: that too
16:49 imirkin_: the other thing is that things like srgb are usually encoded via lut rather than format
16:50 imirkin_: otoh, nvidia display *does* have an explicit srgb colorspace setting, currently unused
16:50 imirkin_: dunno if other display hw has that too
16:51 neg: I see, would additions of such forucc be accepted to drm_fourcc.h ?
16:52 robclark: definitely if there is some hw that can scan it out.. otherwise, not sure.. I guess it doesn't hurt to try and see what others think..
17:04 neg: I see the problem I'm trying to solve is for the libcamera project that exposes the pixel formats as DRM fourcc so a patch to add them to drm_fourcc.h would not be in relation to any hardware which can scan them out
17:13 narmstrong: neg: can't a bayer fourcc with a modifier do the trick ?
17:14 mattst88: is driconf still useful and worth shipping in a distro?
17:15 mattst88: it's still using pygtk, so it's going to be deleted from gentoo without some intervention, so if it's useful, I'd like to find out :)
17:16 pinchartl: narmstrong: that's what we're trying to figure out
17:16 pinchartl: robclark: those formats will likely never be scanned out by any hardware
17:16 pinchartl: imirkin_: note that bayer isn't relate to srbg
17:17 neg: narmstrong: That was my first thought as well, but I can't find any bayer fourcc in drm_fourcc.h. But I think vendor modifiers will be needed at some point as Intel have their own twist on SRGGB10 (https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-srggb10-ipu3.html) for example
17:17 pinchartl: despite the formats in V4L2 being named S[BGR]{4}
17:17 pinchartl: bayer data is more or less greyscale data with a colour filter in front of each pixel
17:17 imirkin_: pinchartl: oh. i just looked at the format and read it as "srgb"
17:18 imirkin_: i see
17:18 narmstrong: neg: but a "generic" YUV420 8BIT and 16BIT without any specific physical layou has been added for AFBC, could be for bayer-like with a vendor modifier
17:18 pinchartl: so for a 2x2 block of pixels, there's one pixel with a red filter, two with a green filter, and one with a blue filter
17:18 pinchartl: those filters can be arranged in different patterns, hence the different bayer formats
17:18 pinchartl: RGGB means that the first line has a RGRGRG... pattern
17:18 pinchartl: and the second line a GBGBGBGB... pattern
17:19 pinchartl: you can have SBGGR, SGBRG, SGRBG and SRGGB
17:19 pinchartl: on top of that, there's 8, 10, 12 and 14 bits per pixel for each of those
17:19 pinchartl: (and possibly more)
17:19 MrCooper: mattst88: the driconf is actually considered kind of harmful, better ship adriconf instead
17:19 MrCooper: the driconf app even
17:19 ajax: fedora dropped it after f30
17:20 mattst88: okay, great
17:20 narmstrong: pinchartl: seems a good usage of modifiers...
17:20 pinchartl: as well as different ways to store pixels in memory for non 8bpp formats (for instance 10bpp stored in 16 bits, or 4 10bpp pixels packed in 5 bytes, possibly in different ways)
17:20 pinchartl: narmstrong: for the packing I think modifiers make complete sense
17:20 pinchartl: for the pattern and bpp, I'm not sure
17:21 pinchartl: DRM has different 4CCs for different bit depths
17:21 pinchartl: as well as for different RGB patterns
17:21 narmstrong: yep
17:21 pinchartl: should we replicate that, and use modifiers only for the packing, or depart from it and use modifiers more widely ?
17:22 danvet:shrugs
17:22 pinchartl: the reason we would like those formats in DRM, and not just reuse the ones from V4L2, is that we want to standardize on a single set of 4CCs
17:22 danvet: I mean wrt modifier vs fourcc
17:22 pinchartl: we have decided that asking the graphics world to switch to V4L2 4CCs is a bad idea
17:23 pinchartl: so we instead use DRM 4CCs in the libcamera API
17:23 danvet: I guess the fun starts when you have a bayer format with some gpu tiling format
17:23 robclark: I guess I don't really have objection to adding more fourcc's to drm_fourcc.. maybe it should just become uapi/linux/fourcc.h or something like that..
17:24 pinchartl: danvet: if we have different 4CCs for different bayer filter patterns and bpps, and use modifiers to express how the data is packed in memory, then we can combine GPU tiling modifiers with those 4CCs
17:24 pinchartl: robclark: I'd love that
17:24 danvet: pinchartl, yeah that's what I mean
17:24 pinchartl: with a 4CC library in the kernel...
17:24 danvet: maybe a slight push towards more fourcc
17:24 pinchartl: wait, that reminds me of something :-)
17:24 danvet: otoh we don't really have different fourcc for yuv sub plane positioning either
17:24 danvet: so ... dunno
17:25 pinchartl: danvet: ok, then we can send an RFC with 4CC = pattern + bpp and modifier = packing, explaining the rationale, and seeing where it goes
17:25 danvet: yeah I'd be ok with acking that
17:25 danvet: or really, any combo
17:25 danvet: bayer_fourcc with just depth + modifier for layout
17:26 danvet: or bayer_fourcc with just depth + tiling modifier + layout externally, it's just an abstract "you get 4 pixels per 2x2"
17:26 danvet: or more explicit 4cc + modifier for tiling
17:26 danvet: I think that's about the 3 options
17:26 pinchartl: to make sure I understand you correctly, that would be two different 4CCs for Bayer BGGR 10bpp and Bayer BGGR 12bpp, right ?
17:26 pinchartl: and modifiers to tell whether 10bpp is stored with one pixel per 2 bytes, or 4 pixels in 5 bytes, or something else
17:26 danvet: yeah I think depth we definitely want separate 4cc
17:27 danvet: hm
17:27 danvet: right there's packing differences even with linear formats
17:27 pinchartl: yes, with some packing formats that are more or less standard, and some that are device-specific
17:28 pinchartl: but if you want to know where the real fun will start
17:28 danvet: I think in the end we'll have some regrets no matter what
17:28 danvet: so just get a pile of acks from enough people and we're good
17:28 danvet: I'm never sure I want to know "where the real fun starts"
17:29 pinchartl: there's hardware that can expose a single frame captured from a sensor with different exposure times, output that as a line-interleaved frame, and prepend each line with one 32-bit word that tells which image it's part of. with a GPU that consumes that :-)
17:30 danvet: let's call that a 3d texture and I dunno
17:30 danvet: just give it a modifier that only applies to 3d textures
17:31 robclark: heh, line-interleaved array formats?
17:32 pinchartl: the camera world is a mess :-)
17:33 pinchartl: you're lucky you don't have to deal with 1kfps on displays...
17:33 malice: Wellllll
17:34 malice: Soon :D
17:34 pinchartl: :-)
17:34 krh: pinchartl: "echo ${PWD#/home/hoegsberg/workspace/mesa/}
17:34 krh: dang
17:35 malice: pinchartl: They have 480Hz already
17:35 krh: "4CC = pattern + bpp and modifier = packing" <- sounds good
17:35 malice: Not sure if publicly available, but there were prototypes at some point
17:35 krh: pinchartl: similar to how we have different fourcc for rgba vs argb vs bgra vs abgr
17:37 pinchartl: malice: what's the use case for that ?
17:37 pinchartl: krh: thanks for the confirmation
17:38 malice: pinchartl: Gaming? More = Better? :D
17:39 malice: And at some point, it will probably be more like "Why not?"
17:39 pinchartl: can the human eye see the difference between, for instance, 240fps and 480fps ?
17:39 malice: Idk
17:39 malice: In certain scenarios, probably
17:39 pinchartl: or maybe it only matters when recording the screen with a 1kfps camera
17:39 pinchartl: which itself should generate video that needs to be displayed on a 2kfps screen
17:40 pinchartl: and we can loop that forever \o/
17:40 malice: Videos are blurry, and you have no control over them
17:40 malice: It's way more noticeable in games than on videos
17:40 malice: But yeah, 480 is quite a lot
17:45 vsyrjala: if human eyes/brain could keep up with <big> fps then i suspect we wouldn't have much need for high speed cameras
17:45 malice: ...
17:45 malice: It's not like you can count the frames and look at them frame by frame
17:45 malice: You can perceive motion being smoother tho
20:38 anarsoul: daniels: hi, can we get commit rights for rellla for mesa? He's one of lima devs
21:06 daniels: anarsoul: Mesa has zero documented procedure to get commit rights, but I believe the way is to mail the list and ask
21:07 anarsoul: IIRC last time I asked in IRC but I don't remember whom
21:09 Venemo: I think there is an inofficial rule that one needs to have N commits in mesa before this can be granted, IIRC X = 25
21:10 Venemo: I don't know of any other rules about it
21:12 anarsoul: Venemo: he's got 32
21:12 anarsoul: :)
21:12 anholt_: hmm. dim apply patch.mbox is the thing I'm supposed to use for applying a patch from the list, right? It's been so long.
21:13 anarsoul: at least that's what "git log src/gallium/drivers/lima/ | grep 'Author: Andreas Baierl' | wc -l" said
21:13 anholt_: (it's just stalling doing nothing)
21:14 Venemo: anarsoul: then I think you just need to ask the right person who has rights to grant these rights
21:15 Venemo: anarsoul: also, AFAIK even if one has the rights, the preferred method of submitting code is still to open a MR on gitlab
21:16 anarsoul: Venemo: yes, that's what we do. But it would be nice if rellla was able to merge MRs
21:16 anarsoul: and assign 'lima' label to his MRs
21:20 Kayden: anarsoul: I just added him
21:20 anarsoul: Kayden: thanks!
21:22 Kayden: it's basically: 25-ish commits / 2-3 series + somebody with commit rights recommending they get access => sure, why not
21:46 daniels: Kayden, anarsoul: maybe submit an MR documenting that somewhere?
21:57 Venemo: it should be on the new website somewhere
22:07 pcercuei: Is there a kmscube-like example application that does not use EGL, just GBM?
22:10 krh: pcercuei: vkcube :-P
22:11 bnieuwenhuizen: krh: why does vkcube use gbm?
22:11 krh: bnieuwenhuizen: to allocate buffers for scanout
22:11 bnieuwenhuizen: why not use vulkan directly for that?
22:12 krh: it predates any kind of vk feature to allocate buffers with modifiers
22:13 krh: I guess we could've done an extension to export device mem as a dma-buf
22:13 krh: and settled for linear
22:13 krh: but we did an import extension instead and used gbm
22:13 bnieuwenhuizen: oh ... you're using the INTEL ext for import ...
22:15 pcercuei: krh: ah, thanks, that's surprisingly useful
23:39 bnieuwenhuizen: Is there a tool to list KMS plane info, supported formats & modifiers? Say something like vulkaninfo/xdpyinfo?
23:41 ascent12: bnieuwenhuizen: https://github.com/ascent12/drm_info
23:41 bnieuwenhuizen: Thanks!