07:25 MrCooper: ickle: FYI your dri-devel list subscription got disabled again due to the megamailservers.eu MX blocking list posts "for containing SPAM-like characteristics"
07:26 ickle: fantastic, patch detected, could be dangerous
07:26 ickle: user could compile their own viruses
07:27 ccr: it's all a grand conspiracy!
07:28 ccr: open source malware development!
07:28 ccr: :D
08:02 danvet: airlied, where/how does prime in X decide whether it needs to do a blit or can directly display?
08:02 danvet: or is that all manual setup with the provider stuff?
08:02 ickle: in the dri3 loader
08:03 airlied: does it ever direct display?
08:03 airlied: pretty sure we always blit
08:03 danvet: well I'm just asking questions :-)
08:04 airlied: we dont shortcut
08:04 danvet: ah that explains some I guess
08:04 ickle: if (draw->is_different_gpu) {
08:04 airlied: if you are intel primary, and nvidia reverse prime display, and nvidia connector
08:05 airlied: you get all the copies
08:05 danvet: ickle, where is that?
08:05 ickle: src/loader/loader_dri3_helper.c
08:05 ickle: mesa
08:05 danvet: ah, was grepping xorg
08:05 ickle: in xorg, present just does as it is told
08:06 ickle: takes dri3 pixmap and blits/replaces window pixmap
08:06 airlied: dri2 used to do it in the server
08:08 MrCooper: airlied: eh, PRIME can display directly with DRI3
08:08 danvet: ah right this had to move to client side
08:08 MrCooper: the server side doesn't even know it's PRIME
08:09 MrCooper: it's up to the kernel to catch when it can't work
08:09 danvet: so client needs to do 2 presents if the pixmap is across 2 xrandr outputs on 2 different gpu?
08:10 danvet: or we just fall back to the copy path if the direct flip fails?
08:10 ickle: no, that bit is fixed up in X
08:10 MrCooper: no, all X drawing is done by Xorg's primary GPU, then copied to secondary GPUs for scanout
08:11 MrCooper: Present doesn't directly support secondary GPUs, so direct flip isn't possible for those
08:12 danvet: MrCooper, ah I guess I misunderstood your comment that prime can do direct display with dri3 then
08:12 MrCooper: that's about render offload
08:13 MrCooper: DRI3 buffers from secondary GPUs can be scanned out on the primary GPU in principle
08:14 danvet: so if we both render and display on 2nd gpu it's roughly render on 2nd gpu -> do a blit in dri3 loder on client side -> present -> do a blit to 2nd gpu -> kms flip?
08:14 danvet: MrCooper, well if your primary gpu is discrete and must scan out from vram, that's getting a a bit tough to make work ...
08:14 danvet: as long as the primary is integrated it tends to work on x86
08:15 MrCooper: the final KMS flip only happens with TearFree (at least with xf86-video-amdgpu/ati), but yeah
08:15 danvet: MrCooper, yeah otherwise you just blit into the screen pixmap and done I guess
08:15 MrCooper: right, artifact city
08:17 MrCooper: danvet: that's where Christian's dma-buf work comes in :)
08:18 MrCooper: obviously, the pipeline above is very sad when it's the same GPU rendering and displaying
08:18 danvet: MrCooper, you can scan out over p2p pci?
08:18 MrCooper: I'd assume so
08:18 danvet: bold
08:18 danvet: :-)
08:19 MrCooper: might be a bad idea even if it can work in theory :)
08:19 danvet: I mean if you can't scan out over pci from system memory, can't see how it would work better over p2p
08:19 danvet: maybe if there's one of these magic cables/interconnects perhaps
08:19 MrCooper: ah, that's because those GPUs can't do scatter-gather scanout
08:20 danvet: but even there that cable would need to support realtime isochronous fetch or something
08:20 danvet: "imma be real pissed if you slack on this read request" or something like that
08:20 MrCooper: i.e. they can only scan out physically contiguous memory
08:21 danvet: yeah that avoids even more of the random "fill didn't happen in time, screen flickered, user unhappy" business
08:24 MrCooper: anyway, Wayland compositors will be able to handle this much better
08:24 lynxeye: danvet: Excuse my ignorant question. Is Intel still doing the full screen flicker instead of repeating last color value on underflow and restart fetch on next possible FIFO state?
08:25 danvet: lynxeye, dunno, I think it depends
08:25 danvet: we also occasionally do the "hang entire memory controller" thing on underrun
08:25 lynxeye: your HW designer seem to really love you guys...
08:25 danvet: it's mutual I think
08:28 lynxeye: danvet: I really don't get why Intel still hasn't grown some HW way to load registers during vblank. Even most of the embedded display units have it by now and you seem to be stuck trying to trick the Linux preemption/scheduling model into providing you some way to do stuff during vblank.
08:47 danvet: lynxeye, oh we've grown that by now, but it's super limited and firmware is in control for otheros reasons
08:47 danvet: but even that doesn't make the fetch engine less yolo
10:32 emersion: > Atomic commits, both real and TEST_ONLY, fake success
10:32 emersion: why this, pq ?
10:33 pq: because any failure would be unexpected
10:33 emersion: is this what happens when a connector is disconnected?
10:33 pq: the same reason as why anything would fake success
10:33 emersion: (and user-space hasn't processed the uevent yet)
10:33 pq: no, when a connector is disconnected, there is no need to fake anything.
10:33 pq: you can force-enable connectors
10:34 emersion: force-enable connectors is via sysfs
10:34 pq: also via KMS, you can simply attach a CRTC and make it run
10:34 emersion: why not make "atomic commit on unplugged GPU" same as "atomic commit on unplugged connector"?
10:34 pq: it is
10:34 emersion: eh, really
10:34 pq: atomic commit on disconnected connector does not fail just because the connector is disconnected.
10:35 emersion: force-enable only works on VGA/HDMI iirc, not DP
10:35 pq: that I don't know about
10:35 pq: perhaps the kernel fakes the DP force-enable part?
10:36 pq: then enabled for real when it's connected or sets link-status to failed if it fails
10:36 pq: ?
10:36 emersion: in igt force-enable is performed only via sysfs iirc, and only on some conenctor types
10:36 emersion: i'm pretty surprised it'd just work via KMS on all connector types
10:37 pq: are you talking about forcing connector status to connected instead?
10:37 emersion: eh, that might be the case
10:37 emersion: force-enable != force-connected?
10:37 pq: no
10:37 emersion: ok, my bad
10:38 pq: force connected: make the connector property report "connected" when it's not, to fool userspace
10:38 pq: force-enable: connect a CRTC to a disconnected connector and turn it on with a mode and FB
10:39 pq: anyway, like I wrote, this is from my understanding and I don't know what drivers actually do.
10:39 pq: my intention very much is to make a disappeared device work "the same" as if it was still present
10:39 emersion: i recall someone mentionning it doesn't work on DP because of DPCD not working or something
10:40 emersion: or aux?
10:40 pq: might be, but the kernel might also lie and it has link-status as the escape hatch when the lies fail :-)
10:42 pq: The whole hot-unplug handling is based on lies to limit the damage to cases where it can actually be handled.
10:44 pq: Personally I would have suggested to not fake success that much, but then if you unplug your device in the middle of e.g. Weston testing which plane configuration works and ends up with not even primary plane working, then making weston handle EIO in there would be some work.
10:45 pq: IMO it wouldn't be a regression, because if you unplugged your device in previous kernel versions, it would have been strictly worse than it would be with new errors.
10:45 emersion: the atomic commit could fail because of other runtime errors
10:45 pq: but meh
10:45 pq: less to fix in userspace with the lies
10:46 pq: it could
10:46 emersion: weston should check the return value
10:46 pq: but it doesn't
10:46 emersion: EINVAL
10:46 pq: so it cannot, because the kernel cannot regress
10:46 emersion: well, it can fail because of ENOMEM at least i assume
10:46 pq: weston checks the return value, but does not have a recovery plan
10:47 emersion: i guess bailing out would be enough
10:47 pq: weston does that
10:47 pq: IIRC
10:47 pq: not sure it that means it will never paint the output again, or will try again on the next damage
10:48 pq: never really looked into it, because these failures are so hard to provoke for testing
10:53 vsyrjala: with i915 the dp forcing only really works if the connector was previously connected, since we hang on to the cached dpcd. if nothing was ever connected there is no cached dpcd and the link bw calculation code gets upset
10:53 vsyrjala: iirc
10:53 vsyrjala: i've occasionally pondered about just popyulating the cached dpcd with fake values from the start
10:54 pq: so the intention is that it "works" but bugs and all that?
10:54 vsyrjala: no one knows if it's really supposed to work
10:54 vsyrjala: certainly new intel hw is going to make this even more painful since the hw/firmware can decide that it can't do what it asked of it, in the middle of the modeset sequence
10:55 pq: I guess no-one has a use-case for force-enable DP :-)
10:55 pq: except one project where I was that needed it to work around something else...
10:55 pq: and that's wasn't intel hw, FWIW
10:56 vsyrjala: we've had bugs reported for thos. iirc it was kodi, which lacked hotplug support and so the user just wanted to force enable the thing from the boot, even if the display wasn't there
10:56 vsyrjala: but faking the dpcd might not fix that because if we fake a too low spec dpcd then the mode the user actually wants might not work anywya
10:57 pq: heh, my case was broken hotplug handling too
11:01 vsyrjala: wrt. the new hw that can just crap out in the middle of the modeset sequence, nonblocking modesets makes this a lot more painful since we now have to figure out how to deal with a total failure after we already told userspace it's going to be ok
11:01 pq: doesn't link-status offer you an easy way out?
11:02 vsyrjala: it lets us inform userspace after the fact. but the question is what happens in the meantime. is userspace going to be happy if all page flips/vblank waits/etc. fail after the modeset supposedly succeded?
11:02 vsyrjala: or are we going to have to simulate vblanks in the kernel
11:02 pq: right
11:05 vsyrjala: it's also going to make the driver code more of a pain becasue we can't anymore just expect the hw state to match the sw state. so presumably we're going to need some kind of "it's dead jim" flag and deal with it in whatever way we can in various places
11:05 vsyrjala:sad
11:06 vsyrjala: though maybe this isn't too dissimilar what we'd need for gpu unplug as well
12:51 linkmauve: Hi, the Windows CI machine is running out of disk space: src\gallium\drivers\llvmpipe\lp_test_format.exe : fatal error LNK1180: insufficient disk space to complete link
13:23 hakzsam: daniels: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/2737887
13:24 daniels: hakzsam: known, being fixed
13:24 hakzsam: awesome, thanks!
13:24 daniels: np
16:07 j4ni: what would be the open source game engine of choice for a beginner wishing to fool around and try stuff?
16:18 thaytan: j4ni, godot seems good
16:18 thaytan: not sure you're asking the right audience here though :)
16:20 alyssa: thaytan: I tried searching for information on it but the page never loaded, it just kept spinning
16:20 alyssa: and i'm *still* waiting for godot
16:20 alyssa: ;p
16:20 pmoreau: :-D
16:21 pendingchaos: jekstrand: can you take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4757 ?
16:23 thaytan: alyssa, just keep waiting, it always takes a little while
16:23 thaytan: I'll check back in a day or two and see how you're getting on
16:27 daniels: fun: https://devblogs.microsoft.com/directx/directx-heart-linux/
16:28 j4ni: thaytan: googling seems to indicate godot or panda 3d, and you may be right about the audience :)
16:29 alyssa: "WDDM D3DKMT" I know what some of those letters are!
16:29 j4ni: daniels: so directx-heart-linux, but does linux-heart-directx? :p
16:30 daniels: j4ni: I don't think I'm authorised to speak on behalf of Linux
16:31 j4ni: merely seeking for observation, not speaking on behalf of ;)
16:31 thaytan: alyssa, I know all of them - my 4yo has been teaching that there are 26 to learn!
16:31 j4ni: *cough* 29 around here *cough*
16:32 j4ni: whoops sorry, how thoughtless of me to *cough* like that in public
16:32 thaytan: j4ni, 29 is too many! Impossible to remember them all!
16:33 alyssa: 2 meters please.
16:33 emersion: > How are the pixels going to flow between Linux applications and the Windows desktop hosting them and how are the various window going to be integrated into unified and seamless experience?
16:33 emersion: hm hm interesting
16:34 j4ni: thaytan: 10+% more to learn!
16:35 emersion: oh, it's using wayland :D
16:36 daniels: emersion: Wayland + RDP
16:38 alyssa: now you just need to virtualize Windows under Linux, and then run that in WSL2, and... :P
16:41 kisak: alyssa: just to avoid the Windows on Windows subsystem?
16:53 alyssa: turtles
16:54 karolherbst: honestly... why adding dx to wsl2?
16:54 karolherbst: I only see disadvantages here
16:54 alyssa: karolherbst: read further down :)
16:55 karolherbst: still
16:55 karolherbst: if we end up with linux software requiring dx, it's already doing enough damage
16:56 thaytan: karolherbst, my guess? encourage people to start thinking of that as a cross-platform graphics API instead of one they don't own
16:56 linkmauve: Don’t we already have a lot of those? Many games for instance require Nine or wined3d.
16:56 karolherbst: I don't want dx to be cross platform
16:57 karolherbst: I won't it to go away
16:57 karolherbst: :p
16:57 karolherbst: * I want
16:57 karolherbst: linkmauve: those are windows binaries, not linux
16:57 ajax: i mean, if it comes with an open source dx12 runtime for linux kernels, awesome
16:57 karolherbst: ajax: it's for wsl2 and closed source :p
16:57 linkmauve: karolherbst, if you have the source code, you can also build them for Linux using winelib.
16:57 ajax: karolherbst: right, my point
16:57 karolherbst: linkmauve: I don't want linux software to use dx
16:57 karolherbst: how pointless is that
16:58 karolherbst: it only helps MS and only because they want to stick with dx12
16:58 karolherbst: just use vulkan
16:58 linkmauve: But many many games already do.
16:58 daniels: ajax: open kernel, closed userspace
16:58 karolherbst: linkmauve: you can only use it on windows though
16:58 karolherbst: so it's pointless
16:58 karolherbst: daniels: ....
16:58 linkmauve: Rewriting their renderer is probably harder than using such a library.
16:58 karolherbst: daniels: it's a shim
16:58 karolherbst: so.. that really doesn't count
16:58 karolherbst: just doing VM magic
16:59 karolherbst: it uses the host dx driver for all the real stuff
16:59 karolherbst: just piping the device through
16:59 Plagman: daniels: that blog post talks about a lot of completely private things like people are supposed to know what they are
16:59 daniels: karolherbst: well sure, it doesn't exactly do like PCI management ...
16:59 jekstrand: This is entertaining: https://devblogs.microsoft.com/directx/directx-heart-linux/
16:59 karolherbst: linkmauve: sure... but then you can only use this linux binary on windows
16:59 karolherbst: making the port... pointless
16:59 daniels: and it's not the shader compiler since that's in userspace
16:59 jekstrand: D3D11 on Linux, sort-of.
16:59 Plagman: if D3DKMT was a real documented api, it'd be cool to port mesa to it
17:00 jekstrand: Oh, daniels already posted. :P
17:00 ajax: i don't have a whole lot fo interest in binding my linux vm / guest / container / whathaveyou to a particular host kernel
17:00 ajax: that is sort of the entire point?
17:00 karolherbst: ajax: exactly
17:00 karolherbst: this is just windows promoting dx12
17:00 karolherbst: and just that
17:00 karolherbst: nothing else
17:00 ajax: if i need services from the hypervisor that only exist from a windows hv then i must not really need those services
17:01 karolherbst: and I am totally against supporting dx12 as long as it's a propriatary API MS being the only one developing the API
17:01 alyssa: jekstrand: Could you ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5102 ? (fsat/pos opcodes, the helpers will go in vendored until we can sort out everything for cross-tree use per karolherbst's comments)
17:01 alyssa: thank you
17:01 karolherbst: seriously
17:01 ajax: i wouldn't mind api compat existing
17:01 karolherbst: this is a bad thing
17:01 daniels: karolherbst: well, it's not exactly going to land mainline without open userspace, right
17:01 ajax: in the same way that i don't mind wine or darling as things in themselves
17:02 EdB: well, it says that after that you can do OpenCl, OpenGL on top of dx
17:02 karolherbst: daniels: it doesn't matter
17:02 karolherbst: if there will be linux software requiring dx12...
17:02 ajax: just let's remember which direction the assimilation is supposed to go, here
17:02 karolherbst: then you need to explain why you took the risk risking this
17:02 jekstrand: karolherbst: There won't be linux software requiring DX12 that you'll have access to
17:02 karolherbst: jekstrand: I really hope so
17:02 karolherbst: but I am sure there will be
17:02 jekstrand: karolherbst: I see two use-cases for this: 1) CUDA development on windows SUCKS so they're making it possible to do CUDA development in WSL.
17:02 daniels: karolherbst: better or worse than CUDA?
17:03 daniels: heh
17:03 karolherbst: just use linux then...
17:03 jekstrand: 2) Lots of games have off-line renderers that they use for e-sports streaming. They want to run those in a cloud environment which means Linux but they don't want to port their entire render pipeline.
17:03 jekstrand: I don't know how WSL fits into that second one, honestly.
17:03 daniels: ^ _lots_
17:03 karolherbst: jekstrand: for 2) you vendor lock in to MS then
17:03 karolherbst: because you can only use this on machines with a windows hypervisor
17:04 karolherbst: so.. only MS benefits
17:04 ajax: perhaps write the hv support for kvm then?
17:04 jekstrand: karolherbst: They're already vendor-locked to MS, the offline renderer isn't something they ship to users, and they have no intentions of doing a Linux port of their actual game client.
17:04 karolherbst: true...
17:04 jekstrand: I'm not saying it's good; just that Linux isn't loosing anything.
17:05 jekstrand: Windows is gaining docker. That's all.
17:05 karolherbst: hopefully you are right
17:05 karolherbst: I am still convinced MS wants to replace NT by Linux though
17:05 karolherbst: and we will end up with linux games requiring dx12
17:05 daniels: ^ that's also my take, from the perspective of someone who's only worked on the KHR->Mesa->DX side, nothing to do with DX-in-kernel
17:05 karolherbst: or dx13
17:05 anholt_: daniels: weird recent windows fail on master build https://gitlab.freedesktop.org/mesa/mesa/-/jobs/2741481
17:06 karolherbst: just takes some years
17:06 karolherbst: and we will look back in 10 years and think: we probably shouldn't have supported this
17:06 jekstrand: As far as I can tell, 90% of the reason for WSL is that Microsoft is loosing piles of developers in the HPC, cloud, and web worlds because development sucks on Windows. Their solution: Make running Linux on Windows more seamless than running in a VM.
17:06 daniels: the first working thing they've announced is DirectML, so you can see it as an assault on CUDA rather than an assault on DRM
17:06 karolherbst: daniels: I see it as an assault to the entire linux desktop actually
17:06 karolherbst: still
17:07 karolherbst: I am convinced they _will_ push for linux to replace NT
17:07 daniels: ajax: uhhhh. impressive.
17:07 karolherbst: and they want to stick with dx
17:07 daniels: karolherbst: tbh I don't think Windows is overly concerned about the marketshare of the Linux desktop
17:07 jekstrand: If Microsoft decides to make Windows 11 run the Linux kernel, that would, IMO, be proof that open-source has finally and totally won.
17:07 karolherbst: yeah.. just that we will be stuck with dx11 then
17:07 daniels: they're probably looking more at the number of developers in the classes jekstrand mentioned who are all running Mac right now
17:07 karolherbst: uhm
17:07 karolherbst: dx12=
17:07 karolherbst: +
17:08 karolherbst: I mean.. sure.. we could start supporting dx12 in mesa
17:08 karolherbst: and I am sure intel and AMD will just do that
17:08 karolherbst: or create new stacks
17:08 karolherbst: dunno
17:08 karolherbst: I see a huge potential for a crappy situation
17:08 jekstrand: With the web and cloud world, Windows is no longer an interesting platform. Microsoft understands this and they are, rightfully, scared.
17:09 karolherbst: yeah
17:09 jekstrand: So they're trying to make Windows relevant
17:09 karolherbst: I totally get windows motivation of doing this
17:09 karolherbst: I am questioning collabor helping out
17:09 karolherbst: *collabora
17:09 anholt_: daniels: looking at more of today's fails, windows is out of disk
17:09 daniels: anholt_: yes, it was earlier, but it hasn't been for a couple of hours
17:09 anholt_: hmmm. wonder what the oom was just now then
17:09 karolherbst: I really hope I am wrong here
17:09 karolherbst: I really do
17:09 jekstrand: karolherbst: Would you question it if I posted an MR tomorrow to make iris and ANV run in WSL?
17:09 karolherbst: but I also see the future that we have to support dx
17:10 jekstrand: Not that I have one. It's a hypothetical question.
17:10 anholt_: jekstrand: I would love that so much.
17:10 jekstrand: I'm sure Plagman would too
17:10 karolherbst: jekstrand: I prefer this over adding dx support to linux
17:11 Plagman: jekstrand: yeah you generally don't hear me shut up about the prospect of running mesa on windows :-)
17:11 Plagman: in fact i was just yapping about it above when daniel posted the blog link
17:11 karolherbst: if anybody starts shipping linux binaries requiring dx and complaining it only works on azure or whatever, then we will be in a huge mess
17:11 Plagman: if one of the outcomes of that ends up being that D3DKMT and family gets documented for real and supported so external open-source things can use it, that'd be swell
17:12 jekstrand: karolherbst: Yeah, I think we'll tell them to go take a hike at that point
17:12 karolherbst: jekstrand: yeah
17:12 jekstrand: Plagman: Yeah, a bunch of the DXGI stuff is documented but I don't know if they've documented this new Linux interface at all
17:12 daniels: karolherbst: everyone's going to make their own value judgements, none right or wrong. I was pleased when we were asked to improve GL+CL support on Windows, because it's better than them using the same resources to just port everything they wanted to DX12. obviously I'd prefer if libdirectx12.so was fully open, or had better governance, or whatever. but this isn't the endpoint - look at how far they've come over
17:12 daniels: recent years ...
17:12 Plagman: it's not a new interface afaik, just bindings for the existing one over to linux
17:13 Plagman: or, one that closely mirrors the normal 'drm' they have, at least their virtualized variant
17:13 daniels: I prefer to try to help bring them into the fold and make even more OSS contributions and have more involvement than they already do, which is something they've been improving at year on year, rather than just push them away
17:13 ajax: jekstrand: be careful to draw a distinction between "windows 11 implements linux as its preferred userspace personality" and "windows 11 is a linux kernel"
17:13 Plagman: the the blog implies they're really close
17:13 karolherbst: daniels: yeah.. I am not against MS taking itneresting in linux, just against pushing for propriatary APIs
17:13 karolherbst: or well
17:13 karolherbst: vendor controlled ones
17:13 karolherbst: I'd also against supporting CUDA
17:14 karolherbst: * be
17:14 jekstrand: When it comes to DX, microsoft will push DX. It's one of the few bits of vendor lock-in they still have that's still actually getting them customers.
17:14 karolherbst: yeah, I don't care about this obviously :p
17:14 karolherbst: vendor lock ins are terrible
17:14 ajax: i don't mind them being more open, i'm just not sure this concrete instance of the idea "dx12 for linux" might not count as more open, to me.
17:14 karolherbst: no intention of ever supporting it even indirectly
17:14 ajax: ... lost my way with the qualifiers there but you get the idea
17:15 karolherbst: again, I hope I am wrong here... but.. welll
17:15 ajax: *shrug* never thought i'd see exfat get as far as it has
17:16 karolherbst: ajax: yeah.. but that was also more of an accident :p
17:16 ajax: how you figure?
17:16 karolherbst: well, source code got leaked?
17:17 karolherbst: or well..
17:17 daniels: exfat wasn't unmerged because no-one knew how it worked, it was unmerged because people didn't want to get sued
17:17 karolherbst: accidentally published
17:17 karolherbst: daniels: sure, but samsung still pushed for inclusion later on
17:17 karolherbst: and they were the ones leaking it
17:17 karolherbst: so....
17:18 daniels:shrugs
17:18 karolherbst: I guess that just forced communication on the legal situation and MS went like: e:shurg
17:18 karolherbst: ...
17:18 karolherbst: eh damn auto replacement
17:19 karolherbst: ¯\_(ツ)_/¯
17:19 karolherbst: :)
17:19 daniels: the legal situation was always clear: Microsoft held patents and were prepared to enforce them against anyone. source code release doesn't change anything about that calculus
17:19 daniels: cf. S3TC
17:19 karolherbst: right, but I doubt samsung would do a proper source code release without contacting MS about it
17:20 karolherbst: and as it got leaked they had to discuss this anyway
17:20 karolherbst: wouldn't be surprised if they thought the same, but it turned out that MS didn't care
17:20 ajax: i was speaking more about msft saying they were down with it (exfat) being in the OIN's base non-aggression pact
17:21 karolherbst: yeah.. that happened later, true
17:21 ajax: legend has it at one point they were making more money off exfat licensing for android than they were for windows phone as, like, a whole.
17:21 daniels: yeah, they moved from an active position of enforcement threats, to a position of explicit non-enforcement? that doesn't happen by accident
17:22 ajax: (i have absolutely no inside information about the truth of that legend, but it sounds truthy enough for me)
17:22 karolherbst: well.. MS is not without a reason the biggest contributor to open source :p
17:22 karolherbst: but yeah
17:22 karolherbst: well.. maybe more to the kernel
17:22 karolherbst: dunno
17:23 karolherbst: I still don't think that vendor controlled APIs are a good thing
17:23 karolherbst: if MS would hand over dx to khronos, then yes, we can talk about it
17:23 karolherbst: not before
17:25 emersion: why is there /dev/dxg instead of a regular render node?
17:26 karolherbst: also... it sounds like MS assumes distributions will just enabled this dx12 support in mesa
17:26 karolherbst: bold move
17:26 karolherbst: although I guess WSL distros have special builds partly?
17:26 jekstrand: emersion: I doubt it uses DRI at all
17:26 ajax: emersion: i can't really fault anyone for not wanting to start with the drm ioctl api
17:26 jekstrand: s/DRI/DRM
17:26 emersion: hm
17:26 jekstrand: They just turned DXGI into IOCTLs
17:26 ajax: which is less a thing that's designed than metastasized at this point
17:26 karolherbst: emersion: it's a magic device talking with the hypervisor ;)
17:27 emersion: but a render node doesn't need to implement a lot of ioctls, does it?
17:27 ajax: i might have hoped for something more abstract than dx12 in ioctl form, but i guess that also depends how well designed dx12 is
17:28 karolherbst: ajax: they probably have 100 ioctls :p
17:28 emersion: there's basically just some basic GEM stuff and everything else is driver-specific?
17:28 ajax: karolherbst: glass houses, my dude
17:28 karolherbst: ajax: for rendering only?
17:28 jenatali: The code for the ioctls is open source already in case you hadn't seen it
17:28 daniels: given that they've said they've got their IHVs to port their DX12 UMDs over to Linux (I have no inside information on this point, but believe the blog as written), it being a straight analogue of the existing DX12 kernel entrypoints would indeed make sense
17:28 ajax: right
17:29 jenatali: https://github.com/microsoft/WSL2-Linux-Kernel/blob/linux-msft-wsl-4.19.y/drivers/gpu/dxgkrnl/ioctl.c#L5134
17:29 ajax: and that's the other thing: for all people complain about windows being proprietary, it is _extensively_ documented
17:29 ajax: if you want to write a workalike the spec is right there
17:29 karolherbst: ehh just 66
17:29 karolherbst: I am disappointed :p
17:30 karolherbst: ajax: I am sure wine devs can point out many places where it's not enough :p
17:30 ajax: sure
17:30 jekstrand: ajax: What's not documented is the driver-private interfaces that are required to do anything useful.
17:30 karolherbst: although that's probably limited to private APIs
17:31 ajax: i'm sure i can point out pmany places where you have to read the glibc source to know wtf is going on
17:31 karolherbst: jekstrand: it also includes C runtime private calls, because.. you know... macro magic or something
17:31 karolherbst: tons of private calls in most dlls
17:31 qyliss: ajax: but you are _allowed_ to read the glibc source
17:32 ajax: qyliss: pretty sure i'm allowed to read the msdn docs too
17:32 daniels: ajax: thank god the graphics stack doesn't suffer from a paucity of documentation
17:32 karolherbst: ajax: what do you do if you need to know what private calls do?
17:32 karolherbst: those are not documented
17:33 ajax: karolherbst: return something wrong and see how it breaks. then return something less wrong. then iterate until you can't tell the difference.
17:33 karolherbst: ajax: it breaks, wine devs need to deal with those most of the time :p
17:33 jekstrand: daniels: Yeah, it would really suck if I had to read i915 kernel code to figure out what an ioctl does.
17:33 karolherbst: private calls are common
17:33 karolherbst: sadly
17:34 karolherbst: which is also driven by the fact that wine doesn't replace all dlls
17:34 ajax: karolherbst: that sort of suggests they're implementing the wrong set of components at once...
17:34 ajax: right
17:34 karolherbst: so inter dll calls are also happening
17:34 karolherbst: and then you have compiler magic doing weird shit
17:34 karolherbst: I am convinced they know what they are doing
17:34 karolherbst: and they have to deal with this crap
17:35 karolherbst: also.. sometimes you mod games by replacing dlls with "modded" ones
17:35 karolherbst: so you also need to have this usecase working
17:35 karolherbst: or mod dx dlls shiped with the games
17:36 karolherbst: or random other crazy shit
17:36 ajax: "need" might be pushing it
17:36 karolherbst: well it's out there
17:36 karolherbst: users use it
17:36 ajax: certainly depends on which set of consumers you're trying to satisfy
17:37 karolherbst: well, people running window software on linux :p
17:37 karolherbst: anyway, they need to deal with this
17:37 karolherbst: and just saying "the user is doing dumb stuff" doesn't cut it
17:37 karolherbst: those are all valid use cases working on windows flawlessly
17:38 karolherbst: and even with wine as long as most of those APIs are implemented correctly
17:38 daniels: if the apps were open then you could just port them native
17:38 karolherbst: sometimes they even have to fix memory placement issues
17:38 karolherbst: and other random weird shit
17:38 karolherbst: especially if mods depend on reverse engineered behaviour of windows
17:39 karolherbst: daniels: true
17:39 karolherbst: point is, the documentation is not enough to reimplement windows
17:40 karolherbst: and what you need to reimplement is what application rely on
17:40 karolherbst: which is actually also driving what linux uAPI needs to look like ;)
17:40 karolherbst: if you introduce a bug and applications are using it, tough it's now part of the uAPI
17:40 karolherbst: even if never documented
17:42 DrNick: the applications rely an a Windows kernel for their anticheat and DRM
17:43 karolherbst: ufffff
17:43 karolherbst: DrNick: I already forgot about those crappy applications
17:43 karolherbst: please never bring this up again :D
17:43 ajax: see this is the thing
17:43 DrNick: Vanguard and Denuvuo and Easy Anti-Cheat
17:43 ajax: by the time you're doing that level of app-specific compatibility, make it a damn app-specific cutout
17:43 karolherbst: yeah.....
17:43 karolherbst: ajax: you can't, not for wine
17:44 ajax: start with how it's documented to work and acknowledge that the crazy shit is crazy
17:44 karolherbst: would be a maintainence nightmare
17:44 ajax: you won't get to 80% functional much of any other way
17:44 karolherbst: I am sure wine is closer :p
17:44 ajax: you're starting from the position that the interop surface is unknowable
17:45 alyssa: glFinish();
17:45 karolherbst: anyway, it's pointless to discuss the startegy of wine here.. it seems to work, and it seems to be something they decided is correct
17:45 karolherbst: if you have a better idea, please go ahead and create a new project for this :p
17:45 karolherbst: I just say what random shit they have to deal with
17:46 karolherbst: and with dx it won't be different
17:46 ajax: more interested in working on darling tbh
17:46 alyssa: ajax: it's a good project name :0
17:47 ajax: i've made some questionable life choices that have resulted in me having very few windows workloads to care about, but a non-zero number of macs
17:47 ajax: sure would be nice to not have those get orphaned, again, again, again.
17:47 karolherbst: darling never could much traction sadlt
17:47 karolherbst: *sadly
17:48 ajax: glass half full way of saying that is it still works as well as it ever did
17:48 daniels: Plagman: there you go, dri-devel submission explicitly says it's a direct translation of D3DKMT
17:49 Plagman: i want actual d3dkmt
17:49 Plagman: not some linux thing
17:50 Plagman: :P
17:50 jenatali: Plagman: That's what libdxcore is for
17:50 Plagman: ?
17:50 jenatali: It hosts the D3DKMTs as wrappers over the ioctls
17:50 Plagman: i was saying i wanted docs for the windows driver model really, not anything wsl related
17:51 Plagman: supporting mesa in wsl is cool but that's not quite where i want to be
17:51 jenatali: Oh, yeah, that... could be better. Some of them do exist though
17:51 Plagman: i'm not sure that you can implement a graphics driver for windows if you don't have nda docs at this point?
17:51 Plagman: i'd be happy to be proven wrong but i just don't know that it's the case
17:51 linkmauve: How does vmware do it?
17:51 jenatali: You're probably right - you can get pretty far with what's public, and anything that's missing isn't intentional (as far as I know), just gaps in documentation that need to be filled
17:52 ajax: i... ought to know this. we've got windows drivers for qxl
17:53 Plagman: there's probably some amount of spread between a basic functional driver and a full-featured vulkan driver with competitive gaming perf, as well
17:53 ajax: and i don't think we _needed_ anything nda for that? but i also haven't asked.
17:53 Plagman: not that i've heavily researched the topic
17:54 Plagman: but getting intel/amd opengl and vulkan through mesa on windows is something i dream about at night yes
17:54 Plagman: this cool new wsl thing would certainly be a start though, would be super cool to run mesa in that as well
17:55 DrNick: does https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/nf-d3dkmthk-d3dkmtcreateallocation not document what you want?
17:55 karolherbst: yeah. running mesa on windows would be kind of cool
17:55 jenatali: Our thinking at this point is to support Mesa on Windows/WSL via the D3D12 driver backend we've been working on, as opposed to trying to target the D3DKMT layer directly, for what it's worth
17:56 kisak: I'm kinda disappointed this more or less looks like a WSL distro lock in strategy, instead of going for a foss vulkan solution at the core.
18:15 DrNick: so has anybody run Mesa-on-Direct3D-on-vkd3d yet?
18:16 alyssa: "Zink"? ;P
18:17 jenatali: Needs more layers
18:17 alyssa: DrNick: Mesa / DX12 / VKD3D / MoltenVK though
18:17 alyssa: run the whole thing on macOS
18:17 DrNick: I'm pretty sure MacOS doesn't support running programs any more
18:18 alyssa: Hmm, throw the whole thing in emscripten and run it in a browser then
18:31 EdB: pmoreau: CTS reminds me how I prefer Piglit :)
18:31 pmoreau: :-D
18:32 pmoreau: The CTS is being improved on, though. At least now it builds properly on Linux and soon the flood of warnings should be trimmed down considerably.
18:33 EdB: but it take ages to run some test
18:34 EdB: https://framabin.org/p/?42cbbede24c38164#LaFxm1qwer85D1kK75i7dCa1nS1IR/j9XN39NwXIq80= for a result of my run
18:34 EdB: I made some fixes on my branch to make some of them pass
18:35 karolherbst: EdB: https://gist.github.com/karolherbst/27448325fe88b66b38e990f90bc3c355
18:36 karolherbst: in case you want to make use of more threads :p
18:37 karolherbst: and more fine grained reporting
18:37 EdB: karolherbst: nice
18:37 karolherbst: error code handling is a bit broken though...
18:37 karolherbst: in the CTS
18:39 EdB: I was thinking of using Piglit to extrat a list of test from the opencl_conformance_tests_12_full.csv file and then a list of sub test for the -list option of each of then
18:39 karolherbst: yeah....
18:39 karolherbst: but that doesn't always work
18:39 EdB: and to exploit their result from the json file
18:39 karolherbst: see the explicit handling for conversion eg
18:40 karolherbst: math_brute_force also uses -p instead...
18:40 karolherbst: or maybe -list is a special thing... dunno
18:40 karolherbst: happy to have something in piglit though
18:41 EdB: not done yet :)
18:41 EdB: but piglit can timeout and give really nice sumary
18:43 EdB: karolherbst: indeed -list from test_conversions is an unknow option
18:45 EdB: from test_api it give a nice liste of for exemple: get_platform_info get_sampler_info get_command_queue_info_compatibility etc
18:47 EdB: it is -p with test_bruteforce
18:47 EdB: :/
18:49 karolherbst: ;)
18:49 karolherbst: anyway, feel free to copy ideas from my script
18:49 EdB: :)
18:50 EdB: test_computeinfo have a bug
18:50 EdB: may be I could motivate my self to create an account on github and send a fix + an alias to -list in test that miss then
18:51 EdB: If someone volontaire before, I'll be glad :)
18:51 karolherbst: ohh that would be cool
18:52 karolherbst: also for conversions
18:52 karolherbst: I generate a lot of invalid combinations
18:52 pmoreau: What’s the bug you have, EdB? I have an open MR for fixing a few things in it: https://github.com/KhronosGroup/OpenCL-CTS/pull/768
18:52 gitbot: KhronosGroup issue (Pull request) 768 in OpenCL-CTS "Update computeinfo tests" [Open]
18:52 karolherbst: but the test doesn't care so it noops passes
18:52 EdB: I really dislike their coding style
18:53 EdB: pmoreau: there are sending CL_MEM_KERNEL_READ_AND_WRITE flag even if env is 1.2
18:53 pmoreau: Should be fixed in my MR, unless I messed it up
18:54 karolherbst: do we have a macro to get the next POT value from a given number?
18:54 EdB: pmoreau: yes, I saw that
18:55 pmoreau: Hopefully it will be merged soon.
18:55 EdB: so, while you are at it, don't you want to add -list in all other test ;)
18:56 pmoreau: :-D
18:56 pmoreau: Going to wait for my MRs to be merged though.
18:56 EdB: Or I could give a patch to you once you've got their trust :p
18:57 pmoreau: Hahahaha :D
18:57 pmoreau: I like the idea of not having to write a patch myself. ;-)
18:58 airlied: ajax: we don't have d3d windows drivers for qxl
18:58 airlied: we also don't have a d3d driver for virtio-gpu/virgl yet, and it's not moving along very fast
18:59 EdB: I so dislike there style that I update some Piglit test to see how clover were failing their test :p
18:59 airlied: Plagman: have we ever asked the vendors for their private APIs?
18:59 pmoreau: :-)
18:59 airlied: jekstrand: like can you port anv to windows internally? :-)
19:01 EdB: pmoreau: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/271/commits for some of them
19:01 jekstrand: airlied: Anything is possible. :-P
19:02 EdB: I did other ugly change not to be seen :)
19:04 airlied: jekstrand: probable though? :-P
19:04 daniels: airlied: porting CS invocations to /dev/dxg would be an easier start and a good leg-up I'd imagine
19:05 airlied: I'm just wondering how big the private vendor bits of D3DKMT look like, I assume there are private vendor bits
19:05 jekstrand: airlied: Oh, yeah, there are private vendor bits
19:05 jekstrand: airlied: And they're substantial and, generally, not a stable API either.
19:05 Plagman: airlied: some high-level conversations, but never goes very far
19:06 EdB: also Piglit never trigger an dmesg, it is more polite. Sure it didn't test as much, but still :D
19:06 jekstrand: airlied: The windows driver distribution model is designed for kernel <-> userspace version lock.
19:06 jekstrand: :-(
19:06 karolherbst: also.. adding ioctls without open source userspace?
19:06 karolherbst: the hell?
19:07 karolherbst: do we really want to do that?
19:07 jekstrand: karolherbst: They don't have to upstream their module.
19:07 karolherbst: jekstrand: they seem to plan to though
19:07 karolherbst: at least they said so
19:07 jekstrand: karolherbst: Well, that's for airlied to try and stop. :D
19:07 karolherbst: :D
19:07 jekstrand: karolherbst: DRM is really the only subsystem that has the open-source userspace requirement
19:07 karolherbst: airlied: you have my +1 on stopping adding this without open source dx12 :p
19:07 jekstrand: Or at least that has a strict one
19:09 ajax: other subsystems have stronger external constraints that make that particular requirement less meaningful, i thnk
19:09 airlied: they don't have userspaces :-
19:09 airlied: :-P
19:09 karolherbst: right
19:10 airlied: the only other subsystem with a messy userspace was rdma, and they've learned mostly the same lessons :-P
19:10 ajax: like, storage is a family of tunnelings of the scsi command set, at this point
19:10 ajax: *hci are externally specified
19:10 ajax: there is no generic gpu interface at anything like that low of a level
19:16 karolherbst: well.. I am happy to accept their driver if they show me their public and open source users of this :p
19:18 jenatali: The immediate consumers of the ioctls would be DXCore, which just implements the D3DKMT entrypoints as already-documented
19:19 jenatali: I suspect we'd actually be totally fine open sourcing that implementation, it's just wrappers around the ioctls with nothing special
19:19 jenatali: The next level up, something that actually uses them would be interesting
19:19 karolherbst: ehh
19:20 karolherbst: wrappers don't count
19:20 karolherbst: same rules as for drm
19:20 karolherbst: so up to GL or VK
19:20 karolherbst: or dx12
19:20 alyssa: Likewise, mesa with a proprietary compiler doesn't count, in case any vendors were considering that.
19:20 karolherbst: :) exactly
19:20 alyssa: (not that it applies here)
19:21 jenatali: Makes sense
19:21 karolherbst: and it has to be thing people actually use, etc...
19:21 karolherbst: not a toy
19:21 karolherbst: or demonstration code
19:21 karolherbst: but the real deal
19:21 jenatali: Sure
19:21 karolherbst: I doubt MS will agree to that though
19:21 karolherbst: or
19:21 karolherbst: they will and I will be surprised
19:22 airlied: jenatali: how do the vendor specifics pass through? is there an ioctl they all hide inside?
19:22 jenatali: Eh, I dunno, I wouldn't say it's out of the question
19:22 jekstrand: It's not just MS. You have to get some hardware vendor to open-source a driver on top of it.
19:22 jekstrand: If you want the "full stack experience"
19:22 jenatali: airlied: There's some void*/size fields in the structs that get sent into the ioctls
19:22 karolherbst: the more the merrier :p
19:22 airlied: jekstranad: or port one of their already open sourced drivers to d3dkmt :-P
19:22 jekstrand: airlied: Yeah.....
19:22 jenatali: jekstrand: Which means you'd also need a corresponding Windows kernel driver on the other side of the paravirtualization pipe
19:23 karolherbst: seriously, if this leads up to at least one vendor fully opensource their driver, then I'd see this as a win
19:29 agd5f_: karolherbst, well, most of our AMD vulkan driver is already open sourced. It would just be the winsys equivalent in PAL for windows that is missing
19:30 karolherbst: ehh.. true
19:30 agd5f_: PAL is used for dx12 as well
19:30 jenatali: And that winsys portion won't make any sense for Linux either
19:32 karolherbst: the question is rather, what's sing the dx*.so files
19:32 karolherbst: I thought there is some dx runtime stuff in between?
19:32 karolherbst: we would need this as well
19:32 karolherbst: :p
19:33 karolherbst: agd5f_: do the vulkan bits on windows even use d3dkmt?
19:33 karolherbst: or is that done through special interfaces
19:33 jenatali: karolherbst: I'm pretty sure has to use the d3dkmt entrypoints
19:35 agd5f_: karolherbst, not sure off hand. Not that familiar with windows
19:38 ajax: pretty sure there's a way to ask 'nm -u' of the dlls to figure out what libraries they import
19:39 ajax: though i'm also pretty sure nm(1) is not the tool for this
19:39 jenatali: agd5f_: Looks like the entire Windows kernel driver and the Windows platform layer is still closed. I don't see anything Windows-y in the PAL repo. Unless I'm looking in the wrong place...
19:39 jenatali: ajax: If you're talking Windows (DLLs?), MSVC's "link.exe /dump /imports" gives you what you want. Unless you meant .so
19:40 emersion: danvet: fwiw i completely agree with your DirectX reply, thanks for writing this
19:41 agd5f_: jenatali, yeah, PAL is just the UMD portion
19:42 ajax: jenatali: i meant a PE/COFF object and a Windows personality under, yeah
19:42 jenatali: Yeah, a search for D3DKMT in PAL doesn't show any code hits, but a mention in a comment which confirms that it is used at least
19:44 danvet: emersion, it's more or less a "pls read docs and btw maybe chat with people first" reply
19:44 danvet: it's kinda the basics
19:47 karolherbst: danvet: did you see greg replies?
19:47 karolherbst:annoyed by the fact that this discussion already got split up
19:49 karolherbst: danvet: anyway, +1 for your reply
19:53 danvet: karolherbst, well greg doesn't do design/architecture code review for drivers
19:54 danvet: I'm typing another mail where essentially I flat out tell him that maybe doing that decision with favoritism doesn't work out too well
19:54 danvet: https://paste.debian.net/1147711/ if you want a spoiler
19:54 karolherbst: danvet: I meant gregs reply to that directx driver though
19:54 danvet: yeah I know
19:54 karolherbst: ahh
19:55 danvet: this reply is for another bikeshed airlied and me are having with gregkh
19:55 karolherbst: ahh
19:55 karolherbst: I see
19:55 danvet: about the entire "should you look at userspace for your driver" thing
19:55 danvet: thus far gregkh said "nope, happy to merge blobby stuff as long as I have ioctl testcases"
19:56 karolherbst: :/
19:56 karolherbst: yeah....
19:56 karolherbst: it feels that way
19:59 karolherbst: btw.. do we have some "this is a 32 bit build" definition somewhere in mesa?
19:59 karolherbst: I actually need it now ...
20:02 ajax: definition in what sense, C preprocessor macro or..?
20:03 danvet: sizeof(long) == 64 :-)
20:03 danvet: not sure that works in cpp
20:03 ajax: #if __SIZEOF_LONG__ == 8
20:03 ajax: if gcc, anyway. no idea about msvc.
20:04 jenatali: MSVC's sizeof(long) == 4
20:05 karolherbst: danvet: I'd probably use size_t though
20:05 karolherbst: but yeah...
20:05 karolherbst: I just though we have something convenient
20:14 airlied: jenatali: yeah amd ifdef out the d3dkmt in their source release process
20:14 airlied: pal is not an open source development model
20:15 jenatali: Makes sense. Too bad, that means we apparently actually have some work to do if we want to satisfy you all :)
20:19 karolherbst: jenatali: at least you accept this :D I know others you wouldn't
20:19 karolherbst: *who
20:21 karolherbst: do we have something like ROUND_POT?
20:21 jenatali: Yeah, we're much more open these days, though of course there is a limit to how far we're willing to go. I suspect we'll need to reach a compromise where we open some stuff and you agree some stuff can stay closed, or else live with our paravirtualization driver never going upstream
20:21 karolherbst: jenatali: honestly.. I prefer the second option
20:21 jenatali: Not entirely my call though :) I'm just an interested developer at this point
20:21 karolherbst: it's not like anybody will ship it except you
20:22 karolherbst: and having something upstream just so that a vendor doesn't need to rebase is something I am personally against
20:22 jenatali: Eh, could be useful for just general Linux VMs to get hardware acceleration without having to dedicate a full PCI device
20:22 karolherbst: on windows?
20:22 karolherbst: honestly...
20:23 karolherbst: also
20:23 karolherbst: vgpus are a thing already
20:23 karolherbst: nvidia supports this on linux already
20:23 karolherbst: and I think intel and AMD do so as well
20:24 alyssa: karolherbst: ALIGN_POT you mean?
20:24 jenatali: Right, via partitioning I think, which only works on some workstation-class GPUs
20:24 karolherbst: jenatali: yeah
20:24 karolherbst: valid point though if you could do that with all GPUs
20:24 karolherbst: but.. yeah
20:24 Kayden: ALIGN() is power-of-two, ALIGN_NPOT works for others
20:24 karolherbst: we could also juse do that on top of vk or so
20:24 Kayden: there's also ROUND_DOWN_TO
20:24 karolherbst: Kayden: I need a pot value :) but yeah
20:24 alyssa: karolherbst: or util_next_power_of_two maybe you mean?
20:25 karolherbst: ahh, probably
20:25 alyssa: Either way it's there.
20:25 jenatali: karolherbst: Paravirtualization supports consumer GPUs and treats guest processes equal to host processes, which could be a useful thing to put in generic Linux VMs (on Windows) for consumer scenarios
20:25 jenatali: But fair point it's still pretty niche
20:25 karolherbst: jenatali: then you need to explain why we want to do that on top of dx12 and not vulkan
20:25 karolherbst: :p
20:25 karolherbst: vulkan would be cool
20:26 karolherbst: runs everywhere
20:26 karolherbst: no vendor lock in
20:26 karolherbst: awesome
20:26 jenatali: If someone wanted to open their Windows Vulkan driver to use the D3DKMT entrypoints in WSL then cool
20:26 jenatali: We don't have any of those to open up ourselves
20:26 karolherbst: why d3dkmt?
20:26 karolherbst: why using some vendor controlled API at all
20:26 jenatali: That's how the paravirtualization protocol works
20:26 karolherbst: we can just have our own nice linux api
20:27 karolherbst: why should we give up control over this API, if we can just create our own
20:27 jenatali: Sure, you could build paravirtualization from scratch, though it'd be tricky to get that to work with arbitrary OS layering - but yeah Linux VM on Linux you could build that
20:27 karolherbst: well the hypervisor just needs to target vulkan and that would work on windows as well
20:27 karolherbst: no?
20:28 karolherbst: I am just wondering what is a _very_ good reason we should agree to this vendor lock in
20:28 jenatali: I think we're getting a bit out of my depth :)
20:32 karolherbst: what I tried to say is: it would be cool if somebody would develop paravirtualization on top of mesa :p ... :p
20:32 karolherbst: but I guess we already have that
20:32 alyssa: virgl..?
20:32 karolherbst: yeah
20:32 jenatali: That's API remoting, very different from paravirtualization
20:32 alyssa: I just write compilers \shrug/
20:32 karolherbst: does it make a difference for the user?
20:33 jenatali: Yeah. API remoting can be expensive and has to be rewritten per-API. Paravirtualization just remotes pre-transformed hardware commands and shaders
20:33 karolherbst: jenatali: "for the user"
20:33 danvet: jekstrand btw read a bit backlog, there's subsystems that are even stricter than drm
20:33 karolherbst: I honestly don't care how it works as long as it works
20:33 jenatali: Performance and compatibility are the differences
20:33 danvet: rdma says "open source and in _our_ repo or go away"
20:33 danvet: they learned this the hard way
20:33 karolherbst: yeah.. but potential performance problems can always be used to argument for everything :p
20:34 danvet: I think media folks reached the same conclusion
20:34 karolherbst: that's not valid
20:34 jenatali: It's not potential for what it's worth - RemoteFX was our API remoting protocol for years, and it's now dead in favor of paravirtualization, largely due to performance
20:34 karolherbst: and with this dx12 we have 0 compatibility already
20:34 danvet: and past that there's really not a hole lot left that creates massive amounts of uapi that hasn't been standardized (at least core concepts) since decades
20:34 karolherbst: so...
20:34 karolherbst: jenatali: yeah.. I mean, what we have could potentially be improved, not going to argue that
20:35 karolherbst: but we already have something
20:35 karolherbst: and this dx12 stuff needs a super super good reason if it really wants to be accepted and stay
20:35 jenatali: Understood
20:35 jenatali: Personally I think we've got a good reason, but obviously I've failed to convince you so far ;)
20:37 danvet: karolherbst, we've actually been talking in a bunch of places about extending drm to add userspace managed residency and monitired fences and stuff
20:37 danvet: so kinda dx12
20:37 danvet: except the tricky part is integrating this all into the existing platform/winsys stuff
20:37 danvet: and getting at least more than 0 drivers ported to it to proof it
20:37 karolherbst: jenatali: I think you missed the point. What's the reason for pushing this dx12 stuff instead of improving what we have and have it all open source and usable on more system than just windows ones
20:38 danvet: idea was also to ditch ioctl outright and go with drm_uring
20:38 danvet: at that point paravirt becomes generic and real fast
20:38 karolherbst: I really don't care about the performance here
20:38 danvet: (if you trust your hw, which post smeltdown is kinda a questionable assumption)
20:38 karolherbst: danvet: cool
20:38 danvet: it's just ... no one got around to typing yet
20:38 danvet: jenatali, I guess if you're massively bored :-)
20:39 karolherbst: :D
20:39 jenatali: karlherbst: I'm not arguing about DX12 just to be clear, I'm only suggesting that having an interface in Linux which can talk to the Windows paravirtualization protocol would be useful
20:39 daniels: karolherbst: sure, VirGL would work if you don't care about performance, but people running intensive GPU workloads probably do ... ?
20:40 jenatali: I think it'd be even better if we could get a single paravirtualization protocol that could be written by DRM without the need for our new kernel driver, and which was supported by both Windows and Linux hosts
20:40 karolherbst: jenatali: yeah... I guess that's a valid point indeed. But then we still have the uapi to figure out
20:40 karolherbst: yeah
20:40 karolherbst: that would be cool indeed
20:40 jenatali: Sure, projecting the D3DKMTs was the quickest way for us to get something that works in the specific layering we have with WSL
20:41 karolherbst: daniels: they are free to come up with a open source stack showing the benefits
20:41 karolherbst: jenatali: yeah.. I mean for MS it totally makes sense
20:41 karolherbst: and have it out of tree is totally fine
20:41 karolherbst: just getting it upstream is a totally different thing
20:42 jenatali: Yep, I hear you, thanks for the discussion :)
20:42 karolherbst: and if users only have to install a ko file in order to make use of it? fine by me
20:42 karolherbst: :(
20:42 karolherbst: ...
20:42 karolherbst: :) I meant
20:43 karolherbst: german keyboard with us layout is annoying.. seriously :D
20:44 imirkin: karolherbst: swiss german physical keyboard layout with us mapping is the worst
20:44 imirkin: all the things in the shift register of the numbers are shifted by 1 to the right (or left)
20:45 imirkin: i.e. the things you don't actually touch type and have to look down for
20:45 karolherbst: imirkin: yeah
20:45 karolherbst: that's what I have as well
20:45 imirkin: but it's close enough to right that it takes a while to catch on
20:51 danvet:typing in swiss german layout for everything
20:51 danvet: I barely learned touch typing, I'm not going to learn another layout before I retire :-)
20:52 imirkin: i worked out of switzerland for a couple weeks many years ago, and i was given a regular comp that i set up in the regular way, with the us layout obviously, and ... yeah. good times.
20:52 danvet: haha
20:52 imirkin: it took me a good half hour to figure out why i kept typoing stuff
21:09 airlied: jenatali: btw ho stable is d3dkmt interface?
21:09 jenatali: airlied: Very
21:10 jenatali: GL/VK drivers on Windows target it directly, if we broke it, we'd break old drivers, which is something we try very very hard not to do
21:12 danvet: jenatali, are you cc'ed on that dxgkrnl patch submission on dri-devel?
21:12 danvet: someone who knows gpu drivers would be good there I think, sasha levin seems out of his depth
21:13 jenatali: danvet: I got a forward of it internally but I'm not on the main thread. There are some GPU folks on it
21:18 karolherbst: jenatali: what about different windows versions?
21:18 karolherbst: or is it the same on all of those?
21:18 danvet: I think the big question is different kmd versions from the vendor
21:19 jenatali: The D3DKMTs have been more or less stable since Windows Vista
21:19 jenatali: You can still run a WDDM1.0 (i.e. Vista) GL driver on Win10 and it should work
21:19 karolherbst: okay, cool
21:21 jekstrand: The real concern with stability is all of the IHV-private APIs
21:21 jekstrand: Most Windows drivers are built assuming UMD/KMD version-lock so no need for documented APIs or stability.
21:22 karolherbst: jekstrand: but I assume we won't have vendor bits in linux otherwise the hw vendors would need to port their stuff as well, no?
21:22 jenatali: Right, the model for paravirtualization that we've gone with so far is that the UMD in the guest/VM comes from the host so that it matches - the OS version doesn't have to match as closely though
21:23 jenatali: karolherbst: For DX12 specifically, vendors are porting their stuff, yes
21:23 karolherbst: ohh, interesting
21:23 jekstrand: karolherbst: If we wanted to get ANV or iris running in that environment, we'd need to do significant porting work.
21:23 jekstrand: And, yes, I've gone through the mental exercise.
21:23 jenatali: That's the big difference between paravirtualization and API remoting. With API remoting, the VM is all vendor-neutral and the host is all vendor-specific. With paravirtualization, the usermode bits run in the guest while the kernel bits run in the host
21:23 karolherbst: I kind of assumed the hw bits were all on the host, but it seems like there will be guests bits as well
21:24 karolherbst: mhhh... yeah okay
21:24 karolherbst: that indeed puts some constraints
21:25 karolherbst: jenatali: will it also require vendor ko files?
21:25 jenatali: karolherbst: No, just .so
21:25 jekstrand: karolherbst: I think it just uses the Windows kernel driver for all vendor stuff
21:25 karolherbst: yeah, that's what I assumed, just making sure
21:26 jenatali: Yeah, the diagrams in our blog post this morning should hopefully be pretty clear about what's all where
21:26 danvet: karolherbst, paravirt without guest side hw specific driver kinda crawls
21:26 airlied: it's windows kernel + linux kernel transport shim + userspace linux d3d12
21:27 danvet: if you do the the pipe between guest and host well it's pretty much raw perf
21:27 airlied: the driver is just a connect the binary blobs together pipe
21:27 danvet: but at the cost of trusting the hw's ppgtt and robustness (haha)
21:27 jenatali: Yep
21:27 danvet: even faster than ioctl and hypercall would just be a ringbuffer like iouring
21:27 danvet: hence the drm_uring thing some people gossiped about
21:28 danvet: one hypervisor core running the kmd in a thread there stuffing the hw
21:28 danvet: other thread running the guest building the command stream
21:28 danvet: 0 hypervisor calls or anything else like that
21:28 danvet: but we haven't built that one yet :-/
21:28 jenatali: danvet: There's hardware scheduling stuff in the works for WDDM as well, which would allow usermode scheduling directly
21:28 jenatali: Not sure how that interacts with the paravirtualization stuff though
21:29 danvet: jenatali, the idea is to stuff all the os stuff over that ring too
21:29 danvet: for managed residency or cross driver sync or anything else really
21:29 jenatali: Oh, I see, rather than individual syscalls, just use a shared memory buffer and a thread which monitors it, interesting
21:29 danvet: also I'm personally not a huge fan of direct submit to hw because you drop the vendor-agnostic scheduler on the floor
21:30 danvet: which means for cloud and stuff you're still stuck in some vendor lock in
21:30 danvet: we kinda don't like vendor lock in here :-)
21:30 danvet: jenatali, iouring, but for gpus essentially
21:30 danvet: including all the pre-binding concepts so that the interface itself wouldn't have to do any copying of userspace cpu addresses
21:31 jenatali: Not familiar with iouring unfortunately
21:31 danvet: trying to find the docs for you
21:31 danvet: it's super neat for async file io
21:32 jekstrand: jenatali: Roughly, iouring is a circular ring buffer that lives in memory shared between userspace and kernel with rules about who moves what pointer and how. Zero traps between the kernel and userspace most of the time.
21:32 danvet: jenatali, https://kernel-recipes.org/en/2019/talks/faster-io-through-io_uring/
21:32 jekstrand: The only time you have to trap is if you have to wake up the kernel to flush or need to stall from userspace
21:32 jenatali: Huh, cool, thanks!
21:32 jekstrand: It's pretty neat
21:32 danvet: https://lwn.net/Articles/776703/
21:33 danvet: jenatali, it's under very active development, so these articles are best only for intro
21:33 danvet: there's lots of work going on to reduce roundtrips for everything
21:33 jenatali: Makes sense
21:33 danvet: e.g. like pre-bind the fd you will get so you can queue up all the read/writes after an open or creat() right away
21:33 jekstrand:wants drm_uring
21:33 danvet: I think for gpu it's perfect
21:33 ickle: ugpu
21:34 danvet: since the error handling is essentially "throw it all away and give up"
21:34 jekstrand: danvet: If we just put the entire KMD in the X server, we wouldn't have to trap to the kernel as much. :-P
21:34 danvet: ickle, I kinda think we should be even more aggressive than your ugpu
21:34 ickle: the krh concept was
21:34 danvet: oh right forgot to cc krh
21:34 ickle: and by the time you get to iova semaphores, you are there
21:35 ickle: iova futexes
21:35 danvet: yup
21:35 jekstrand:wants drm_futex too
21:35 danvet: the horror is blending it in with dma-buf/fence/... so we don't have to reinvent all the userspace
21:36 danvet: krh, https://lore.kernel.org/dri-devel/CAKMK7uGnSDHdZha-=dZN5ns0sJ2CEnK2693uix4tzqyZb9MXCQ@mail.gmail.com/T/#mabd0ce8b1f07a92a6d45c86a458bc9f666602230 forgot to cc you
21:37 robclark: irccc :-P
21:37 Lyude: danvet: poking you since you're in the Suggested-by: for this, any idea why cea35f5ad5ff ("drm/i915: Don't select BROKEN") was reverted later in 198db0fc276c ("Revert "drm/i915: Don't select BROKEN"") ? I'm wondering if this might be related to the defconfig issues with ppc64le I'm seeing on drm-tip (looks like they may have been there for a while though) https://paste.centos.org/view/f511311b
21:38 alyssa: robclark: Internet Relay Chaos Computing Chat?
21:38 ickle: because we're being silly
21:38 robclark: heheh
21:38 krh: danvet: yeah I saw from Twitter
21:38 krh: I've been pushing render node forwarding, but I'm pretty burned out on that now
21:38 danvet: Lyude, I successfully managed to eradicate all memories of this
21:39 ickle: we want to hide stuff behind broken, but run CI on it; kconfig really doesn't agree with that
21:39 danvet: but iirc it was some fight about stuff blowing up in autobuilders
21:39 Lyude: i wonder if `depends on BROKEN` might be what we want here
21:40 ickle: hah
21:40 danvet: it's impossible to enable BROKEN without hacking stuff up
21:40 danvet: to make sure autobuilders dont accidentally enable code that doesn't compile
21:40 danvet: like ickle said what we want isn't approved, so hacks :-/
21:41 Lyude: danvet: what's really confusing me here though is why is DRM_I915_DEBUG getting selected here at all when DRM_I915 isn't even enabled in the defconfig
21:41 danvet: krh, render node forward?
21:42 krh: What Ms is doing now, but with render nodes
21:42 ickle: still depends on X86 && PCI
21:42 danvet: krh, oh for paravirt?
21:42 ickle:wondered if we managed to get ahead of ourselves
21:43 sashal: danvet: I'm with you re: me not being a gpu person. The Microsoft folks around this driver are on the Cc list and can respond as well, but they're not Linux people to begin with either
21:43 krh: Yes
21:43 danvet: sashal, I don't think the linux kernel stuff is the hard part
21:43 danvet: even the linux gpu stuff shouldn't be that tricky
21:44 danvet: the big questions are all about windows and linux gpu stack on collider course and what to do with that
21:44 danvet: so that everyone gets out of this happier
21:44 danvet: since see above, there's lots of ideas that we kinda do want to make happen
21:46 Lyude: hm, looks like the config issue doesn't happen on master so I guess I've got somewhere to start investigating
21:48 CounterPillow: Thank you for your service, danvet. Braver than any troop o7
21:48 danvet: sashal, the entire thing is pretty much 1:1 port of wddm2 to linux, with kinda minimal amounts of s/.DLL/.so/
21:49 danvet: hence why I think we need someone who gets wddm and how that all works
21:50 sashal: danvet: I thought that dxgkrnl being just a pipe for making wddm api exposed on windows wouldn't cause concerns on the gpu side of things
21:50 sashal: *exposed on linux
21:51 Kayden: danvet: I've always thought krh's "forward the render node and DRM API" seemed like a better virtualization plan than "rewrite one API on top of another API", where you get into "but the feature sets are different" disasters, etc
21:51 danvet: Kayden, ofc, I just think we can go even more all-in on this
21:51 Kayden: danvet: the DRM API is so much smaller than e.g. all of Vulkan :)
21:51 anholt_: yeah, render node forwarding seems so obvious to me.
21:51 danvet: essentially instead of ioctl forwarding just have a shared ringbuffer
21:51 Kayden: yep
21:51 danvet: get the guest kernel entirely out of the picture
21:51 Kayden: very excited about drm_uring
21:51 sashal: danvet: If there are any questions I didn't answer well on the mailing list feel free to point it out and I'll get the windows folks involved in this.
21:52 sashal: Or if you have other questions I can start a smaller thread with them
21:52 danvet: sashal, I think I knew all these already
21:52 danvet: your answers I mean
21:52 danvet: e.g. the dx12 mesa driver
21:52 danvet: there's a lot more between that and the /dev/dxg interface
21:53 danvet: sashal, also about "it's just dx12", one problem is it smells a lot like classic embrace, extend, extinguish
21:53 danvet: the other is, how do you glue this all into the existing gpu ecosystem we have on linux
21:54 sashal: danvet: that's fair, but this is very wsl2 specific, so the scope is very limited
21:54 danvet: there's massive list of things that have conceptual equivalents, but implementation is entirely incompatible
21:54 danvet: sashal, oh every hw platform vendor comes with that story
21:55 krh: Kayden: yeah drm uring with iova futex basically needs no work to work in a virt case
21:55 danvet: replace wsl2 with intel, amd, nvidia as you see fit
21:55 danvet: or well really any combo of os/platform/gpu hw
21:55 danvet: we haven't (thus far) let any of them invent their own "it's only for us" stuff and land it in upstream
21:57 danvet: if upstream becomes a fragmented mess in the gpu space it's essentially useless
21:57 danvet: sure you have a driver, but when the next big thing in gpu apis comes (and it will) you're dead
21:58 karolherbst: also if we make an exception for one vendor, another comes and also wants to get one
21:58 Lyude: oh-yep, bisected the ppc64le defconfig issues to "drm/i915: Don't select BROKEN"
21:58 jenatali: If WDDM and DRM were really close enough, I could see it being reasonable to try to switch over to exposing the DRM usermode APIs instead of projecting a WDDM custom API
21:59 karolherbst: jenatali: not the point
21:59 karolherbst: what if GPU hw vendor comes up with a completly new API
21:59 karolherbst: says: this requires a new uAPI as well, here is our stack
21:59 karolherbst: how is that different?
21:59 sashal: danvet: I think that we see it differently: the way I see it it's just a pipe, not a gpu on it's own
22:00 danvet: jenatali, atm we're not even remotely close :-(
22:00 sashal: We could have just created an opaque messaging protocol via shared memory and have gotten the same thing
22:00 sashal: There's no logic going into dxgkrnl
22:00 karolherbst: no new uapi then ;)
22:01 danvet: sashal, yeah, we still want the entire thing, not just the pipe
22:01 danvet: because the pipe alone is pretty useless to keep evolving stuff and making sure it all integrates
22:01 sashal: danvet: I'm not sure how that would work since the GPU is shared with the host
22:01 danvet: jenatali, e.g. dx12 monitired fences vs drm_syncobj both map to the same client apis, but implementation is worlds apart
22:02 danvet: sashal, it's not really the first paravirtualized gpu driver we have
22:02 jenatali: danvet: Too bad
22:02 danvet: jenatali, that's why extending drm with userspace managed residency and monitored fences and all that is kinda tricky
22:03 karolherbst: anyway, if stuff like that just gets merged, this will mean more work for me for totally unrelated stuff... :p
22:03 karolherbst: so I have a personal interest to not allow random uapis to pop up
22:03 danvet: jenatali, I guess the other thing is that if we do that major revision, going all the way to an iouring style interface would make much more sense
22:03 danvet: so would again have a mismatch
22:04 danvet: plus I expect a somewhat practial problem of even if we start out with everything matching
22:04 jekstrand:makes popcorn
22:04 danvet: microsoft might not be too happy that there's now some open source upstream defining how dx kmd interface works :-)
22:05 danvet: also we have somewhat of an opinion about the vendor parts on both kmd and umd side ...
22:05 karolherbst:thanks jekstrand
22:05 airlied:still lacks some of the io_uring vision :-P doesn't the hw already have a ring buffer :-P
22:05 karolherbst: jekstrand: both kinds or just the sweet ones? Actually, I have no idea what kind of popcorn is common in the US
22:05 danvet: I'd love to make this happen in some form, but "it's complicated" doesn't even grasp the surface I think ...
22:06 danvet: airlied, yeah but the hw doesn't do the memory management
22:06 alyssa: karolherbst: butter, sugar, and salt
22:06 jekstrand: karolherbst: Generally butter and salt
22:06 jekstrand: But sometimes caremel
22:06 danvet: airlied, and maybe we don't want to let vendor vendorize the scheduling
22:06 karolherbst: ahhh, I remember hearing about that
22:06 jenatali: danvet, that's a good summary :)
22:06 danvet: that could be horrors to tie back into cgroups
22:06 airlied: danvet: yeah scheduling is messy if you have userspace command submission
22:06 airlied: since it's like just give it to the firmware
22:06 karolherbst: butter popcorn sounds interesting
22:06 danvet: airlied, so drm_uring to stuff it all in
22:07 danvet: and let kernel driver dispatch
22:07 airlied: maybe we need a userspace scheduler :-P
22:07 airlied: bring back dri1
22:07 danvet: n:m thread ftw
22:07 danvet: well some of the dxgkrnl stuff I don't understand was talking about locking order
22:07 danvet: I wonder whether that was dri1 locking or reimplemented lockdep
22:08 airlied: fwded render nodes is only useful if you only care about Linux on Linux workloads
22:09 alyssa: yeah, BSDs matter too :)
22:09 airlied: but a lot of workloads out there are Windows on Linux
22:09 airlied: which it doesn't help serve at all, since I can't see us shipping a drm shim driver for Window
22:09 jekstrand: karolherbst: What do you usually put on your popcorn?
22:09 airlied: then building d3d12 on top of vulkan so that aero works
22:09 airlied: jekstrand: cocaine
22:10 airlied: or acid if you live in the valley
22:10 karolherbst: jekstrand: we usually have salt or sugar/caramel ones here... never saw the butter ones
22:13 sashal: danvet: I guess that I'm missing why you want more than a pipe - dxgkrnl doesn't try to mix in with the kernel's gpu implementation. It sounds to me like you're asking me to create the problem and then solving it
22:14 sashal: Would it make it simpler if we moved the ioctl stuff to userspace and just shared memory to pass messages back and forth?
22:22 airlied: danvet: I'm not sure it makes sense to align dxgkrnl with Linux, though I'm interested in how is interacts inside Linux with the winsys for display of htings
22:23 airlied: like you just run guest apps and the display as native windows apps talking to a windows X server etc
22:24 Kayden: currently it's entirely headless
22:24 Kayden: but it sounds like that may be changing in the future
22:25 danvet: apparently rdp's stuff over
22:26 sashal: airlied, Kayden: that was what was announced today. There was a demo of gimp running on windows
22:29 swick: is that gtk3 gimp with vulkan or gtk2 with shm?
22:30 jenatali: It's shm
22:31 swick: oh, vulkan is in gtk4 only
22:31 swick: but yeah, shm makes sense
22:34 airlied: yeah the email says "Further, at this
22:34 airlied: > time there are no presentation integration"
22:51 sashal: airlied: let me get back to you on the plan around presentation support
23:02 danvet: airlied, sashal I guess once we get to integration we might just need a second stack for wsl
23:02 danvet: *wsl2
23:03 danvet: like you get the dx12 pipe in hyperv for cuda and ml and all the headless stuff
23:03 danvet: and something else if you want presentation integration and all the winsys/platform goop that normally comes with a linux gpu driver
23:03 danvet: and that something else is tbd
23:04 danvet: might be two entirely separate worlds that only get back together in the host windows kmd
23:04 airlied: yeah and I'd rather the something else doesn't sneak in on the back of this thing
23:04 danvet: jenatali, ^^
23:04 jenatali: Sounds reasonable to me
23:08 sashal: airlied: "depends on !CONFIG_DRM"? :)
23:18 danvet: sashal, distro's wont appreciate that I think
23:20 sashal: danvet: We ship the kernel for all the distros that bolt on top of WSL2
23:20 danvet: well then I kinda wonder what the point of upstreaming is ...
23:20 sashal: And right now it ships with CONFIG_DRM disabled
23:21 airlied: danvet: yeah I don't think distros ever need to ship it
23:21 sashal: Because I'm hoping that later on it can grow into something more meaningful :)
23:21 airlied: since the WSL2 kernel comes from MS
23:21 danvet: sashal, if msft ships it then config tricks also don't really matter I think
23:21 jenatali: I still think it could be useful for running e.g. a full Ubuntu VM on Windows with GPU/ML acceleration
23:21 danvet: we're also not going to catch them
23:22 sashal: danvet: if they remove that config in the upstream Kconfig you will, right?
23:22 airlied: jenatali: do you not replace the kernel in that case?
23:22 karolherbst: jenatali: for that there are already vGPU solutions or not?
23:22 karolherbst: or passthrough
23:22 sashal: If MS does it out of tree then it's not your problem
23:22 airlied: karolherbst: nothing that can run ML
23:22 karolherbst: airlied: why not?
23:22 danvet: sashal, there's a lot of stuff flying around
23:22 jenatali: airlied: No, if it's just an off the shelf VM we don't
23:23 airlied: karolherbst: passthrough isn't useful there, and "SRIOV" is only on certain highend GPUs
23:23 danvet: sashal, anyway I think if we have some consensus about what's ok and what's not ok to eventually extend then drivers/hv sounds reasonable
23:23 karolherbst: airlied: yeah... okay, well
23:23 sashal: jenatali: yes, in theory it would work with "full ubuntu" too
23:23 danvet: no need for some control freak measures :-)
23:23 sashal: wsl2 is really just a vm
23:23 karolherbst: but then we get back to why propriatary api...
23:23 sashal: danvet: fair enough
23:24 jenatali: karolherbst: Is your "proprietary API" concern about DX12 or WDDM?
23:24 karolherbst: both?
23:24 jenatali: Heh, fair enough
23:24 sashal: karolherbst: I tried to cover that in my answer to Daniel's mail
23:24 airlied: karolherbst: because it's 0 overhead
23:24 airlied: translating it makes no sense
23:24 sashal: We want to use GPU partitioning on the host
23:24 danvet: also disam->asm is kinda a hard mode approach to "hack on your gpu stack to extend it to do what you want it to do" :-)
23:24 karolherbst: yeah, I guess this makes sense
23:24 karolherbst: but then we get again to this new upai without open source user problem
23:25 karolherbst: *uapi
23:26 karolherbst: I totally get why MS wants to prevent their software becoming completly irrelevant in the cloud space... but still
23:26 karolherbst: no reason for us to buy into that
23:27 karolherbst: and if it's just a small shim, there is also no significant benefit for MS maintaining it downstream, is there?
23:28 karolherbst: and for the general linux ecosystem we really want to have a cool paravirt solution for gpus
23:29 karolherbst: airlied: I think people who care about overhead already buy those high end GPUs
23:29 karolherbst: so who actually benefits here
23:31 karolherbst: yeah.. I don't see it
23:31 karolherbst: no matter how hard I try to think about scenarios, there are always other solutions
23:32 karolherbst: only which makes sense is windows user not wanting to use linux
23:33 airlied: karolherbst: there's no easy solutions, there's a lot of vendor hacks
23:33 airlied: I can't really fault MS for wanting to avoid vendor hacks here, since I spend most of my life avoiding vendor hacks here
23:33 karolherbst: airlied: no. I mean you need some kind of business so that partitioning starts to make sense
23:33 karolherbst: you can also just... not use VMs
23:33 airlied: it's just their avoidance strategy is more proprietary and closed hacks
23:33 karolherbst: so you don't have to deal with any of that
23:33 karolherbst: if you run customers VMs you are big enough and actually need GPUs with proper support
23:34 karolherbst: then you already have vGPU support
23:34 airlied: karolherbst: developers want to run stuff locally as well though
23:34 karolherbst: on you local machine it doesn't matter unless you run windows
23:34 airlied: and this is for people running windows
23:34 karolherbst: right
23:34 karolherbst: then again: why can't windows maintain that downstream
23:34 airlied: they can, they are just asking to upstream it
23:34 karolherbst: I really don't see the use case where it would directly benefit linux users
23:34 karolherbst: right
23:35 sashal: karolherbst: uh, the folks using wsl2 are "linux users"
23:35 airlied: since we go around telling people to upstream everything :)
23:35 karolherbst: sashal: sound more like disappointed users that windows server is not a thing anymore to be honest
23:35 sashal: Hey I'm not trying to promote windows here
23:35 karolherbst: I know
23:36 karolherbst: just don't see windows user using wsl2 as linux users
23:36 karolherbst: they would use windows server if they could
23:36 karolherbst: but can't
23:36 karolherbst: so
23:36 karolherbst: I see it this way
23:36 karolherbst: if we have that, we are just stuck longer with windows
23:37 karolherbst: which I see as a fundamentally bad thing
23:37 karolherbst: and not supporting it will probably bring users to linux faster
23:37 karolherbst: or some other OS because they get upset about windows
23:37 karolherbst: dunno
23:37 karolherbst: or maxos
23:37 karolherbst: *macos
23:37 sashal: I guess that unlike you I don't choose to see everything as a windows vs linux war :)
23:37 karolherbst: so again: why would should we care about MS business issues?
23:38 karolherbst: sashal: yeah.. I mean, I argue this more from a closed vs open source point of view in the end
23:38 karolherbst: I am not convinced the linux desktop is the answer either
23:38 karolherbst: just... we need something better
23:38 karolherbst: and MS could be the one providing that
23:38 karolherbst: but not like this
23:39 sashal: karolherbst: hrm, no one is asking you to maintain the code, right? It comes with it's own maintainers file
23:39 karolherbst: windows on top of a linux kernel eg :p
23:39 sashal: No need to care about microsoft if you don't want to
23:39 karolherbst: sashal: uapi has some certain regression rules following that
23:39 karolherbst: so if we get new uapis, those need to be super stable
23:39 karolherbst: like... stable stable
23:39 danvet: sashal, I guess there's another mismatch of what maintaining means
23:40 danvet: for most gpu folks that means "can keep evolving this entire thing as new gpu apis come out"
23:40 karolherbst: and if anybody complains their application broke using those interfaces, commits can and will get reverted
23:40 jenatali: I'd like to think we understand what super stable means
23:40 karolherbst: no matter how many features you added by breaking it
23:40 danvet: for most kernel driver maintainers it's more "keeps compiling and doesn't break existing userspace"
23:40 karolherbst: and no matter how much you are against reverting
23:40 karolherbst: doesn't amtter one bit if the maintainer is against reverting
23:40 karolherbst: and refuses to fix
23:41 danvet: jenatali, yeah I think windows is even more strict on that
23:41 karolherbst: yeah.. I guess that's true
23:41 airlied: yeah I think the fun will be when someone goes and packages up an nvidia d3d12.so in a container
23:41 karolherbst: I usually deal with ... parties having more relaxed rules on that
23:41 airlied: and distributes it to someone else, when the host driver is different :-P
23:41 danvet: we do some fairly creative abi contract bending sometimes in drivers/gpu because we can just read the source of everything that every ran using them (and everything else is just not upstream's problem)
23:42 jenatali: Meanwhile we're quite used to closed source apps and having to keep them running
23:42 airlied:also got confused because of the wayland/rdp announcment, I thought the streams could cross
23:42 airlied: but it appears that is a completely orthogonal thing to this
23:42 jenatali: airlied: So far
23:42 karolherbst: jenatali: yeah.. I guess I am not used to discuss with others having similiar strict rules
23:42 danvet: yeah some tweets already talk about acceleration in the context of the wayland thing
23:42 karolherbst: it's a fair point I am happy to respect
23:43 karolherbst: jenatali: just you don't have a person called linus torvalds who will just revert patches behind your back :p
23:43 karolherbst: or well, with you knowing
23:43 karolherbst: but you can't do anything about it except fixing
23:44 karolherbst: MS had a few exceptions breaking stuff I assume
23:44 jenatali: karolherbst: Don't worry, we've got equivalents. If you break Windows, things aren't good :P
23:44 danvet: karolherbst, well I think with the hw vendor extension stuff that seems to be going on it's entirely different
23:44 karolherbst: yeah.. maybe
23:44 danvet: which has some potential for lolz with containers
23:44 karolherbst: ahh yeah, containers will be annoying here
23:44 danvet: but I guess the people doing nvidia containers are already aware of that
23:44 karolherbst: and in 20 years we have this container from 2020 which has to run somewhere in a banks server
23:44 karolherbst: tough
23:45 danvet: since the linux nv kernel blob is equally not having much of an stable uapi going on
23:45 karolherbst: yeah..
23:45 karolherbst: in their open source -uvm driver you can even see where their API breaks
23:45 karolherbst: it's not even backward compatible
23:45 karolherbst: or forward
23:45 karolherbst: or in any way
23:45 karolherbst: they just.. not care
23:45 danvet: it's the same everywhere
23:46 danvet: afaik at least
23:46 karolherbst: and we have tools to parse their ioctls...
23:46 karolherbst: fun I say
23:46 karolherbst: a lots of fun
23:49 krh: airlied: certainly, having a guest userspace that relies on certain host hw is something that can be managed and has enough benefits that it's worthwhile...
23:50 karolherbst: ufff, don't remind me
23:50 karolherbst:joined too many meetings where stuff like this got discussed
23:51 airlied: krh: yeah I expect semi-contained containers will be way forward for graphics or compute things
23:52 airlied: the lowlevel API is too high level, in-kernel vulkan ftw :-P
23:53 karolherbst: containers using nvidias stack area already annoying enough
23:57 jekstrand: airlied: No, in-kernel level0