<gfxstrand>
Let's throw it at some CI to see if it blows rusticl up
<karolherbst>
I have a collection of other random patches I'll have to upstream anyway and tomorrow is time off, so I might do some of that stuff next week
<karolherbst>
I also need SpvCapabilityFPFastMathModeINTEL for random stuff, but I think we can just enable that one...
frankbinns has quit [Ping timeout: 480 seconds]
<karolherbst>
getting a lot of "iris: Failed to submit batchbuffer: No space left on device" in random tests... sadly nothing tells me what the problem is, though I think my SVM impl is borked
<alyssa>
gfxstrand: have you considered using nir_shader_intrinsics_pass
<karolherbst>
that's even _with_ the MR fixing some of it
<karolherbst>
but there is more annoying stuff going on
<karolherbst>
generic pointer nonsense
<karolherbst>
CapabilityInt64Atomics oh boi...
zzoon_vacations_till_6th_Aug[m is now known as zzoon
<karolherbst>
anyway.. I think I'm happy enough with my current global program varaible implementation, I just have no idea how to deal with those "constant" pointers to variables nonsense :'(
<karolherbst>
or rather, I have ideas, I just hate them all
camus has joined #dri-devel
camus2 has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<karolherbst>
gfxstrand: I found a couple of tests where I ran into explicit stride asserts after memcpy lowering
<karolherbst>
will investigate later
<karolherbst>
probably just me having a weird order of passes
<karolherbst>
ehh..
<karolherbst>
it's after opt_memcpy
<karolherbst>
nvm
camus has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
pa has quit [Ping timeout: 480 seconds]
tlwoerner has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
<gfxstrand>
karolherbst: Pushed with some improvements.
<gfxstrand>
Pushed again. One of the fixups was bogus
<gfxstrand>
karolherbst: It should now be patching alignments through properly
tlwoerner has joined #dri-devel
yuq825 has joined #dri-devel
<DemiMarie>
Are there plans to fix the blocking in vkQueuePresentKHR?
<gfxstrand>
Uh... I don't think we're violating anything
<gfxstrand>
And I don't think we block.
<gfxstrand>
Yeah, we have a throttle thing.
<gfxstrand>
We have a throttle thing for X11, too.
<gfxstrand>
We have them because apps are dumb
<gfxstrand>
There's not much I can do with an unhinged rant. If someone wants to file a bug with an example of said misbehavior and can explain what they think Vulkan requires there, we can talk about it. A giant rantpost about how everything is terrible that just assumes the reader agrees isn't actionable.
<ids1024[m]>
If it waits on wl_surface_frame callbacks, it may block indefinitely for occluded windows.
<DemiMarie>
gfxstrand: yeah, good point, that is my fault for linking the blog post.
<DemiMarie>
sorry about that
<gfxstrand>
If the app requests FIFO, yes, we're going to block on frame callbacks. That's literally what they asked us to do.
<DemiMarie>
ah okay
<gfxstrand>
If you don't want us blocking on frame callbacks, requrest MAILBOX.
<gfxstrand>
*request
<DemiMarie>
so this is just buggy apps that don’t realize that they need to have an event driven main loop?
<gfxstrand>
Or that use FIFO instead of MAILBOX
<gfxstrand>
With Wayland, you really should be using MAILBOX and handling the frame callback yourself or in the toolkit.
<DemiMarie>
Makes sense
<gfxstrand>
And, yes, there's a bit of a mismatch between the way FIFO and SwapInterval are specified and Wayland app throttling.
<DemiMarie>
Is using MAILBOX the appropriate thing on other platforms too?
<gfxstrand>
Well, you want some amount of throttling everywhere.
<gfxstrand>
If you use FIFO, you get throttling.
<gfxstrand>
That's what it's for.
<gfxstrand>
With Wayland, you can actaully manage it yourself and get something more predictable.
<DemiMarie>
makes sense!
<gfxstrand>
With X11, the best you can do really is FIFO/eglSwapInterval(1)
<gfxstrand>
If you set MAILBOX, there is a 1:1 mapping between vkQueuePresent() and wl_surface.attach/commit.
<gfxstrand>
The Vulkan spec even says so. :-)
<DemiMarie>
sorry for wasting your time
<gfxstrand>
No worries.
<gfxstrand>
Oh, I think I know why we do extra blocking in Vulkan for Wayland
<gfxstrand>
I guess we do block for everything other than MAILBOX
<gfxstrand>
But, also, you should always use MAILBOX with Wayland.
<gfxstrand>
Well, we don't block much
<gfxstrand>
That's probably more of a documentaiton problem than anything
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
melonai3 has quit [Ping timeout: 480 seconds]
g0b has quit [Ping timeout: 480 seconds]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
g0b has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
g0b has quit [Remote host closed the connection]
bmodem has joined #dri-devel
crabbedhaloablut has joined #dri-devel
melonai3 has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
g0b has joined #dri-devel
kugel has quit [Ping timeout: 480 seconds]
kugel has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
sima has joined #dri-devel
mattst88 has quit [Remote host closed the connection]
mattst88 has joined #dri-devel
aravind has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
bgs has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
kem has joined #dri-devel
junaid has joined #dri-devel
kugel has quit [Ping timeout: 480 seconds]
kugel has joined #dri-devel
macromorgan has joined #dri-devel
alanc has quit [Remote host closed the connection]
macromorgan_ has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest9251
macromorgan has joined #dri-devel
Guest9251 has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
aravind has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
vliaskov has joined #dri-devel
aravind has quit [Remote host closed the connection]
ishitatsuyuki has joined #dri-devel
pcercuei has joined #dri-devel
dviola has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
junaid has quit [Quit: leaving]
lynxeye has joined #dri-devel
Haaninjo has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
donaldrobson has joined #dri-devel
aravind has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<MrCooper>
gfxstrand: it would be possible in principle to do FIFO without blocking in vkQueuePresentKHR, it would require new Wayland protocol though
<emersion>
explicit-sync-v1 can do it
<emersion>
er, v2
swalker_ has joined #dri-devel
swalker_ is now known as Guest9265
Guest9265 has quit [Ping timeout: 480 seconds]
<MrCooper>
that can't do FIFO semantics
<emersion>
i believe it can
<emersion>
send an unmaterialized sync point to the compositor, signal the sync point on presentation-time feedback of the previous frame
<MrCooper>
or on the frame event, I see, clever :)
junaid has joined #dri-devel
<karolherbst>
gfxstrand: new code seems to cause a "Floating point exception (core dumped)"
<karolherbst>
but that's probably my fault :)
<karolherbst>
no allignment information is there
<karolherbst>
I'll post more infos on the MR
junaid has quit [Quit: leaving]
<MrCooper>
emersion: would that require multiple acquire points (another one for the Vulkan acquire point) for the same buffer attachment in the protocol?
<emersion>
MrCooper: it should be possible to have a presentation timeline, which chains the Vulkan API acquire point and then the FIFO point
<emersion>
such that the point submitted to the compositor depends on both
<MrCooper>
what if the sync points immediately before and after the Vulkan acquire point are already used?
<emersion>
the presentation timeline is completely independant from the Vulkan API's
<emersion>
Vulkan user submits frame with timeline A and point 42
<MrCooper>
k, good
<emersion>
mesa transfers this point to timeline B, point 1
<emersion>
then adds a new point 2 to this timeline for FIFO purposes
<emersion>
and sends timeline B, point 2 to the compositor
<MrCooper>
the same principle could be used for "not before" presentation timing as well
<emersion>
yeah
<emersion>
the obvious downside is that since the latching is client-side, there may be races
<emersion>
but on the other hand it's as flexible as it gets
<MrCooper>
and the compositor/kernel might be able to do a better job if they know the target ahead of time
<emersion>
can always start with client side and offload some of it to the compositor in the future once we have more exts
<emersion>
right
<MrCooper>
agreed, good approach in general
<MrCooper>
a Mesa implementation of FIFO using the v2 protocol seems like a good thing to use as one of the 3 implementations required by the protocol process
<emersion>
my original plan was to implement the upcoming ext to present with timelines
<emersion>
but yeah, that'd be a good alternative as well
<MrCooper>
yeah, either or both seems nice
<MrCooper>
swick[m]: ^ might be interesting to you
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<swick[m]>
interesting idea
<swick[m]>
but presentation-time feedback is still not the thing you should be using for FIFO semantics
<MrCooper>
agreed, frame events are better for that
djbw has quit [Read error: Connection reset by peer]
<karolherbst>
gfxstrand: but anyway.. it seems like copy_deref lowering also needs a similiar fix to that memcpy lowering as it can also explode in size with huge arrays
<pq>
maybe USB-C becomes a new top-level connector type, and then it has sub-types HDMI (dongle), DP (dongle), DP-alt (USB-C alternate mode or what is it?), etc.?
<pq>
or should dongles be more MST like nowadays?
<pq>
i.e. dynamically create MST connectors - but that might be confusing
<emersion>
pq, will break existing user-space
<pq>
which suggestion, how?
<emersion>
existing DP connectors, which are physically USB-C, can't have their type changed
<pq>
d'oh
<emersion>
breaks compositor config files etc
kts has joined #dri-devel
<emersion>
we could have a cap or something, but not sure it's worth it
<emersion>
we'd probably want a prop anyways…
<emersion>
to be able to expose the exact USB-C connector device
<pq>
connector props to supercede all the current "connector type" fluff?
<emersion>
e.g. a "usb_device" prop with "5-2:1.1"
<pq>
sounds good at first hand
<emersion>
we could have a "type" property which supersedes the type field, yeah
<emersion>
but we need to clearly define it
<emersion>
(and that wouldn't link to the USB device)
<pq>
it might link... depending on how it's defined
<emersion>
i'd expect a KMS enum
<emersion>
if it's a string, "type" is probably not a very good name
<emersion>
reminds me of the "PATH" stuff…
<emersion>
"PATH" = "usb:5-2:1.1" is tempting
<pq>
"USB-C:5-2:1.1,HDMI,VGA" for example, to say it's a physical USB-C and which one, using a dongle to convert to HDMI, plus another dongle to VGA. Assuming all that could be known, which I guess cannot always be.
<pq>
a proper PATH with physical connector and add-on dongles sounds tempting
<emersion>
oh the USB-C sysfs is pretty nice
<emersion>
has properties like a "dock" bool
<pq>
but I'm afraid I can't get much involved here, too far off of my current work
<emersion>
> ls /sys/bus/usb/devices/1-0:1.0/usb1-port1/physical_location/
<emersion>
dock horizontal_position lid panel vertical_position
<pq>
not sure I even have USB-C personally anywhere
<emersion>
i'm not sure baking the subconnectors into the path necessarily makes sense
<emersion>
maybe…
<pq>
if there is a converter dongle, it's on the signal path, so
<emersion>
right, and a converter might have multiple output ports
<pq>
sounds more and more like MST
<emersion>
so DP → HDMI → VGA should probably have a different path from DP → HDMI → DVI
<emersion>
or DP → DVI → VGA
<pq>
that would make sense to me
<emersion>
(assuming there is a HDMI converter that has either VGA or DVI output here)
<emersion>
(or a DP converter which can do either HDMI either DVI)
<emersion>
or*
<pq>
but if a converter has multiple output ports, then shouldn't each one be exposed as a separate connector? Maybe not, if only one can be used at a time, but how do you then... update the path based on which one is connected?
<pq>
assuming the converter even tells us that to begin with
<emersion>
what do you mean?
<emersion>
KMS props can be updated
<pq>
I'm just thinking from end-user perspective: you have a port on the computer, and you plug in a thing that has multiple different types of ports. How do you represent that in UI?
<emersion>
ah, so you're saying that ideally we know which availabe ports an adapter has?
<emersion>
potentially even before anything is connected?
<pq>
ideally yes, but I also wonder if that's feasible at all
<emersion>
i'd be surprised if it was
<emersion>
i'd be surprised if we can figure out the DP → HDMI → VGA case even
<jannau>
I think USB-C/dp-altmode converters with multiple outputs are using DP MST
<emersion>
DP-MST has a native concept of tree, but for anything else i don't think so
<emersion>
jannau: yeah, we're wondering about non-DP stuff
<pq>
the connector prop should be designed around the most flexible/complex case, and anything else that doesn't have all the info just reports whatever
<emersion>
agreed
<emersion>
(cc lumag, see the whole discussion above)
<zamundaaa[m]>
pq: it's not necessarily that easy, as you're requiring everyone to put all the info in from the beginning. You can't change the prop for a given hardware setup if it's used by userspace as a port identifier
<zamundaaa[m]>
So if you find out you can get more information later, you'd need yet another property to do that without breaking existing userspace
junaid has joined #dri-devel
<pq>
true
<pq>
so we'd actually need a property with an array of strings, so better ones can be added without deleting old ones... uhh
<pq>
that problem is universal though, and always present; we're thinking of a new prop because we can change the old stuff, and that is a one-off fix. Once the new prop becomes broken the same way, we'd need yet another prop for the same reason.
<pq>
*we cannot change the old stuff
<lumag>
pq, I have a USB-C -> DP and HDMI (two output ports). Only one output ports is detected and works.
<pq>
lumag, only one output port ever, or does it switch somehow?
<emersion>
pq, yeah
<lumag>
If I plug in HDMI and DP, only HDMI is detected
<lumag>
and read
<emersion>
DRM_CLIENT_CAP could be used to some extent
<emersion>
and the kernel can shim the old APIs…
<lumag>
So far we have support for single logical connector connected to several physical connectors, think about CONNECTOR_TV and respective subconnector types.
<emersion>
hm, but a compositor is not very likely to be able to ever upgrade
<lumag>
emersion, why?
<emersion>
so yeah, need access to all variants, old and new
<pq>
emersion, I wonder if the shimming will need to be per-driver, too
<emersion>
lumag: because configuration files store the prop value
<lumag>
true
<emersion>
pq, could definitely happen yeah
<emersion>
driver exposes a short string, then realizes it can expose more
<lumag>
emersion, what about exposing USB connectors and a shim DP connectors?
<lumag>
Just for AMD and intel
<emersion>
what do you mean by "shim" exactly?
<lumag>
lightweight aliases
<lumag>
I haven't looked into corresponding drivers though.
<emersion>
so user-space would see DP for Intel/AMD?
<emersion>
but USB for everybody else?
<emersion>
that doesn't sound great
<lumag>
emersion, so user space would see USB for everybody, and aliasing DP for intel/AMD
<emersion>
we could have CLIENT_CAP_USB_CONNECTOR or so
<emersion>
so user-space would see two connectors, one USB and one DP, which are actually the ame?
<emersion>
same*
<lumag>
yep
<emersion>
that sounds like it would cause many issues
<zamundaaa[m]>
it definitely would
<gfxstrand>
karolherbst: Yes, lower_var_copies needs something. I think what it needs is a threshold at which it emits memcpy().
<emersion>
user-space would not know these are the same, and would try to drive each indepdendantly
<gfxstrand>
karolherbst: Hrm... Actually that might not be tractable...
<gfxstrand>
It probably needs a loop threshold instead
<lumag>
true
<lumag>
emersion, pq: I don't like the idea of 'path' including the USB path. It might change from boot to boot.
<zamundaaa[m]>
emersion: regarding CLIENT_CAP_USB_CONNECTOR, that would not be a good idea. We need the old identifier as well as the new one
<emersion>
lumag: really?
<pq>
lumag, USB path is not a physical path?
<emersion>
i thought usb path was physical
<lumag>
emersion, pq. it includes bus id. And bus id can change depending on the probe order
<pq>
well, replace that with something that is a physical path
<emersion>
"The bus on each new host controller gets the next available bus number."
<lumag>
yes
<emersion>
that's a good point
<emersion>
lumag, do you know if there is something else which doesn't change?
<emersion>
something to represent a purely physical path for USB?
<lumag>
emersion, no. We can create 'something', but it will not map to the actual system property.
<lumag>
VID/PID do not change, but then we don't have a clear way to distinguish between several similar dongles
<lumag>
typec path?
<emersion>
we'd want something to identify "the upper-left USB port on this USB dongle"
<emersion>
which doesn't change
<lumag>
emersion, the problem is that there can be no _USB_ in case of a DP dongle
<emersion>
AFAIK DP has such a concept
<lumag>
which one?
<emersion>
"the upper-left DP port on this DP dongle" as a stable identifier
<emersion>
or maybe not and we've misunderstood the PATH prop the whole time?
<emersion>
(also cc vsyrjala)
<jannau>
device tree based systems might have labels on ports, the apple silicon systems all have something like 'label = "USB-C Left Front";" the usb-c/4 ports la
<emersion>
jannau: is this exposed via sysfs with "physical_location" i mentioned earlier?
<lumag>
emersion, what about something completely different for the DP: something like 'protocol' or 'bearer'. Which can be 'native', 'USB' or 'HDMI' (only for dual-mode ports)
<lumag>
pq ^^
<gfxstrand>
karolherbst: Okay, I've added a max unroll length to lower_var_copies as well
<pq>
are we trying to solve the path problem (which has value in its own right), or just the connector type problem without path?
<emersion>
in the case of HDMI, the subconnector would be HDMI already i think?
<jannau>
I think all usb-c dp-altmode converters expose a BILLBOARD usb device
<gfxstrand>
karolherbst: It's not amazing on arrays of arrays but it's better than what we have now
<emersion>
pq, well they interact somewhat, so trying to see if there's a good solution to both, or if the solution should be separate
<lumag>
jannau, not all
<pq>
yes, I too think they interact
<lumag>
it is an option, not a requirement
<lumag>
and in some cases they disappear after DP altmode being negotiated
<pq>
and I suspect that solving path would be an answer to the type question, but not vice versa.
<emersion>
yes
<zamundaaa[m]>
I don't think having the connector type in the path would be important. All I want to use the path for is as a fallback when monitors have broken EDID
<jannau>
I don't see the label exposed in obvious places in /sys
<emersion>
my immediate goal is to be able to expose strings such as "Samsung SyncMaster via HDMI and USB-C Left Front" to users
<zamundaaa[m]>
For me, the connector name is only relevant because it gets shown to the user. Other than that I don't care about it
<emersion>
you can hide it from the user if you can figure out that it's USB-C
<zamundaaa[m]>
emersion: if we can get nice computer-side port names that would be great. I have doubts we can get that on most hardware though
<emersion>
zamundaaa[m]: jannau said it's in device tree at least
<lumag>
emersion, it is not required.
<emersion>
sure
<lumag>
We don't have labels on msm
<emersion>
but when it's here, nice to show to users
<lumag>
emersion, I don't think it is a part of DT spec
<lumag>
or schema
<pq>
If one can tell an end user which port a thing is a la "third from the left, in the back" etc. then that in itself is a persistent port ID, and therefore equivalent to a path. But the information does not always exist.
<pq>
Sounds like we have three different things: path, end-user location, and connector type.
<zamundaaa[m]>
Should these two things maybe be split? One thing for showing to the user, explicitly not guaranteed to be persistent, and one actually persistent ID with compatibility guarantees
<jannau>
lumag: it is part of bindings/connector/usb-connector.yaml
<lumag>
jannau, ack, excuse me then
<emersion>
i don't think we'd want KMS to generate end-user strings
<lumag>
I remembered krzk removing some of the labels from 410c DT
<zamundaaa[m]>
Not end user strings, just a path that the compositor can convert into usable (and translated) strings
<emersion>
these can be generated by the compositor from just the USB ID
<lumag>
if there is a usb ID
<emersion>
there is always a USB ID for USB devices
<lumag>
emersion, if there is a USB device
<zamundaaa[m]>
emersion: a split would be important imo because then you can add user-visible information later on, without breaking config files
<emersion>
lumag: sure
<lumag>
I have dongles w/o USB
<lumag>
or with the USB disconnecting after altmode is negotiated
<emersion>
that's a fun one
<lumag>
emersion, it is a part of DP capabilities VDO:
<lumag>
7
<lumag>
USB r2.0 Signalling Not
<lumag>
0 = USB r2.0 signaling may be required on A6 – A7 or B6 – B7 while in DisplayPort
<lumag>
Used
<lumag>
Configuration.
<lumag>
1 = USB r2.0 signaling is not required on A6 – A7 or B6 – B7 while in DisplayPort
<lumag>
Configuration.
<emersion>
so hm
<emersion>
from the start when i said "USB device ID" what i really thought of was "USB port ID"
<lumag>
I think you meant 'typec port id'
<emersion>
ie, if a USB-C port is disconnected, some unique identifier for this port
<emersion>
yeah, maybe
<lumag>
But I'm not sure whether amd and intel drivers maintain such link
<emersion>
Connector 5 with object ID 114 has "mst:92-1"
<lumag>
yes, which tells that it is going through Connector 1 (with ID 92)
<emersion>
eh, but 92 is another connector…
<emersion>
ouch…
<emersion>
that means it's not a stable identifier at all
<emersion>
pq ^
<lumag>
well, connector IDs are stable in 99% of cases
<emersion>
hm no
<lumag>
why?
<emersion>
upgrades create new props, which share the same namespace, for one
<emersion>
driver probe order
<emersion>
etc
<lumag>
Ah.
<lumag>
driver probe order will not change it, since each device has its own namespace
<emersion>
okay, that makes PATH mostly useless
<lumag>
But for the new props, it's true
<emersion>
hm, possible
<emersion>
i don't remember
<lumag>
I'd say, PATH is semi-dynamic.
<lumag>
In other words it can not be used as a static reference, but it can be parsed to produce one.
<emersion>
that's not a good thing to store in a config file
<emersion>
hm
<emersion>
but what are the numbers after the parent connector ID?
<lumag>
emersion, that's why xorg parses it to produce sensible names
<emersion>
are these dynamic or not?
<lumag>
MST port number
<lumag>
static
<emersion>
ok, nice
<lumag>
On the devices i have here it corresponds to the physical port
<lumag>
emersion, I'd say PATH = 'typec:%d' solves our issues.
<emersion>
i don't think so
<lumag>
We can parse it and then generate 'USB-DP-%d' connector names
<emersion>
a connector can be both Type-C and DP-MST
<lumag>
Then the base connector will have Type-C and next connector will be DP-MST
<emersion>
to not regress user-space, PATH needs to be "mst:<something>" for all DP-MST connectors
<emersion>
hm
<emersion>
i see
<lumag>
In my case I'll have DP-1 with PATH='typec:0', and DP-4 / DP-5 / DP-6 with PATH='mst:103-#'. Xorg then renames DP-4/5/6 to DP-1-1, DP-1-2, DP-1-3
<lumag>
And correspondingly DP-2 with PATH='typec:1' (or vise versa) and DP-something renamed to DP-2-1, DP-2-2, etc.
<lumag>
The only issue I foresee is SlimPort, the legacy/obsolete DP-over-micro-USB.
<emersion>
that sounds good to me, with the caveat that i don't understand things deeply enough to say for sure whether this is a good use of PATH, or an abuse
<emersion>
well this one would be completely different no?
<emersion>
i don't know if anyone cares enough to address it
<emersion>
by "completely different", i mean probably PATH with "usb:<something>"
<lumag>
emersion, yep
<lumag>
at least it sounds logical then
<emersion>
and the same would apply for other display-over-older-USB things
<lumag>
It is supported by drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c, which I hope to try on Nexus7-2013 at some point
<emersion>
like GUD
<lumag>
ok.
<lumag>
I can then scratch an RFC during the weekend and send it to dri-devel
<emersion>
nice
<emersion>
i can write the user-space
<lumag>
:-)
greenjustin has joined #dri-devel
<lumag>
mceier, yes, but the fallbacks are basic - type + index (not the object ID)
<emersion>
mceier, i don't see your message
<mceier>
lumag: yes, you can ignore me, since I donn't really know the context ;)
<pq>
emersion, PATH property for DP-MST is not persistent at all? Whee. Well, it just means more parsing, don't simply save the PATH string as-is. Replace the conn ID with a proper path.
<karolherbst>
gfxstrand: cool, will give it a try. I have a few patches around to reorder some of the lowering, because I'll need it for program variables as well. Anyway, seems to work either way now.
paulk-bis has quit [Ping timeout: 480 seconds]
<alyssa>
Do we have any common code for handling ADJACENCY in the absense of a geometry shader?
<alyssa>
other than nir_create_passthrough_gs, I guess
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Omax is now known as Guest9285
<alyssa>
hmm, gl-3.2-adj-prims passes, I wonder why the CTS doesn't
Omax has joined #dri-devel
Guest9285 has quit [Remote host closed the connection]
<dottedmag>
How is GBM_BO_USE_RENDERING really used? In libgbm DRI backend the only use of this flag is to check that GBM_BO_USE_CURSOR and GBM_BO_USE_RENDERING are not specified at the same time.
rsripada has quit [Quit: No Ping reply in 180 seconds.]
rsripada has joined #dri-devel
<alyssa>
got it. 2 bugs in nir_create_passthrough_gs,
Company has joined #dri-devel
<alyssa>
MR coming soon
<alyssa>
kusma: zmike: It looks like nir_create_passthrough_gs wants the VS/TCS but doesn't actually use it, it just uses the shader info
<alyssa>
Is there a compelling Zink reason it's done like this?
<zmike>
you'd need to ask pac85 but he's not on irc
<alyssa>
Why should the passthrough GS be tied to the shader, as opposed to just the context/screen?
<alyssa>
who is pac85?
<alyssa>
kusma wrote this code
<zmike>
antonino
<zmike>
just create a ticket
<alyssa>
Alright
<alyssa>
It looks like it would be sufficient to pass in (outputs_written, has_transform_feedback_varyings, xfb_stride, xfb_info) instead of the whole shader
<zmike>
could be
<alyssa>
in the common case where there's no GS that's just outputs_written
<zmike>
on my side there's no requirement for it being the way it is
<alyssa>
which means you can reuse passthrough GS's for unrelated VS's as long as they write the same outputs
<alyssa>
which seems.. potentially good?
<zmike>
but this is emulation code that I don't (personally) support or deal with so you'll want to ask in the ticket
<alyssa>
yeah fair enough
<alyssa>
I'm considering the incredibly dubious choice of using a passthrough GS anytime XFB is used
<alyssa>
but I digress :~P
<alyssa>
oh, hm, this might be tricky without lowered I/O though
* alyssa
may fork create_passthrough_gs for a lowered I/O-only version if this can't be fixed with derefs
<zmike>
just convert it to lowered io?
<alyssa>
oh that MR landed, nice :)
<zmike>
the only caveat, as I replied, is that variables/types do have to exist and be correct
<zmike>
which is probably not a huge ask?
<zmike>
but who knows what your needs for this are
<alyssa>
certainly I don't
<alyssa>
Hmm
<alyssa>
Now I'm wondering if it wouldn't be better to handle adjacency in the VS
<alyssa>
meh, this is a totally stupid edge case that apps won't hit, not worth the combinatorics
Duke`` has joined #dri-devel
junaid has joined #dri-devel
<DemiMarie>
pq emersion: from a security perspective, Qubes really wants physical paths determined by where a user plugged in their device, so that a malicious device cannot spoof another device.
<DemiMarie>
emersion: Qubes OS considers external peripherals, such as USB devices, to be untrusted by default (that’s why we have sys-usb). Ideally DisplayPort alt mode would be limited to trusted devices, though that is not currently implemented. For it to be possible to implement, though, the ID needs to be something a malicious device can’t spoof, as otherwise a malicious device could impersonate a trusted one.
lynxeye has quit [Quit: Leaving.]
kts has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
danilo has joined #dri-devel
danilo has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
^ then I guess we just have to wait a week or two for this issue to disappear hopefully?
rsalvaterra has joined #dri-devel
<DavidHeidelberg[m]>
zmike: KHR-GL46.layout_binding.sampler2D_layout_binding_texture_ComputeShader took down by `free(): unaligned chunk detected in tcache 2` is that something you aware?