00:29 jekstrand: airlied: If you review WSI patches, you get two new extensions for free. :P
00:49 airlied: jekstrand: will give it a look now
01:00 airlied: jekstrand: didn't feel like going one step further and hiding wsi_device from the drivers completely?
01:02 jekstrand: airlied: You mean just heap allocate it?
01:02 jekstrand: We could
01:02 jekstrand: I don't really care
01:02 jekstrand: I kind-of like embedding things rather than more pointers but meh.
01:03 airlied: jekstrand: yeah I just did it to completely make wsi_device opaque to the driver, like if it was a layer
01:03 airlied: but it's not really necessary
01:03 jekstrand: The one place it's a bit nice is that for modifiers I have to make the "extension" add an extra tiny entrypoint.
01:04 jekstrand: So I just make the driver assign it instead of piping it through a procaddress function
01:04 jekstrand: I'm perfectly content to hide it thought
01:08 airlied: jekstrand: I also did this: https://paste.fedoraproject.org/paste/dadT0PqzjtD~~Tp8DmVvFg
01:08 airlied: again just was one of those extra steps, I'm pretty happy with the final state of the series, we can discuss further things later :)
01:16 jekstrand: airlied: Hrm... I kind-of like that...
01:16 airlied: jekstrand: granted it's just local_fd now
01:16 airlied: since you droped the gpu flag
01:16 jekstrand: Yeah
01:17 jekstrand: Because, if you have fully generic prime support, why allow drivers to disable it? :-)
01:17 airlied: jekstrand: we still have that flag on the x11 specific interface btw
01:18 jekstrand: I'm not sure what you mean.
01:19 airlied: https://paste.fedoraproject.org/paste/HkKYuKwJkupYU516kCBiaQ/
01:19 airlied: you might want to squash a working version of that in
01:29 fredrikh: jekstrand: i assume it's not an issue with radv and anv, but VK_IMAGE_LAYOUT_PRESENT_SRC_KHR is not a valid srcImageLayout in CopyImageToBuffer
01:30 airlied: jekstrand: sent two further cleanups to the list, do with them as you wish :)
01:36 Lyude: Are there any good GPU benchmarks on Linux that would work without anything but GBM?
01:37 airlied: Lyude: don't think so
01:39 Lyude: :(
01:39 Lyude: guess I could just use a headless X server
01:40 airlied: Lyude: should I ask what you want to benchmark?
01:40 robclark: what, kmscube isn't a good benchmark? :-P
01:40 robclark:ducks
01:41 airlied: robclark: it lacks gears
01:41 jekstrand: fredrikh: We do make a couple of assumptions. :)
01:41 robclark: heheh
01:41 jekstrand: fredrikh: I'm hoping to significnatly reduce those assumptions over time until it's a bonified layer
01:41 kisak: so when are we going to see a million fps out of kmsgears?
01:42 Lyude: airlied: power measurements for nouveau clockgating
01:42 airlied: 1582/1644 (96.2%) dEQP-GLES31.*compute* - so close :-)
01:42 jekstrand: airlied: :)
01:42 jekstrand: kisak: I can give you a driver that'll do that. I can't guarantee correct rendering though. :P
01:48 kisak: airlied: someone should have mentioned to you that your r600 / GL 4.2 patchs put the high end cards past the GL spec that was advertized when they were sold originally
01:49 kisak: at least for the 6950
01:49 airlied: kisak: well in theory anything that can do GL4.0 can do GL4.6
01:50 airlied:isn't sure in practice how that works :)
01:50 kisak: I expect that's a huge headache without hardware compute support
01:51 airlied: well I don't think anyone made a gpu that can gl 4 tessellate without compute support
01:52 kisak: ah, I did not know that
01:59 Kayden: that's kind of awesome
02:14 airlied: imirkin_: is there a way to generate sparse binding images via GL? so we'd have DCL IMAGE[4], with no earlier ones?
02:16 airlied: or is it just ssbo I have to worry about sparse bindings for?
02:19 airlied: imirkin_: even setting a binding = 4 for a buffer ends up with BUFFER[0] for me in the tgsi
02:26 jekstrand: airlied: Thanks!
02:29 jekstrand: chadv: Review quickly before I get to itchy. :P
02:41 mareko: airlied: we have only sparse buffers in MesaGL
02:45 airlied: mareko: I meant sparse bindings of images/buffers as opposed to sparse objects
02:47 mareko: airlied: I think st/mesa remaps all slots to 0..n, it does that for samplers, it might be the same for images
02:48 airlied: mareko: yeah it appears to
02:52 Kayden: that's convenient
02:54 mareko: it happens for be convenient for GCN, which has shader slot descriptions in memory, so it only ever has to upload N slots without holes
02:55 mareko: however the original intent was to solve glUniform remapping of samplers in st/mesa
02:59 mareko: the catch is that when a shader is changed, st/mesa has to rebind all shader slots, because the mapping can be different
03:30 imirkin: airlied: nnnnot sure.
04:37 airlied:drops r600 compute v0.1
04:41 Bob131:ooohs/aaahs
04:51 airlied: it looks like today is patchbomb tuesday/wednesday
06:28 Bob131: airlied: I just got a chance to try out your R600 compute patchset, and I can report 100% fewer hard lockups running the piglit CL test suite! \o/
06:52 airlied: 3
06:52 airlied: p9
07:11 airlied: Bob131: oh that's an interesting side effect
07:11 airlied: I didn't know the piglit cl test suite caused hangs!
07:12 Bob131: a single run was taking about 90 minutes just from the number of times I had to hit the reset button
07:13 airlied: Bob131: would be interesting to know if one of the prep patches fixes it or a side effect of one of the features
07:13 airlied: 0005-r600-no-need-to-reinit-compute-regs.patch seems like it might help[
07:17 dolphin: airlied: As you might know, since -rc1, our CI has been on fire
07:18 dolphin: so I can't say I have certainty in the stability of the next -fixes pull I'm considering...
07:19 dolphin: I can say BAT is looking good, but the shards are just dead
07:21 airlied: dolphin: feel free to delay a day or two or send it and I can stick in CI when the fires are out
07:34 Bob131: oh, sorry airlied. I had erroneously assumed master was still causing hangs. I know it was failing about a week ago, so I'll try bisecting again
08:02 mbalmeida: Hi. I'd appreciate a bit of help to debug an issue related to building the amdgpupro driver on a vanilla Linux kernel
08:03 mbalmeida: Version of the Linux kernel is 4.10.17. It seems that the amgpupro driver requires the symbol 'drm_gem_prime_dmabuf_ops'
08:03 mbalmeida: The symbol is defined in drivers/gpu/drm/drm_prime.c but AFAICS is ' static' and not exported
08:05 mbalmeida: Is this a known issue ?
09:31 lynxeye: mlankhorst: we are seeing a bad interaction between modeset and first pageflip on imx-drm with 4.15
09:31 mlankhorst: more information needed?
09:31 lynxeye: it mostly comes down to imx-drm not using drm_atomic_helper_wait_for_flip_done in the commit_tail, so blocking commits don't wait for flip done
09:32 lynxeye: so userspace is able to queue the first pageflip before modeset flip completion, resulting in EBUSY with the new commit_setup
09:32 mlankhorst: seems you already have the solution then :)
09:33 lynxeye: do we require wait_for_flip_done to be used with the new commit setup? in that case the generic commit_tail needs cahnging
09:33 mlankhorst: use wait_for_flip_done instead of wait_for_vblanks
09:33 lynxeye: and is it reasonable to wait for flip completion in blocking commits, instead of just hw_done?
09:34 mlankhorst: I guess you might get away with fixing drm_atomic_helper_commit_tail and drm_atomic_helper_commit_tail_rpm..
09:34 mlankhorst: danvet: ? ^
09:34 lynxeye: I'm trying to clarify expectations, as imx-drm is probably not the only driver broken by this change
09:35 mlankhorst: I think we chickened out originally..
09:38 danvet: yeah blocking stuff should wait for flip_done I think
09:38 danvet: but I'm not really clear on what broke why?
09:38 mlankhorst: danvet: wait_for_vblanks != wait_for_flip_done
09:40 danvet: but wait_for_vblanks should be worse than wait_for_flip_done?
09:40 danvet: worse = waits longer if you race
09:40 lynxeye: danvet: without wait_for_flip_done in the commit_tail the blocking commit only waits for hw_done
09:40 danvet: I'd bet more on imx not signalling flip_done correctly ...
09:40 danvet:pre-coffee fyi
09:41 danvet: but we have a wait_for_vblanks in there?
09:42 danvet: or is there some race going on?
09:42 danvet: I mean I'm all for s/wait_for_vblanks/wait_for_flip_done/
09:42 danvet: I even thought mlankhorst typed a patch
09:42 lynxeye: wait_for_vblanks does a for_each_old_crtc_in_state, I guess there is no old CRTC in the case of initial modeset
09:42 danvet: old means old state
09:43 danvet: not old as in "was active when we started"
09:43 mlankhorst: yeah because for_each_old_crtc_state_in_state is a bit.. excessive :)
09:43 danvet: since the old_state will be freed we abuse it a bit for book-keeping, but that's all
09:44 danvet: lynxeye, in upstream you can see that we look at new_state->active
09:45 danvet: thanks to mlankhorst cleanup work it's less confusing now
09:45 danvet: but I still don't get why this broke ...
09:45 danvet:grabs some coffee
09:46 danvet: mlankhorst, btw what happend to that wait_for_flip_done patch?
09:47 mlankhorst: danvet: I think we chickened out from auditing all drivers
09:53 danvet: seanpaul, [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers
09:53 danvet: for you to ack I guess
10:11 lynxeye: danvet: just added a bit of tracing: wait_for_vblanks isn't more agressive than wait_for_flip done, at least not for the modeset
10:12 danvet: lynxeye, if it's less, then we indeed need to audit drivers and switch to flip_done
10:13 danvet: so for you the flip_done fires after the vblank_wait?
10:14 lynxeye: I've hacked our commit_tail to call both wait_for_vblanks and wait_for_flip done. the flip done waits for a flip on a crtc, the wait for vblanks apparently doesn't find anything to wait on
10:14 lynxeye: just digging in why
10:16 MrCooper: danvet: FWIW, DC is switching from wait_for_vblanks to _flip_done, because there were timeouts with the former
10:19 danvet: MrCooper, are you using the commit_tail stuff?
10:19 danvet: we might want to do that in the core ...
10:20 danvet: and timeouts with the former sounds like some bug somewhere
10:20 MrCooper: git grep commit_tail drivers/gpu/drm/amd/display/ says yes
10:20 danvet: mlankhorst, ^^ more reviewers for your old patch, can you dig it out again and cc: everyone?
10:24 mlankhorst: danvet: don't know if I still have it..
10:24 danvet: mlankhorst, also pls push the deferred fbdev fix to -fixes
10:24 mlankhorst: lynxeye: wait_for_vblanks is the old version of wait_for_flip_done, don't need both..
10:26 lynxeye: danvet: more info what happens: first weston does a drm_mode_setcrtc -> blocking commit with proper vblank wait, then drm_atomic_connector_commit_dpms blocking commit, but planes_changed == false, so no vblank wait, then nonblocking pageflip, which fails in the setup, as the flip_done hasn't signaled yet
10:26 lynxeye: mlankhorst: yeah but apparently the expectation was the wait_for_vblanks is always more agressive in waiting than wait_for_flip_done
10:27 lynxeye: it isn't in the above sequence
10:27 lynxeye: so the new check for flip_done in the commit setup is now breaking existing userspace
10:30 mlankhorst: hm need wait_for_flips_done
10:32 danvet: hm, should we flip that across the board?
10:33 danvet: and remove wait_for_vblanks()?
10:33 danvet: I only created the vblank wait thing because flip_done didn't exist yet
10:34 lynxeye: danvet: yeah, wait_for_vblanks seems like a good way to shoot yourself, given the new expectations of the helpers
10:37 lynxeye: a bit unfortunate that we now need to cram a series touching lots of drivers into 4.15-rc
10:39 lynxeye: minimal fix would be to really make wait_for_vblanks wait more agressively by letting it also wait if !planes_changed
10:39 mlankhorst: danvet: yeah I'm for removing wait_for_vblanks
10:40 danvet: lynxeye, if that's all we need then I think that's better
10:40 danvet: for -rc
10:40 danvet: and the full series for -next
10:40 lynxeye: okay, I'll give this a spin
11:36 mlankhorst: lynxeye: I'll give you my r-b and aply to fixes
11:37 mlankhorst: also adding output from dim fixes to it
11:42 mlankhorst: hm no Fixes: de39bec1a0c4 ("drm/atomic: Remove waits in drm_atomic_helper_commit_cleanup_done, v2.")
11:47 mlankhorst: danvet: can drm-misc-fixes be forwarded?
11:48 danvet: mlankhorst, done, but forgot to push out :-)
11:55 danvet: mlankhorst, done now for real, push your patches
14:09 seanpaul: danvet: re rockchip MAINTAINER patch, was waiting for v2 with heiko added
14:29 seanpaul: danvet: looks like my rerere-cache is borked
14:30 seanpaul: http://paste.debian.net/998162/
14:36 stschake: when is a dma_fence released/freed? every driver I can find gets a reference through dma_fence_init, then later signals it, but none seem to explicitly _put it
14:44 mlankhorst: stschake: they all do..
14:47 stschake: the only dma_fence_put for msm is in an error case, and for vc4, here it's deleting its only reference immediately after signaling: https://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_irq.c#L142
14:48 robher: robclark, xexaxo1: android recently added wide gamut support and this config fails with mesa (virgl). Anything jump out at you? https://www.irccloud.com/pastebin/ZgxGKLKX/
14:51 mlankhorst: stschake: looks like a bug in vc4? anholt? ^
14:53 xexaxo1: robher: am I reading this correctly - one is looking for a EGL_{RED,GREEN,BLUE and ALPHA}_SIZE of [at least] 16... don't think this was ever supported
14:55 xexaxo1: seemingly we adverise EGL_EXT_pixel_format_float, although the implementation is simply not there...
14:55 robher: xexaxo1: it is triggered if EGL_EXT_pixel_format_float is set which appears to be unconditional in mesa.
14:55 robclark: robher, heh, I didn't even realize you could create context like that (I thought just FBO.. shows what I know)
14:55 xexaxo1: like a few other extensions really... both in GLX and EGL land :-\
14:56 robclark: robher, but w/ virgl I suppose that maybe it also depends on host supporting that format..
14:56 robclark: which I guess x11 doesn't so host maybe doesn't??
14:56 mlankhorst: stschake: I know nouveau handles it correctly at least, it calls dma_fence_put in nouveau_fence_signal
14:58 stschake: okay, so at least they *should* do _put and I can stop looking for a convenience path or so that somehow drops the reference :)
14:59 mlankhorst: yeah as far as I can tell vc4 is leaking here..
15:00 mlankhorst: unfortunately I don't have a spare pi to test, they're all in use :(
15:00 robher: robclark, xexaxo1: FP16 support is relatively new?
15:01 danvet: seanpaul, but then heiko would need commit rghts too?
15:01 danvet: maintainer without commit rights is a bit silly
15:02 seanpaul: danvet: he's getting commit rights, no?
15:02 danvet: seanpaul, git reset --hard
15:02 danvet: I have no idea why we leak that stuff behind
15:02 robclark: robher, for off-screen render targets (like FBO), no.. but I assume it is outside of that?
15:02 seanpaul: yeah, already paved it
15:02 danvet: or maybe we need to add the entire rr-cache to .gitignore and force-add changes?
15:03 ajax: robclark: if it's specified as an egl attribute then it's not an fbo
15:03 robclark: ajax, right, that is my point
15:03 robclark: we've been able to render to f16 and f32 forever.. but the window system integration part, I'm not sure about
15:04 robclark: robher, does it work on real hw (ie. freedreno or vc4 possibly)?
15:04 xexaxo1: robher: seems like it (2016). mesa's implementation (41f7de477c68a5ae3fd8b086dfb4a8cc10a35c39) explicitly states that no new configs are exposed
15:04 ajax: it's mostly not wired up, no? like, we don't even have drm fourcc codes to name the format
15:04 robclark: I thought I saw a patch for the fourcc.. but yeah
15:05 robclark: for android it might not matter, as long as hwc doesn't try to scan it out directly
15:05 ajax: the one i saw was to make fp16 drawables work on intel for windows guests
15:05 ajax: which is... embarassing
15:05 robclark: it can certainly use it as a texture
15:05 robclark: yeah
15:05 xexaxo1: and the spec does not mandate that there will be any ... sounds a lot like the ARB_get_program_binary scenario
15:05 robher: robclark: will have to do a build.
15:06 robclark:wonders if any of the mobile display controllers can scan this out
15:06 ajax: hdr on your phone!
15:06 ajax: it won't look any better but at least it'll be slower
15:06 robclark: well, that is where android is going ;-)
15:07 xexaxo1: robher: reasonable solution is for Android to not assume fp configs solely on the presence of the extension.
15:08 xexaxo1: sadly it's a common misuse of ChooseConfig ;-(
15:11 robher: xexaxo1: don't really understand because the extension says EGL_COLOR_COMPONENT_TYPE_FLOAT_EXT is added. You're saying that ChooseConfig failure should be handled regardless of the extension?
15:13 xexaxo1: robher: precisely. presence does not imply that things will always succeed.
15:13 ajax: robher: it says that FLOAT is a valid thing to ask about, it doesn't say that any configs will be guaranteed to have that property.
15:16 ajax: we probably could fix mesa to only expose the extension for a given EGLDisplay if there was a float config in the list
15:17 ajax: i suspect we just say the extension is always present because it's simpler that way
15:20 xexaxo1: android compliance has extra requirements on top of EGL spec, which explains why they cut corners ;-)
15:22 robclark: so that said, if platform_android code dtrt, I would have thought this could work on android..
15:23 robclark: not sure about virgl, since I guess it also is limited by what host can do, but at least on real hw.. the gpu is perfectly capable to render to f16 and f32 formats..
15:25 robher: robclark: the format is at least defined in virglrenderer. Whether it succeeds in adding the format, no idea.
15:26 robclark: if virglrender uses the guest "screen" as a texture that it samples from, it might work out for virgle.. I'm not sure enough about how virglrender works..
15:27 robclark: it isn't uncommon for games (for example) to use f16 or f32 FBO's for intermediate rendering stages (and then use that as texture in next stage)
15:38 robher: Here's my fix: https://android-review.googlesource.com/c/platform/frameworks/base/+/550746?polygerrit=1
15:45 danvet: seanpaul, is heiko committer already?
15:46 seanpaul: danvet: as of last night, no
15:46 seanpaul: i think he hangs out here, but i forget his nick
15:47 daniels: mmind00: ^
15:47 seanpaul: that's it!
15:47 seanpaul:grumbles about non-firstlast nicks
15:48 danvet: seanpaul, add it to your magic thing?
15:48 seanpaul: a nick resolver?
15:56 danvet: seanpaul, yes pls :-)
15:56 seanpaul: danvet: added to the "if i get bored" pile
15:57 seanpaul: (although it doesn't look like mmind00 has set his realname, so it wouldn't work in that case anyways)
15:58 danvet: seanpaul, just a page really, almost no one has set their real name to anything meaningful
15:58 danvet: mmind00, so commit rights for rockchip maintainership?
15:59 seanpaul: danvet: it's less fun if i have to update the thing, i'd rather cross-reference the whois data
16:21 imirkin_: are there any modetest-like applications out there which test the "new" degamma/csc/gamma properties?
16:26 robclark:not aware of one..
16:26 robclark: would probably be good sorta thing to add to modetest
16:27 imirkin_: it looks like newer nvidia hw has something for this, but it'll require a lot of guess-and-checking, and an application that can show me that i have it right vs wrong would be very convenient.
16:29 danvet: imirkin_, igt?
16:29 imirkin_: danvet: is there something in igt for this? which puts up an image on the screen which will indicate to me if i got it right or not?
16:30 danvet: ofc there's something in igt for this
16:30 danvet: but needs crcs
16:30 danvet: I guess we could patch igt to use interactive testing as a fallback for crcs
16:30 imirkin_: ok, so ... not something i can just run and play around with by looking at it
16:30 danvet: we have some mode for interactive testing
16:31 danvet: imirkin_, well if you have crcs then --interactive-debug=crc or something like that will give you what you want
16:31 imirkin_: while i wouldn't be surprised if nvidia hw had crc functionality, i don't think we know how to operate it
16:31 danvet: ask nicely?
16:31 danvet:blissful optimist today
16:31 danvet: imirkin_, but yeah shouldn't be too hard to keep the interactive debug mode and just make all the crc tests pass in igt
16:32 imirkin_: having a non-interactive test suite we could run would clearly be awesome, but at the very least an interactive one would be nice
16:32 imirkin_: e.g. with modetest it's pretty obvious when things go right vs wrong
16:32 danvet: we have both, if you have crcs :-)
16:32 danvet: and the other bit can be fixed
16:32 imirkin_: this thing can't rely on me being able to tell 0xffffff from 0xfffffe with my eyes :)
16:32 danvet: but atm we have this nice modetest vs igt split
16:33 danvet: I think we do black and white
16:33 danvet: because anything but 0 and 1 could be affected by rounding
16:33 danvet: which upsets crcs
16:33 imirkin_: ok, well i should be able to tell that difference apart...
16:34 danvet: generally the crcs tests work like 1) draw reference frame using, grab crc sw 2) do the hw thing, grab crc3) compare
16:34 danvet: *using sw
16:55 imirkin_: danvet: just curious, where do your crc's live? just like some mmio reg that you read out? or does the hw write them into a buffer?
16:56 danvet: mmio regs
16:56 danvet: we get an interrupt every time a new one is ready
16:57 danvet: probably real hard to r/e, since generally never used in production, only validation
16:57 imirkin_: yeah
16:58 imirkin_: well, we can look for mmio regs whose value changes based on the fb
16:58 vsyrjala: maybe cycle the content of the display using n distinct frames and look for a pattern of n values in some register(s)?
16:58 imirkin_: exactly
17:21 eric_engestrom: xexaxo1: I just noticed https://mesa3d.org/release-calendar.html is quite out of date wrt 17.3
17:21 eric_engestrom: could you update it with the new expected dates?
17:30 fabe: anholt: a review of https://lists.freedesktop.org/archives/piglit/2017-November/023414.html would be appreciated (just the single patch, not the entire series)
18:08 xexaxo1: eric_engestrom: coming in a second
19:11 chadv: jekstrand: i'm in review mode now. i'm done digesting turkey.
19:14 jekstrand: :)
19:14 jekstrand: chadv: There are some modifiers patches in wip/dri3-v1.1 you may want to look at as well.
19:15 jekstrand: chadv: lfrb will be sending them to the list soonish but they're on my branch if you want to look early.
19:15 jekstrand: chadv: The end result is that the proposed dma_buf API works really well.
19:15 jekstrand: I more-or-less copied and pasted it for WSI and I'm very happy with both ends (driver and client) of it.
19:50 nchery: is there any documentation for writing a shader runner test?
19:51 robclark: jekstrand, btw, what was you idea about how (for example) SwapBuffers() works without a gbm sorta thing? I mean if we don't have the surface related bits of gbm, then I guess there needs to be some sort of new egl extension? That is kinda the part I was thinking of keeping (and not adding to $new_thing)
19:52 jekstrand: robclark: Good question. Maybe I've been in Vulkan land too long but I was kind-of thinking you would just import it as an EGLImage and bind it to a framebuffer.
19:52 jekstrand: I don't know if that's allowed though.
19:52 robclark: you can do fbo rendering..
19:52 ajax: "it"?
19:55 airlied: does anyone have a primer on hdr? like what renders in what formats and what formats get scanned out, and what monitors actually display
19:56 ajax: monitors accept 8/10/12 bpc unorms
19:56 ajax: you render to fp16 or rgb10a2
19:57 ajax: the crtc does Something to pack that down to the output format
19:58 danvet: there's magic infoframes involved too on the display side
19:58 danvet: so it's not just "scan out high bit depth"
19:58 danvet: it's more like yuv color spaces, except much worse
19:58 danvet: some of the hdr wire formats even are yuv
19:59 ajax: for 10bpc i'm not sure that's necessarily true, but yeah
19:59 danvet: well it's also a huge mess of competing standards
19:59 airlied: so dealing with in X is a pita because we can't change the root window depth on the fly?
19:59 danvet: and this time around we can't avoid all the color management fun with "just assume srgb"
20:00 danvet: since that will look like crap
20:00 danvet: airlied, at least for our hw the color conversion units will be rather limited
20:00 danvet: so you switch between color mapping in the gpu on a final pass and doing it with planes
20:00 danvet: depending whether overlays or not
20:01 danvet: I think vsyrjala has some kinda of plan somewhere
20:01 ajax: airlied: ... which is why the deepcolor extension describes how we lie about window depths, yes
20:01 airlied: ajax: cool so we'd never render X in HDR :)
20:01 ajax: the driver can change the scanout surface's format if it wants, it just has to make it look consistent to clients
20:01 ajax: no, you can
20:01 ajax: you just have to be prepared to do a bunch of bullshit
20:02 airlied: ajax: or rather we never render to the root window in hdr?
20:02 ajax: yeah.
20:02 danvet: smells like compositor in X
20:02 airlied: so we can start an X server in depth 24, and then have fp16 or rgb10a2 fullscreen windows okay?
20:03 ajax: needn't be fullscreen. if it's not fullscreen you do have to realloc the framebuffer though
20:03 ajax: danvet: X is a compositor already, just not a very clever one
20:04 airlied: so HDR rendering is kinda orthogonal to 30bpp X support?
20:04 ajax: yeah. plain depth 30 is just a gamma ramp like depth 24.
20:05 vsyrjala: you can do "hdr" even w/ 8bpc. that's how i've been pushing hdr to my tv here so far :P
20:05 danvet: yeah hdr = don't assume it's srgb, it's not much about actual bit depth
20:05 danvet: except with hdr banding is much worse with low depth
20:05 airlied:has acquired a hdr10 monitor (well it's in a box in the office where I'm not going for a while)
20:06 vsyrjala: iirc hdr10 is some kind of a marketing "standard" for cheap monitors that want to claim "hdr support"
20:07 vsyrjala: ie. they accept the stuff in, but what they output isn't anything special
20:07 airlied: vsyrjala: nope I think hdr10 is the other thing
20:08 airlied: it's the marketing name for monitor that actually have hdr support
20:08 airlied: and hdr is the name for monitor that claim int
20:09 airlied: at least hdr10 monitors are a lot more expensive
20:09 vsyrjala: depends on the manufacturer. when i was looking for a tv hdr10 was often advertized by the el-cheapo models, and the the higher end ones had some other hdr term which i've now forgotten
20:09 airlied: there is only one hdr10 monitor on sale
20:10 vsyrjala: it might be different with monitors
20:10 vsyrjala: or it might have already changes since i last looked, which was maybe half a year ago
20:11 airlied: there is also hdr10+ which yet another standard from amazon
20:12 airlied: but most devices seem to fall down on the brightness levels I think
20:12 airlied: they don't have enough nits :)
20:13 vsyrjala: yeah. nits is usually what i was looking at usually. if they even specified it anywhere, which they often didn't :(
20:14 vsyrjala: can't remember what this tv had. i think it was sort of midrange, so it might have a bit more nits that the average tv
20:17 vsyrjala: airlied: by any chance does that monitor do hdr over dp? i've not yet had the time to figure out what are the relevant standards for that, if any
20:18 airlied: vsyrjala: good question, won't know until I get it on my local desk I suspect the specs don't say much
20:18 airlied: dell up2718q
20:18 airlied: DP1.4, HDMI v2.0a is all I get
20:19 airlied: 100% Adobe RGB, 100% sRGB, 100% REC 709, 97.7% DCI-P3, 76.9% REC2020
22:00 TD-Linux: the most important part of "hdr" is telling the monitor what gamma to use (there are two common ones, smpte2084 and HLG)
22:02 TD-Linux: hdr10 basically says smpte2084 + 10 bit + rec2020 primaries & matrix, plus signaling maxcll (basically changing the gamma curve)
22:02 TD-Linux: mpv has a shader impl that can tone map back into sdr, and convert rec2020 primaries to srgb
22:03 TD-Linux: once you can tell the TV that you're sending smpte2084, you can turn off the tone mapping
22:03 TD-Linux: and if you tell the TV you're sending rec2020 you don't have to convert to srgb primaries
22:28 airlied: jekstrand: do you have way to check if a dma-buf fd is from i915 or another driver?
22:28 airlied: for the fd properties interface
22:39 jekstrand: airlied: I don't know of a way
22:41 jekstrand: airlied: It's not as big of a deal for us, I don't think, because we don't have a difference between on and off-card memory.
22:42 jekstrand: Though I should probably add a line to try and set_domain on it or something so we can reject it.
23:11 airlied: jekstrand: I'm guessing I might just flag all memoryTypes, and worry about adding an ioctl later :)
23:11 jekstrand: airlied: Sounds like a plan. :-)
23:11 jekstrand: airlied: I think I can probably figure out how to write that code.
23:12 jekstrand: airlied: It would be neat in radv if you could at least make the distinction between on and off-card memory and expose that via GetMemoryFdPropertiesKHR.
23:14 airlied: jekstrand: well we'd mostly be making the distinction between own device fds and other device fds
23:14 jekstrand: right
23:14 jekstrand: I'll write the "all memory types" code
23:46 jekstrand: airlied: Can I just use RADV_MEM_TYPE_COUNT?
23:47 airlied: jekstrand: (1<< RADV_MEM_TYPE_COUNT)-1?
23:47 jekstrand: Yup
23:47 airlied: yeah should be fine
23:47 jekstrand: ok