00:03airlied: jekstrand: pop quiz, printf strings as outputs from spirv_to_nir or stash in nir_shader
00:06jekstrand: Uh.... It's gross no matter what we do?
00:08jekstrand: I think I'd rather not have a separate output from spirv_to_nir just for printf strings.
00:08airlied: okay I'll stash in nir for now and see how we go
00:08jekstrand: If you just leave them more-or-less how SPIR-V parses them, they'll end up as constant initializers and then folded into nir_shader::constant_data.
00:08jekstrand: THat doesn't seem awful
00:09jenatali: airlied: I'd suggest adding a generic CL info struct, in additional to string reflection, we're probably going to want to add argument metadata parsing/reflection too
00:09jenatali: Maybe store as pointer-to-data if you care about the size of nir_shader
00:10jekstrand: jenatali: I think the argument reflection needs to be separate.
00:10airlied: jekstrand: don't want them in constant_data though
00:10jekstrand: Because it's going to need a separate entrypoint which doesn't try to parse all the way to NIR.
00:10airlied: I want to take them out on the cpu side completely
00:10jenatali: jekstrand: I suppose; For my purposes at least I'd be happy to get the metadata as a side effect of translating to NIR, I don't think we need them separate
00:11jenatali: I think Clover tries to get it earlier though so maybe keeping it separate would make sense there
00:11jekstrand: airlied: Sure. If the lowering happens early enough (before we lower_io on constants), you'll get a deref_var which points to a variable with a constant-initialized byte array. Once you've parced it, let dead code and dead_variables go to town.
00:11jekstrand: jenatali: Oh? I thought clover's early fetching was for a reason. Maybe not?
00:12jekstrand: jenatali: I don't have too strong a preference I don't think. But it should be something we CAN do early if we want.
00:12jenatali: I didn't look too closely at what metadata they're pulling out or when, we kinda just added the minimal amount we needed on top of what NIR was already giving us
00:31karolherbst: I think the feature I like the most about rust is to be able to simply extend primities/objects with random functions :D https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/3e95c19581606066682d8967fd2e57d1d63977b4
00:32jenatali: That was one of my favorite things about C#
00:33karolherbst: jenatali: was that always possible in C#?
00:33jenatali: I think so... I haven't written C# in nearly a decade :)
00:34karolherbst: C# got support for dynamic typing in version 4 and I am actually wondering if Rust is the first strongly typed langauge with this feature
00:34karolherbst: as normally you know this from dynamically typed ones
00:35jenatali: I... did not know it had dynamic. For the most part it's still static
00:36karolherbst: but seems like it's also a feature of static types, nice
00:36karolherbst: still wondering why C++ doesn't have it :p
00:37jenatali: I think it's down to the translation unit infrastructure. C# also supports partial classes, defining some of a class's members/functions in one file, and more in another
00:37karolherbst: ohh, interesting
00:37karolherbst: but I think rust also allows multiple impl blocks
00:37karolherbst: you just need to pull stuff you need into scope
00:38jenatali: Impressive considering Rust is compiled to machine code, C# just compiles to IL usually, though I think they have tech that goes to machine code these days
00:39karolherbst: jenatali: well.. the rustc compiler pulls in _all_ source files into one invocation
00:39karolherbst: so it doesn't matter
00:39karolherbst: jenatali: one thing though, the struct you have to declare in one step :p
00:40karolherbst: dunno if you can split field declarations in C3
00:40karolherbst: *C# :D
00:41jenatali: Yeah, I think you can
00:45karolherbst: the closer I look into the CL API the more terrible it becomes
00:46karolherbst: now I am at clCreateContext
00:46karolherbst: and that property stuff is just terrible
00:59karolherbst: jenatali: what's another cool thing is that rustc points out dead struct members :)
00:59jenatali: That's quite nice
00:59jenatali: Clang can do that for C++ too, in some cases
00:59jenatali: I was surprised to see that when I first compiled D3D for Linux :P
01:00karolherbst: yeah, I think it does it for structs inside cpp files or so? dunno for sure
01:00karolherbst: maybe private members only?
01:00jenatali: Yeah I think private only, if it can see all implementations of member functions
01:00karolherbst: always hard to tell what's actually dead or not
01:00karolherbst: or of some idiot just does field out of bound writes into the next field, because of "opimitzed code" or so
01:01karolherbst: but I never seen such code and I hope I never will
01:12jenatali: jekstrand: When you get a chance, I think the CLOn12 compiler stack is ready for another round of review, I got all your comments so far
02:13jekstrand: jenatali: Ok, I'll take another look tomorrow
02:29airlied: okay I think that's printf working as well as I want it to be
02:47karolherbst: airlied: you need to serialize the stuff :p
02:49karolherbst: CL is stupid, it has this "this API is totally for application kernel caching, but totally won't be abused for closed source modules sold for 'compatible' CL implementations"
03:21airlied:gets lost in explicit copy constructor attemps for clone kernel
03:29karolherbst: my progress is also interesting now
03:29karolherbst: clCreateProgramWithSource ...
04:02airlied: hmm I suppose I can extract the printf fmt strings at vtn stage as well for consistency
09:08dj-death: I'm looking at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5096 (adding EGL_EXT_protected_surface support) and I'm struggling to understand how the created image will be used
09:08gitbot: Mesa issue (Merge request) 5096 in mesa "EGL_EXT_protected_surface support" [Egl, Radeonsi, Merged]
09:09dj-death: it seems some implementation require the whole context to be protected before the image can be used
09:11dj-death: Looks like what GL_EXT_protected_textures/EGL_EXT_protected_content are doing
09:23pepp: freedreno odd CI failure: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5646708#L1705
09:24pepp: dj-death: for radeonsi/amdpu the image will have to be used directly by the display hardware (= direct scanout)
09:34dj-death: pepp: thanks
09:34dj-death: pepp: I guess I didn't get the usage then :)
09:35dj-death: I can't see who will render to it after it's created
09:35dj-death: a media driver maybe?
09:38pepp: dj-death: a use case can be a media player. See also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7006: secure decode needs to use tmz (protected) buffer.
09:38gitbot: Mesa issue (Merge request) 7006 in mesa "Enable Secure Vaapi Playback Through Decryption with TMZ" [Va-Api, Radeonsi, Merged]
09:40pepp: dj-death: so with secure decode you get the video frames decoded to tmz buffer. The media player can only read these frames in a secure context, which means it has to write to a secure/protected/encrpyted frame buffer
09:41pepp: this is where EGL_EXT_protected_surface comes into play: it allows the player to request a protected framebuffer. It also allows the compositor to know that this framebuffer is special and that it shouldn't try to do composition with it
09:42dj-death: but I thought the player would have to be protected too
09:42dj-death: that's kind of the missing API piece I guess
09:43pepp: no, the only thing the player has to do is allocate a protected framebuffer
09:44pepp: and enable secure decode
09:45pepp: something like this: secure stream -> secure decode (enabled by the player) -> protected buffer (allocated by the driver) -> media player -> protected framebuffer (requested by the player, through EGL_EXT_protected_surface) -> screen
09:45dj-death: there is nothing coming from the application telling the decoder to switch in protected mode?
09:47pepp: yes, the app switch to secure decode. But "protected mode" is a thing that does'nt exist.
09:47dj-death: okay, I guess our HW is just different then
09:48pepp: this is handled transparently by the driver, and boils down to: "do I need to read from a protected buffer" then use a protected context. Otherwise use a normal context.
09:49pepp: (well there probably is some kind of protected mode down the stack but not in the radeonsi driver)
10:02DPA: What would that mean for screen recording? Would that still work? Is this DRM?
10:04emersion: "protected buffers" stands for Digital Restrictions Management, yes
10:06emersion: a better name for "secure surface" would have been "write-only surface" or something
10:08DPA: So with some hardware, such as open hardware, some things now will simply never be possible?
10:08DPA: Why is this allowed to exist in linux? I think it should be removed.
10:08DPA: Let userspace circumvent DRM like it used to, then maybe stuff will even start actually working.
10:10MrCooper: and Linux allows that of course, which is why this won't make any difference outside of special platforms which are somehow locked down to prevent users from running their own kernels
10:10emersion: MrCooper: well… TMZ should prevent even tainted kernels from accessing "protected surfaces"
10:12MrCooper: the kernel could just lie about the TMZ/HDCP status?
10:12emersion: the way it works is that the GPU has hard-coded copyright holder keys in its chip
10:13emersion: so to decode the stream you _need_ to create a "protected surface"
10:13emersion: and then the GPU enforces pixels don't go out of the "protected surface", except via connectors where HDCP is enabled
10:13emersion: so yeah. tl;dr is it sucks
10:14karolherbst: also, the sec stuff is broken anyway
10:14emersion: right. as always, it's not like it's really secure anyways…
10:15karolherbst: the biggest issue is just, that the content industry will 1. DMCA takedown all publications of security issues in this area and 2. revoke vendor keys immediately
10:16emersion: i guess the answer to "why is this merged" is "some mesa maintainers were paid for this and didn't care about DRM"
10:16karolherbst: I also heard that some vendors get told to never publish sec bulletins of sec issues involving this
10:18karolherbst: yeah.. it's all very terrible
10:20karolherbst: emersion: but how can the GPU enforce that the kernel is not tainted?
10:21ccr: I would suggest, at the very least, a passive-aggressive approach to these things. rename functionality handling HDCP etc. DRM stuff in some vaguely offensive way .. I mean offensive to the parties that have interest in these things, e.g. RIAA/MPAA/etc.
10:21emersion: karolherbst: it doesn't need to. all of the restrictions are enforced inside the GPU firmware
10:21karolherbst: like? eat_dirt_riaa and so on?
10:21karolherbst: emersion: ohh right, as you only see the stream encrypted anyway
10:22lynxeye: What's the alternative to merging DRM enabling technology? Just having HDCP and protected surfaces upstream doesn't reduce your freedoms, as things continue to work as before. It just _adds_ the freedom for users of the code to actually lock down the device and then go to the content provider to get a DRM license for the device.
10:22emersion: yeah i think so
10:22karolherbst: ccr: careful what you say about drm :p
10:22karolherbst: we put a lot of efforts into this code :D
10:22ccr:appreciates the efforts a lot
10:23karolherbst: lynxeye: forcing people to have downstream forks
10:23karolherbst: but yeah
10:23karolherbst: it's all very transparent anyway
10:24DPA: If I was to pay for video streaming, then the video streams should be licensed to me for viewing, and not to my graphics card vendor. How is this even legal?
10:24karolherbst: but all hw tends to be broken in this area
10:24karolherbst: just a catch up until you find a way to extract that stuff
10:24emersion: lynxeye: the whole concept of DRM reduces freedom. supporting it upstream means it's more wide-spread, gives more power to copyright holders, etc
10:24karolherbst: DPA: because they have big money
10:24karolherbst: emersion: honestly.. they don't care :p
10:25karolherbst: they would do the same even if it actually costs them
10:25lynxeye: karolherbst: Why would you want to penalize people using your technology for the brainfarts of the content industry? I guess many people would rather watch 4K content on a upstream Linux OS with DRM support, than having to build their own kernel/mesa for this...
10:25karolherbst: lynxeye: money money
10:26karolherbst: lynxeye: building your own kernel/mesa doesn't help though
10:26karolherbst: it really just doesn't matter
10:26karolherbst: it's even more stupid on android devices
10:26karolherbst: some vendors allow you to root, but once you do that, you loose all drm stuff
10:26karolherbst: well.. not all
10:27karolherbst: but some streaming services just outright disallow you to watch
10:27karolherbst: or you get only 480p videos
10:27karolherbst: and if you don't play by the rules, your OS is not allowed to display the media content at all
10:28karolherbst: it's really that simply from their point of view
10:29lynxeye: Depends on how the DRM stuff is implemented. If it's in firmware below the kernel (just like TMZ on AMD) having root should have no influence on DRM licensing.
10:29karolherbst: for example just look at the widevine crap
10:29karolherbst: you need a binary blob, closed source
10:29karolherbst: or you can screw yourself
10:29karolherbst: your choice
10:29karolherbst: sure, "some" videos will work regardless, most won't
10:30DPA: I need to think of some way to make the media industry unprofitable and puth them out of business, it's the only way to stop them...
10:30DPA: If only there was some way to make video & music production as easy or even easier than writing a book for everyone somehow, that could work...
10:30karolherbst: DPA: they won't stop even if it means going out of business :p
10:30lynxeye: My argument is not that I agree with any of the DRM bulls**t, but blocking implementation of the requirements in upstream kernel and mesa would not penalize the once pushing the crap (content provider), but the users. So you would put pressure on the wrong end.
10:31karolherbst: yeah... well... wondering what would AMD do if we outright nack those things
10:31karolherbst: maybe just stop contribution to linux alltogether?
10:31emersion: "This feature enables media companies to abuse your users."
10:31karolherbst: it's a very difficult political issue
10:31emersion: "killing environmental regulations doesn’t harm the environment"
10:32emersion: same thing
10:33lynxeye: nope, more like taking away the trash bins to solve the waste problem
10:34MrCooper: karolherbst: they'd either need to carry downstream patches, or lose some business (which might affect AMD's funding of other upstream Linux/Mesa development)
10:34karolherbst: thing is, that technically having the functionality in the kernel doesn't prevent anything and just allows for more features. _but_ the political/social issues besides that are more relevant
10:34karolherbst: and people alsways scream about "code shouldn't be political"
10:34karolherbst: so you have to fight those idiots as well
10:35karolherbst: linux is a highly political project, as it's usually a fight against companies benefits/goals and what's best for upstream
10:35karolherbst: MrCooper: sure, but that's the political aspect I am talking about
10:36lynxeye: Yea, but that just works if you actually have a means to penalize the ones pushing crap. With DRM you won't hurt the content providers by not allowing this to exist upstream.
10:37karolherbst: you hurt users wanting to use it though
10:37emersion: lynxeye: so you're fine with writing unethical code?
10:40lynxeye: karolherbst: Exactly. And the users are the ones that grant you the power in Linux to fight against company bulls**t. If you don't have any users than there is no incentive for companies to care about your opinion.
10:40karolherbst: lynxeye: well... "users" are also companies using linux in their embedded devices
10:41karolherbst: desktop is close to irrelevant for the overall linux market
10:41karolherbst: so google is one big player wanting to have it in for obvious reasons
10:41karolherbst: as a "user"
10:42karolherbst: do you want to antagonize google? maybe, but then they just write their own kernel
10:42karolherbst: maybe they keep it downstream
10:43karolherbst: but this issue is really not as simple as "users being the ones in front of desktop/laptops"
10:44karolherbst: personally I am also against any kind of drm and think this is all just stupid and bullshit, but one also need to see the bigger picture before making any kind of judgements here
10:47ccr:eyes Fuchsia slightly.
11:01pq: "Taking away the trash bins to solve the waste problem" seems like a very good analogy to me for denying "secure content" stuff in upstreams, if looking at it purely from a political perspective.
11:01pq: A technical question would be: Does integrating the "secure" stuff upstream hurt upstream development, e.g. making code harder to write and fix?
11:50cwabbott: jenatali: I just saw we have load_ubo_dxil in mesa master nir_intrinsics.py, but we added load_ubo_vec4 recently which is the same thing... seems like some wires got crossed
11:54cwabbott: or are you already using it? load_ubo_vec4 has an extra component specifier because some HW uses a vec4-based index but can also load a compile-time-constant range of 32-bit components within the vec4, like .xy or .yz or something
11:54cwabbott: but you could easily just extract the components in your backend
11:55cwabbott: also, load_ubo_dxil is missing CAN_REORDER (that allows CSE)
12:44danvet: karolherbst, I guess having an upstream implementation should make it easier for inquisitive minds to hack it all up
12:44danvet: and find all the neat holes
12:44danvet: since usually the hole is right next to the working thing
12:44danvet: so it's nice to have it all documented in readable code
12:44danvet: aside from that I think it's a wash
12:45danvet: doesn't hurt, doesn't help
12:45danvet: maybe helps a bit to pay the bills
12:46danvet: plus it's very entertaining to watch the content protection hw engineers (who generally drank the kool aid hook, sinker & all) squirm
12:46danvet: when you explain that they need to have open userspace or forget about it
12:46karolherbst: I mean, I totally get the situation, I also just like to see the content industry getting pissed of
12:46danvet: there's a 20+ mail thread with me essentially repeating "nope"
12:47danvet: I think we're too far from riaa to piss those people off
12:47danvet: but I'm definitely pissing some content protection people off
12:47karolherbst: you'd think
12:48danvet: I think our open hdcp implementation also gets some people really heated
12:48karolherbst: riaa DMCAed youtube-dl for instance
12:48karolherbst: so.. I wouldn't say we are too far away
12:48danvet: we might get there :-)
12:48danvet: dmca'ing the kernel would be rather glorious
12:49karolherbst: somebody uploaded the youtube-dl code to githubs dmca notice repo
12:49karolherbst: that was funny
12:49kusma: cwabbott: I have a patch for using load_ubo_vec4 instead, but there's some gotchas. Our lowering pass is a bit more robust than the existing one (it can lower 64-bit variables and some other details), so I need some time to port that stuff over.
12:50karolherbst: danvet: but yeah.. they are just waiting for any reason and I don't think they even recognize potential damages
12:50kusma: cwabbott: For GL this works fine as-is (we don't support 64-bit anything in GL yet), but for CL this is a disaster (and yeah, we use UBOs in CL)
12:51kusma: We also do the same thing for SSBOs and other stuff.
12:51kusma: Zink is going to need this for 64-bit support also, so it's on my list of things I have to do
12:54karolherbst: kusma: if it's a backend pass you can just whatever instruction there is as long as it doesn't get into core code
12:54karolherbst: but yeah...
12:55kusma: karolherbst: yeah, I think cwabbott just wants this cleaned up.
12:56kusma: Which is fair. I would prefer to wait until the CL bits land, so I don't needlessly make merging a moving target for that MR.
12:59cwabbott: kusma: it's fine, I just happened on it while looking at something else
12:59cwabbott: just wanted to make sure you were already aware of it
13:03kusma: cwabbott: Yeah, I'm aware. I saw it come in on master, and knew we had the same. It's fairly high on my priority-list to fix :)
13:54jenatali: cwabbott: Yep, like kusma said we're aware and we'll clean it up once CL's done :)
13:55kusma: nothing's ever truly done, blabla ;)
14:49enunes: imirkin: hey, I just saw that message now about clip planes: yes indeed, in that MR I did some analysis using ES 1.1 in the last weeks and it will take some driver rework so I'll post it in a followup MR
17:33danvet: narmstrong, when you review a patch from someone without commit rights, pls also push it to drm-misc-next
17:33danvet: re the meson patches from lee jones
17:34danvet: otherwise just more work for everyone
17:39narmstrong: danvet: yup
17:39danvet: I'm applying it all now, just for next time around
17:40danvet: narmstrong, ^^ just in case you're wanting to do that now
17:40mripard: danvet: would you be ok to take https://firstname.lastname@example.org/ through drm-misc? hch and Hans Verkuil are ok with it
17:42danvet: if you have acks from media it's all fine
17:42mripard: Hans acked it yeah
17:42mripard: great then :)
17:42danvet: and drivers/soc
17:42danvet: not sure who's doing that
17:43danvet: I guess hch ack is good enough too
17:43mripard: I don't think there's anyone in charge of drivers/soc really
17:43danvet: seems to be split up per-soc
17:43mripard: but I can ask the arm-soc people if you'd be more comfortable with it
17:44narmstrong: danvet: afk but will do asap
17:44danvet: and it's you anyway
17:44danvet: narmstrong, I meant nothing for you to do this time, I'm doing it already
17:44danvet: just next time around
17:44danvet: mripard, imo all good to go
17:44mripard: danvet: great, thanks :)
17:47zmike_: jekstrand: oh I thought you were still in #zink...went to ping you and it didn't complete
17:48zmike_: are there plans to do more with pipeline stage/access in anv barrier usage?
17:53jekstrand: zmike_: There's talk of it
18:18GNUtoo: emersion: Hi, at XDC 2019 you organized the "Let's make KMS planes useful for compositors" workshop,
18:18GNUtoo: I recall from it that it was possible for applications to request specific pixel format to the kernel.
18:18GNUtoo: If the hardware "planes" can do BGR or RGB but not both at the same time, is there already the infrastructure in place in the kenrel to tell that RGB is not available anymore once BGR is starting to be used?
18:24arnd: mripard, danvet: the arm-soc people are happy to take patches for drivers/soc/, split up into logical branches. https://email@example.com/ looks reasonable as a single branch we can take through our 'drivers' branch
18:25mripard: arnd: we need to keep the bisection and all patches together, hence why I suggested drm-misc
18:25mripard: but if you prefer you can take all the patches as well
18:25danvet: yeah a-b: me for whatever
18:27arnd: I think going through the soc tree is the most logical place fro the series, and it helps avoid merge conflicts. If something else depends on it, it could be a shared branch
18:28mripard: arnd: I'll send you a PR tomorrow then
18:31LiquidAcid: GNUtoo, pixel format is a property of the plane, if you use libdrm then it's an array in drmModePlane
18:33emersion: GNUtoo: yes, the kernel can fail atomic commits containing both BGR and RGB
18:34emersion: so planes would advertise both formats, but trying to use two different formats would fail
18:34emersion: note, that would probably confuse existing use-space
18:35GNUtoo: emersion: ahh, that's probably the issue here
18:35emersion: in other words, don't expect existing user-space to start trying out all formats once one doesn't work
18:35GNUtoo: I assumed that userspace would retry with another format
18:36emersion: yeah, it's very tricky for user-space to figure out _why_ an atomic commit fails, and what it can do to make it work
18:36emersion: the only option rn is to take a guess
18:36GNUtoo: Still, as I understand it, we can still patch userspace to retry formats as it's supposed to do that in the first place.
18:36emersion: i'm not sure it's supposed to…
18:37LiquidAcid: shouldn't userspace try to figure out a working combination by issuing test commits first?
18:37emersion: trying a format is expensive: you need to allocate a new buffer, then perform a test-only commit
18:37GNUtoo: Was it possible to get hints on what might work?
18:38LiquidAcid: but you would only need to do that once during startup of the application right?
18:38GNUtoo: (like the userspace would ask for a list of preffered format)
18:38emersion: one of the discussions we had at XDC 2019 was about hints indeed
18:38GNUtoo: indeed, that's our use case here
18:39emersion: it was discussed to add some driver-specific logic in libliftoff to allow user-space to know what to do
18:39emersion: we're still pretty far off that goal, though
18:40emersion: to expand on the "should user-space try other formats" thing
18:40emersion: there are many properties user-space sets
18:40emersion: it's hard to know which one causes the atomic commit to fail
18:41emersion: and quickly gets out of hand if you want to try everything
18:41emersion: for instance, some drivers want user-space to retry modifiers
18:41emersion: if you retry formats*modifiers, that's already a big list
18:41emersion: and that's just for FB_ID
18:42GNUtoo: Here the issue we're having is much more simplified: We want to use the same kernel image and parameters for booting Android or a recovery image, both use conflicting pixel formats
18:43GNUtoo: So if userspace asks for RGB, the kernel would then deny BGR or vice versa
18:43GNUtoo: With both formats being supported by the driver
18:43danvet: so for multi-plane using userspace the most basic fallback that should always be there is "disable a plane" as fallback
18:43danvet: until you have a single primary plane per crtc left
18:43emersion: ah, right
18:43danvet: if I understand it correctly, that should work?
18:44danvet: so should be ok enough for recovery image
18:44emersion: at the cost of potentially not getting full hw accel
18:44danvet: everything else is a lot more nasty
18:44danvet: well yeah
18:44danvet: but once you're on your single plane, you can start going through other options
18:44emersion: but, i think in practice user-space will only allocate all in BGR or all in RGB?
18:44danvet: (fourcc, modifier) list is a good one
18:44GNUtoo: Right now we dllud implemented it with a kenrel parameter that sets the list list of supported format to either one or the other list of compatible formats but not both
18:45danvet: until you have something that works and hopefully still accels
18:45danvet: also for some plane usage it might be useful to drop some features
18:45danvet: like try without hw rotation
18:45danvet: or hw scaling
18:45danvet: before dropping that plane usage outright
18:45danvet: or less nv12 (that often needs 2 planes underneath, plus at least one scaler)
18:46danvet: it's kinda nasty, but 90% good enough job should be possible on most reasonable hw
18:46emersion: yup yup. also alpha, and many other props…
18:46danvet: and for the 10% unreasonable hw you might just need to hardcode that specific screen layout for that specific phone
18:46danvet: emersion, I think with most hw alpha is more something that bites with other blending usage
18:46danvet: like lut or ctm or whatever
18:47danvet: but could also be something to drop
18:47GNUtoo: We can indeed hardcode a bit part of it
18:47GNUtoo: *a big
18:47GNUtoo: Though ideally over time we'd need to make the hardcoding at runtime and not build time
18:48GNUtoo: (Else supporting many devices will become a pain to handle)
18:48danvet: GNUtoo, not sure you're hardcoding needs are really needed
18:48danvet: btw for context, which hw/compositor?
18:49danvet: could also be driver issues in there, generally not the most awesome driver we have
18:49danvet: it's really old, plus not much maintenance going on
18:51dllud: Hi everybody! This is the implementation with the boot time parameter that GNUtoo mentioned:
18:51emersion: yeah, i'd say just expose both formats, and fail atomic commits if they contain mixed formats
18:52emersion: existing user-space should at least be able to light up the screen that way
18:52Plagman: i like how 'unreasonable hw' automatically means 'phone' :P
18:53danvet: Plagman, there's a lot of unreasonable desktop hw too
18:53dllud: emersion, what would be most acceptable upstream, the boot time parameter or listing all and failing the atomic commits?
18:53danvet: like amdgpu only has a pipe scaler for the primary plane
18:53anholt: honestly, rpi's display is the only reasonable one I think I've seen. and even that...
18:53danvet: so if you scale that, but not the cursor, it can't
18:53danvet: but other planes have their own scaler
18:54emersion: dllud: the latter i believe
18:54GNUtoo: dllud: can we easily do that in the lower layers of Android ("just expose both formats, and fail atomic commits if they contain mixed formats") in a way that makes applications / camera use the right format?
18:54dllud: (right now upstream only supports RGB, but the hardware can do BGR)
18:54danvet: anything where choosing one thing in a plane has massive effects in other planes is kinda awkward
18:54emersion: and amdgpu's cursor plane is actually not a proper plane :P
18:55danvet: aside from running out of global resources like reassignable scalers, clocks, memory bw, or converts or whatever
18:55Plagman: so if we scale main plane on amd, hw cursor scale comes with?
18:55emersion: Plagman: correct
18:55Plagman: and we'd have to scale the image if we wanted to undo that?
18:55emersion: i believe so
18:55danvet: or just not use the cursor
18:55emersion: ^ that's more realistic
18:56danvet: so if you put the scaled video on the primary plane it might come down
18:56Plagman: you mean use another general purpose plane in lieu of a cursor, or just composite it by hand?
18:56emersion: either would work
18:56Plagman: cause the latter is expensive unfortunately
18:56danvet: and the compositor falls back to ragequit, I'll render this in full res RGB
18:56danvet: with a single primary plane
18:56emersion: the overlay plane seems like a proper plane
18:56Plagman: is there only one of those that work with rgb?
18:57danvet: essentially anything where converters, scalers, or anything else is hard-coded assigned to a plane is kinda awkward to program
18:57Plagman: realistically i think we'd probably want to bend over backwards to still be able to use the cursor
18:57Plagman: but scaling the image in SW doesn't seem too bad
18:57emersion: cursor can only do ARGB8888
18:57danvet: or the example from GNUtoo where pixel format choice is global
18:57Plagman: although i understand there's an upper size limit as well
18:57emersion: overlay can do that, but also more formats as well
18:58danvet: so yeah, if you look, any display hw has some really quirky corners
18:58danvet: i915 is pretty bad with bw limitations due to formats/rotation
18:58danvet: plus the lut/ctm hw is fun (but we don't expose a lot of that yet)
19:00danvet: robclark, the only dma_fence you can do for drm_uring is the "it's already signalled, but here it is" dma_fence
19:00danvet: so that's a kinda bad stall each frame
19:01danvet: robclark, btw should I apply these patches from lee jones now or will you?
19:01danvet: maybe I could
19:01danvet: I meant, maybe I could not good enough :-)
19:01danvet: and it's all rather trivial stuff
19:02robclark: danvet: we can still return a dma_fence, it would be the one place we need to wait, but not worse than ioctl
19:03danvet: you can't return the dma_fence before it's already signalled
19:03danvet: from drm_uring
19:03robclark: danvet: for lag's patches, I didn't have a chance to see if they are likely to conflict with anything else in msm-next
19:03robclark: danvet: we can return it before it's signalled, but it needs to be "armed"
19:03robclark: same thing as w/ ioctl
19:03danvet: I'd like to get those patches out of my mind
19:04robclark: danvet: I was planning to pick them up in msm-next for 5.11, just haven't had a chance to switch to my kernel hat since yesterday ;-)
19:04danvet: yeah I'm just nagging about small drm drivers maintained somewhere else :-)
19:04robclark: a couple of the docs patches, I think I'll just try to fix the missing fields
19:05robclark: drm/msm isn't all that small ;-)
19:05danvet: it's smaller than the insta patch apply service from agd5f
19:06danvet: robclark, anyway can you pls reply on the list you'll take care of these?
19:06robclark: I do tend to batch up applying patches so I'm not *constantly* context switching
19:06danvet: yeah that's why I like group maintainering
19:06danvet: for trivial mass patch piles like this someone else can wrestle it
19:07danvet: since "once per kernel release" is kinda not awesome for contributors
19:11robclark: I suppose technically seanpaul can still apply/push patches.. but I suspect he is about as busy as me
19:11danvet: yeah seanpaul seems to have signed off from kernel stuff in upstream too
19:19bnieuwenhuizen: Plagman: my understanding from AMD HW is all planes besides the cursor are equivalent
19:19bnieuwenhuizen: but no idea if that means a scaler per proper plane
19:50Plagman: emersion: is this log really riddled with TMDS -> TDMS typos or am i being dumb?
19:50Plagman: is this the dump tool doing that, or the kernel having typos?
19:51Plagman: well, for some definition of 'riddled', only 2 spots
19:51Plagman: more broadly though: cool that this tool and db exists! super useful
19:52emersion: oh, probably a typo in my code
19:52Plagman: cool, that sounds better than it showing like that from the kernel :P
19:56emersion: aaaand fixed
19:58Plagman: open source™
20:04tango_: I mean this could just be done with closed source too, since the typo author fixed it 8-D
20:14DrNick: neat, hardware video decoding in firefox appears to be losing vertical hold occasionally
20:15DrNick: which is weird considering the complete lack of analog signal
20:15Plagman: pitch mismatch can cause things to flee vertically right?
20:17DrNick: its actually more like the video is getting squished vertically and only drawn in the top part of the rectangle, with black at the bottom
20:18ajax: 50% top/bottom?
20:18DrNick: seems to happen immediately after a background tab gets raised to the foreground again
20:18ajax: (would make me think interlace confusion if so)
20:18DrNick: which is I guess an improvement over the solid green rectangle
20:18DrNick: no, its like 90%
20:21ajax: how many years of userspace bc is reasonable to maintain?
20:22ajax: just to pick a Totally Arbitrary line in the sand, say i wanted to drop support for loading drivers that predate mesa 8.0 (feb 2012)
20:24ajax: that's more support lifetime than you get out of rhel or ubuntu lts...
20:25jenatali: From a MS perspective that's such a short compat timeframe :P
20:26DrNick: Windows 10 will still load XDDM drivers, no?
20:27jenatali: No, that did die in Win8
20:27ajax: jenatali: can you take a video driver from windows 8 and expect it to work in 10?
20:27jenatali: ajax: Yes, Vista+
20:29ajax: oh yeah, vista was wddm. which is actually a better analogy, since the drivers that only exist pre-mesa-8 are all userspace modesetting
20:29ajax: (fucking die already DRI1)
20:29jenatali: Ah, ok, got it, that seems fair then
20:29airlied: like what even might be useable, mga?
20:30airlied: probs just burn dri1 down
20:30ajax: mga, rage128 if you're a masochist
20:30ajax: unichrome if you're completely mad
20:30jenatali: Yeah I guess we lived with XDDM+WDDM combined for ~6 years (Vista/Win7) before we killed XDDM, so 8 seems reasonable to me
20:31ajax: mesa 8 also happens to be when we grew gl 3.0 and GLX_ARB_create_context
20:32ajax: and i kind of feel like if the bug you're bisecting is that old you can build your own libGL too
20:33dcbaker[m]: ajax: honestly we can probably just drop everything since we dropped autotools. You're not going to bisect from only meson to only autotools
20:35ajax: enh. more for toolchain-related build failures than anything else, there.
20:36ajax: having recently done an experiment where i undeleted a gallium driver and then incrementally rebuilt it forward to master...
20:46danvet: mesa sunsetting dri1 would give us a prime excuse to do the same in the kernel
20:48airlied: we ahoild at least make sure no distroa enajle legacy drm drivers
20:48ajax: we only did the mesa-dri1-drivers thing in rhel6
20:49idr: ajax: Come on... what about my Voodoo5?
20:49anholt: debian's got CONFIG_DRM_LEGACY=y if that's the question
20:50idr: (It was a joke, BTW.) :)
20:51ajax: airlied: anyone doing that with a modern toolchain has sunk a lot of effort into keeping 7.11 building...
20:51danvet: oh man debian is glorious, enables all the root hole backwards compat options
20:52danvet: but not the drivers
20:53danvet: anholt, ^^
20:53anholt: ahaha that's great
20:53robclark: danvet: taint kernel if DRM_LEGACY=y ?
20:53anholt: yep, no tdfx, r128, mga, sis, via, savage
20:54danvet: robclark, I got it added to the checker of the kernel hardening folks
20:54danvet: Kconfig checker I mean
20:54ajax: squeeze was the last to ship with mesa 7.x. wheezy was 8.0.5 at release time, i'm not sure if they ever had a separate package for dri1 drivers.
20:55ajax: jcristau: ^ any idea? packages.d.o doesn't seem to know about wheezy anymore
20:55ajax: danvet: we should disable the /dev/agpgart frontend too
20:55ajax: if that's not already a thing. i had a patch for that somewhere
20:55danvet: jcristau, maybe disable CONFIG_DRM_LEGACY and CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT while at it
20:55tango_: isn't wheezy oldoldstable?
20:55danvet: saves you at least one CVE
20:56ajax: tango_: oldoldold. buster is stable, stretch, jessie, wheezy
20:56tango_: oh, p.d.o only goes back to oldstable
20:56danvet: ajax, oh right
20:57tango_: ajax: you're only a solid “purge old code” streak these months
20:57danvet: ajax, but that one gives you nice holes at least only on old crap hw
20:58ajax: tango_: some days it feels like the only real skill i have. 2020's been rough, i take my victories where i get them.
20:58danvet: otoh we could just go and sunset all of drivers/char/agp
20:58danvet: I think all the kms drm driver nuked it
20:59ajax: my threshold for caring these days is can it do gles2. which just barely includes agp.
20:59danvet: ajax, kms drivers don't do agp mode anymore
20:59danvet: so if we kill dri we can also delete drivers/char/agp
20:59ajax: but if you don't need it for r300 then word
21:00danvet: r300 switched to the built-in gart a few months back after a thread that yes, agp is still broken
21:00ajax: slash nv40 i guess
21:01ajax: slash matrox p, xgi v5, 3dlabs wildcat, s3 chrome somethingorother...
21:01danvet: oh right it's not dead, still compile time option :-/
21:02danvet: ajax, and goes up to r500 with the bridge chip
21:03ajax: alright well !7660 shots fired
21:04danvet: lol char/agp/ very much yolo locking
21:40danvet: ajax, I typed up the agp frontend patch and sent it out
21:52pepp: idr: hi! could you take another look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7078 (display list optimizations)?
21:52gitbot: Mesa issue (Merge request) 7078 in mesa "mesa: optimize display list" [Mesa, Performance, Opened]
21:56jenatali: ajax: Penny is a fantastic name, and seeing that is perfect timing, I was just about to go start figuring out how to glue glon12 into our WSL virtualization, which is nearly identical to what you're doing for Zink
21:58ajax: jenatali: hah, thanks! hoping that making the MR for it will motivate me to finish it
21:59ajax: the "dri" backend handling in libGL has bugged the shit out of me for a while so i'm taking the opportunity to clean it up as i go
22:00ajax: danvet: looks very close to what i
22:00anholt: ajax: assuming people don't flip out about dri1 removal, I'll sign up to review that series.
22:00ajax: d done, will r-b when i get a moment (likely tomorrow)
22:26jekstrand: jenatali: What's up with undef_to_zero?
22:31jenatali: jekstrand: Without that we ended up getting 8bit types coming into the DXIL backend which only ended up getting converted
22:31jenatali: We might've been able to get by with constant folding on undefs instead
22:34jekstrand: jenatali: Oh, ok. That makes sense.
22:35jekstrand: jenatali: Yeah.... We really need undef folding.
22:35jekstrand: But undef-to-zero should work.
22:47jekstrand: jenatali: You should probably review the commits from me that are in there. :P
22:47jenatali: jekstrand: Right :)
23:09jenatali: jekstrand: Not sure I'm following the f2i64 point about integer division lowering...
23:10jenatali: I think I'll drop that patch, disable that test for now, and we can figure it out later
23:11jekstrand: jenatali: My understanding is that you need saturating conversions for div/rem correctness, right?
23:11jenatali: jekstrand: No, it's just for correctness of float->long/ulong I think
23:12jekstrand: jenatali: Then why was div/rem mentioned in the commit message?
23:13jenatali: The algorithm for f2i64/f2u64 used fdiv/frem to get the high bits and low bits of the resulting 64bit value
23:13jekstrand: Then I completely misunderstood the patch. :)
23:14jenatali: Yeah, the patch just bypasses that if the incoming float is out-of-bounds, with bcsel afterwards, instead of using fmin/fmax and then continuing to use fdiv/frem
23:17jekstrand: jenatali: Just to double-check, f2u32 does a truncation, right?
23:17jenatali: Yeah, NIR's modes for float->int/uint is rtz
23:20jekstrand: jenatali: So does this matter for regular f2i64 or only for the saturating version?
23:21jenatali: jekstrand: I think according to spec it doesn't matter for regular f2fi64, but in practice even just doing a round trip on INT64_MAX it's needed
23:21idr: ajax, anholt: Given that these days having multiple libGL on a system is possible... I'd be very surprised if removing DRI1 from libGL was a problem for anyone.
23:22jekstrand: jenatali: Yeah, I'm just wondering if the fix belongs there or in our lowering of convert_alu_types
23:22anholt: yep. glvnd is the right interface.
23:23jekstrand: jenatali: In particular, I never quite believed nir_clamp_to_type_range for int64....
23:24jekstrand: jenatali: I thought I'd convinced myself it was fine but I guess not. :)
23:24jenatali: jekstrand: Ah, right, it clamps as a float before feeding it into the alu opcode, hmm
23:25jekstrand: jenatali: Yup
23:25jenatali: jekstrand: We could leave the int64 pass alone, and just add a special case to nir_convert_with_rounding to do the bcsel on out-of-range float->int/uint conversions
23:25jekstrand: jenatali: And this is "fixing" it by always shoving the max float value to UINT64_MAX instead of the slightly smaller uint64 value that might actually be the right thing.
23:26jekstrand: jenatali: Yeah, I think that's what we actually want.
23:26jekstrand: jenatali: And I think we may only have to do it for int64 but I'm actually not sure...
23:26jenatali: jekstrand: "Might be the right thing"?
23:26jenatali: I think float16->int32 might need it too
23:26jekstrand: Yeah, I think so
23:27jekstrand: I thought that was sketchy when I reviewed that code. :)
23:27jekstrand:clearly needs to set the alarm on his BS-o-meter to a higher volume. :)
23:27jenatali: An out-of-range float converted to integral is either undefined, or saturated to max, I'm not sure what you mean by returning the slightly smaller uint64 value
23:29jenatali: But yeah I'll drop that patch for now, it's not strictly required and I'll rework it afterwards
23:29jekstrand: Ok, sounds good.
23:29jekstrand: I think I've either reviewed or ACKed the rest.
23:29jekstrand: I left a few comments but they're all nits
23:29jenatali: I believe so - I addressed all your comments locally, I'll push in a sec
23:29jekstrand: I'll try to summarize this discussion on that thread quick.
23:29jenatali: Thanks, I was just about to do that :P
23:30jcristau: ajax: i don't think we ever had a separate package from dri1
23:36jenatali: jekstrand: I think that's everything then. Anything else I should wait for?
23:36jekstrand: jenatali: If you think curro's ok with it, then marge it
23:37jekstrand: jenatali: It sounded like he was conditional on trying to unify some stuff with clover.
23:37jenatali: jekstrand: My interpretation of his last "fair enough" was a begrudging okay, conditional that we'll try to work together to unify things afterwards
23:37jekstrand: jenatali: Ok, that was mine too.
23:38jenatali: I'll give curro some time to chime in here in case we're misinterpreting :) probably marge in the morning
23:39jenatali: Thanks for all the help and reviews :)
23:40jekstrand: Thanks for fixing all the bugs in NIR for us. :)
23:47jekstrand: jenatali: I added a patch on top for lower_undef_to_zero
23:47jenatali: jekstrand: Thanks :)
23:47jekstrand: jenatali: If you'd rather I make my own MR rather than messing with yours, I can do that. :)
23:47idr: pepp: That and mareko's uniform / pushattrib / all of everything MR are on my list for the next day or so.
23:47jenatali: Nah that's fine
23:47jekstrand: It's fun when you can cut a pass in half just by using the right helpers. :)
23:48idr: I've been trying to get !6358 landed, and I'm trying to get another MR out.
23:51jenatali: jekstrand: I think these are all the follow-ons: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3824
23:51gitbot: Mesa issue 3824 in mesa "CLOn12 compiler follow-ons" [Clover, D3D12, Opened]
23:51jenatali: At least until printf lands and I need to hook that up too - though maybe I'll just do that in airlied's MR
23:52jekstrand: jenatali: That seems about right to me.
23:52jekstrand: jenatali: Uh... yeah... printf. :(
23:52jekstrand:should look at that, probably.
23:53jenatali: jekstrand: I think you shouldn't need to do anything about it? Unless you mean just reviewing
23:53jekstrand: I mean reviewing
23:53jekstrand: airlied's NIR code always needs review. :)
23:57airlied: jekstrand: oh you'll love printf, lots of horrid bits
23:58jenatali: It's not *that* bad