01:31 mareko: tarceri: is the nir linker enabled and fully working with st/mesa?
01:33 mareko: tarceri: does it replace the GLSL linker, or does it work on top of it?
01:34 mareko: jekstrand: is lower_precision the only thing you didn't want to be done in GLSL IR for mediump?
01:50 jekstrand: mareko: It's been a while. At XDC, I think I had an opinion and reasons but I honestly don't remember them now.
02:48 tarceri: mareko: it works on top of it currently, we still need to inplement support for linking varyings
02:48 robclark: mareko, jekstrand: there were some things that we have to "lower" in glsl, but upshot of xdc discussion was f2fmp (and I guess we need an integer equiv) so glsl ir provides enough info in nir about when we can and can't fold away precision conversions.. currently the precision conversion folding we handle in backend..
02:49 tarceri: mareko: also there is no linking support for ubos
02:49 robclark: the glsl part is just to insert f2fmp so backend knows when it can fold convsersions
02:50 tarceri: mareko: see gl_nir_link_glsl() for what is supported currently
02:53 tarceri: I'm currently working to replace the pass that resizes uniform arrays, then after that I'll likely start looking at adding support for linking varyings but that's probably going to be a bunch of work
02:56 tarceri: I'd advise against adding support for new things in the glsl ir linker if possible
02:56 mareko: robclark: GLSL also lowers texture opcodes to f16
02:57 robclark: we do as well.. although might just be down to conversion folding in backend
02:58 robclark: iirc there were some more recent fixes about samplers.. since there is some lolz about highp sampler but low/medp coords
02:58 mareko: which is something that I think GLSL shouldn't have to do, because 1) nir preserves mediump on samplers 2) who cares about mediump if the next instruction is f2f16
02:58 robclark: turns out that sampler counts as arg to texture() so effects precision of coord
02:59 robclark: there were some cases were (prior to adding f2fmp) not enough information was preserved at nir level, hence need to handle somethings in gsls
02:59 robclark: not sure I remember all the details off top of head
02:59 robclark: nroberts might remember better
03:00 mareko: nir has mediump on inputs, outputs, samplers, and images, no need for GLSL
03:00 robclark: but the approach was to mostly handle in nir and add nir opcodes like f2fmp where bitsize conversion is optional
03:00 robclark: but without things like f2fmp, nir doesn't know when some conversions are unnecessary
03:01 mareko: yes, f2fmp is for alu, and the rest can be derived from variables
03:03 robclark: maybe.. the texture() case is a bit more complex.. since it is highp input if either sampler or coord/etc is highp
03:03 robclark: input/output is simpler.. but otoh not all backends want to lower in certain cases
03:05 mareko: robclark: texture() seems simple: if coord is f2f32(f16), the coord param can be f16; if the result if followed by f2fmp/f2f16, the result can be f16
03:06 robclark: no, the sampler uniform precision can force coord to be highp
03:07 robclark: ie. highp sampler doesn't mean result is highp, it means src args are highp
03:08 mareko: robclark: but what's the point in highp coord if the source is f16?
03:08 robclark: so, I guess the thing is the stuff that has ambiguous precision, like literals
03:09 robclark: so the rules that deal with texture() src that is mediump_var * something_ambiguous need to be handled at glsl level
03:09 mareko: robclark: same for images?
03:10 mareko: though I guess there is not much to be gained from int16 vs int32 precision for image coordinates, might be always int16 except for buffers :)
03:11 robclark: images, I'm not sure off top of head.. they came along later when spec was better defined.. but I *assume* they follow same rules as textures
03:12 robclark:not the best spec lawyer.. I just know some of the things I assumed where simple about texture() turned out not to be
03:18 imirkin: robclark: textures imply auto-derivatives, which gets into the level of precision for d/dx. with images, it's all integer coordinates, so it either fits or not.
03:21 robclark: as in dFdx/dFdy?
03:34 imirkin: yes
03:37 robclark: does *any* highp sampler or coord promote dFdx/dFdy? I suspect we don't handle that (but otoh I suspect that is a thing that should be handled in glsl)
03:38 imirkin: i suspect it's not super-well-defined
03:38 imirkin: i'm just pointing out that it's something to consider before automatically transitioning things
03:41 robclark: "not super-well-defined" seems plausible.. also an argument for keeping that in glsl and just emitting 'optional' conversion instructions into nir where appropriate
03:44 krh: if the texture coords are fp16, the derivatives will be as well
03:45 krh: they're just the delta of the texture coords between the quad neighbords
03:46 imirkin: sure
03:46 imirkin: but the fp32 delta will differ from the fp16 delta
03:48 krh: right, but if the sampler of the tex coords are mediump, that's what you get, right?
03:48 imirkin: maybe?
03:48 imirkin: probably just the coords, not the sampler itself
03:49 imirkin: i think sampler precision refers to the color values
04:05 krh: imirkin: I don't see anything in the spec that says that the sampler affects the returned values
04:06 krh: that comes down to the precision of the variable they're assigned to
04:07 krh: the only thing the sampler affects as far as I can tell, is that it's an argument to texture() and affects the whether the rest of the arguments get lowered
04:08 imirkin: hm, ok
04:44 ascent12: In Mesa, I'm trying to modify some of the egl wayland platform stuff. From a `struct dri2_egl_display`, is there a proper way I can iterate over all of the associated `struct dri2_egl_surface`s?
05:14 airlied: jekstrand: was there every any discussion about a vulkan user ptr type thing?
06:17 daniels: ascent12: hm, what do you need that for?
07:29 ascent12: daniels: For dmabuf-hints, if the default hints are updated (and no per-surface hints are present), it would be good to reallocate any surfaces that needs it.
07:39 daniels: ascent12: ah OK, I see what you mean
07:40 daniels: tbh in that case I would rather use a serial or something in the display, then have the surface just check at get_back_bo time, i.e. surface pulling from display, rather than have the display push to the surface
07:41 daniels: the latter has un-fun threading implications, particularly if it's already stuck in get_back_bo waiting for a release or frame event
07:43 ascent12: daniels: Yeah, I was wondering if any threading stuff was going to get involved. Having a serial does seem like less of a hassle. I can't think of anything obvious to use for a serial, unless I just go with clock_gettime.
07:44 daniels: ascent12: just incrementing number?
07:46 ascent12: Oh right. I was overthinking it. Just increment a number every time the default hints are updated, and keep that number inside of the surface when doing an allocation.
07:46 daniels: yeah, exactly
07:47 daniels: then in get_back_bo, you already have the extents equality check for realloc - just extend that to also realloc if the per-surface hints are present and have been changed since you last allocated (a bool will do for that, whenever you get a new event), or if you don't have per-surface hints, if your alloced-from-device-hints serial != the current device-hints serial
07:48 ascent12: Yup
10:17 MrCooper: danvet pq: IMHO "smooth transitions" involving buffers from the previous DRM master is a red herring; xf86-video-amdgpu/ati set dummy all-black buffers (and destroy all other KMS FBs) before switching away, to prevent other DRM masters from spying
10:18 emersion: MrCooper: what do you mean by "red herring"? shouldn't be done?
10:18 MrCooper: anyway the priority should be making it reliable, then maybe worry about fancy stuff
10:18 emersion: it's a common practice for login managers to leave the last frame behind
10:19 emersion: display managers*
10:19 MrCooper: doesn't mean the next DRM master needs to do anything with it
10:19 emersion: GNOME cares about this, i believe
10:20 MrCooper: on startup, but on VT switch I don't think so
10:20 emersion: ah, not on VT switch ofc
10:21 emersion: hmm, maybe it depends, i've heard gdm is involved when the session is locked
10:21 MrCooper: for such fancy transitions I can agree that some kind of protocol is needed between the parties
10:36 danvet: MrCooper, well sure you need to have your compositor integrated with your screensaver to make this work correctly
10:36 danvet: just because X kinda fails at that doesn't mean it's not possible
10:38 MrCooper: not sure what you're talking about now; my concern is a DRM master being able to reliably restore its desired configuration, no matter what the previous one left behind
10:39 MrCooper: and I'm not seeing how "smooth transitions" should have any impact on that
10:40 danvet: it's kinda the same problem
10:40 danvet: gunk left behind by the previous compositor causing trouble
10:40 danvet: difference is just transient vs permanent trouble
10:40 MrCooper: I'll take the former
10:40 danvet: but this here was just re your statement that since -amd/ati switch to black we don't need to care about smooth transitions
10:41 danvet: the "red herring" thing
10:42 MrCooper: I'm saying smooth transitions are irrelevant in general for VT switching
10:44 MrCooper: and I'm also arguing that most DRM masters shouldn't let them be possible at all when switching away from their VT
10:46 MrCooper: and leaving it impossible to reliably restore configuration when switching to one's VT due to some hand-waving about smooth transitions is... not sure what to call that :)
10:49 emersion: VT switching is mostly fine, you can just blindly restore props
10:51 MrCooper: the problem is you can't always know which values to restore
10:52 emersion: everything?
10:55 MrCooper: to which values?
10:55 MrCooper: daniels: so i.MX doesn't support modifiers?
10:55 vsyrjala: was just going to ask: what if the user wants a non standard default value for some prop? if someone is going to do something around this area would be nice to solve that issue as well, somwhow
10:56 daniels: MrCooper: ha, I literally just opened GitLab to type '... but this is in the fallback path so please ignore that entire paragraph'
10:57 daniels: regardless, I don't see why the optimise for scanout vs. not calculus should change depending on whether or not modifiers are supported ... ?
10:57 emersion: MrCooper: save all the values as "initial values" on launch, restore them after VT switch
10:58 MrCooper: because without modifiers, scanout is definitely never possible without GBM_BO_USE_SCANOUT
10:58 emersion: possibly overwriting some values when the compositor understands the prop
10:58 MrCooper: emersion: that breaks if the state was broken somehow when you got the values
10:59 emersion: MrCooper: yes, and that's what we're discussing about in the ML thread
10:59 emersion: initial launch
11:00 emersion: vsyrjala: what does it mean for a user to setup a custom default value? what's the use-case?
11:00 MrCooper: which means there must be some way to get default values other than the current state
11:01 emersion: -1 to letting the user use this as a generic KMS configuration tool
11:01 emersion: that's not the intended purpose
11:01 emersion: MrCooper: yes, either from the kernel, either from another user-space program
11:01 emersion: a library was already ruled out
11:01 emersion: iirc
11:02 vsyrjala: the usual use case is the quatization range knob, which many displays implement badly
11:03 emersion: maybe should be a quirk in the kernel?
11:03 emersion: isn't there an "unset" value?
11:04 emersion: hmm, can't find the prop, what's the name?
11:04 vsyrjala: 'Broadcast RGB' or somehting along those lines
11:05 emersion: https://drmdb.emersion.fr/properties/3233857728/Broadcast%20RGB
11:05 emersion: so, there is "Automatic"
11:05 emersion: sounds like a good default value
11:05 vsyrjala: except is's crap on some monitors
11:06 pq: MrCooper, danvet, red herring indeed. I am only interested in not making smooth transitions impossible. I am not interested in making then work.
11:06 emersion: ^ same :P
11:06 emersion: vsyrjala: just like some gamma LUTs don't look right on some monitors?
11:07 emersion: or was it some default non-linear gamma LUTs in the GPUs? can't remember
11:08 vsyrjala: edid tells us things about gamma/primaries/etc. it doesn't tell us whether the display implements the quantization range thing wrong
11:08 vsyrjala: it's sad they didn't just make the selectable quant range mandatory
11:09 pq: vsyrjala, IMO, non-standard default value is "I am changing things behind the display server's back and expecting it to work". Which won't work.
11:09 emersion: yeah, agreed
11:10 vsyrjala: how's that different to "reset all the things to default behind the display serves's back"?
11:11 emersion: i think this is also a bad idea
11:11 emersion: but for a different reason
11:12 emersion: re quant range: let's say the user unplugs the bad screen and re-plugs another one
11:13 pq: vsyrjala, reset to defaults is done *by* the display server, not behind its back. Since it's impossible to unset properties you don't understand, you have to set them to something. That something is "the default value", and it doesn't matter what it is, as long as it a) never changes, and b) allows at least some kind of picture on screen.
11:14 pq: IOW, the default is the value the hardware uses when there is no control implemented for the value.
11:15 vsyrjala: i thought the proposal was to make the kernel to reset everything?
11:15 pq: no
11:15 emersion: it was to allow user-space to get "default values" from the kernel
11:15 emersion: but since then, s/kernel/somewhere/
11:15 pq: one of the proposals was to let the kernel give us the defaul values of properties, so that we can use them on those properties userspace does not understand yet.
11:16 pq: and only for the purpose of getting repeatable KMS state.
11:16 pq: repetable state with unrecognized properties, because almost always there will be some properties the userspace program does not yet undertand
11:18 pq: but some other userspace program may understand those properties I do not, and change them, causing my KMS state to be different from what I used on a previous reboot if I don't know what to reset it to.
11:22 pq: Repeating KMS state after VT switchings is easy, just do a blind save and restore of the properties you don't understand.
11:22 pq: Repeating the KMS state across reboots or restarts is the harder issue where I hoped the kernel could have offered "default values" I can use without understanding them.
11:23 pq: but if not, then I probably have to save the unrecognized KMS property values into a file on my first boot, and then re-use them always.
11:24 pq: that's going to be slightly awkward, because there is no persistent naming of CRTCs, connectors, or planes.
11:25 pq: so I have to just save <object-type>:<prop-name>:<prop-value> and hope that all CRTCs have the same value for the property.
11:25 pq: if they don't, I have to arbitarily pick one
11:27 emersion: why do you want to repeat KMS state across reboots?
11:27 pq: monitor color profiles
11:28 pq: any change in any property has a chance of invalidating the color profile, depending on what the property is
11:29 pq: it would be nice if people can get away with just verifying the color profile is still correct, rather than needing re-measure it
11:29 pq: (verification is measuring too, but faster to do than re-profiling, I believe)
11:29 emersion: oh right
11:32 pq: I guess if the worst case, each display server will be having its own config file where users can write their own <object-type>:<prop-name>:<prop-value> defaults for the properties the display server itself doesn't understand.
11:34 emersion: i don't intend to write anything to a file, fwiw
11:34 emersion: i know it's not correct, but it's just too much to ask
11:36 pq: yeah, one alternative is not add knowledge of new properties into your display server ASAP, even if to just smash it to some constant value.
11:37 pq: *is to add
11:37 pq: but failing to catch up exposes the kernel for regressions bug reports
11:38 pq: "I updated my kernel, and now my login manager changes this new KMS property messing up the color in my display server who doesn't yet understand the property."
11:41 pq: I wonder how all the other kernel sub-systems manage with the "never break userspace" rule. I don't believe the lose-lose-scenarios would be limited to DRM, but I lack the knowledge to imagine what they could be.
11:43 pq: It's not enough to land new UABI into the kernel first, because people can always stick to older kernels and start using new userspace first, then a kernel upgrade exposes the new feature and behaviour changes only because you upgraded the kernel.
11:44 linkmauve: Like when Mesa was updated to support 10-bit configs and GNOME-Shell started misbehaving and people blamed Mesa for it.
11:58 imirkin: pq: new userspace can require new kernels
11:58 imirkin: sadly the inverse isn't true
11:59 imirkin: (or happily, depending on one's vantage point)
12:04 emersion: kernel can require new user-space via drm caps
12:05 pcercuei: pinchartl: ping
12:08 pq: imirkin, new userspace could, but doesn't if it wants to be compatible with older kernels.
12:08 pq: so new userspace will use new KMS properties if they exist - if they are behind a cap, userspace attempts to set the cap
12:09 pq: if people are allowed to run new userspace with old kernels, the problem is always possible
12:10 Vanfanel: pq: Lets say I issue a synchronous flip with drmModePageFlip(), and then, just after the drmPageFlip() call, I poll on the fd to wait for the flip event to arrive. Would it be the same as if I did the synchronous drmModePageFlip() and then simply called drmWaitVBlank next to it?
12:10 pq: Vanfanel, no.
12:11 pq: Vanfanel, drmWaitVBlank waits for any vblank, but you don't know which vblank your pageflip will happen (your flip may have unsignaled fences it needs to wait for first)
12:12 Vanfanel: pq: ah!! I understand... I wait for the pageflip, which could be done in any vblank, not the next one. right?
12:13 pq: more or less, yeah
12:13 Vanfanel: Also, there could be other vblanks on different connectors, etc..
12:13 pq: if you can guarantee that all fences are already signalled, then the flip should occur on the immediate vblank - if the kernel gets your submission in time
12:14 Vanfanel: pq: I understand, yes
12:15 pq: vblanks are a crtc, not a connector thing
12:18 pq: Looks like drmWaitVBlank() also cannot handle more than two CRTCs. A lot of hardware nowadays has three or more.
12:19 emersion: i thought it could, with some flag bits reserved for the CRTC?
12:19 emersion: return (output->pipe << DRM_VBLANK_HIGH_CRTC_SHIFT) &
12:19 emersion: DRM_VBLANK_HIGH_CRTC_MASK;
12:20 emersion: fun stuff
12:20 pq: I only saw one bit in the header for the secondary "controller"
12:20 pq: ahha
12:20 pq: yeah, hard to figure out how that works from the header alone
12:20 Vanfanel: pq: If I poll() on the fd to wait for that flip, is there any reason to poll() inside a while() loop? In SDL2 code, it seems that someone (me maybe, maybe Sigmaris..) the polling is done inside a "while(waiting_for_flip)" loop, which does not make sense to me. As I see it, the poll() will stop blocking when the flip event happens, we call drmHandleEvent() on the fd, and thats it, right?
12:21 emersion: there's the new API with drmModeQueueSequence though
12:21 emersion: it's better™
12:21 vsyrjala: apart from the name
12:21 emersion: indeed
12:22 pq: Vanfanel, the poll() will return when *something* happens. You still need to check if it was the flip and if not, wait more.
12:22 pq: Vanfanel, usually you also watch for lots of other things in the same poll(), like input.
12:23 Vanfanel: pq: ok, so that was the reason. Could it be that other events happen on the fd once I issue a flip? Like.. other different flips?
12:23 pq: Vanfanel, but even if it's the DRM fd where something happens, you still need to use drmHandlEvent() to see what it actually was.
12:23 vsyrjala: also signals are a thing
12:26 Vanfanel: pq: ok, I understand. Then, what SDL2 kmsdrm backend is doing now in the event callback function (page_flip_handler) is simply "waiting_for_flip=false". Since waiting_for_flip is read in the loop around the poll() and is also set to false on the callback function, shouldnt it be protexted by mutexes or similar?
12:26 Vanfanel: I mean, anything done in a callback function is done in another thread, so... it seems dangerous to access the same variable from both sides
12:27 Vanfanel: I am asking this because, in general, I dont see any mutex protection for these variables in any KMS/DRM code examples
12:29 Vanfanel: *protexed = protected, sorry
12:30 emersion: page_flip_handler isn't called in a different thread
12:32 emersion: the best way to not have issues with threads is to not do threads
12:39 Vanfanel: emersion: page_flip_handler has to be run in a separate thread. How else could we do drmModePageFlip(), which returns inmediately, and then run page_flip_handler whenever the event comes? It has to be in a different thread for sure or I dont understand how callback functions work.
12:40 daniels: Vanfanel: the callback is _only_ called when you call drmHandleEvent(), and is called in the same thread, right before drmHandleEvent returns
12:40 daniels: it is not automatically called asynchronously
12:40 Vanfanel: daniels: then maybe its called asynchronously ONLY when we issue async flips?
12:40 emersion: drmHandleEvent just calls the callback, synchronously
12:41 emersion: if there's a page-flip event available
12:43 pinchartl: pcercuei: pong
12:44 pcercuei: pinchartl, I'd like your advice on something
12:44 pcercuei: trying to update the ingenic-drm driver to support one board I have, that has a built-in LCD + an external HDMI chip
12:45 pcercuei: both are driven from the exact same pins of the SoC
12:45 pinchartl: what does the SoC output ? DPI (parallel RGB) ? LVDS ?
12:45 pcercuei: DPI
12:46 pinchartl: ok
12:46 pcercuei: So I have one encoder, with two bridges, one for the LCD and one for the HDMI
12:46 pcercuei: the problem is that the two support different modes, so they cannot be enabled at the same time
12:47 pinchartl: right
12:47 pinchartl: so you have one drm_crtc and two drm_connector objects, right ?
12:48 pcercuei: yes
12:49 pcercuei: but the crtc can't send one part of the image to one connector, and another part of the image to the other connector
12:49 pcercuei: because it's the same output really
12:49 pinchartl: first of all, there's the userspace API. I assume you want to convey to userspace that the two connectors can't be used at the same time ?
12:49 pcercuei: yes
12:50 pinchartl: that's exposed to userspace as part of the possible_clones field of struct drm_mode_get_encoder
12:50 pinchartl: so you would need to create two drm_encoder objects
12:50 pinchartl: basically, one for each chain of bridges
12:51 pinchartl: and I think that's it :-)
12:52 pinchartl: ingenic-drm would need to look at how many bridges are connected in parallel to the CRTC output
12:52 pinchartl: and create one drm_encoder for each
12:52 pcercuei: so, in theory you could clone the output... *if* the mode matches on both
12:53 pinchartl: that's something that KMS can't express though :-/
12:53 pinchartl: so you have another option
12:53 pinchartl: you could set the possible_clones field to allow cloning
12:54 pinchartl: (or even use a single drm_encoder)
12:54 vsyrjala: can't clone with a single encoder
12:54 pinchartl: sorry, scratch that
12:54 pinchartl: it's actually not an issue. you can report through possible_clones that cloning is possible
12:54 pinchartl: when cloning the same mode is used
12:55 pinchartl: so both encoders will validate the atomic commit
12:55 pinchartl: and reject modes they don't support
12:55 pinchartl: (by delegating the check to bridges)
12:55 pcercuei: it's a bit more complex than that, I think,
12:55 pinchartl: so it should be all good, if userspace tries to clone and set a mode that one output can't support, it will be rejected
12:55 vsyrjala: hmm. or can you clone with a single encoder? maybe you actually can. can't remember anymore
12:55 pcercuei: because you must not be able to set different modes on each output
12:56 pinchartl: pcercuei: the mode is set at the CRTC level
12:56 pinchartl: an atomic commit that would include both connectors will have a single mode
12:56 pcercuei: alright
12:56 pcercuei: So two encoders, that can clone each other
12:56 pcercuei: I will try that. Thanks :)
12:57 pinchartl: you're welcome
12:58 pinchartl: let me know how it goes if you can, I'm interested in the outcome
12:58 vsyrjala: at least on i915 cloning with digital connectors often isn't possible due to the clock. different interfaces may need different clocks (eg. lvds needs 7x, hdmi needs 5x, etc.)
13:01 vsyrjala: i guess dpi just needs 1x though since it's parallel?
13:01 MrCooper: pq: "read current KMS state, save to file, restore from then on" is still prone to the initial state you read being broken in the first place
13:01 pq: Vanfanel, as others said, there are no multiple threads. The kernel and drivers and hardware work concurrently to your program, yes, but when the kernel sends the event, it's just bytes becoming available on the FD.
13:02 pq: Vanfanel, you have to read() the FD to get the bytes and then interpret the bytes. drmHandleEevent() does this and calls the func pointer you give it.
13:02 MrCooper: Vanfanel: even if you guess the right vertical blank period, drmWaitVBlank may signal too early, and drmModePageFlip directly after that may still return EBUSY
13:03 pq: MrCooper, yes, but at least I have the same state and not different state on every start-up.
13:04 pq: Vanfanel, have a look at how drmHandleEvent() is implemented in libdrm. No threads there.
13:06 MrCooper: Vanfanel: you need to set a unique user_data value for each flip, and then match up the user_data value passed to page_flip_handler(2)
13:09 karolherbst: anybody any opinions on how to deal with PIPE_CAP_RESOURCE_FROM_USER_MEMORY but the driver only supporting it for compute?
13:11 karolherbst: I have this, but I think it's ugly.. https://github.com/karolherbst/mesa/commit/ff8ce2a8d6765eece70d29732e0bffbc4cd0f1ee
13:12 karolherbst: but converting it to a shader cap also makes less sense
13:15 MrCooper: it makes little sense full stop — why does it matter for the shader engine where the memory came from?
13:27 karolherbst: MrCooper: because it matters for NV hw. We only have replayable faults on the compute engine and we don't have an API for adding page table entries based on user ptrs
13:27 karolherbst: so right now I only can use this to implement SVM for CL
13:28 karolherbst: and for stupid reasons you need to support host_ptr buffser in CL for a proper SVM implementation
13:28 imirkin: you'd have to make a dedicated cap for that, i think
13:28 imirkin: so that i can be used in compute-only environments
13:31 karolherbst: imirkin: I know
13:31 karolherbst: that's what the patch does
13:31 karolherbst: I am just asking if anybody has a better idea
13:31 karolherbst: or maybe we split it and drivers need to advertise both for the GL extension?
13:34 jekstrand: airlied: Vulkan user ptr?
13:35 imirkin: karolherbst: no, like MrCooper said, that makes no sense
13:35 imirkin: resources aren't attached to engines
13:36 karolherbst: yeah... that's my biggest problem with the split here
13:36 karolherbst: but..
13:36 karolherbst: we only support it for compute engines really
13:36 imirkin: because clover.
13:36 karolherbst: no
13:36 karolherbst: because of hw
13:36 karolherbst: or missing kernel API
13:36 imirkin: er, sorry, i misread
13:36 karolherbst: choose one
13:36 imirkin: you only have to support it for compute engines because clover
13:37 imirkin: so it works out
13:37 karolherbst: yeah
13:37 imirkin: but having separate caps and requiring both makes no sense
13:37 imirkin: either you support it or you don't
13:37 karolherbst: I know
13:37 karolherbst: well
13:37 karolherbst: we can't use the resources for graphics
13:37 karolherbst: I tried
13:37 karolherbst: hw doesn't like it
13:37 imirkin: this is a way to cheat and say "yeah, i do actually support it, but only in these super-limited circumstances. buyer beware."
13:38 karolherbst: imirkin: so what would you do?
13:38 imirkin: i thought i covered that...
13:38 kusma: Hmmm, recently rebased our d3d12 driver on a recent-ish mesa master, and I'm seeing problems with 32-bit bools... We don't handle them, and we don't want them. But we didn't use to get them (apart from a few cases which we handled explicitly), and there's no lowering to 1 bit as far as I can see...
13:38 imirkin: add a new cap that says it's ok for compute-only contexts
13:39 karolherbst: imirkin: so essentially my current patch
13:39 imirkin: ok
13:40 kusma: Zink also wants 1-bit bools, btw
13:43 jekstrand: kusma: You don't have to lower *to* 1-bit bools
13:43 jekstrand: Also, why wouldn't d3d12 want 32-bit? I thought we got 32-bit bools from DX.
13:44 kusma: jekstrand: DXIL uses 1 bit bools
13:45 kusma: jekstrand: Hmm, why do I get 32-bit bools without any lowering then?
13:46 jekstrand: gallium may be calling the lowering pass on your behalf
13:47 kusma: jekstrand: doesn't seem like it...
13:47 jekstrand: Wait, no, it can't
13:47 jekstrand: kusma: Weird...
13:48 kusma: By the way, I don't get 32-bit bools for *all* bools, I think...
13:48 kusma: Just... some...
13:48 kusma: I need to check that a bit closer, but doesn't seem like it happens.
13:48 jekstrand: Oh, that's some pass being midly busted
13:49 kusma: I'll see if I can bisect the same piglit with Zink, as that also asserts on bools with bitsize != 1
13:49 cwabbott: yeah, nothing should be producing 32-bit-bool instructions except the lowering passes
13:50 kusma: cwabbott: even if they come from, say glsl-types?
13:50 cwabbott: yes
13:50 kusma: I mean, like boolean uniforms, for instance
13:50 jekstrand: Oh, boolean uniforms are 32-bit
13:50 kusma: OK
13:50 jekstrand: And you should get a i2b
13:50 kusma: Ah, nice.
13:51 kusma: We have some special handling for stuff like this, maybe that's just busted now?
13:51 pcercuei: pinchartl: that works perfectly
13:52 jekstrand: Actually, for UBOs and SSBOs you get i2b/b2i(ssbo write). For uniforms and shared, it's b2b.
13:52 pcercuei: now when I set a screen to a mode that's not supported by the other, the other is turned off
13:52 kusma: jekstrand: b2b *could* explain this
13:52 pinchartl: pcercuei: \o/
13:52 pcercuei: I can't test cloning, since my LCD is 320x240 and my monitor can't pick that, but I believe it works
13:53 pcercuei: I create the encoders with devm_kzalloc, is that OK?
13:53 kusma: jekstrand: is there a good reason why that doesn't produce i2b by default?
13:53 jekstrand: b2b can usually be dropped
13:54 imirkin: pcercuei: doublescan to the rescue?
13:54 jekstrand: So, for instance if you're reading/writing to/from shared memory, you don't need to do any conversion on the write or on the read.
13:54 pcercuei: imirkin, how to?
13:54 jekstrand: Otherwise, we'd be sanitizing to 0/1 on write and then doing a != on read which we don't need.
13:54 imirkin: you'd have to make a custom mode
13:54 kusma: jekstrand: well, if b32 and i32 are essentially the same, you could ague the same for i2b? :P
13:55 jekstrand: For uniforms, the CPU-side code can sanitize things for you so you get a known representation of true and false allowing you to avoid doing a conversion.
13:55 kusma: jekstrand: won't we have to sanitize uniform data anyway?
13:55 pcercuei: imirkin: doublescan would be a hardware feature of the HDMI chip, I believe
13:55 kusma: jekstrand: I mean, the UBO might get filled by a drunk application developer...
13:55 jekstrand: The point of b2b is that the input is sanitized so you can potentially emit zero back-end code for it.
13:55 kusma: jekstrand: I get that, but is it really sanitized in the UBO case? I don't think so?
13:55 pcercuei: my driver for the HDMI chip (ITE IT6610) is extremely simple right now, it's even amazing that it works
13:55 jekstrand: For UBOs, it may get filled by a drunk programmer. For non-UBO uniforms, we sanitize inside the GL state-tracker.
13:56 imirkin: pcercuei: maybe? not sure about that. afaik it should be pretty much supported everywhere
13:56 kusma: jekstrand: Oh, actual uniforms... We don't have those :P
13:56 imirkin: pcercuei: i could be mistaken though. only really work with desktop platforms.
13:56 jekstrand: kusma: Not in your back-end but GL has them in the front-end
13:56 kusma: jekstrand: Right, but it's been lowered to ubos... maybe that lowering should also lower the type?
13:57 imirkin: pcercuei: yeah, i guess you're right. it needs to know how to scan out a 320x240 image and make it appear 320x480 or whatever on the wire
13:57 jekstrand: kusma: No need. It's been lowered to a UBO which you know hasn't been filled by a drunk programmer. It's been filled by the GL state-tracker which has sanitized all the boolean values.
13:57 pcercuei: but that's a good idea, I didn't think about it. I'll see if the chip supports doublescan
13:57 kusma: Either that, or I should just treat b32 as i32 somehow. But that creeps into many places.
13:57 kusma: jekstrand: Ah, fair point.
13:58 jekstrand: kusma: Just treat b2i as i2i and move on
13:58 imirkin: pcercuei: my guess is you're trying to get above the 15mhz minimum or whatever it is?
13:58 kusma: jekstrand: that's a bit easier said than done, as we also care about the alu-types when inserting bitcasts etc.
13:58 pcercuei: imirkin: I think the minimum resolution for HDMI is 640x480
13:59 imirkin: pcercuei: well, i don't think it has to do with resolution, it has to do with TMDS speeds
13:59 imirkin: also monitors may set a range above HDMI's minimum
14:00 imirkin: so as long as you're above the min, HDMI should handle it, monitor probably should do. doublescan, max out the porches, etc
14:00 jekstrand: kusma: Write two lines of opt_algebraic to turn b2b into i2b/b2i?
14:01 kusma: jekstrand: Yeah, perhaps. We already have our own version of that anywy.
14:01 jekstrand: Every back-end should have their own nir_algebraic stuff
14:01 kusma: Indeed.
14:01 jekstrand: Ok, that's a mass blanket statement....
14:01 kusma: Well, it's just super convenient. I don't see why not.
14:02 kusma: I mean, I'm not going to force anyone or anything ;)
14:03 jekstrand: I think I'd like to see us try to move away from a million bits in nir_shader_compiler_options towards back-ends having their own nir_algebraic lowering passes.
14:05 jekstrand: The issue with that, of course, is that nir_opt_algebraic and the back-end pass can end up fighting if nir_opt_algebraic isn't aware of things the back-end pass is lowering.
14:10 vsyrjala: pcercuei: imirkin: dvi/hdmi min is 25mhz iirc. cea-861 240p/480i/etc. modes use the pixel repeat thing to bump the clock above that limit
14:10 vsyrjala: could of course repeat pixels/lines w/o that too, but then the sink won't know that they're being repeated
14:11 imirkin: vsyrjala: well, doublescan tells it (no clue how that parameter is indicated on the wire though)
14:13 vsyrjala: it's not. if i could i'd nuke the dblscan flag from the drm mode in fact
14:14 imirkin: vsyrjala: huh, ok. oh, i guess as long as it displays 320x480, and it's the same image, no one's the wiser, with proper scaling
14:14 imirkin: (which you'd get with a CRT)
14:21 kusma: jekstrand: yeah, so this stuff broke zink badly as well, kinda as expected ;)
14:23 kusma: oh, wait. That might actually be something else (alignment stuff), bisecting this is going to be a bit annoying, I guess ;)
14:25 kusma: (I really need to get zink testing on CI)
14:28 zmike: zink, you say?
14:30 zmike: anything I could help with?
14:39 kusma: zmike: I'm bisecting now ;)
14:39 zmike: alrighty!
14:39 kusma: ugh, seems several regressions happened here :/
14:41 kusma: Oh, right. No, maybe not. It's just the alignment-fix that doesn't work earlier here, because bit_size is less than 8
14:46 kusma: Nah, it's broken :/
14:47 zmike: I think my current code might actually be hitting this same thing after doing more digging
14:47 zmike: with vector shuffle swizzles
14:47 kusma: you're seeing an assert with non-1-bit bools?
14:48 zmike: hm maybe it's slightly different
14:48 zmike: I'm not expert enough yet
14:49 kusma: jekstrand: c217ee8d35fcac8ab11e7b5bfd0e053e1fed7df0 is the first bad commit for me.
14:52 jekstrand: kusma: That is the one that started adding the b2b opcodes
14:53 jekstrand: I thought I checked that all drivers were ok. I guess I missed zink.
14:53 kusma: jekstrand: Yeah...
14:53 jekstrand: Again, 2 lines of nir_algebraic should fix it for you
14:53 jekstrand: Just turn b2b32 into b2i and b2b1 into i2b.
14:53 kusma: Sadly, zink don't have its own nir_algebraic... yet...
14:54 kusma: I guess now is the time to add one?
15:14 bnieuwenhuizen: jekstrand: Kayden: who knows about format modifiers in GL+scanout at Intel?
15:15 imirkin:nominates ickle
15:15 jekstrand: o/
15:15 jekstrand: or vsyrjala
15:15 jekstrand: for the kernel side
15:16 bnieuwenhuizen: jekstrand: for modifers & compression, how do you handle coherency between the main and auxiliary plane when you have an app possible doing front buffer rendering?
15:17 jekstrand: bnieuwenhuizen: You don't
15:17 jekstrand: bnieuwenhuizen: We have a hack in X11 which looks for multi-plane modifiers and doesn't use those for front-buffer rendering.
15:17 jekstrand: In retrospect, we probably want a property that you either get as part of the kernel blob format or which you can query via gbm which says "this isn't safe for front-buffer"
15:17 jekstrand: I'd love to see that fixed properly
15:18 jekstrand: Especially since we're going to have single-plane compressed images at some time
15:18 bnieuwenhuizen:dodged a bullet by not putting everything in one DRM plane then
15:19 bnieuwenhuizen: Is there anything you need to do between rendering and display, e.g. "clear color elimination"?
15:20 bnieuwenhuizen: if so, when do you do that? Some kind of flush call? Or at the end of every command buffer?
15:21 jekstrand: There is. I don't know how that works in gallium though. Kayden?
15:23 MrCooper: the flush_resource hook is for that
15:24 bnieuwenhuizen: MrCooper: Main question there would be what do drivers do with apps that don't use the "window system integration" but use plain dma-buf in GL + KMS
15:26 MrCooper: glFlush should call flush_resource in that case (glamor should match that case more or less)
15:28 bnieuwenhuizen: yeah, that was what I was thinking, but trying to do my due diligence to see if Intel found a better way
15:29 Kayden: We resolve in flush_resource()
15:30 Kayden: (using the modifier to know if we have to resolve clear colors, or resolve all aux, or maybe neither)
15:31 Kayden: it looks like if we have aux, and the resource is being exported without PIPE_HANDLE_USAGE_EXPLICIT_FLUSH, and it's the first instance of that, we shut off aux
15:31 Kayden: because the winsys isn't going to call flush_resource() so we wouldn't have a resolve point, and so we can't do anything
15:32 Kayden: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/iris/iris_resource.c#L1107
15:32 Kayden: I do feel like that's probably a giant hack, but it seems to work
15:32 bnieuwenhuizen: Kayden: my problem with that is we can hardly shut off the aux plane on an image with a modifier that uses the plane
15:33 dj-death: Kayden: I did introduce a bit of a mess with sharing of bufmgr across screen objects
15:33 dj-death: Kayden: seems to be fixed in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4861
15:33 dj-death: Kayden: would you be able to give it a look?
15:33 Kayden: bnieuwenhuizen: well...that's for an image produced by the Gallium driver and exported elsewhere
15:33 Kayden: for import...yeah
15:34 Kayden: if you're importing something with aux planes and then trying to re-export it elsewhere...can't see that working out
15:34 Kayden: dj-death: thanks for the reminder, I'd looked briefly over the weekend but should actually review it :)
15:35 bnieuwenhuizen: Kayden: jekstrand: MrCooper: thanks for the help!
15:35 MrCooper: my pleasure
15:38 Kayden: ditto, definitely appreciate the help :)
15:38 Kayden:is still not that well versed in this area
15:42 Kayden: dj-death: I'm still not entirely clear how multiple-screen happens :/
15:45 dj-death: Kayden: grab the demo repo in mesa
15:45 Kayden: xmanywin or something?
15:45 dj-death: Kayden: ./src/xdemos/manywin.c
15:45 dj-death: Kayden: XOpenDisplay * number_of_windows
15:45 Kayden: ah, different X display connections
15:45 dj-death: yeah WTH???
15:46 Kayden: TBF, we had a bug reported about that demo in like 2010-2011, I had no idea anyone actually fixed it
15:46 imirkin: Kayden: just de-dup in the loader like every other driver?
15:47 dj-death: maybe that's the way indeed
15:47 Kayden: that sounds a lot nicer...
15:47 imirkin: i saw iris added something, but it was weirdly different than what everyone else did
15:47 dj-death: I thought we did like radeonsi
15:48 dj-death: except with the same bugs all over again ;)
15:48 Kayden: this is the iris_drm_winsys.c stuff?
15:48 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c#n40
15:48 imirkin: you were doing it somewhere other than drm_screen_create? or something else was funny.
15:49 Kayden: I just copy and pasted anholt's code from v3d_drm_winsys.c because it was 1 line of code and seemed to do what I wanted, and everybody else had piles of complexity I didn't understand. :)
15:49 imirkin: ah
15:50 Kayden: it sounds like that complexity is probably a Good Idea(tm), and maybe both iris and v3d should have it. :)
15:50 imirkin: i haven't looked at radeonsi of late
15:50 imirkin: but the nouveau thing has very little complexity, imho
15:51 Kayden: yeah that looks straightforward
15:51 dj-death: it seems radeonsi is still subject to the manywin issue
15:51 MrCooper: nope
15:51 MrCooper: should definitely de-duplicate screens when the DRM FDs reference the same file description
15:51 dj-death: I don't see where you compare file descriptors in radeon_drm_winsys.c
15:51 MrCooper: radeon winsys is still broken, look at amdgpu
15:51 Kayden: looks like freedreno_drm_winsys.c does the right thing too
15:52 imirkin: tbh, the nouveau code looks different than what i remember
15:52 imirkin: i think someone refactored it ... util_hash_table_create_fd_keys does something clever
15:52 Kayden: that was Marek's refactor
15:52 MrCooper: otherwise the separate screens may step on each others' toes for things like GEM handles
15:52 imirkin: right. it sets up the table with the "equal_fd" function which looks at st_dev/st_ino/st_rdev
15:53 MrCooper: which isn't sufficient :)
15:53 dj-death: I see
15:53 imirkin: MrCooper: hm?
15:53 dj-death: I'll try the freedreno approach
15:53 dj-death: and revert a few things in iris/i965
15:54 Kayden: dj-death: thanks!
15:54 MrCooper: imirkin: still need to keep track of the DRM FD passed in, or GEM handles retrieved may not be valid for it
15:55 imirkin: MrCooper: hmmmm ... that sounds right.
15:55 MrCooper: imirkin: see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4861 for a discussion of all the issues
15:55 imirkin: thanks
15:56 MrCooper: np
16:09 kusma: jekstrand: This seems to fix the problem: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4903
16:37 Vanfanel: MrCooper, pq: thanks for your early responses :) You are helping me a lot
16:47 Vanfanel: pq: Out of pure curiosity, how does drmModeHandleEvent() know that the event is of the expected type? I mean: I pass a drmEventContext struct to drmModeHandleEvent(), and all I am passing in that struct is VERSION and page_flip_handler. How does it know I am waiting for THAT vblank event and not another event?
16:49 daniels: drmHandleEvent() dispatches every event that is available on the DRM file descriptor
16:49 daniels: so if you have two events pending on the DRM FD, drmHandleEvent will call page_flip_handler twice
16:49 daniels: it's your responsibility to use the user_data pageflip argument to disambiguate the two events, and perform your own internal event routing
16:51 sravn: tzimmermann: I am getting a little full of mgag200 patches, which is why I push for gettitng patches pushed to drm-misc.
16:51 sravn: Maybe they are not optimal but then you have a more lean code base to work from.
16:54 Vanfanel: daniels: Lets say I have a bool "waiting_flip" as user_data for the flip issue (drmModePageFlip call). It is set to TRUE before issuing the flip, and its set to FALSE in the page_flip_handler. Acording to what you said, how do I know if it is being set to FALSE based on the correct event??
16:56 daniels: well, pageflip events don't happen randomly - they only happen for pageflips you have requested. and there can only be one per output, since you cannot submit multiple pageflips in a row without the previous one completing.
16:56 daniels: so the only place this would happen is when you have multiple outputs active on the same DRM connection, which are being updated independently
16:56 daniels: if that is the situation you have, then use the user_data argument to drmModePageFlip to disambiguate between the two
16:57 daniels: either pass a pointer to your output struct, or pass a pointer to bool waiting_for_flip for your output, or the output's number, or ... anything
16:57 daniels: but that is how you tell the difference
17:03 MrCooper: s/output/CRTC/, but yeah
17:09 Vanfanel: daniels: Yes, so I know that the event is the only I was waiting because the user_data pointer received by the callback function (page_flip_event) is the same pointer I passed to drmModePageFlip(), right? So if I pass waiting_flip in drmModePageFlip() from one side, and receive waiting_flip in page_flip_handler on the other side, in page_flip_handler I can be sure that it got called because the flip I
17:09 Vanfanel: issued in drmModePageFlip() has arrived. Am I right?
17:11 daniels: yep, that's correct
17:22 Vanfanel: daniels: So... what if another event (not the flip I am waiting for) arrives on the fd, then I call drmHandleEvent() because the poll() stops blocking because of that unknown event, and I set waiting_flip to FALSE on the page_flip_handler? I recover waiting_flip as the user_data, but page_flip_handler has been called on the WRONG event, so I am not receiving the right user_data pointer there...
17:23 Vanfanel: In simpler words: what am I reciving as user_data in case that the event is not the flip?
17:23 tzimmermann: sravn, you're already doing a lot of work to get patches reviewed. don't feel obligated to do all this.
17:24 tzimmermann: savn, you commented on to_mga_device() in the other series several time. so i made a really patchset for that macro, instead of shoveling it into the atomic series
17:30 daniels: Vanfanel: huh?
17:30 daniels: Vanfanel: you call drmModePageFlip(..., DRM_MODE_PAGE_FLIP, user_data)
17:30 daniels: user_data is a pointer
17:30 Vanfanel: yes
17:30 anholt: MrCooper: gitlab ci deps question, since I think you understand it better. I have a pipeline where arm_build container build failed, and it looks like meson-arm64 thus didn't get triggered, but a630_gles* did. does that seem possible? are we missing some needs/dependencies?
17:30 daniels: at some point, your page_flip_handler will be called with _that same value_ you passed as user_data earlier
17:32 daniels: so as an example, you can have struct my_output { bool waiting_for_flip; } do_flip() { my_output[0].waiting_for_flip = true; drmModePageFlip(..., &my_output[0]); } page_flip_handler(void *user_data) { struct my_output *output = user_data; output->waiting_for_flip = false; }
17:32 Vanfanel: daniels: but page_flip_handler could be called because of other events arriving on the fd, too. In those cases, what does page_flip_handler get as user_data?
17:32 daniels: ... whatever you passed into it
17:32 daniels: it doesn't get called for random events which are created from nothing
17:32 daniels: the only way you will ever have a page_flip_handler() call, is if you called drmModePageFlip() with DRM_MODE_PAGE_FLIP_EVENT set
17:33 daniels: the user_data parameter to page_flip_handler() will be the user_data you passed into drmModePageFlip()
17:33 daniels: if you are calling drmModePageFlip() multiple times (say, for multiple outputs), it is _your responsibility_ as the caller of the DRM API, to make sure that the user_data parameter allows you to disambiguate between the different calls, and to do whatever event routing you need to do
17:33 Vanfanel: daniels: ohhh god, I understand now... whatever events come, page_flip_handler will ONLY be called if the event is a page flip (as its name implies), right? And page flips dont arrive from thin air...
17:33 daniels: yes
17:34 daniels: we don't just create events for no reason
17:34 daniels: anholt: well that might go some way to explaining the mystery of the missing artifacts ...
17:34 Vanfanel: heh, now I totally understand. Thanks A LOT. Going to take notes on all this, so I dont have to bother you guys again in the future :)
17:35 anholt: daniels: the usual missing artifacts failure has a meson-arm64 job that says "no artifacts found" at the end
18:30 ddevault: where should I send an oops for amdgpu? is there a mailing list or bug tracker?
18:44 pepp: ddevault: https://gitlab.freedesktop.org/drm/amd/issues/ ?
18:45 ddevault: thanks!
19:48 airlied: kusma, daniels : is the runtime part of your dx cl thing available yet?
19:49 airlied:probablu just not looking in the rihgt place
20:13 airlied: has freedreno got a flappy test still?
20:14 airlied: arm64_a530_gles31 just failed for me
20:15 anholt: airlied: I just got flake reporting enabled (https://gitlab.freedesktop.org/mesa/mesa/-/issues/2654) so we may be missing some.
20:15 anholt: link?
20:16 airlied: https://gitlab.freedesktop.org/airlied/mesa/-/jobs/2571219
20:16 airlied: dEQP-GLES31.functional.shaders.builtin_functions.precision.reflect.lowp_compute.vec3,Timeout
20:16 anholt: timeouts, oof.
20:17 anholt: I spent a while this week on trying to get a kernel with cpufreq so that we would be so absurdly slow on a530.
20:18 anholt: unfortunately db820c's been abandoned so its cpufreq isn't heading upstream, and my attempt to rebase it was crashing at boot.
20:18 anholt: could maybe crank the timeouts up on this HW, and drop the number of tests even more
20:20 airlied: uggh that's annoying
20:20 airlied:sees if marge wins the race this time
20:22 anholt: airlied: I'll be watching this hw once that MR lands, and will try to respond appropriately. sorry for the disruption!
20:35 daniels: airlied: unfortunately not yet; I have no ETA for it
20:40 airlied: daniels: boo-urns
20:41 airlied: daniels: I'll keep any eye out then
20:42 daniels: airlied: i'll let you all know as and when
20:46 kusma: airlied: here, jenatali might know more :)
20:46 jenatali: airlied: I heard you're asking after the CLOn12 runtime?
20:47 airlied: jenatali: yeah just wondering if/when it can be looked at
20:48 jenatali: airlied: It's not in the open yet, let me check if there's any good reason not to publish as-is...
20:50 jenatali: Anything in particular you were looking for? Just curious :)
20:55 airlied: jenatali: nope, no hurry was just wanting to look at another opencl implmentation
20:57 jenatali: airlied: There's always clvk, but I'm guessing you already knew about that one: https://github.com/kpet/clvk
20:57 jenatali: Though it's got a laundry list of limitations we're hoping to not have
20:59 Plagman: clon12 -> vkd3d when?
21:00 airlied: lols :-P
21:00 jenatali: Heh, probably sooner than you think
21:00 airlied: the gpu api pokemon adventure continues
21:00 jenatali: Oh wait, vkd3d doesn't do DXIL does it?
21:00 Plagman: it does now
21:00 jenatali: Oh cool
23:21 airlied: jekstrand: just saw reply, yeah lime AMD_pinned_memory for GL
23:23 jekstrand: airlied: context?
23:27 airlied: cl/lvl0/svm all have the concept of copy memory, where memory us a void *userptr
23:30 airlied:is just digging into lvl0 vs vulkan a bit more
23:37 bnieuwenhuizen: airlied: so how hard to implement lvl0 on top of vulkan?
23:38 bnieuwenhuizen:is kinda assuming we can just EXT all the shader stuff ...
23:44 airlied: bnieuwenhuizen: the memory management is more the mess I think
23:45 airlied: bnieuwenhuizen: it uses void * for result of all allocations and all interactions
23:45 airlied: and expects it to be dereferenceable
23:46 airlied: so copy buffer is just void *->void * api
23:48 airlied: I expect the EXT to cover this might be a bit messy :-P
23:51 Kayden: that sounds unpleasant
23:55 airlied: ah device allocstions aren't meant to be accessed by the host
23:55 airlied: but it's still ugly