00:04anarsoul: yet it doesn't explain why glamor is a bit worse
00:12airlied: anarsoul: well glamor has overheads
00:13airlied: you'd be surprised how much tuning you might have to do to get glamor to beat memcpu
00:17anarsoul: airlied: what kind of tuning?
00:18anarsoul: I'm a bit lost on where to start
00:33airlied: anarsoul: I suppose you have to find a way to profile what it's doing now
00:33airlied: anarsoul: like look at what gets submitted to gpu
00:33airlied: looks for places it's stalling
00:35airlied: ivyl: is you I bother if patchwork fails to process an email?
01:19imirkin: anarsoul: glamor on a gles2-era gpu is almost certainly going to be a loss. glamor has lots of branching, etc. maybe with shader specialization based on consts you could do better.
01:23airlied: it 's also possible you hit some ping-pong path where gles2 wasn't enough
01:35anarsoul: imirkin: :(
01:36anarsoul: but I can't just disable glamor without loosing GL, right?
01:37imirkin: as it currently stands, that might be right
01:45anarsoul: looks like it spends a lot of time in u_default_texture_subdata() -> util_copy_box() -> memcpy
01:45anarsoul: a lot is 86.65%
02:14mareko: I might enable glthread by default, my next update will make it perform well with non-VBO data
02:19airlied: anarsoul: that's the copy data to a texture path
02:19airlied: which I'm not sure what can be done to optimise
02:19airlied: make sure you get neon memcpys I suppose
02:20anarsoul: airlied: yeah, but that's for non-composited variant, for composited we're getting intermediate copy and perf drops 3x
02:21anarsoul: so I guess we can do better with own _subdata() implementation
02:35airlied: anarsoul: hmm not sure about that, you might be able, the bottleneck there is simply uploading the data from cpu to gpu, which is what putimage mostly does
02:36anarsoul: airlied: let me upload 2nd flamegraph
02:37anarsoul: see 2nd svg at https://gitlab.freedesktop.org/snippets/925
02:39airlied: anarsoul: oh copy shouldn't be heading down those paths
02:39airlied: maybe it's a gles2 deficiency
02:39airlied: work out why glamor_copy_gl fails
02:39anarsoul: airlied: it doesn't fail
02:39anarsoul: it untiles and then tiles image back
02:40airlied: ah glamor_copy_cpu_fbo
04:53agd5f: imirkin, not sure if that possible. IIRC the audio is embedded in the blanking period of the video
04:53imirkin: agd5f: well, you could send bs video data
04:55imirkin: agd5f: someone asked about it in #nouveau
04:55imirkin: apparently there are HDMI receivers which function something like that
07:15vsyrjala: imirkin: if userspace wants hdmi to work they're just going to have to set a mode. we have more than enough problems with audio interactions that i'd not want to add any more
07:17imirkin: ok, so long story short, that use-case is not explicitly supported
07:17imirkin: which is what i thought btw
07:17imirkin: but wanted to double-check with the other desktop drivers. sounds like we have consensus :)
07:37ivyl: airlied: yep, what's wrong?
07:57airlied: ivyl: the vmware pull from Roland a few days ago didn't end up in patchwork
07:57airlied: it's likely something obvious but I alway for get how to check
07:58ivyl: I'll look into that, if you have msg-id handy that would help
08:55mripard: sravn: done
08:59hakzsam: MrCooper: hi, mind to ACK the top commit that introduces more fossils https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4082/commits ?
09:01MrCooper: I'd rather not, since I know nothing about fossils; you don't really need it anyway?
09:03hakzsam: yeah, I can push directly
09:23pepp: TIL: pushing a commit with a "Closes: ..." tag to a fork master's branch will automatically close the issue (the commit just needs to land in any master branch, not necessarly mesa/master for instance)
09:37sravn: mripard: thanks, will look at it tonight
09:45hakzsam: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/2018058 --> flaky arm64
09:58MrCooper: pepp: hmm, maybe that wouldn't happen with just "Closes: #<issue number>" instead of the full URL?
09:58pepp: MrCooper: probably
10:00MrCooper: FWIW, the master branch in my forked Mesa repo has nothing but a README pointing to the main project: https://gitlab.freedesktop.org/daenzer/mesa/-/tree/master
10:03pepp: MrCooper: I'm going to mark the master branches from my forks "protected" so I can't push to them by mistake. I think gitlab should make this feature off by default for forks anyway
10:04hakzsam: it's not a flaky actually
10:04MrCooper: pepp: agreed
10:24shadeslayer: daniels: https://lists.freedesktop.org/archives/dri-devel/2020-March/259914.html
10:38tjaalton: what's required to get a new libdrm release out?
10:42danvet: 1. draw short stick 2. do it
10:43danvet: https://gitlab.freedesktop.org/mesa/drm/-/blob/master/RELEASING should be up to date
10:47danvet: sravn, https://paste.debian.net/1136123/ ok with your r-b?
11:15tjaalton: danvet: ninja would expect to have a 'build.ninja'
11:26tjaalton: eric_engestrom: ^ what's missing from the libdrm RELEASING doc? running ninja fails with 'ninja: error: loading 'build.ninja': No such file or directory'
11:30HdkR: tjaalton: Make sure to make the build directory, and run meson in it to create the ninja files
11:34tjaalton: HdkR: ok, that helped
11:55MrCooper: anholt robclark: lots of MRs hitting arm64_a630_gles3 failures when trying to merge
13:35sravn: danvet: The example "+ * ret = drm_mode_config_init(drm);" shall use the drmm_ variant.
13:35sravn: danvet: with this fixed r-b
13:36danvet: oh right
14:41jekstrand: arora: Don't expect me to be on IRC on week-ends. I might be but don't plan on it. :-)
14:43arora: jekstrand: Oh ok.
14:45arora: jekstrand: In the application, I have to write milestones and deadlines, can you help with the milestones part?
15:00jekstrand: arora: Uh, probably. Though I'm not sure how big this project is going to end up being so I'm not sure what milestones would be reasonable.
15:01jekstrand: Certainly, doing the whole thing in a single summer may be a bit much
15:01jekstrand: arora: Also, did you read the backlog over the week-end? There was some chatter right after you left
15:02jekstrand: 19:16 Venemo: jekstrand, how does gpu selection work currently? I noticed that sometimes it selects the secondary gpu without DRI_PRIME
15:02jekstrand: 19:17 Venemo: maybe it happens when I only compile RADV but not ANV
15:03jekstrand: 19:18 jekstrand: The Vulkan loader gives you a list of GPUs in some order (treat it as random) and the app picks one.
15:03jekstrand: 19:18 jekstrand: Dumb apps pick the first one.
15:03jekstrand: 19:18 kisak: fwiw, there's prior work for a vulkan device selector https://github.com/aejsmith/vkdevicechooser
15:03jekstrand: 19:18 jekstrand: Smarter apps such as games may be more selective.
15:03jekstrand: 19:18 kisak: ^as an overlay
15:03jekstrand: 19:19 jekstrand: Yeah, that'd be a good starting point
15:03jekstrand: 19:19 jekstrand: It sues device IDs which aren't stable though so it's clearly incomplete
15:03jekstrand: 19:20 pendingchaos: there's also this layer: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1766
15:03jekstrand: 19:23 kisak: there was a request for this functionality to go into Proton, which is clearly the wrong part of the render pipeline, which was bounced to the vulkan loader and NACK'd at https://github.com/KhronosGroup/Vulkan-Loader/issues/202
15:03gitbot: KhronosGroup issue 202 in Vulkan-Loader "Ability to re order graphics cards when presented to a app? vkEnumeratePhysicalDevices" [Closed]
15:03jekstrand: 19:23 gitbot: KhronosGroup issue 202 in Vulkan-Loader "Ability to re order graphics cards when presented to a app? vkEnumeratePhysicalDevices" [Closed]
15:03jekstrand: arora: ^^
15:03jekstrand: arora: FYI: This channel is logged publicly:
15:04jekstrand: arora: Probably the best place to start would be airlied's layer which is Mesa MR !1766
15:04jekstrand: arora: It's entirely ENV var based but should be able to re-order GPUs which is the start.
15:08arora: Yea, exactly, I dont't know big this project is either, but it really intrigues me so I am willin to spend my summer on it. I will go through airlied's layer.
15:08arora: /s/know big/know how big
15:12arora: jekstrand: Also, the application deadline is 31st of this month, shall I send a draft to you for a review?
15:13jekstrand: Sure, I'd be happy to read over it.
15:14jekstrand: I guess this means that I have to go sign up for GSoC somewhere?
15:17arora: For students, we had to go over here: https://summerofcode.withgoogle.com/ and sign up to submit applications to the organizations. Not sure how it works for you..
15:18jekstrand: I probably have to fill out something
15:33robclark: jekstrand: tlwoerner should be able to help if you have questions about signing up as mentor.. iirc you do have to setup an account on the GSoC site
15:44tlwoerner: jekstrand: hi, i'm one of the admins for this year's X.Org GSoC, i'll send you a mentor invite
15:45tlwoerner: i can try sending it to the email you use on the mailing lists, but, as robclark points out, you (most likely?) need a google account to access some things
15:46jekstrand: tlwoerner: email@example.com is a google account
15:46jekstrand: tlwoerner: Please use that as the address
15:48tlwoerner: jekstrand: okay, here comes the invite :-)
15:49tlwoerner: arora: for milestones... there are 3 evaluations that will take place: june 15-19, july 13-17, and the final evaluation aug 17-24. it is strongly recommended that your milestones are set such that your mentor will have something "concrete" to evaluate at those times
15:53tlwoerner: arora: sometimes it helps to "work backwards" from your goal. if, by the end of august, you hope to have <this> working, what should be working halfway between now and then? etc...
15:58arora: tlwoerner: ok, so I upload the application now for review, will it be accessible to you and jekstrand?
15:59tlwoerner: arora: yes... and to all the mentors
16:00arora: jekstrand: Are we gonna finish this entire thing in that time, if so, what should be the "concrete" milestones?
16:01tlwoerner: arora: for projects that are accepted into GSoC, we create a week-by-week schedule, and there are weekly meetings to check in on how things are progressing accordingly
16:04arora: ok, noted
16:05jekstrand: arora: Good question. I suspect that we should target having a competent config-file rules system (possibly also usable by GL drivers) as the final goal.
16:05jekstrand: If you get to working on GUI tools by the end of the summer, great, but we shouldn't count on it.
16:06jekstrand: Also, I think it's more important to get the rules system right than to rush it so we can get to fancy shiny tools.
16:18arora: jekstrand: Ok, so getting a config-file rules system would be a goal for the final evaluation, what would be the in between processes to reaching that goal?
16:19jekstrand: I think getting a *good* rules system should be the final goal.
16:19jekstrand: But there are a number of steps along the way to that
16:20jekstrand: Unfortunately, this one's a bit hard to define milestones for. :-(
16:20jekstrand: Because it's going to be as much about defining the rules file format and figuring out how to implement different things as anything.
16:20jekstrand: So it's kind-of hard to break it into features
16:20jekstrand: But I think we can try
16:25arora: Remember you told that "One piece is the mechanism for actually doing the GPU selection. This could be done via a Vulkan layer or, directly in the Vulkan ICD loader."
16:26arora: jekstrand: So can this be the initial milestone?
16:26tlwoerner: perhaps one of the (early) milestones could be to investigate file formats and choose one. plus there may be libraries that may be able to help with parsing. e.g. if you decide to use a "INI"-style format, there are probably libraries that will help?
16:29arora: tlwoerner: The deliverables sections includes • investigation
16:29arora: • programming
16:29arora: • documentation
16:29arora: • dissemination
16:30arora: oops, What should those include?
16:31tlwoerner: arora: for X.Org specifically, we want to see all that all potential candidates can submit at least one patch to a relevant mailing list
16:33tlwoerner: arora: so between now and the 31st, please make sure you've submitted at least one patch via email for any X.Org project
16:33arora: oh, I will keep this in mind
16:34tlwoerner: arora: you'll also need to blog regularly, so setting up a (free!) blog will be required. a blog is a good place to put your "investigation" ideas
16:36tlwoerner: arora: if you use github or gitlab those would be places to put your program and documentation
16:36arora: tlwoerner: Where can I find some bugs to resolve in xorg to send the first patch?
16:36jekstrand: arora: I'm not sure if that's a good initial milestone. If we just merge airlied's layer (I've not yet looked at the code), then that's basically done.
16:36arora: tlwoerner: Yes, I have set up a blog and will be blogging regularly.
16:36jekstrand: arora: Though I don't know if that layer re-orders or just selects a GPU manually.
16:37tlwoerner: arora: https://bugzilla.freedesktop.org/ ?
16:37jekstrand: tlwoerner: Most projects are using gitlab issues these days
16:39arora: tlwoerner: There's no difficulty tags on the bugzilla page, so it's hard me to select a first patch to get started and understanding the workflow.
16:40MrCooper: hakzsam pendingchaos bnieuwen1uizen: intermittent radv-fossils job failure (manual retry passed): https://gitlab.freedesktop.org/mesa/mesa/-/jobs/2024280
16:40tlwoerner: arora: sorry, the bugzilla isn't used anymore
16:40tlwoerner: arora: start here: https://gitlab.freedesktop.org/explore/groups
16:42arora: jekstrand: ok, and what about this: 21:56 tlwoerner| perhaps one of the (early) milestones could be to investigate file formats and choose one. plus there may be
16:42arora: libraries that may be able to help with parsing. e.g. if you decide to use a "INI"-style format, there are probably
16:42arora: libraries that will help?
16:43hakzsam: MrCooper: thanks for reporting
16:43arora:argh, sorry for the wrong formatting
16:45jekstrand: arora: That seems like a good milestone
16:45arora: tlwoerner: Other than a first patch and a blog, are there any other pre-requisites?
16:46jekstrand: arora: I would also put in milestone 1, thoroughly reviewing airlied's layer and making sure you understand what it's doing.
16:46jekstrand: arora: Maybe your first patch could be modifying it so that it can take either an integer number in the environment variable or a string human-readable GPU name.
16:47tlwoerner: arora: https://www.x.org/wiki/GSoCApplication/
16:50arora: jekstrand: Ok, I will add those two tasks as milestone 1.
16:54arora: tlwoerner: Is this part of x.org projects: https://github.com/KhronosGroup/Vulkan-Loader ?
16:55jekstrand: arora: No, it's not
17:22alyssa: ....igt is still mailing list based wee
17:25danvet: hey wasn't panfrost the last hold out on mesa
17:25danvet: but yeah maybe time to poke ivyl
17:41MrCooper: tanty: please check the "Auto-cancel redundant, pending pipelines" box under "General pipelines" in "CI / CD" settings of your Mesa project (and any other personal GitLab projects)
18:10tanty: OK, thanks for the advice.
18:12tanty: Mmm ... it was already marked ...
18:15tlwoerner: jekstrand: ajax: did either of you see the GSoC mentor invite?
18:43ajax: tlwoerner: just clicked through it, i should be listed as a mentor now
18:44tlwoerner: ajax: confirmed, thanks :-)
19:04airlied: jekstrand: my layer reorders so you get the device for your display server by default
19:05airlied: then is env var based
19:18airlied: step 0 could be merge my layer :-)
19:20jekstrand: tlwoerner: I did.
19:20jekstrand: airlied: Yeah, I think that's step 0
19:21jekstrand: airlied: I think that's the right path forward
19:21jekstrand: airlied: Which means I should probably review it. :-P
19:27airlied: I think the only case not having exts really breaks is identical gpus
19:31airlied: ivyl: https://firstname.lastname@example.org/T/#mbb1e23ac4b267a159c852029863691bfd65b6e72
19:33jekstrand: airlied: For the extension issue, I thought layers could enable extensions.
19:33airlied: jekstrand: nope
19:33airlied: the loader blows up
19:35jekstrand: airlied: And the loader is required to return NULL for vkGetPhysicalDeviceProperties2 if you don't enable it... :-(
19:36gitbot: KhronosGroup issue 51 in Vulkan-Loader "Enabling extension in layer causes crash" [Open]
19:37jekstrand: airlied: Yeah, that sucks.
19:39jekstrand: airlied: We can pull vendorID and deviceID and do a match and hope for the best.
19:40jekstrand: It's busted if you have identical GPUs
19:40jekstrand: airlied: I'm guessing that's what you're already doing?
19:40jekstrand:goes to read the actual code.
19:40airlied: jekstrand: yes
19:40airlied: if the exts aren't therer it fallsback
19:45karolherbst: uff... why does commenting commits still needs to be broken :/ Does anybody have a good idea on how to give inline comments on single commits?
19:47karolherbst: (I am simply annoyed about my comments not showing up in changes whenever I view a commit within an MR)
19:55alyssa: danvet: "hey wasn't panfrost the last hold out on mesa" we were definitely yes.
19:55alyssa: and by we I mean I
19:55alyssa: I just like things the way I like them, okay!
20:00mareko: anholt`: please fix or remove this test from CI, it consistently fails: https://gitlab.freedesktop.org/mareko/mesa/-/jobs/2026984
20:01airlied: yeah upvote :)
20:04anholt: mareko: marked for marge. was looking into the failure while waiting for the original pipeline to come back clean.
20:04anholt: order-dependent failure, needs 4 tests to run to trigger :/
20:37pendingchaos: tarceri, jekstrand: maybe one of you could review this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4190 ?
22:12robclark: noticed some valgrind unhappiness on recent master.. no sure if something someone is already looking at?