00:04jljusten: anholt: I think I just need to add 'Multi-Arch: same' to control. I'll give it a try.
05:21airlied: seanpaul: you have some open review on last of keithp's patches for leases, anything else you want to say?
05:22airlied:has pushed all the ones before that to drm-next
06:18danvet: aknautiy, "HDMI Aspect Ratio" can you pls reply to that mail on dri-devel with latest status?
08:38itoral: nha: did you have a chance to look at the v2 of "glsl/linker: produce error when invalid explicit locations are used"? you granted Rb to the v1 but I found a couple of regressions in piglit aferwards that I fixed in the new version
08:55nha: itoral, yes, r-b on v2 as well
08:55nha: thanks for the patience!
09:05itoral: nha: no worries, and thanks for the Rb!
10:01tagr: danvet: I'm getting a strange merge conflict trying to rebuild drm-tip
10:02danvet: tagr, stuff you pushed or something else?
10:02tagr: danvet: it's somewhere in drm/amd, that's stuff I never touch
10:02danvet: gitk --merge helps with that
10:02danvet: tagr, might be simply because dim rolls forward drm-next/fixes too when you push
10:03danvet: amd conflicts is why I want hwentlan agd5f and Co using dim too :-)
10:03tagr: yeah, I think that's what happens
10:03tagr: it's trying to merge drm-intel-next-queued and failing
10:04danvet: tagr, I'm fixing it quickly
10:05danvet: agd5f, airlied revert conflicts with -next fyi
10:05tagr: danvet: thanks, I was going to try and resolve it myself, but couldn't figure out exactly where the first parent was coming from
10:09tagr: danvet: looks like 79867462634836ee5c39a2cdf624719feeb189bd might be the correct fix for the revert
10:10tagr: oh nevermind... the revert mentions that =)
10:11danvet: tagr, gitk --merge is perfect for figure most conflicts out
10:11danvet: I think the dim pages do mention it
10:12tagr: yeah, I never learned how to use it =\
10:18tagr: danvet: looks like it doesn't show you much more that git diff does, except you get to peek at both parents via click
10:19danvet: tagr, it filters the history, showing you just the commits that touched the conflicting area
10:19danvet: instead of full history of both parents
10:20tagr: yeah, that helps a little
10:21tagr: it's still somewhat annoying to resolve in this case because git's already thrown away most of the hunk from the second parent that we actually want
10:21danvet: git blame would be really useful too, but that only shows you the first parent and the other as "new"
10:22danvet: hm I didn't look that closely tbh
10:22danvet: I just made it compile :-)
10:26tagr: danvet: fwiw: http://paste.debian.net/991638/
10:26tagr: danvet: that's not build-tested, though
10:27tagr: danvet: looking at that second hunk, something went wrong, though
10:27tagr: that was resolved automatically, though, so maybe we've got a bad resolution in rerere?
10:28danvet: airlied, ^^ you might want to backmerge properly to avoid my crap landing somewhere :-)
10:32airlied: danvet: yeah ill send fixes tmrw and try and backmerge asap
10:35tagr: danvet: I /think/ your resolution is actually reverting things to what's in drm-next-fixes rather than what's supposed to be in -next
10:35tagr: danvet: it probably doesn't matter much for drm-tip, because that's for Intel CI only, right?
10:53danvet: dolphin, vivijim j4ni seanpaul airlied: I've frozen airlied/drm-next to the pre-lease state because the leases are fireworks
10:54j4ni: we need to get drm contributors running igt and/or CI running on dri-devel
10:58danvet: j4ni, ci for dri-devel is on the plan
10:58danvet: but there's simply still too much noise in BAT imo to inflict it on unsuspecting bystanders imo
10:59danvet: upside is that at least some have figured out what we're doing and are now cc'ing intel-gfx for core changes :-)
11:08airlied: ah i must have been seanpaul suggested lockdep warns, boo for assuming review changes were fine
11:09airlied: ah well tmrw dave problem
11:38strfllw: jekstrand: since you wrote the original, any opinion on https://patchwork.freedesktop.org/patch/183215/ ?
11:53robertfoss: robclark, robher, daniels: I need to set up a bug tracker for drm_hwcomposer, is that something that can be done on fd.o easily?
11:54daniels: robertfoss: yeah, we can set up either bz or phab easily enough if you'd like, but both will ultimately be replaced with gitlab, so it'd just be fairly temporary
11:55robertfoss: daniels: maybe whatever is the easiest to migrate to gitlab makes the most sense?
11:55robertfoss: daniels: how is the gitlab migration looking now?
12:04daniels: robertfoss: ETIME :(
12:06j4ni: daniels: "bz" ... "will ultimately be replaced with gitlab"???
12:06ajax: sounds good to me tbh
12:07daniels: j4ni: that's our long-term plan
12:07daniels: (you'd be surprised how good gitlab's issue tracking is these days; it's come an infinitely long way from 8.x to current)
12:09j4ni: the first thought is not about the relative merits of the tools themselves. it's about all the tooling and processes and custom platform/feature fields etc we have around fdo bz
12:10ajax: i mean, he did say "long term"
12:10ajax: consider yourself warned i guess?
12:10j4ni: yeah, sure, but seems kind of accidental warning
12:11daniels: yeah, it is; i was hoping to get a kind of fd.o update session at xdc so we could talk about this, but without that just blogging saying 'we'll likely do this at some point!' seems fairly hopeless even without a test install
12:12j4ni: so even if gitlab is absolutely better (which I have no idea if it is, never used it) there's a non-trivial cost associated with the transition
12:12ajax: whatever happened to the fdo admin blog anyway, not seeing it on planet
12:15daniels: j4ni: no doubt
12:15daniels: j4ni: the dangling carrot of going through the transition cost is that it unblocks a lot of things: people can just create repos and do repo maintenance on their own, manage their own group access rights, etc etc
12:16daniels: (additionally i think the tool is better than cgit + bz + patchwork + ... but ymmv)
12:16j4ni: ...we've also put a lot of effort into patchwork
12:17j4ni: and our CI is triggered by patchwork, and the results are fed back there
12:18daniels: i was a bit flippant earlier. if i was restating it better, i would have said something like: 'well, since we're installing gitlab, and plan to after an initial bedding-down and transition period, strongly suggest that people migrate their uses of other tools from those tools to gitlab, then later seek to deprecate and switch off those other tools one by one as and when appropriate, which we choose to host bug
12:18daniels: tracking for a small project with currently 0 bugs tracked doesn't make much difference, since that would be one of the first projects we seek to move anyway.'
12:20daniels: none of this is to say 'yeah so i was planning to tell intel next week that they have to redo their entire workflow from scratch in 2 days max'
12:20j4ni: heh, I didn't think so either
12:22j4ni: so how about I just pretend I never heard this, and you can set up a test install, plan your announcement and schedules and stuff, and we can talk more?
12:23daniels: sounds good to me :)
12:26j4ni: and fwiw off the bat I'm not opposed to any of this. we'll just need time to plan what we're going to do. possibly we'll still need to keep patchwork around, that's pretty central. but I think we already have admin over that anyway, don't we?
12:30mupuf: daniels: I wonder if I should ask my manager to free some time to help here
12:31daniels: mupuf: ooh, yes please
12:31daniels: j4ni: yeah, totally
12:31daniels: j4ni: gitlab's ci is pretty slick as well, but that only applies if you use it for review rather than email :P
12:32mupuf: daniels: ok, will do
12:33daniels: thanks :)
13:37seanpaul: airlied: I'll take another pass of leases today. iirc, keithp's explanation was all I needed
14:11jekstrand: strfllw: Looks reasonable to me. What version of XCB gets this fancy new function?
14:19strfllw: presumably 1.13, but that's not a released version
14:19strfllw: which is a bit unfortunate
14:19strfllw: it isn't a new function though, the commit in question just fixes it
14:22HdkR: Lyude: What were you working on at XDC again? I've forgotten :D
15:06Lyude: HdkR: I was working on biopenly during the con! That and backporting a patch to fix a bug in my laptop's kernel
15:06Lyude: I work on many other things as well though, like nouveau
15:07HdkR: Lyude: I remember you being frustrated with kernel bits, I couldn't remember exactly what it was that was causing it :P
15:08Lyude: oh it was just me being silly and not disabling IRQs on the right spin locks, lol
15:10HdkR:runs off to LLVM developer meeting
16:07robertfoss: robher: I'm having some issues testing kms_swrast, more specifically building kms_swrast_dri.so
16:07robertfoss: robher: http://paste.debian.net/991704/
16:08robher: robertfoss: humm, it should be in /vendor now.
16:08robertfoss: robher: I figured changing the defconfig would be enough, CONFIG_BOARD_GPU_DRIVERS="freedreno virgl etnaviv imx kms_swrast"
16:08robertfoss: robher: I'm still on android 7
16:09robher: robertfoss: should be "swrast", not kms_swrast
16:09robertfoss: robher: ah. testing that now
16:10robertfoss: robher: when loading the driver later it is kms_swrast either way?
16:12robher: robertfoss: yes, because of the env var.
16:28keithp: daniels: thanks for the non-std display suggestions
16:29daniels: keithp: np, thanks for the prompt!
17:02agd5f: danvet, sorry about the conflict
17:35anholt: danvet: any opinion on 64-bit padding of vc4's madvise ioctl?
17:38keithp: daniels: so, I'm writing up the X RandR side of the non-desktop display stuff. I'm going to have a property mirroring the kernel property (as one does). However, I could easily let the user override that value if they like. That would make the output appear/disappear and I imagine the desktop environment would automagically add/remove it from the desktop.
17:38keithp: Wondering if that seems like overkill
18:35Lyude: Does anyone know how to workaround the annoying egl crash in git master for upstream mesa?
18:37Kayden: there were some crashes recently, but I thought those got fixed with the reverts in 84f3afc2e122cb418573f1e9c61716520f9859c1 and ~1 from there
18:37Lyude: Kayden: let me rebuild real quick and double check
18:43Lyude: Kayden: ....OK. yes, it is working. it was a problem on my end that i don't entirely understand, but things work at least!
18:43Kayden: working is good :)
18:44Kayden: always annoying when it's some weird temporary breakage that doesn't make sense though
18:45Lyude: actually; it just worked because I typed the wrong ldconfig command. ugh, I think it might be segfaulting on the local prefix of libdrm I have since fedora's libdrm isn't up to date enough to work with upstream mesa
18:46airlied: Lyude: i did build them all
18:47Lyude: airlied: hm?
18:47airlied: i may have forgotten to file an f25 update
18:47airlied: Lyude: i try and build libdrm for all open fedora within a day of noticing
18:47danvet: agd5f, I'm just finding new excuses to drag you folks in :-)
18:48airlied: since once it annoys me once it will annoy me 10 times more
18:48Lyude: oh this is f26, might still be pending in bodhi
18:49Lyude: yep, libdrm-2.4.84-1.fc26 rpm enhancement testing 2017-10-12
18:54bbrezillon: anholt: hm, it seems some of the header I am including in vc4_purgeable_bo.c stopped including <signal.h>, because it was compiling before, and after rebasing on master I get the same error you had
18:54Lyude: Kayden: damn. I'm still getting a crash on this machine, and I don't think it's coming from libdrm?
18:55Lyude: i should note as well; I'm using ninja for building this
18:56danvet: MrCooper, cache dirt bug now move to mesa, sry for the confusion yesterday
18:56Lyude: Kayden: https://paste.fedoraproject.org/paste/OIdDQ23gX5bRXHUgTmsFvQ
18:57airlied: anholt: in the v2 patch it looks well padded
18:57Kayden: I haven't run into that one :(
18:57anholt: airlied: ok, if it sounds good to you then I feel ready to merge.
19:08Lyude: I'll take a look and see if I can figure out what's happening here
19:19anholt: oh, wow. vc4's GPU reset has been broken if the binner is where the hang occurred, for a year and a half now.
20:17Lyude: dcbaker: you're the one doing the autohell->meson conversion for mesa at the moment, right?
20:19Lyude: also Kayden tracked down the bug, it's the fault of building with meson apparently
20:24dcbaker: Lyude: that's me
20:26Lyude: dcbaker: alright; I noticed that this build of mesa is failing because it appears some of the EGL stuff isn't done in meson yet. Is anyone working on getting that working with meson?
20:26dcbaker: Lyude: There are patches on the list
20:27Lyude: ah cool. I will probably check them out and review them, now that I've realized the huge difference in speed between autotools and meson trying to work with the former on my dual core laptop is just becoming aggravating :(
20:27Lyude: so it'd be worth the time to help get this built under meson
20:28Kayden:didn't actually track anything down, just parroted information he heard from yesterday
20:28mareko: Kayden: is idr around you somewhere?
20:29Kayden: nope, sorry
20:29Kayden:will ping him for you though
20:30mareko: I'll send him mail
20:31Kayden: magical wand of summoning...success :)
20:33mareko: idr: if we implemented OpenGL 4.5 Compatibility in Mesa (for radeonsi), would you be opposed to having it in the master branch?
20:33idr: Yes. Very strongly.
20:33ajax: the compatibility profile? yow.
20:33Kayden: It might help kill fglrx, FWIW.
20:34mareko: yes, it might kill our closed source GL driver forever
20:34Kayden: I think the thinking was to implement enough of the compatibility profile to get a set of CAD etc apps working that AMD customers care about
20:34Kayden: but not necessarily worry about every interaction
20:34ajax: have we considered doing that as a layer above libGL?
20:35ajax: (not entirely sure if that makes sense as a question, but)
20:35Kayden: one thing I'd thought about was...if we were to do anything...could we avoid promoting to compatibility profile, and only use it when explicitly requested?
20:35idr: ajax: I did at talk about this at DDC a decade ago. Short answer... you have to basically write a whole driver on top.
20:36ajax: idr: if it's just the one driver for arbitrary core ctxs...
20:37idr: Having something half-baked is a non-starter, and implementing it correctly is going to add a bunch of overhead and a ton of maintenance burden.
20:37mareko: we kinda need that compatibility profile... now... it can be an out-of-tree branch, I don't mind that, I'm just offering you the source code
20:37mareko: .. that has yet to be written
20:37idr: ajax: It's still a lot of work.
20:37ajax: oh no doubt
20:39mareko: BTW we do care about compatibility profile performance, it has to outperform the closed driver in workstation apps
20:40idr: mareko: What GL version do they actually need?
20:40HdkR: People are still using the compatibility profile?
20:40mareko: idr: no idea
20:40HdkR: Can't you just tell them to stop being trash?
20:40idr: HdkR: No... because NVIDIA has spent a decade telling them to be trash.
20:41HdkR: Trash buddies
20:41idr: mareko: I ask because the compatibility profile problems really start when we added more shader stages.
20:42idr: We could easily do 3.1, but adding geometry shader support... is too painful to think about.
20:43idr: We'd also need about a billion more piglit tests. The CTS uses core profile, so it won't help.
20:43mareko: yeah I expect to have an (out-of tree?) piglit branch too
20:43ajax: on the plus side, those tests have a known "pass" state. whatever nvidia's gl does, that's a pass.
20:44Kayden: there are a ton of interactions I can't see us ever doing properly, like feedback/select with geometry shaders. but I don't think anybody actually cares about those.
20:45Kayden: so it's sort of a question about how lame is good enough
20:45Kayden: was also hoping to avoid giving people compatibility mode by default, to still discourage its use, but allow it to be used for enterprise apps
20:45mareko: Kayden: that's kinda done, we can use gallium/draw to emulate selection and feedback modes
20:45idr: Kayden: You'd be surprised. I'd fully expect the kind of app that wants GL 4.x compatibility profile to want all those esoteric functions.
20:46idr: There's a reason they haven't ported to a more modern API, after all.
20:46Kayden: idr: I'd expect both in the same program, but both combined?
20:46anholt: I think a much more fair assumption is "we've got a giant pile of old code that renders one way using compat functions, but we also want to do some fancy shaders in this one tiny part of our codebase"
20:47Kayden: that's what I'd expect. that seems feasible. if it's everything-together, that seems crazy.
20:48HdkR:watches the dumpster fire
20:48idr: mareko: I think my suggestion is to implement things version by version (the tiny bit of 3.1 that remains, then 3.2, etc.) and send them out.
20:49idr: Then we can discuss the cost / benefit of each set.
20:49mareko: this is my todo for GS: https://hastebin.com/agimewatef.md
20:50mareko: it's the only big feature between GL 3.0 and 3.3
20:50idr: Probably also need to test additional interactions with gl_Foo and separate shader objects in geometry shaders.
20:51Kayden: I would need to do some ugly shader interface unification in i965 to make it work, but I think I can make that happen
20:51mareko: Kayden: I don't have to :) I kinda have to
20:51mareko: for radeonsi that is
20:53idr: Ugh... and LUMINANCE_ALPHA textures everywhere...
20:53Kayden: That's fortunately not that bad.
20:53Kayden: It's a little bit of extra code in the "get me a swizzle" function
20:55mareko: just FYI, if we merge it, it will be an optional feature and I assume most drivers won't want to expose it
20:56Kayden: we've had a few apps that need compatibilty profile as well
20:56Kayden: on i965
20:57Kayden: it turned out they needed about 1% of compatibility profile
20:57idr: mareko: Do you have a requirement for GL_ARB_geometry_shader4 as well?
20:57mareko: idr: no
20:57Kayden:is still very not excited about ARB_geometry_shader4
20:58mareko: what's the deal with that?
20:58danvet: MrCooper, there's still the issue that if you'd export something from i915 and import from amdgpu, the coherency mode will be wrong
20:58Kayden: the arrays are sized dynamically via the API rather than in the shader
20:58danvet: since i915 expects you to snoop, mostly :-)
20:58idr: mareko: One of the sizes is specified via the API instead of in the shader... so you have to do a major recompile.
20:59idr: It looks like geometry shaders and TexBOs are the only 3.x compat features that aren't already supported.
21:00idr:thought there was more than that.
21:01Kayden: Yep, it's pretty tiny.
21:01idr: I think I have a patch that does TexBOs already... somewhere.
21:01Kayden: There's one in ~anholt/mesa from 5 years ago or so
21:02idr: Yeah... I think it was that plus some more to actually advertise 3.1 with GL_ARB_compatibility.
21:09airlied: mareko: how do you know compatability works, do you have target apps?
21:10airlied: like piglit tests would be a lot of typing without some real world targets
21:16mareko: airlied: workstation apps
21:18airlied: but do yoy have access to them?
21:18mareko: I will
21:18airlied: i assume autocad, maya, lightwave sort of things
21:18airlied: i wonder if targetted app profiles insteafld of all of compat would be a better plan
21:20Kayden: that's another idea
21:20Kayden: essentially, enable compat profile for apps via driconf
21:20idr: airlied: That's a factor to consider in the cost / benefit analysis that I mentioned above. :)
21:21Kayden: sort of like glthread...whitelist apps that are known to work
21:21imirkin_: mareko: i know these are early days, but happy to discuss changes to gallium api as necessary. i think this would be great for nouveau too.
21:22mareko: I think we better do full compatibility if we wanna replace the closed driver completely
21:22airlied: imirkin_: better than threads? :-)
21:22imirkin_: airlied: i don't think the two are mutually exclusive
21:24mareko: if we replace the closed driver on Linux, we might also just add Windows support
21:25imirkin_: airlied: i was under the impression that the threads thing was being worked on, but now i hear that's off.
21:26imirkin_: the threads stuff is all regarding a use-case i think is dumb though (using GL for regular application rendering), so it's difficult to stir up the necessary willpower to rewrite the whole driver
21:27mareko: imirkin_: what threads?
21:28imirkin_: nouveau + threads = fail
21:28airlied: mareko: nouveau can threaded ctx usage
21:28imirkin_: issue is wholly inside nouveau. airlied was just pointing out that it's gone unfixed for years.
21:29imirkin_: games are rarely affected, mostly it's just the KDE/Qt stuff.
21:30airlied: imirkin_: seems more useful than compat, which is $1000 apps a few games
21:30imirkin_: and every demo anyone's tried to run
21:31imirkin_: they all assume compat
21:31imirkin_: people come in and say "bleh, why don't you support anything past 3.0" - very annoying.
21:31imirkin_: and it does them little good to be told about the diff between core and compat
21:32airlied: imirkin_: educating people off deprecated apis is part of the servixe
21:32imirkin_: the people complainign aren't the peopel writing the code
21:32airlied: imirkin_: but what code are they running?
21:32mareko: telling people they are wrong is the best way to make enemies (and make them ignore you)
21:33imirkin_: some demo they downloaded off the interwebs
21:33airlied: i wonder how apple dealt with it
21:33imirkin_: i think people expect nothign to work on macs, so it's ok
21:34mareko: GL 4.0 compat is also just tessellation, the other features are tiny
21:34HdkR: imirkin_: Dolphin gets angry with Nouveau due to threads as well :p
21:34airlied: we need to instill the same set of expectations :-)
21:34imirkin_: they don't even have a page up button, so the whole thing is pretty moot :p
21:34imirkin_: HdkR: self-inflicted pain
21:35imirkin_: HdkR: just don't trigger the draw in your threaded compilation and you'll be fine.
21:35airlied: mareko: i rhink the spec is full of holes
21:35mareko: airlied: not really, the deltas are mostly the same as GS
21:35HdkR: Yea, Stenzek apparently disnt realize that
21:35airlied: mareko: the tbo interactions seemed undefined in some areas
21:36HdkR: So when he added to code to make the blob stop deferring compiling, broke nouveau
21:36airlied: lots of things around texture format interaction seem to be do whatever nvidia does
21:37mareko: airlied: texture buffer objects? those are simply (just luminance etc. formats)
21:37airlied: mareko: do amd have at keast a decent internal test suite for compat?
21:37airlied: since cts doesnt cover it
21:37mareko: most likely
21:37tarceri: airlied: the problem is binary blobs support compat, mesa doesn't so the expectations are already high
21:37imirkin_: HdkR: yeah, coz blob defers compiling. i think all the mesa drivers don't anymore.
21:38HdkR: i965 just doesnt share shader binaries between contexts apparently
21:38imirkin_: er right - not all mesa drivers. some mesa drivers don't precompile
21:38HdkR: So that could be a form of deferred :p
21:38imirkin_: but nouveau and radeonsi definitely do.
21:39mareko: we don't share binaries between contexts
21:39mareko: but there is a shader cache in memory that does that
21:39imirkin_: mareko: but you don't recompile, just reupload right?
21:40mareko: imirkin_: yeah it's loaded from the cache, which is per screen
21:40mareko: it's still a different shader object
21:40imirkin_: didn't you introduce the PIPE_CAP_DONT_CARE_ABOUT_CONTEXT?
21:40HdkR: I guess as long as it doesnt go theough a compile step then Dolphin doesnt care :p
21:40mareko: imirkin_: oh yes
21:41mareko: imirkin_: that's true, we have context-independent shaders
21:42airlied: mareko: anholt can point a lotd of missing interactions with tbos i think
21:42imirkin_: funky TBO interactions is the reason i've always heard for why mesa doesn't support higher GL versions
21:43airlied: the spec is going to be vague and full of missing pieces since nobosy really cares about ir
21:43mareko: I don't see any problem with TBOs, why are we even talking about it? :)
21:43anholt: I have long since paged that information out.
21:43pmoreau: jekstrand: Does NIR have some equivalent to “Capabilities” in SPIR-V? Or do you check for those before converting to SPIR-V? Or maybe just ignore them completely?
21:43anholt: but yeah, there was some minor tbo interaction, and it was our excuse to say no to compat. I regret that choice at this point.
21:43mareko: luminace, alpha, intensity are the reasons we didn't wanna support TBOs
21:44jekstrand: pmoreau: nir_spirv_supported_extensions in nir_spirv.h
21:44mareko: and those are actually used by st/mesa PBO uploads already
21:44jekstrand: pmoreau: But that's just for whether or not we complain about the SPIR-V capabilities.
21:45jekstrand: pmoreau: NIR itself has nir_shader_compiler_options
21:45pmoreau: jekstrand: Ah, thanks, I’ll have a look at it. I was thinking I would need to check in clover that all devices support the required capabilities before accepting the binary.
21:45jekstrand: And there are a bunch of lowering passes that you can run to get rid of stuff.
21:45airlied: mareko: seems you have it all in hand then, go forth and compat :-)
21:46mareko: PIPE_CAP_BUFFER_SAMPLER_VIEW_RGBA_ONLY == 0 is required for TBOs + compat
21:47imirkin_: that was made for SI? or r600?
21:48imirkin_: probably OK to leave them behind at this point :)
21:48mareko: that's it: https://cgit.freedesktop.org/~mareko/mesa/commit/?h=master&id=f6b8582304a9038b505cedcbf08f70051b8a9f62
21:50imirkin_: of course then GL 3.1 will get exposed, which means you have to be careful about ARB_compatibility
21:50imirkin_: oh wait no - not until GL 3.2
21:51imirkin_:can't wait for user clip planes and geometry shaders
21:54mareko: radeonsi only needs to handle legacy color/texcoord inputs/outputs for GS
21:54imirkin_: nvidia is pretty well-equipped for it all, but it just never supported UCP's (not even on nv30 with shaders enabled)
22:05imirkin_: [and the pre-shader stuff did it using some kind of crazy texture-based technique i think]
23:01keithp: airlied: I've got the X server all hacked up to expose a 'NonDesktop' property. If we make the kernel advertise that, then I think things will 'just work'
23:01keithp: Set the NonDesktop property and the X server reports the device as Disconnected
23:01keithp: otherwise it acts completely normally
23:05keithp: airlied: do you want me to work on merging your patches back into the lease series?
23:06keithp: and rebasing at drm-next?
23:09airlied: keithp: I'm going to push leases mostly as is, with ickle's fix to next once it clears a run in intel-ci
23:09airlied: keithp: we can then discuss my lease fixes on top if we want them, keeps it cleaner and less chance of breaking
23:09airlied: keithp: the only thing with non-desktop is the whole shed color for the name
23:10airlied: but it seems non-desktop is where I've landed as well so meh, it's just words and someone will use them wrong anyways
23:18keithp: airlied: right, non-desktop or NonDesktop?
23:18keithp: (sorry, X doesn't have any props with '-' that I could find?)
23:19airlied: keithp: X also passes through the kernel props
23:19keithp: if you're happy to merge the branch as-is, that's fine with me; the changes all seem good
23:19keithp: so the name should match
23:19airlied: so link-status is there now :-)
23:20mdnavare: airlied: yayy!
23:20keithp: if the name matches, I do no work in the modesetting driver, just DIX
23:20keithp: ah, link-status
23:20keithp: ok, non-desktop will be fine then. I'll go update the proposed randr spec change and X server code
23:21keithp: I've already got the kernel changes done and built (for NonDesktop, of course). One moment...
23:21airlied: man i hate naming
23:21keithp: agreed. non-desktop is what you're getting.
23:22keithp: you good with a merge instead of a rebase?
23:22keithp: (I guess it doesn't matter if there aren't conflicts)
23:22mdnavare: keithp: I had an idea of inducing link-status failure through a debugfs just to test these userspace solutions of handling link failure, what do you think?
23:23airlied: keithp: I'm cherry-picking them at the moment
23:23airlied: keithp: there were in next yesterday
23:23airlied: keithp: btw I think seanpaul is wrong as we don't need the idr mutex there
23:23airlied: just going to confirm it
23:23keithp: mdnavare: it's either that or let the X property be writable, and that seems like a bad idea
23:24mdnavare: keithp: Yea we cant make it writable , only kernel should have control
23:25keithp: airlied: I've left the matching X property writable by X; what the heck
23:25keithp: hrm. Probably can't and have the kernel control it. Hrm.
23:25keithp: how does this work anyway
23:26keithp: airlied: here's my name patch: git://people.freedesktop.org/~keithp/linux drm-next-lease-stage
23:26mdnavare: keithp: But after i expose the debugfs node, , so after link training the kernel should set link-status to BAD if that debugfs node tell it to..?
23:26keithp: mdnavare: sounds like that should work; essentially a way to force a failure.
23:28mdnavare: keithp: yes
23:29keithp: I think your idea is a good one then
23:29mdnavare: keithp: That way if this gets scaled to be used in Wayland, they will have a way to test it without caring about that CTS equipment
23:29keithp: airlied: looks like modesetting needs to poll the kernel for property values at GetOutputProperty time; it currently doesn't
23:30airlied: keithp: yeah there is a get property hook into the ddx that is also empty
23:30keithp: indeed. I'll go fill that in. Will make link-status also work :-)
23:31mdnavare: keithp: Awesome
23:31airlied: keithp: we need to decide if the idr_mutex protects the leases idr as wel
23:31airlied: it doesn't seem that consistent
23:31airlied: dev->master_mutex seems to be protecting it sometimes
23:31keithp: hrm. I thought I was consistent, I at least thought about it
23:32airlied: well I think with ickle's patch it's probably is consistent
23:32keithp: ok, I think master should be used
23:32keithp: you mean the lessee_idr?
23:33airlied: keithp: the master->leases one
23:34airlied: I was just wondering if we needed the idr mutex for it at al
23:34airlied: but I think for consistency it's probably good to take it
23:34keithp: It certainly needs a lock of some kind
23:36keithp: looks like it's only used a few places, and only _drm_lease_revoke has it wrong
23:36keithp: oh, and list_lessees_ioctl
23:36airlied: keithp: yeah the get ioctl as well
23:37keithp: it needs to be the idr_mutex though -- it's part of looking up an object in the crtc_idr
23:37keithp: as you have to check leases there
23:37keithp: shall I fix it up?
23:38airlied: keithp: yes please, you should pull Chris patch as well
23:38keithp: ok, I probably don't see that one
23:38airlied: https://cgit.freedesktop.org/~airlied/linux/commit/?h=for-intel-ci&id=d562eacb4d444c5eb909ae2bd32913cb2436b37b is it fixed up
23:39keithp: hrm. lock ordering concern -- master_mutex before idr_mutex?
23:39keithp: or idr_mutex before master_mutex?
23:40airlied: yeah master before idr
23:40keithp: because otherwise, that patch would be wrong :-)
23:41daniels: keithp: property> it's maybe overkill, but seems reasonable
23:41daniels: otoh, you're the one who will have to live with the consequences in the long run ;)
23:41keithp: daniels: alternative?
23:42keithp: Just not exposing it at all?
23:42keithp: on the X side, we don't really need the property; a non-desktop display will show Disconnected with valid EDID
23:44daniels: keithp: nothing springs to mind
23:44keithp: yeah, same here
23:44airlied: daniels: and I happily await a glorious udev future, with some way to shove info into the kernel
23:45airlied:would much prefer to update udev database like steam can for for input devices
23:45keithp: airlied: yeah, some EDID udev helper for connectors. That's gonna happen any day now
23:47daniels: we can do that surprisingly quickly
23:49airlied:would like to see it happen as an independent project like libinput
23:50airlied: we would need hooks to trigger udev on monitor hotplugs (maybe send EDID in the hotplug msg)
23:52keithp: airlied: master_mutex *and* idr_mutex? I don't think so, but want to check
23:53airlied: keithp: nope we may need the master mutex for other things, but for the leases we just wanted idr
23:53keithp: actually, yes, I think so. master_mutex covers the list of lessees in each lessor; idr_mutex covers the leases within a lessee
23:54keithp: so, if we want to walk the list of lessees, we need master
23:54airlied: okay we should write that sentence of wisdom
23:54keithp: will do
23:54keithp: I'll stick it at the top of drm_lease.c