08:49Shibe: would explicit-synchronization allow flipping without the cpu being involved? If I understand correctly, then right now an app first tells the compositor it's done rendering, at which point the compositor asks KMS to flip. with a dma_fence I guess it would just hand that to KMS and it could flip itself?
08:53lynxeye: Shibe: No, right now the app hands the compositor a buffer with a implicit fence, which will be ready sometime in the future (when the fence signals). The compositor can already hand this buffer to KMS and schedule a flip. The kernel driver will then wake up when the fence signals and execute the flip.
08:58pq: Shibe, if you mean continuously updating frames without the CPU being involved, then no, at least Wayland architecture very much relies on the display server handling client updates frame by frame since things can change dynamically.
08:58pq: that is irrelevant to how they sync
10:59j4ni: pinchartl: is this good to go now? http://email@example.com
11:01pinchartl: j4ni: I'm not fond of the hdmi_ prefix in this case, but not to an extent that I'd like to block the patch, so no objection
11:02j4ni: pinchartl: okay, thanks! and if the naming starts bugging you too much, you know how to fix it! ;)
11:03pinchartl: a previous version proposed an alternative naming is I recall correctly, but it was rejected
12:40pcercuei: Trying to use a PRIMARY drm_plane provided by a different component in my ingenic-drm driver
12:41danvet: pcercuei, allocated with devm_kzalloc?
12:41pcercuei: I can create the plane just fine in the component, but how can I get a pointer to it in the main driver, in order to call drm_crtc_init_with_planes()?
12:42pcercuei: danvet: yes
12:42pcercuei: but the code is still very young
12:42danvet: expect an oops on unload
12:43danvet: or KASAN splat at least :-)
12:43danvet: pcercuei, so essentially the way it's generally done is all components register their components
12:43danvet: but don't do any setup
12:43danvet: then in master_bind you create the drm_device
12:43danvet: and pass that around as the void * argument to component's bind function
12:43danvet: then in there you create the planes
12:44pcercuei: yes, that's what I have in place right now
12:44pcercuei: the thing I'm stuck at is drm_crtc_init_with_planes()
12:44danvet: if your crtc is also a component, I guess you need to hand-roll something of your own
12:44pcercuei: since it requires a pointer to the drm_crtc, which is in my main driver, and a pointer to the drm_plane which is in my component driver
12:44danvet: to make sure planes are all created already
12:45danvet: other option: not quite that many components
12:45danvet: they are meant to help write drivers, not hinder
12:45danvet: no obligation to use them
12:45danvet: I think makes more sense to use them for stuff like output encoders, which are more variable
12:46pcercuei: The component in question is a IPU driver, which can do scaling and color conversion, and which has a different register area, interrupt and clocks
12:46pcercuei: so a component makes sense
12:46danvet: or maybe try to stack the components?
12:47danvet: i.e. the crtc itself is a component master, which passes the drm_crtc * pointer as the void * to the plane components?
12:47danvet: from a quick search all other drivers with components have their crtc/planes together
12:48danvet: or other option, create the drm_crtc at the top level master_bind
12:48danvet: and stuff the IPU and planes in there as components
12:49pcercuei: the "component helper usage recommendations" in gpu/drm/drm_drv.c seems to say that the struct drm_device should be passed as the driver data, but indeed if I pass the drm_crtc instead, that would work for me
12:50pcercuei: ah, no. I'd need a pointer to drm_device too
12:52pcercuei: There doesn't seem to be a way to iterate over components, either
12:55pcercuei: Is there maybe a way to create the CRTC without a master plane, and add it afterwards, just like how it's done for overlay planes?
12:56danvet: I guess we could make that possible with a new function
12:56danvet: and then add a check at drm_dev_register time that no driver forgot to do so
12:56danvet: pcercuei, what I meant is to have 2 component masters
12:56danvet: one for the drm_device
12:56danvet: and one for the drm_crtc
12:57danvet: the drm_crtc would bind the planes and other stuff together
12:57danvet: and build the drm_crtc
12:57danvet: the drm_device would then bind the drm_crtc and other stuff together into the overall drm_device
12:58danvet: so from the drm_crtc->master_bind you'd register the drm_crtc component, but don't yet bind the components of the drm_crtc
12:58danvet: then when the drm_crtc->bind function is called you also know that all the crtc components exist already (since you didn't register your component for the overall drm_crtc before that)
12:58danvet: and you can bind them, passing your crtc structure to their ->bind callback
12:59danvet: and then do the drm_crtc_init_with_planes
12:59danvet: it's a bit russian doll, bit I think should work
12:59danvet: +/- locking fun in component.c$
13:03danvet: (the locking fun is nasty, iirc we've done nested components before)
13:05karolherbst: is there a way in meson to disable searching in system directores in find_library?
13:17pcercuei: danvet: it'd be simpler, if there was a way to iterate over the components
13:18pcercuei: then I can get the plane using a simple dev_get_drvdata()
13:20danvet: pcercuei, but if you're unlucky it's not yet set up
13:20pcercuei: if it's not yet set up, then component_bind_all() would return -EPROBE_DEFER, no?
13:47MrCooper: jvesely: really sad that Gentoo are still screwing their users with BUILD_SHARED_LIBS after all these years...
13:50karolherbst: MrCooper: anyway, I would like to enforce llvm + clang libs from the same directory.. just wondering on how to achieve this
13:51karolherbst: this alone could get rid of a lot of issues
13:51MrCooper: I hope a Meson expert can jump in
13:51karolherbst: well, find_library can't do it afaik, but yeah
13:51karolherbst: would be usefull to have something
15:33ajax: karolherbst: i think find_library can be twisted into enforcing two dependencies be from the same library, but what problem is this trying to solve?
15:37ajax: so wrt minimizing the dollar cost of CI: which parts of the pipeline are the most expensive? is it a particular set of build or test stages, or container creation, or..
15:47MrCooper: ajax: for Mesa currently egress traffic for pulling docker images from the registry
15:49MrCooper: that's the bulk of ~1TB per week; pulling artifacts is less than 100GB per week now
15:52MrCooper: to put things in perspective, all fdo projects together generated a bit over 3.5TB of egress over the last week
15:58dos1: hi! coud anyone point me to how could I check what is the reason of mesa reporting OpenGL 1.3 as maximum supported version on etnaviv with GC7000?
15:59dos1: using MESA_GL_VERSION_OVERRIDE=2.1 makes it work (otherwise GLX fallbacks to software rasterizer)
15:59dos1: on GLES it's reporting 2.0 correctly
16:02lynxeye: dos1: wrong condition in one of the feature checks
16:18dos1: lynxeye: thanks! seems it fails because ARB_shadow is not exposed
16:20dos1: ...which makes sense given there's 8d5f905faad76a46c732dc43c4009cbf0f5da170. thanks again
16:28karolherbst: ajax: local build of llvm + system build of clang
16:31ajax: karolherbst: wouldn't that break something like nix where every package gets its own prefix?
16:32ajax: (assuming i'm remembering right that that's nix that does that)
16:32karolherbst: ajax: mhhhh good point
16:32karolherbst: but I have no other of enforcing that the clang and llvm stuff somehow is compatible
16:33karolherbst: and somehow I get the feeling that most llvm+clang related issues are only in 5% of the cases our fault and all others are just local mess ups of the build system
16:33ajax: build a test executable during the configure phase?
16:33karolherbst: not blaming the users, just llvm build system
16:33karolherbst: yeah.. I guess that's the best approach probably
16:33karolherbst: init clang and see how that goes
16:34ajax: and turn it off for cross-builds, but you're already into "you know what you're doing" territory there
16:36karolherbst: ajax: how is meson in regards to rpaths?
16:37ajax: pretty good? if you build executables that link against your own shared library targets, you get something like this in the built binary:
16:37ajax: RPATH Library rpath: [$ORIGIN/:$ORIGIN/../pixman]
16:38ajax: which then gets nerfed at meson-install time
16:38karolherbst: okay, nice
16:38karolherbst: well I want to pin the found clang/llvm paths though
16:38karolherbst: and I guess for cross-builds we could at least link and see if this works
16:39karolherbst: well, imagine you have your local and your system one, and I just want to use the same file used for linking when running this executeable as well
16:39ajax: they're going to change between meson-configure and ninja-build ?
16:39karolherbst:is really annoyed by the fact, that here is no clang-config
16:40karolherbst: ajax: we use llvm-config --libdir to find clang
16:40ajax: lol, seriously?
16:40karolherbst: any better ideas?
16:41ajax: i don't remember it being that stupid back when i reluctantly owned those packages
16:41karolherbst: if you are aware of a better way of doing this, please tell me, we could make this whole thing more robust then :p
16:43karolherbst: and because things are so stupid, meson has native support for llvm-config including the cross-build files...
16:45ajax: well regardless. build (and if native, try to run) a test binary for whichever llvm and clang the compilation environment happens to find.
16:45karolherbst: yep, I guess that's the only way here
16:45ajax: and if it fails you fail at configuration time, and if it succeeds then anything else funky that happens is the user's fault for having a broken environment
16:45ajax: not a great answer, i agree
16:47craftyguy: does anyone know where I should report issues with building dEQP? I don't see any obvious places/pointers in the readme or upstream repo: https://android.googlesource.com/platform/external/deqp
18:14tanty: craftguy: https://issuetracker.google.com/issues?q=component:deqp ?
18:23craftyguy: tanty: thanks!
18:34mdnavare: hwentlan: seanpaul: There's a patch in our DP PHY compliance patch series that has a change in drm/amd/display since we changed the name of a register in drm_dp_helper , it has a r-b, since its in AMD and drm_dp_helper.h in 1 patch, should i merge it through drm-misc is that okay?
18:34mdnavare: hwentlan: seanpaul: https://patchwork.freedesktop.org/patch/357757/?series=71121&rev=9
18:48mdnavare: hwentlan: ?
18:50hwentlan: yes, that's fine. agd5f usually pulls those minor changes in when rebasing our branch
18:51mdnavare: hwentlan: Great thanks Harry, will merge that through drm-misc then
19:06ajax: MrCooper: if the grafana is to be believed then omg yes !4432 already
19:07Lyude: seanpaul: could I maybe get you to review the ACT wait/dropped NAK patches on dri-devel?
19:08seanpaul: Lyude: sure thing
19:08ajax: and then if we could put x86_build on a diet that'd be super
19:09ajax: wonder if it'd be worth it to split out the cross arches as derived images
19:10mdnavare: seanpaul: Actually need your advice on merging this series: https://patchwork.freedesktop.org/series/71121/ 1st two patches are drm so can be emrge through drm-misc but then rest are i915, should the entire series be ust merged through drm-misc and then i915 patches be backmerged to dinq later?
19:10mdnavare: j4ni: ?
19:10seanpaul: mdnavare: sorry you'll probably want to bug mlankhorst_ or mripard, i'm no longer a -misc maintainer
19:12mdnavare: seanpaul: okay guess its too late for them in their timezone atleast mlankhorst_, but what is the general approach in this case?
19:12mdnavare: mlankhorst_: Still around?
19:13seanpaul: mdnavare: as a peanut gallery member, i am entitled to give my opinion ;-) a topic branch might be a good idea for this?
19:15mdnavare: seanpaul: okay yes thats what I was thinking
19:16Lyude: seanpaul: cool, thanks!
19:16mdnavare: seanpaul: although i havent merged anything yet through a topic branch so not clear about the process so will wait for j4ni or mlankhorst_ to guide
19:16Lyude:waves at mdnavare
19:17Lyude: i can help with topic branches if you need
19:18mdnavare: Lyude: Cool thanks Lyude, let me get confirmation from j4ni or mlankhorst_ for merging this series through a topic branch and then will sync with you for creating and merging process
19:20Lyude: sure thing
19:25Lyude: seanpaul: also-just found another issue with the simultaneous down replies that seems to cause a NULL deref, will send out a patch for it in just a little bit
19:25kherbst: hakzsam: btw, what's the best way to reverse engineer the sm counters with nvidia?
19:27imirkin: i remember he had some tool to dump them out
19:27imirkin: via CUDA or OpenCL or something
19:29kherbst: probably cuda
19:34Lyude: seanpaul: ok-one more patch for you to review if you've got the time
19:35imirkin: kherbst: or that perf API they have (had?)
19:35kherbst: dunno :D
19:35kherbst: that's why I am asking :p
19:49sravn: Lyude: thanks for the vblank ascii art - posted a new series. If patch are OK can you please add both r-b and s-o-b. s-o-b is required for the Co-developed-by: ... tag, and I cannot take full credit
19:50Lyude: sravn: np, thanks for putting this stuff into docs! :) I'll take a look at it in a bit
20:03Lyude: seanpaul: should I add your r-b for the split-up version of the drm_dp_mst_port_has_audio() removal?
20:04seanpaul: Lyude: yeah for sure if you decide that's a good idea
20:04Lyude: seanpaul: alright-I'll add your r-b, but I'll let the patch sit on the ml for a little longer in case there's any objections
20:04seanpaul: i'm just not sure if intel has reasons to avoid reaching into the port aside from lifetime issues of old
20:05Lyude: from the intel folks I mean
20:05seanpaul: sgtm, thanks
20:29alyssa: Any tricks to make libgallium_dri.so smaller (w/o hurting compile time)?
20:32ajax: smaller in what sense? on disk, in memory, ...
20:33HdkR: Making compile times smaller? :P
20:34alyssa: ajax: On disk - the board I have is too slow for on-board compiles, but pushing 100MB dri.so over the network is proving slow
20:34alyssa: (In which my Chromebook is the super-fast device.)
20:34ajax: meson configure -Ddebug=false
20:34airlied:assumes you only build one driver in
20:35alyssa: ajax: how much debug does that disable?
20:35alyssa: airlied: aye.
20:35ajax: alyssa: -g0 i think
20:35alyssa: Okay, could be worth a try
20:35alyssa: thanks :)
20:35ajax: no idea how much of a win -g1 would be relative to (the default of) -g2
20:36imirkin: alyssa: scp -C
20:36krh: strip the binary?
20:37alyssa: imirkin: actually, that's slower :( I assume overhead cpu over compressing is still worse than LAN
20:37alyssa: krh: also worth a try, thank you :)
20:37imirkin: usually that's a win
20:37imirkin: gzip | netcat?
20:37alyssa: It's ethernet for both devices, but also slow CPUs..
20:37imirkin: (so you don't have the ssh overhead)
20:37krh: stripping gets me from 71M to 8M
20:38alyssa: krh: ....that sounds like a winner then :2
20:38ajax: stripping is mostly equivalent to building without debuginfo up front, afaik
20:39alyssa: Yeah, but easier to turn on and off I assume
20:39alyssa: krh: and yes that makes the problem disappear, thanks :)
21:00pcercuei: Looks like it is not possible to create a "component master" without components
21:00pcercuei: I guess I'll have to make my own soup
21:16imirkin: vsyrjala: hey, so ... at what point does the intel driver do the scdc write to the monitor?
21:34vsyrjala: should be just before we enable the link
21:35imirkin: vsyrjala: do you deal with failed scdc writes?
21:35vsyrjala: not really
21:36imirkin: is there a reason you do it before enabling the link rather than after?
21:36vsyrjala: spec says that's the order iirc
21:36imirkin: that's a good reason :)
23:27airlied: Lyude: btw I can cofirm the 30 retires for ACT was purely picked from the ether
23:30airlied: Lyude: the earliest version of that code I can find has 30
23:32Lyude: airlied: gotcha
23:33airlied: I remember being annoyed at the specs lack of timeouts
23:34airlied: like bleh users can just wait forever for a mnonitor to turn on
23:34Lyude: yeah, I was kinda surprised. Doesn't seem like they have any more timeouts in 2.0 as well
23:34Lyude: airlied: tbh-now that we're getting specs from VESA, maybe we can contribute back and suggest stuff like that
23:35Lyude: may as well give them some value for their services :)