01:28 jekstrand: mareko: Does modern AMD HW have actual HW atomic counters? From my (likely poor) grepping of mesa code it looks like r600 does on some chips but radeonsi says no
01:31 jekstrand: bnieuwenhuizen, hakzsam: ^^
01:35 imirkin: (definitely only r600 has the "special" impl in mesa. not 100% sure about hardware level)
01:35 jekstrand: imirkin: So radeonsi lowers to SSBOs?
01:36 jekstrand: If so, that's 4 more lines of code I can delete. :D
01:36 imirkin: to the best of my knowledge, yes
01:37 jekstrand: Well, it also is to the best of my knowledge but that's not saying mutch. :-P
01:37 jekstrand: *much
01:38 imirkin: gotta trust someone sometime :p
01:38 jekstrand: Oh, I could always blind push a patch and see if anyone complains. :)
01:58 mareko: jekstrand: it has but we don't use them
01:58 mareko: and not even planning to
02:06 imirkin: mareko: just curious -- why not? not a perf win? or just too complicated?
02:07 mareko: instead the compiler just collapses 32 or 64 SIMD lanes of an atomic op into 1 lane atomic and executes that
02:07 mareko: imirkin: too complicated
02:07 imirkin: ah yeah, we keep meaning to do that on nouveau
02:11 mareko: hopefully one day the hw will collapse the atomic
02:12 imirkin: also nvidia likes to do this trick where they will check if a predicate is set on all lanes, and do unconditional jumps rather than predicated execution
02:13 imirkin: i.e. if you have if () { } else { }, they will check if it's the same on all lanes, and jump around
02:14 mareko: we have explicit jump instructions done by the scalar unit
02:16 mareko: the compiler usually generates both types of branching: jumps and thread masking, but tiny branches only get thread masking
02:17 imirkin: right, obviously for a single instruction, the checking is more expensive
02:17 imirkin: there's some threshold where nvidia adds the jumps
02:17 mareko: the jump itself has some cost
02:17 imirkin: nothing's free in this world =/
02:18 jekstrand: mareko: Cool. I'll delete your memory_barrier_atomic_counter handling too. :)
06:05 anarsoul: is there a way to emulate 24-bit RGB formats in mesa if they're not supported natively?
07:37 hakzsam: CI broken https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1297105
07:44 bbrezillon: pinchartl, ahajda: regarding "drm/bridge: Fix drm_bridge_chain_pre_enable()", I'm no longer sure what I should do
07:44 bbrezillon: should I patch all bridge_chain helpers to take an encoder instead of a bridge, or should I keep things as they are now and update the doc accordingly?
07:46 tomeu: hakzsam: looking at it
07:49 hakzsam: dcbaker: no release calendar for mesa 20 btw?
07:54 tomeu: tpalli: have retried a few jobs in !3256 and hopefully now it will pass CI and be merged
07:55 tpalli: tomeu ok, thanks
07:56 ahajda: bbrezillon: the most important thing is to fix regressions, so IMO you can apply these patches. Docs are incorrect for other helpers as well so their update can be done in separate patch, together with api change.
07:56 ahajda: bbrezilllon: if api change is OK :)
08:03 tomeu: hakzsam: if you retry the t860 job in your MR, it should pass now
08:03 hakzsam: tomeu: great, thanks
08:03 tomeu: well, guess you need to rebase anyway
08:04 tomeu: np, sorry about the downtime
08:04 bbrezillon: ahajda: already pushed the 2 critical fixes (VC4 and Exynos)
08:04 hakzsam: yeah, since marge is broken
08:05 bbrezillon: patch 1 doesn't fix a real bug since all callers for drm_bridge_chain_pre_enable() pass the first bridge
08:05 bbrezillon: *callers of
08:06 bbrezillon: ahajda: and that's the API change I wanted to discuss :)
09:58 j4ni: airlied: danvet: considering that we (i915) apply all of our fixes to our next branch and then backport to fixes, should we just stop feeding our fixes branch to linux-next? is there any added value, and just conflicts for linux-next folks?
09:59 j4ni: dolphin: vivijim: ^
10:02 dolphin: a worthy question
10:22 danvet: j4ni, hm good point, I guess the for-linux-next* branches predate the i915 cherry-pick flow by a margin
10:22 danvet: otoh as soon as the pull lands in drm-fixes the conflict will pop up anyway
10:23 danvet: all we lose is some early warning (assuming that dropping cherry-picks is not something we do often)
10:28 j4ni: an alternative is *gasp* dropping the critizised cherry-pick workflow...
10:28 j4ni: ...but that's a different set of worms
10:29 j4ni: (different flavor of canned worms?)
11:37 danvet: j4ni, was sfr actually unhappy anywhere?
11:38 danvet: I figured he's plenty used to this by now
12:51 mlankhorst_: bbrezillon: safe to do a pull request now?
13:19 dv_: hi. with just the linux framebuffer, I can make screencaps simply by using dd if=/dev/fb0 of=dump . but with KMS & DRM, this does not work.
13:19 dv_: so, in such a case, how could I make a screencap?
13:22 bbrezillon: mlankhorst_: I think so
13:22 bbrezillon: mlankhorst_: I pushed all the fixes I wanted to push
13:29 GyrosGeier: dv_, there is a good chance that there are multiple "on-screen" buffers that are cycled through
13:30 dv_: I know. but I though perhaps there's some way to get access to the front buffer
13:30 GyrosGeier: probably not without synchronization
13:37 MrCooper: dv_: only the display server displaying via KMS can reliably get a capture of the displayed contents in general, so get it from that
14:15 bl4ckb0ne: tpalli: hiya, i think it would be easier to discuss here rather than on the MR
14:16 bl4ckb0ne: regarding https://gitlab.freedesktop.org/mesa/piglit/merge_requests/205, i think I lack the free time and overall piglit knowledge to add a gles test
14:17 bl4ckb0ne: the extension i added is for gl 2.0 and gles 2.0, so it could fit in the existing gl tests
14:17 bl4ckb0ne: but i fully agree that a gles test in piglit would be a nice thing to have
15:11 dschuermann: robclark: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3320
15:58 imirkin: is there a polite way to ban elima1 temporarily while he figures out his internet situation? or just try to ignore the join spam?
16:06 kisak: imirkin: a kick with a please fix your client message?
16:08 nroberts:prods him on the internal Igalia chat
17:39 dcbaker: hakzsam: I'm not making the 20.0 release, that's going to be jasuarez I think
17:40 dcbaker: mareko: I had to resolve some conflicts with one of your patches on 19.3, it's the top commit of staging/19.3, could you look at it and let me know if that looks okay?
18:39 anholt_: dcbaker: any idea why format_unpack.c (for example) is recompiled every time I git commit?
18:42 dcbaker: anholt_: no, could you run ninja with -d explain, it should tell you why it decided to do that
18:43 anholt_:waits for this test run
18:45 anholt_:eyes nonzero UnexpectedPass from the nir-to-tgsi branch on softpipe
18:58 anholt_: dcbaker: not feeling enlightened https://paste.centos.org/view/661dd31b
18:59 dcbaker: anholt_: do any of those include the git_sha.h (or whatever it's named)
18:59 anholt_: not that I can see (just context.c, version.c, a couple other .cs)
18:59 anholt_: git_sha1.h is explicitly listed on format_pack.c.o's ninja build deps
19:00 anholt_: along with other unrelated generated files (program_parse.tab.h, get_hash.h, etc.)
19:00 dcbaker: some .h including other .hs probably
19:01 anholt_: it's notable that these are generated files with spurious dependencies on other generated files.
19:02 anholt_: dcbaker: git_sha1.h, for example, never appears in a .h.
19:28 mareko: dcbaker: it looks good
19:28 dcbaker: awesome, thnaks
19:30 dcbaker: anholt_: I'll have a poke at it in a couple of minutes, because you're right, it does look odd
19:32 anarsoul: isn't it time to ban elima1 till he figures out what's up with his client?
20:00 mdnavare: keithp: Hi Keith I was looking at some of your blogs on Present extension and presentcompletion notify events and trying to understand what we currently have in X and Mesa and how we can make use of that for say full screen games to send a flip event to the display driver to display the new frame on the screen and how we can synchronize this with the display rate using VRR
20:05 keithp: mdnavare: present already has most of the mechanism you need for this; you can queue presents for arbitrary times, which would let you control VRR from the app
20:05 keithp: what it doesn't have is any reporting on what reasonable VRR intervals are
20:06 keithp: It might be possible to express those limits using output properties, something like 'min frame interval' and 'max frame interval' values
20:07 keithp: full screen games already get reasonable feedback from present, although Vulkan is missing some functionality to expose that above its API
20:07 keithp: There's a couple of efforts going on in the Vulkan SI group to add extensions for this
20:10 mdnavare: keithp: so currently for full screen games, they use this present extension or GLX_OML_sync_control ?
20:13 mdnavare: keithp: Also when you say it can queue presnets for arbitrary times, that means say the refresh rate varies from 40hz to 120Hz, with this present extension, it can request flip events at these various times based on the frame duration?
20:13 keithp: GLX_OML_sync_control is implemented using present
20:14 keithp: as is the Vulkan google display timing extension
20:14 keithp: and, yes,present lets the application specify when it wants a frame shown using time values
20:14 keithp: so it should be ready for VRR there, although I don't think anyone has hooked it up in a driver
20:17 mdnavare: keithp: I wonder how AMD currently does it in their Mesa stack, hwentlan?
20:19 mdnavare: keithp: so for me to scope the work required for VRR, I should add that the present extension has the capability to specify when it wants a frame shown using time values but that needs to be implemented in the mesa driver along with setting the vrr_enabled crtc property for the application that needs vrr
20:20 mdnavare: keithp: I have also sent this patch : https://patchwork.freedesktop.org/series/68489/ that adds drm helper to extract the vmin and vmax from EDID and I will add next step to expose those to userspace through crtc property
20:20 keithp: should only need work in the X bits -- all of the mesa side should 'just work'
20:20 keithp: mdnavare: cool
20:21 mdnavare: keithp: Okay so Mesa side should already be sending the timestamps through the API, now X needs to somehow capture this and send it to display driver through a new IOCTL?
20:22 mdnavare: not sure if my understanding here is correct?
20:23 keithp: your understanding matches mine at least?
20:23 keithp: I'd assume you'd include this information in the flip ioctl request to the kernel
20:24 mdnavare: keithp: yes we can modify the flip ioctl to specify the frame duration i guess
20:24 keithp: or add a new one
20:24 keithp: whichever seems best
20:25 mdnavare: keithp: Right now X just sends the flip ioctl call whenever it sees a frame render request from Mesa?
20:26 keithp: one that matches the flip requirements (full screen, on top)
20:26 keithp: it will delay sending the flip request until after the vblank for the preceding frame
20:27 keithp: so if you're doing 30Hz on a 60Hz monitor, X delays sending the flip ioctl until after that second vblank has arrived
20:27 jekstrand: airlied: Can you ack my LLVMpipe patch in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3307
20:27 keithp: Ideally, you'd be able to send the flip ioctl to the kernel at any point and have the kernel wait. However, you would also like to be able to replace the queued flip in the kernel so you could implement Vulkan's 'MAILBOX' mode
20:29 mdnavare: keithp: So because the X currently takes care of delaying the flips as per the application's refresh rate or timestamps that it sees in the GLX_OML_sync_control extension, the kernel just shows the same frame twice since it is displaying at a fixed 60Hz
20:29 mdnavare: ?
20:30 keithp: yup
20:31 keithp: however, that works because we're using a fixed refresh interval
20:31 mdnavare: keithp: And now if we see VRR support, X should not delay the flip requests but just send it as per the time values in GLX api and kernel will try to terminate or expand the vblank accordingly to sync with the requested flip rate?
20:31 keithp: yes
20:31 keithp: which is fine except you then commit to the next frame early, which means you really can't do MAILBOX
20:32 keithp: right now, we fake MAILBOX mode by allowing you to replace frames up to the point where they're queued to the kernel
20:32 mdnavare: keithp: hmm i donno how he Mailbox mode works
20:32 keithp: I don't know if you want to try to fix that problem; it's not exactly related to VRR, although VRR makes it more visible
20:33 keithp: MAILBOX lets you keep drawing frames and sending them to the system for presentation, the system picks the last frame it was given before vblank and shows that
20:33 keithp: we can't do that reliably using DRI, sadly
20:35 mdnavare: keithp: but as far as VRR changes are concerned all of these changes just happen in X to avoid the flip request delaying and use the presnet time values to directly to send the flips? But then why would you need to send the frame duration with it since if flip requests occur at the expected refres rate then kernel can just start displaying as soon as the frame is reay or worst at the max blanking time supported
20:35 keithp: oh, you might want to read up on googles display timing extension for Vulkan. It's a mixture of better reporting and frame time requesting; the frame time requesting bits are definitely relevant here
20:36 keithp: the frame shouldn't be displayed until the time specified by the application -- if you display too soon, you'll get judder
20:37 keithp: that's because the image is computed for a specific time
20:37 keithp: which is especially important in head-mounted display systems
20:40 mdnavare: keithp: ah okay so say GLX API says present frame for time t1, currently X delays the flip event until that t1 is reached, now with VRR it will send the flip with t1 presentation time and kernel will just stretch its blanking interval until T1 or terminate it earlier if t1 is smaller than the nominal blanking interval for 60Hz?
20:40 keithp: current X delays until just after the frame before the frame closest to T1, because it doesn't have VRR support :-)
20:41 keithp: otherwise, yup, send the flip to the kernel with t1, the kernel schedules as best it can
20:41 keithp: ok, I've gotta run; heading to LCA this afternoon
20:42 mdnavare: oh okkky cool thank you so much for this discussion keithp
20:42 mdnavare: keithp: Hopefully i can discuss further with you if you are going to Fosdem
20:42 keithp: have fun; alas I'm missing FOSDEM because I'm going to LCA
20:43 mdnavare: oh :( Well but LCA would be awesome
20:43 mdnavare: i believe you will see danvet too
20:43 keithp: \o/
20:44 airlied: jekstrand: just back from hols, will look today
20:46 mdnavare: airlied: Also mind taking a look at : https://patchwork.freedesktop.org/series/68489/
20:48 airlied: mdnavare: will do
20:48 jekstrand: airlied: Cool
20:48 mdnavare: airlied: awesome thank you so much
20:55 alyssa:wonders how hard it would be to heuristically detect multipass stuff
20:55 Sachiel: leeloo dallas, multipass
20:55 alyssa: texture([FBO], gl_FragCoord.xy / [screen size])
20:56 alyssa: ^ That general structure can be worked out at compile time, and checking that the texture/uniform make sense can be done at runtime, probably
20:59 imirkin_: see ARB_texture_barrier for how that's supposed to work
20:59 imirkin_: you're not supposed to add in an implicit barrier - up to the user to throw in a glTextureBarrier()
21:00 sravn: fatfingered and got this: "In order to use the DRM repositories, you MUST use the 'dim' ..."
21:00 sravn: Thanks to whoever added this to the repo infrastucture
21:01 alyssa: imirkin_: Mm, the goal is performance-related, not functionality
21:03 alyssa: Trying to figure out if we can detect GL/MRT-style multipass stuff at runtime and if stuff is sane rewrite the shaders to keep everything on chip (with the mechanism of Mali's Pixel Local Storage, basically optimized vulkan subpasses)
21:03 alyssa: May be too many gotchas for it to work
21:03 alyssa: But it's the only way to make deferred shading not suck..
21:04 imirkin_: that doesn't work for multipass in general
21:04 imirkin_: only for the cases covered by ARB_texture_barrier
21:04 alyssa: So presumably barriers would be one of the criteria required :)
21:05 imirkin_: find a specific use you want to optimize first
21:06 alyssa: Specific use, as in an app?
21:06 imirkin_: yes
21:06 imirkin_: which exemplifies the thing you're trying to address
21:06 alyssa: STK's gles3 renderer
21:06 imirkin_: otherwise you do a ton of work for nothing
21:07 alyssa: The gles3 renderer, with "advanced effects" turned on, is a deferred shading pipeline with a lot of passes at maximum effects level and that's bonkers for tilers
21:07 robclark: I'm pretty sure that auto-pls is not sane
21:08 imirkin_: alyssa: so how does your proposal improve that? assuming an infinitely smart rewriter?
21:09 alyssa: imirkin_: pixel_local_storage is a mali extension specifically to support deferred shading pipelines, by allowing you to render/read right out of the tilebuffer instead of main memory
21:09 imirkin_: right i get that
21:09 alyssa: So if you stay within 128-bit of data, everything stays on chip and you save ludicrous amounts of memory bw
21:09 imirkin_: ok
21:09 imirkin_: so have you found the specific shaders in stk that will benefit from this?
21:10 ccr: ludicrous speed!
21:10 alyssa: which - I'd have to profile/perf count first - I'm assuming bottlenecks this kind of thing
21:10 imirkin_: that's the problem though ... bottleneck could be coming from shaders that would not benefit from this at all
21:10 alyssa: This is still pretty far out, just trying to mentally map my next N time intevals.
21:10 imirkin_: it sounds like a pretty crazy idea though, imho
21:10 imirkin_: doesn't make it bad though
21:11 robclark: I'd expect PLS would help stk some.. but I'm less convinced it is a sane thing to try to detect in the games rendering and replace multi-pass with single pass + PLS
21:11 alyssa: robclark: What about with an explicit whitelist of apps known not to break with it?
21:11 alyssa: (I guess that would put me in nv blob territory >.<)
21:12 robclark: you might as well just re-write stk ;-)
21:12 alyssa: Pff
21:12 sravn: robclark: the panel-simple.yaml is not committed to drm-misc-next, so you are good to go.
21:13 robclark: I'm sure they'd accept patches, they all seemed friendly enough when I'd asked questions before in #stk
21:13 sravn: robclark: s/not/now/
21:13 alyssa: I kinda wish PLS (or something like it, maybe closer to Vulkan subpasses) would have caught on. \shrug/
21:13 robclark: sravn: ok, thx
21:13 alyssa: I guess I have panvk to look forward to for that ;P
21:39 austriancoder: piglit does not really have some glshademodel tests or did I just not find them?
21:39 anholt_: pendingchaos: is there a good way for me to have nir_opt_load_store_vectorize() avoid loading across a vec4 boundary?
21:43 anholt_: austriancoder: you're probably looking for the interpolation tests.
21:43 anholt_: generated code
21:44 imirkin_: austriancoder: i was sure there were some
21:44 imirkin_: you mean glShadeModel(GL_FLAT) and so on?
21:44 imirkin_: they're in shader_test's
21:44 imirkin_: not to mention e.g. tests/spec/gl-1.0/dlist-shademodel.c
21:44 anarsoul: is there a way to emulate certain formats that aren't supported by hardware natively?
21:44 imirkin_: tests/shaders/glsl-fs-flat-color.c
21:44 anarsoul: mali4x0 can sample from 24-bit RGB, but can't render into it
21:45 imirkin_: some in the provoking vertex tests
21:45 imirkin_: and yes - like anholt_ said, in the generated interp tests
21:45 anarsoul: but looks like chromium wants FBOs with GL_RGB format
21:45 anholt_: anarsoul: basically no hardware supports rendering for 24bpp, that's entirely normal to be totally unsupported.
21:45 anholt_: FBOs with GL_RGB will be automatically promoted to 32bpp.
21:45 anarsoul: hm, I wonder why it fails then...
21:45 imirkin_: highly second that advice - forget 24bpp packed rgb exists
21:46 imirkin_: remove support for it in your driver entirely
21:46 anarsoul: oh, OK
21:46 imirkin_: and then all will be well
21:46 anarsoul: imirkin_: anholt_: thanks, will try
21:46 imirkin_: the only "packed" format worth supporting is RGB32, and *ONLY* for PIPE_BUFFER's, since it's required by ARB_tbo32 and so on
21:47 imirkin_: [obviously only useful if you support texture buffer objects in the first place, forget if they're required for ES3 or not]
21:49 pendingchaos: anholt_: I don't think there currently is one
21:49 pendingchaos: you could require that 8/16-byte loads are 8/16-byte aligned but that would disallow 8-byte loads with an offset like n*16+4
21:49 austriancoder: imirkin_: ahh... shader_test .. now I only need to do some python magic as written in the docs to just run these tests
21:49 austriancoder: thanks
21:49 imirkin_: austriancoder: bin/shader_runner foo.shader_test -fbo -auto
21:49 imirkin_: if you want to run all of them, piglit-run.py -t interpolation or whatever
21:50 austriancoder: imirkin_: I want to run all that have something to do with shademodel
21:50 anholt_: if you pass generated interpolation tsets, you're probably done.
21:50 imirkin_: grep -rl shademodel generated_tests | xargs bin/shader_test -fbo -auto
21:52 austriancoder: superb... thanks
21:53 imirkin_: but probably good to run all of those tests since they will point out a wide variety of issues
21:53 imirkin_: they're pretty picky about this stuff. hard to get everythign right.
21:53 imirkin_: esp coz of stupid GL 3.0 rules
21:54 imirkin_: where you can stick noperspective/flat on gl_Color but not gl_SecondaryColor
21:59 craftyguy: jasuarez: are you the release manager for mesa 20.0?
22:26 Ntemis: @endrift pine64 showed me the finger :)
22:26 endrift: huh
22:26 Ntemis: so no ansi keyboard from your pinebook
22:26 endrift: wat
22:26 endrift: oh you mean replacing the keyboard on mine
22:27 endrift: I forgot about that
22:27 Ntemis: yes
22:27 endrift: yeah I wasn't expecting it
22:27 Ntemis: they didnt respond back when asked
22:27 Ntemis: usually they do
22:27 endrift: I'm probably just gonna buy a second one and resell my first one
22:27 endrift: I have a friend who said she'd buy it off me
22:27 Ntemis: good to know and sorry i tried ...
22:27 endrift: no worries
22:28 endrift: it was worth a shot
22:28 Ntemis: yeah
22:28 Ntemis: so.. to me point on visiting you guys again
22:28 endrift: also man elima1 fix your connection
22:29 anarsoul: Ntemis: I doubt they have spare parts atm
22:30 anarsoul: also I'm not sure about PBP but it wasn't trivial to replace keyboard on original PB
22:30 Ntemis: am about to enable panfrost on mesa 19.3.1 and 5.4 for xu4(odroid) and i was wondering of mali t628 is supported
22:30 Ntemis: of=if*
22:31 anarsoul: I don't think it's supported
22:31 anarsoul: and you should ask #panfrost
22:33 Ntemis: thanks @anarsoul
22:33 endrift: echoing anarsoul, I seem to remember hearing it wasn't supported a few days ago, but #panfrost would know better
22:34 Ntemis: on it to find out
22:59 airlied: okay he's ignoring me :-P
23:00 imirkin_: lol, fail
23:00 imirkin_: ~devel
23:00 imirkin_: vs devel
23:01 airlied:sucks at irc mangement
23:01 airlied: jekstrand: done
23:02 jekstrand: airlied: thanks!
23:06 airlied: mdnavare: might be nice to have a blank line between the if (data->type != EDID_DETAIL_MONITOR_RANGE) continue and comment on next line, but otherwise looks good to me, might be nice to get vsyrjala or hwentlan to ack it as well
23:45 dv_: I have a project here that does a splashscreen simply by dd'ing a raw .rgba image to /dev/fb0 . of course, this means that no scaling, color conversion, etc. is done. however, that project also now uses KMS.
23:45 dv_: is there a recommended simple way to do a splashscreen with KMS?
23:46 imirkin_: what do you want after the splash screen?
23:47 dv_: this is on an i.mx6. after the splashscreen, a qt5 based application takes over fullscreen.
23:47 dv_: qt5 uses GBM here to generate an EGL context and render to screen
23:48 imirkin_: it's tricky to get this without a blink, i think
23:48 dv_: well if it shows black for a little moment that's ok
23:48 imirkin_: this is one of the things kms does poorly - handoff between applications
23:48 imirkin_: oh, then you just want a dumb little application that displays an image?
23:48 dv_: yeah
23:48 dv_: what is important though is to make sure that the login prompt does not show up
23:48 dv_: otherwise the transition truly is jarring
23:49 imirkin_: why would the login prompt show up?
23:49 imirkin_: just remove it from /etc/inittab
23:49 dv_: it currently does ... oh well I suppose disabling ttys from framebuffer would do the trick
23:49 imirkin_: (or whatever ghastly systemd thing you might be using)
23:52 dv_: so anyway, about the dumb little application
23:52 dv_: any recommendations?
23:53 imirkin_: more complicated than what you need, but have a look at modetest in libdrm
23:53 imirkin_: it's used for testing all kinds of stuff
23:53 imirkin_: so it has more functionality than you need
23:53 imirkin_: but basically just set up a fb, dump the data you want into it, and go
23:53 dv_: hm interesting
23:53 dv_: I was originally looking at plymouth, but it seems overkill to me
23:54 imirkin_: that's like the "proper" solution
23:54 imirkin_: and it handles handoff to things too
23:54 imirkin_: somehow.
23:54 airlied: sleep(5) :-P
23:54 dv_: unfortunately, this seems to involve a hardcoded list of supported things
23:54 imirkin_: airlied: fancy!
23:55 imirkin_: dv_: https://cgit.freedesktop.org/mesa/drm/tree/tests/modetest/modetest.c
23:55 imirkin_: look at the non-atomic stuff if you don't want to hurt your head
23:55 imirkin_: basically everything you need is here: https://cgit.freedesktop.org/mesa/drm/tree/tests/modetest/modetest.c#n1443
23:56 imirkin_: bo_create is fairly simple, in buffers.c (the complexity is around trying to handle various formats, etc -- like i said, this is a testing tool)
23:57 dv_: ok thanks