11:03imirkin: anyone who cares about vdpau could review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4108 ?
11:16j4ni: danvet: airlied: may I have your ack for merging these via drm-intel along with the rest of the series, please? http://firstname.lastname@example.org http://email@example.com http://firstname.lastname@example.org
11:17danvet: j4ni, ack
11:17danvet: btw drivers/video is now (mostly) in drm-misc too, so not different from other drm core stuff really
11:17j4ni: I suppose http://email@example.com could use an ack from Bartlomiej Zolnierkiewicz too but not sure if he's here
11:17danvet: I think drivers/video/backlight is still outside
11:18danvet: fbdev doesn't even use this
11:18danvet: it was put in their so it's neither in drm nor in v4l
11:18danvet: so if we'd need an ack, video ack would be more relevant
11:29danvet: or hans or pinchartl
11:29danvet: but imo optional
11:29danvet: pq, you're opt-in idea sounds good to me
11:30danvet: we can just filter out the cursor if the flag isn't set and the cursor has the hotspot property
11:30danvet: if the client sets atomic
11:30danvet: well, maybe if the client sets universal planes
11:30danvet: and legacy userspace should indeed keep working
11:30j4ni: danvet: sorry, hans verkuil or de goede?
11:30danvet: I think we want the verkuil one
11:30danvet: iirc he authored these helpers originally
11:30j4ni: that's what I thought
11:31pq: danvet, I am unsure how much people actually care about making it any kind of proper. It sounds like everyone is happy with status quo + hotspot.
11:34danvet: pq, the prop shouldn't be a lot more lines really
11:34danvet: the igt I'm going to ask for will be more
11:34danvet: since strictly speaking new uapi :-)
11:37pq: danvet, one could also make the point that using cursor planes for non-cursor content is unwanted.
11:37emersion: i'm not happy with the status quo :)
11:37emersion: pq: but then we can't fully make use of the hw we have
11:38emersion: do some hw drivers expose a cursor plane just because some user-space won't use hw-accelerated cursor otherwise?
11:38pq: emersion, too bad - let drivers expose a duplicate of the cursor plane as an overlay plane
11:40pq: I dunno - Mutter made that mistake but was corrected
11:41pq: emersion, if the KMS driver implements legacy cursor_set2 kernel internal API, the driver does not need to expose a cursor plane for userspace to be able to make use of it. But if the driver does not implement cursor_set2, then the DRM core converting from legacy UAPI to atomic needs a cursor plane AFAIU.
11:42pq: obviously applied only to userspace using the legacy UAPI
11:44Venemo: cwabbott: how would you feel about keeping the original varying slot of the variables available somehow, even after nir_lower_io?
11:45Venemo: currently it's a little bit of a headache to check driver_location (aka nir_intrinsic_base) against eg. outputs_read
11:46cwabbott: everything after nir_lower_io should be in terms of driver_location already
11:47Venemo: it doesn't touch outputs_read
11:47cwabbott: location is the API-level location, so only user-facing things should be using it
11:47cwabbott: if you need to know outputs_read, then it should be in terms of driver_location
11:48Venemo: but how?
11:48cwabbott: where does it get generated?
11:48cwabbott: can you switch over that?
11:49Venemo: cwabbott: the problem is currently being solved by an ugly loop here: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/compiler/aco_instruction_selection.cpp#L3337
11:49Venemo: basically this is what I'd like to avoid doing. I only did it because I didn't find a better way
11:50cwabbott: I mean, what generates outputs_read in the first place?
11:50cwabbott: nir_gather_info probably shouldn't be using location, or if it's used both before and after linking/nir_lower_io then it should generate two versions
11:51Venemo: it is generated by nir_shader_gather_info
11:52cwabbott: in general, the backend should be unaware of what the API-level location is and something like this is a sign that you're getting the two things mixed up
11:52Venemo: that is not exactly true
11:52cwabbott: in this case it sounds like nir_shader_gather_info is getting mixed up
11:52Venemo: I mean I understand the principle that you are upholding, but it makes this case hard for me
11:53Venemo: basically we have to make some exceptions for some API-level locations, such as tess factors
11:54cwabbott: in this case the "proper" fix would be to gather outputs_read with driver_location as well
11:55cwabbott: if the only use is in backends to optimize stuff, then it should only be using driver_location
11:55Venemo: the backend has to know "is this a tess factor"
11:55Venemo: and "is this output read"
11:56Venemo: now, storing driver locations in outputs_read is not feasible. the driver location can be anything, while outputs_read is just a 64-bit wide bit field
11:58Venemo: so instead, I propose to have the lowered io remember the original API location, which would make my problem solvable in a straightforward way
12:06cwabbott: hmm, seems annoying but unavoidable then
12:06Venemo: yeah but I really don't want to have that loop in there
12:07cwabbott: sorry, I meant that adding the original location is unavoidable if we want to clean that up
12:07Venemo: ah, right
12:07Venemo: I think it shouldn't hurt, if we name it appropriately
12:07Venemo: to avoid confusion
12:07Venemo: it could be like: nir_intrinsic_api_location or something
12:07cwabbott: yeah, i/o stuff tends to be rife with confusion already
12:08cwabbott: I'd just use the existing location thingy though
12:08Venemo: which one?
12:08cwabbott: isn't there already a nir_intrinsic_location?
12:08cwabbott: or LOCATION in nir_intrinsics.py
12:09Venemo: there is no such thing as nir_intrinsic_location in nir.h at least
12:09cwabbott: oh, maybe not
12:10Venemo: nir_intrinsics.py also only has driver location
12:10cwabbott: yeah, right
12:10cwabbott: api_location sounds fine then
12:11cwabbott: sorry, it's been a few months since I've touched input/output stuff and the knowledge tends to fade fast
12:20Venemo: no problem cwabbott
12:23Venemo: I realize that TCS is basically an edge case here
12:25Venemo: but it's one big edge case that comes with a huge headache
12:37danvet: pq, we're strongly discouraging custom legacy cursor implementations
12:37danvet: the random semantics aren't great across drivers
12:38danvet: but that is also a mess
12:38emersion: what is "custom legacy cursor implementations"?
12:38danvet: legacy cursor which doesn't just remap to the cursor plane also exposed through atomic
12:39danvet: only when the driver sets drm_crtc->cursor pointer do you get that fallback
12:39emersion: ah right
12:39danvet: without that you can still implement a legacy cursor will all the quirks
12:39danvet: which also means that it's a bit tricky for userspace to figure out whether the legacy cursor is something separate
12:39danvet: since we don't expose the drm_crtc->cursor pointer
12:40danvet: you have to guess that by lining up planes of cursor type with their crtc
12:40danvet: I think msm/mdp4 work like that
12:40danvet: and probably also amdgpu
12:41danvet: ah no, amdgpu has a cursor plane
12:41danvet: so afaik it's just msm/mdp5
12:41danvet: the oldest one
12:42emersion: maybe radeon too?
12:42danvet: pq, so I guess in reality you can forget the "cursor only exposed through legacy ioctl on an atomic driver" case
12:42danvet: emersion, not atomic
12:43emersion: oh, atomic + legacy cursor
12:43emersion: i see
12:44danvet: iirc mdp4 is a2xx, mdp5 is a3xx and dpu is a5xx or so in msm land
12:44danvet: robclark ofc knows better
12:50flto: mdp/dpu is separate from the GPU, there is a2xx without msm display, a3xx with mdp4/mdp5, a5xx with mdp5/dpu
13:14emersion: jekstrand: is there a way to flatten a sync_file? ie. remove any fences already completed from the file?
13:15emersion: it would simplify my life to continuously merge KMS fences for a single buffer, the buffer being used an arbitrary number of times on an arbitrary number of CRTCs
13:16emersion: i guess i could have a "sync_file_set" type in user-space and do the tracking myself instead of merging…
13:18pq: danvet, blame EVDI for spoiling me. But, err... what part of my proposal does that invalidate?
13:52tomeu: danvet: just stumbled by chance on the patch adding drivers/gpu/trace and I'm a bit surprised to see no comments from DRM people: https://firstname.lastname@example.org/
13:52tomeu: that CC list might not have helped...
13:54danvet: pq, none, was just additional information that we have more than just one problem around cursors
13:54danvet: I still think your proposal is solid, and not more work than just adding the properties
13:54danvet: since we'll need igt testcases anyway
13:54danvet: and userspace
14:01pq: danvet, ok, cool. I probably won't comment on the topic again though, I don't actually care about cursor planes that much. If Weston needs fixing, that's ok.
15:41jekstrand: emersion: Not really, no.
15:42jekstrand: emersion: I take that back. You can just merge sync files indefinitely.
15:42jekstrand: emersion: The kernel implementation of sync_file_merge will automatically discard any sync_files that have already been signalled.
15:42emersion: oh, excellent
15:44jekstrand: emersion: It also sorts fences so that it can de-duplicate them.
15:45emersion: makes sense
15:45jekstrand: So, yeah, feel free to merge as much as you want.
16:20lrusak_: I'm having a weird issue where "unhandled 7" is being printed out on stderr/stdout. It seems to happen when I call "glDrawElements(GL_TRIANGLE_STRIP, 4, GL_UNSIGNED_BYTE, 0);" however nothing appears in the debug logging with GL_KHR_debug
16:20lrusak_: how can I debug this?
16:22emersion: it's a radeon bug
16:22emersion: there's a gitlab issue about it in the mesa tracker
16:26lrusak_: ah ok, I'll have a look, thanks!
16:26lrusak_: I think this was the offending line btw https://gitlab.freedesktop.org/mesa/mesa/-/blob/19.3/src/mesa/state_tracker/st_program.h#L101
16:35lrusak_: emersion, is this the issue? https://gitlab.freedesktop.org/mesa/mesa/issues/631
16:35gitbot: Mesa issue 631 in mesa "Slow performance using glDrawElements calls with GL_UNSIGNED_BYTE indices" [Bugzilla, R600, Opened]
16:38lrusak_: doesn't seem like it..
16:39emersion: damn, can't find the issue again
16:40emersion: yeah, this is the offending line
16:40emersion: i swear i've seen a bug mentionning this
16:41emersion: lrusak_: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2656
16:42emersion: gitlab search is useless af
16:43lrusak_: yea I think it's actually me using texture external wrong
16:43lrusak_: but thanks for the link :)
16:44emersion: then maybe i'm using it wrong too :S
16:45lrusak: well looking at the code where the error comes it seems like only YUV formats should be used with OES external?
16:45lrusak: however my code seems to work fine. I just get this "unhandled" spamming the console
16:47emersion: yeah, that was my case as well
16:54lrusak: so is it actually a problem? I guess I can just use TEXTURE_2D for RGB formats
16:56emersion: mareko: thoughts? ^
17:20arora: Hello, I am interested in Vulkan GPU Preference tool on GSoC, how can I go about learning and contributing?
17:24arora: airlied jekstrand
17:42arora: Whom should I contact regarding this?
17:44imirkin: does the gsoc suggestion have a name associated with it? if so, contact that person
17:44imirkin: (usually they do)
18:01arora: imirkin: Mentors are airlied and jekstrand, I have been trying to contact them but to no avail
18:02imirkin: well, they're generally around
18:02imirkin: airlied is in australia, so it's like 5am there
18:02imirkin: jekstrand was around a few hours ago
18:03arora: oh ok, thanks for that info
18:03mareko: emersion: what's the issue?
18:04imirkin: arora: i don't look very closely, but i remember a few other people have come in here asking about that project in the past week or three
18:05arora: hehe it might have been me, it's the third time I am inquiring about this
18:06imirkin: lol ok
18:06imirkin: well make sure you stick around
18:08arora: surely gonna stick around, I had been looking for that tool for myself lol, and getting to work on it is kinda cool
18:11emersion: mareko: the question is basically, should OES external only be used with YUV formats? why does it still work with RGB?
18:12jekstrand: arora: Sorry. Been writing a book of an e-mail
18:14jekstrand: arora: Maybe the best place to start is by saying what you already have experience with.
18:14jekstrand:goes to the kitchen to grab some lunch. BRB. Feel free type and I'll read it in a few.
18:17mareko: emersion: the spec doesn't specify which formats must be supported and which formats mustn't be supported
18:18arora: jekstrand: yay, you finally replied. I have experience with C and moderate experience with C++ (because of competitive programming), currently I am learning linux device drivers. I had been looking for this tool this past year but there wasn't any, and I am glad that's its part of gsoc this year. I am willing to learn whatever it takes to bring this project to life. I also have the required hardware.
18:21arora: Also, I am in first year of undergraduate, so I can dedicate the required time.
18:22ajax: airlied, danvet: fyi as the group admins, i blessed myself into the drm gitlab group for purposes of mesa/xorg issue triage
18:22ajax: airlied, danvet: apparently being a site admin does not give you the ability to move issues between arbitrary projects
18:23ajax: TIL about gitlab, episode #43
18:23danvet: yeah I guess the issue management will have a few disappoints like that :-/
18:23danvet: especially the cross-project moving stuff
18:24ajax: it makes sense, in a way. now that i know that's how the permission model works i think i approve.
18:24danvet: well generally you can file if you can see it
18:25danvet: or do you move issues from drm to mesa?
18:25ajax: in this case it was from mesa to drm
18:26ajax: clicked on the Move issue button, tried to type drm / amd, got a blank stare in response
18:26danvet: ajax, btw is Reporter not good enough for that?
18:26ajax: added myself to the drm group, reloaded the issue, tried again, magically drm/amd appeared
18:26danvet: I thought Reporter = Issue wrangling, Dev = mr stuff, Maintainer = everything else on top
18:27danvet: more a question about mass-granting permissions later on, since I expect this will be somewhat recurring thing to do
18:28ajax: reporter may well be sufficient
18:29ajax: am doing
18:29ajax: yeah, demoted myself to Reporter and the Move button still works
18:30danvet: cool good to know
18:30danvet: wonder whether we should just add everyone from @mesa as reporter?
18:30danvet: and vice versa
18:30danvet: ïf that's possible
18:31ajax: (looking, i think it is...)
18:33ajax: yeah, so what you do is go into Settings / Members for drm/intel, hit the Invite group tab, and add mesa at reporter level
18:33danvet: well I mean doing it at drm directly
18:33jekstrand: arora: I'm not really sure where to start, to be honest. Or what the architecture should look like.
18:34jekstrand: arora: I do, however, roughly know what pieces will be needed.
18:34ajax: we have that too, nice
18:34danvet: ajax, since you're in mesa that would subsume that
18:34danvet: other way round we'd need to invite drm-intel/-* I guess
18:34ajax: ^ you should see the Invite group tab there?
18:34arora: jekstrand: ok, and what are those pieces?
18:34jekstrand: arora: One piece is the mechanism for actually doing the GPU selection. This could be done via a Vulkan layer (probably the preference) or, if that doesn't work, directly in the Vulkan ICD loader.
18:35danvet: ajax, yup added mesa as Reporter, deleted you
18:35danvet: Move button still functional?
18:35arora: jekstrand: yes, ok.
18:35ajax: danvet: indeed it is, excellent.
18:36jekstrand: arora: The second piece is a mechanism for specifying the rules to apply when choosing the GPU. This could be per-app preferences stored on disk somewhere, an environment variable, or possibly some service that the layer talks to over dbus or similar.
18:36danvet: ajax, cool, I think this is the simplest way to hand out Reporter rights
18:36jekstrand: My gut says to start with a simple on-disk file format.
18:36danvet: happy to add anyone else
18:36arora: jekstrand: yes, like in a .config folder
18:36danvet: j4ni, mupuf ^^ might be useful for igt vs drm-intel too
18:36jekstrand: Possibly also with an environment variable which the layer and/or loader picks up.
18:36jekstrand: A dbus thing could be needed for extra advanced stuff but I suspect it's over-kill.
18:37jekstrand: The third piece is some sort of a GUI tool for modifying that file that could hopefully be embedded in the GNOME settings pannel, for instance.
18:37jekstrand: In recent versions of Windows, they actually have this baked into the core OS and it's pretty nice. It'd be good if we could eventually have that same level of integration.
18:37danvet: hm might as well just do that right away
18:38mupuf: danvet: sorry, what's the context here?
18:38arora: jekstrand: Indeed, even the AMD tools are great on windows
18:38jekstrand: arora: Yeah, AMD and Nvidia both have their own tools and then Microsoft decided they wanted one unified thing.
18:38danvet: mupuf, people need Reporter permissions in both src and dst project to be able to move issues
18:38danvet: I'm thinking about just handing them out for everyone who's a member
18:39mupuf: a member of what?
18:39arora: jekstrand: oh nice
18:39danvet: mupuf, mesa is now a member of drm/ in gitlab with Reporter permissions
18:39danvet: i.e. anyone who's a member of the mesa group can now move mesa issues to drm projects
18:40danvet: but I think we should also do this across drm projects
18:40danvet: i.e. igt commit rights give you drm-intel Reporter
18:40jekstrand: When it comes to rules, I suspect we'll need a few different mechanisms for detecting the app. The first is likely going to be to look at the application and engine names provided in the VkApplicationInfo through the Vulkan API. However, we'll likely want to be able to fall back to looking at executable names and maybe some other things.
18:40jekstrand: That's on the "match" side
18:40mupuf: agreed, Reported-level is no different from what we gave everyone on freedesktop
18:41danvet: oh crap their projects, not groups
18:41danvet: mupuf, so not possible :-/
18:41arora: jekstrand: yes, like a process name parser?
18:41jekstrand: On the gpu selection side, I think we'll likely want three modes: Default (leave it alone), Prioritize (re-order the list of GPUs so that the preferred one comes up first), and Require (remove all GPUs from the list except exactly the one the user wants).
18:41jekstrand: arora: Yeah, there are a few different ways to get the executable name for the current process.
18:41danvet: mupuf, I guess if we grant Reporter rights we should do that for the drm/ group
18:42danvet: not individual projects
18:43jekstrand: arora: Probably the best place to start would be to play around with making a layer that re-orders/hides GPUs. It wouldn't even need to read a file quite yet.
18:43arora: jekstrand: Like a gui utility?
18:44jekstrand: arora: When it comes to asking questions about writing layers, I suggest you hop on the Khronos slack channel: khronosdevs.slack.com/
18:44jekstrand: arora: No, GUI comes very much later.
18:44jekstrand: arora: We need to be able to actually show/hide GPUs first.
18:44jekstrand: arora: And the way that'll work is either inside the loader itself (which finds the driver libraries and loads them) or in a layer which shims itself in between the application and the driver.
18:45arora: jekstrand: Oh ok, I will start with that.
18:46arora: jekstrand: I was wondering if someone else had also approached you regarding this?
18:46jekstrand: arora: People mention things on IRC all the time; very little of it actually happens.
18:46jekstrand: I wouldn't worry about competition just yet
18:48arora: Oh ok :D. BTW, can I get your email id so I keep in touch regarding this?
18:48lrusak: can anyone fix this mirror? https://github.com/freedesktop/drm-tip
18:49arora: jekstrand: Oh ok :D. BTW, can I get your email id so I keep in touch regarding this?
18:52jekstrand: arora: I'm also in that slack channel
18:53arora: jekstrand: Ok, I will head out now and keep you updated in case if I make any progress.
19:16Venemo: jekstrand, how does gpu selection work currently? I noticed that sometimes it selects the secondary gpu without DRI_PRIME
19:17Venemo: maybe it happens when I only compile RADV but not ANV
19:18jekstrand: The Vulkan loader gives you a list of GPUs in some order (treat it as random) and the app picks one.
19:18jekstrand: Dumb apps pick the first one.
19:18kisak: fwiw, there's prior work for a vulkan device selector https://github.com/aejsmith/vkdevicechooser
19:18jekstrand: Smarter apps such as games may be more selective.
19:18kisak: ^as an overlay
19:19jekstrand: Yeah, that'd be a good starting point
19:19jekstrand: It sues device IDs which aren't stable though so it's clearly incomplete
19:20pendingchaos: there's also this layer: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1766
19:23kisak: 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
19:23gitbot: KhronosGroup issue 202 in Vulkan-Loader "Ability to re order graphics cards when presented to a app? vkEnumeratePhysicalDevices" [Closed]
19:31imirkin: like from newegg?
19:31imirkin: running out of graphics card... time to reorder!
19:38jekstrand: kisak, pendingchaos: Yup, there are many partial solutions or proposed solutions but nothing has made progress yet.
19:44anarsoul: are there any obvious reasons why I'm getting "(EE) AIGLX error: sun4i-drm does not export required DRI extension" in Xorg.0.log with lima? apparently either coreExt or renderExt are missing, but I expected these to be provided by mesa
19:54Venemo: so I guess when the only icd file is radv, it will always just offer radv
19:55Venemo: but what I don't really get is, how is radv able to work with the secondary GPU without DRI_PRIME=1
19:55Venemo: afaik it shouldn't have worked
19:55ajax: DRI_PRIME just tells the loader to pick "a different" GPU
19:55Venemo: but does it know to use PRIME without the env var?
19:56ajax: define what you mean by "use PRIME"
19:56ajax: apologies for all the double-quotes
20:00imirkin: Venemo: with DRI3, the client selects what it wants
20:01imirkin: you just pass dma-buf handles with rendered contents
20:02Venemo: by "use PRIME" I mean render on the secondary GPU but output to the primary GPU
20:02imirkin: so the client doesn't really handle the output side of things
20:03imirkin: it just gives a dma-buf to the winsys, which in turn does whatever it likes with it
20:03airlied: jekstrand: i do have an open r adding a device select layer
20:03imirkin: (although preferably displays it on the screen)
20:04lrusak: what happens then if modifiers are being used?
20:04airlied: jekstrand: for some reason everyone ignored i
20:04ajax: then you (the client) had better have picked a set of modifiers for that buffer that the server can consume
20:04lrusak: is there a way for a buffer to be "untiled" so it can be displayed?
20:04jekstrand: airlied: Yeah....
20:05ajax: which may mean either that the server rejects buffers it doesn't like, or that it tries to convert them
20:05ajax: but in practice means you do this with linear surfaces without any clever tricks
20:05lrusak: I'll have to try again displaying vaapi decoded frames from the cpu to the amd gpu
20:06lrusak: *intel cpu
20:06Venemo: imirkin: ah, okay
20:06airlied: fixing vulkan to allow layers to enable exts is near impossible
20:07airlied: any layer in this area will hit that roadblock
20:08ajax: hmm. i wonder if you could make a tiling-converting compute shader and use that as a fancy blit.
20:24sravn: Is Andrzej Hajda hanging around here?
20:24pendingchaos: would it be possible for the layer to create it's own instance to query the pci bus info?
20:24pendingchaos: it's hackish and relies on the instance to have a consistent device order though
20:25sravn: narmstrong: Are you or Andrzej going to pick up "[PATCH v10 0/2] drm: bridge: Add NWL MIPI DSI host controller support"?
20:32jekstrand: pendingchaos: Yeah, that doesn't sound robust
20:41anarsoul: so looks like __DRI_CORE is missing with lima + sun4i-drm and thus xorg-server can't initialize AIGLX
21:14anarsoul: ah-ha, symbol name is __driDriverGetExtensions_sun4i_drm but Xorg is looking for __driDriverGetExtensions_sun4i-drm
21:14anarsoul: I guess all kmsro drivers with -drm suffix are affected
21:15anarsoul: any ideas on how to fix it assuming that '-' is not allowed in symbol names?
21:16ajax: not in C symbols, anyway
21:16anarsoul: I can patch Xorg to replace dashes with underscores
21:17ajax: probably best to do anything outside [a-zA-Z0-9_] while you're at it
21:17anarsoul: ajax: I guess it takes driver name from kernel
21:17anarsoul: should I fix it there?
21:17anarsoul: and then in mesa?
21:17anarsoul: I'm not sure how to avoid breakage though :\
21:18anarsoul: mripard: ^^ since you're one of sun4i-drm maintainers
21:18ajax: i wouldn't change the kernel
21:30anarsoul: that did the trick: https://gist.github.com/1529919045cf19345036250b7d7ddd38
21:37imirkin: how did this not come up with imx-drm?
21:39anarsoul: imirkin: no idea
21:39anarsoul: maybe they're not using X?
22:06jekstrand: anholt`: Random fail for you: https://gitlab.freedesktop.org/jekstrand/mesa/-/jobs/2005148