<jenatali>
dj-death: that's one of the reasons I'm not thrilled about the idea of that approach going into common code. I don't think meson MSVC solutions can do that mixed native+cross thing
<Company>
though maybe I should check validation layers first, I might be doing something stupid
<jenatali>
That approach = using clc at compile time
<mripard>
I'd be inclined to just drop that patch since it's getting clear we're not going to have a consensus
Kwiboo has quit [Ping timeout: 480 seconds]
<sima>
mripard, aren't we just at the "people talk past each another" phase?
<sima>
or I'm just confused
<DemiMarie>
<tleydxdy> "it should be possible if you can..." <- Someone already wrote a driver but it will take a while to get native context support, if ever. Test signing is fine for this.
<sima>
also I don't see what we're gaining by dropping that patch, I guess you'd still end up with the infoframes helper setting the infoframes to support broadcast/full range on ycbcr?
kts has quit [Ping timeout: 480 seconds]
<vsyrjala>
the infoframe helpers don't handle yuv quantization range
<vsyrjala>
yuv is not a standard thing across kms atm
<sima>
don't you need to set the bits right in there?
<vsyrjala>
it's done in the drivers
<sima>
sure the encoder needs to be programmed to match too
<vsyrjala>
i mean the infoframe is set up by explicitly by each driver when transmitting yuv. the helper will not help
<sima>
oh I thought that's already in there
<alyssa>
dj-death: oh, I'm not touching RT for years lol
fab has quit [Quit: fab]
<sima>
the can't we just add a line that it's kinda up to the driver how this works with ycbcr and done?
<vsyrjala>
the problem with yuv is that we also need some way to configure the matrix, so need a new prop anyway. i think it would probably be better to roll the matrix+quantization range into that single prop so that it's easier to see what combos are actually supported
<sima>
yeah but if someone gets around to that we can do the usual uapi backwards dance fun and figure out something?
<vsyrjala>
and having a prop called "RGB..." that also magically affects YUV is a bit confusing
<mripard>
vsyrjala: the whole point of this series is for drivers not to have to prepare infoframes
Kwiboo has joined #dri-devel
<sima>
unless the idea is that vc4 is so wrong it has to be reverted
<vsyrjala>
imo vc4 is wrong. they magically extended the meaning of that prop without consulting anyone
<dj-death>
alyssa: heh, okay, then maybe I'll drop GRL before you get to that
<mripard>
sigh. sure. let's put the blame on an undocumented property on the one that used it I guess.
simondnnsn has quit [Read error: Connection reset by peer]
<sima>
yeah the property is extremely not documented
<sima>
which this patch set tries to fix
<vsyrjala>
i mean the name is literally "RGB...". if that's not enough docs I don't know what is
<sima>
and i915 kinda did ... never
simondnnsn has joined #dri-devel
kts has joined #dri-devel
<mripard>
the RGB is not a good argument. i915 is using Limited 16:235 for bpc > 8 bits, even though that doesn't make any sense
<mripard>
but somehow that was ok?
<vsyrjala>
it's at least less wrong
<vsyrjala>
didn't we also have some earlier series that tried to come up with a new standard prop for all this? what happened to that one?
<vsyrjala>
one without such terrible name/semantics
<emersion>
there are other cases where a prop enum entry with "RGB" in it is meaningless
<emersion>
"Colorspace" IIRC
<vsyrjala>
colorspace just sets up the infoframes exactly as requested. so if you tell it rgb, we send "RGB" in the infoframe
<mripard>
I guess my question is now then: we have a property that is widely used, and aside from a few historical mistakes, works for everyone
<emersion>
user-space can't know whether it's RGB or not, vsyrjala
<mripard>
*why* should we need a new one
<emersion>
so drivers now ignore the "RGB" part
<vsyrjala>
the plan was to come up with a new property. what happened to that one?
<mripard>
you're not answering
<vsyrjala>
that was a question to emersion
<sima>
mripard, btw where's the docs for the color space thing? I seem to be blind
<emersion>
vsyrjala: conflating RGB/YUV into the Colorspace prop was a bad idea to begin with
<mripard>
sima: the color space thing?
<emersion>
even with kernel feedback, there are issues
<sima>
mripard, yeah
<vsyrjala>
we need new props anyway. so i think if we just keep extending these old crap ones we are painting ourselves in the corner, and we definitely will end up with a totally unusable/confusing uapi
<emersion>
e.g. you modeset, kernel decides to switch to YUV, and then there is an intermediate state where the infoframe still signals RGB
<mripard>
sima: I'm not entirely sure what you mean :)
<vsyrjala>
yes, we all know the Colorspace props is not usable with the automagic yuv fallback. hence the plan to come up with a better prop. i though someone was working on that?
<emersion>
i don't think so
<sima>
mripard, the docs for the "Colorspace" property
<sima>
I've found them, but they helpfully don't have a list of values for that enum so was hard to find
<vsyrjala>
the enum values are a direct 1:1 mapping to HDMI/DP specs
<emersion>
sorry, i mixed things up, it's not Colorspace, it's COLOR_ENCODING
<sima>
I'd just put links there and into the docs for the broadcast stuff
<sima>
oh right
<vsyrjala>
and the exposed anum values change depending on whether it's DP or HDMI because naturally those don't agree
<emersion>
or is it?
<emersion>
well, i don't remember
<emersion>
some prop somewhere had this issue
<sima>
emersion, that's on the plane
<mripard>
sima: I'm not using it in my series, so I haven't really looked at it
<emersion>
hm, so yeah, "Colorspace" was the culprit probably, sorry for the noise
<emersion>
it has "BT2020_RGB" and "BT2020_YCC"
<emersion>
at least amdgpu ignores the _RGB/_YCC part
<emersion>
not sure what i915 does, but if it doesn't ignore the suffix, it's broken
<vsyrjala>
i915 sets up the inforframe exactly as instructed by the prop. nothing else is touched. that is all that prop is supposed to do
<sima>
mripard, oh I got confused, I thought we already had a prop to control the state->hdmi.output_format you're adding
<vsyrjala>
i think amdgpu attached other meanings to that prop, which is wrong
<mripard>
sima: no, so far it's only a set of fallbacks in the code
<mripard>
there was some work to let the userpace set it somehow, but it's not merged yet
<zamundaaa[m]>
vsyrjala: no, it's up to the driver to make it work, no matter if userspace sets RGB or YCC
<zamundaaa[m]>
Userspace literally cannot make it work otherwise
<vsyrjala>
no. that is not what that property was added for. people have corrupted it's meaning to be a mess
<emersion>
vsyrjala: introducing a prop with no correct way userspace to set it is a kernel mistake
<vsyrjala>
hence the plan to add a new property without this mess
<emersion>
now it's up to i915 to make it work with the current uAPI
<vsyrjala>
yes. we know it's crap. we need a *new* prop
<emersion>
no
<zamundaaa[m]>
A new property doesn't fix the old property being broken
<emersion>
existing compositors are using it
<vsyrjala>
there is no way to make that prop work
<emersion>
there is, amdgpu does
<vsyrjala>
and what happens when you set some xvycc/etc value in there? answer: it's just broken
<zamundaaa[m]>
You just don't expose those values if they don't make sense
<swick[m]>
I have opinions but am stuck at a meeting
<zamundaaa[m]>
Feel free to introduce something that works better, but don't break userspace because it's not a nice API
<vsyrjala>
everyone already seemed to agree to add a new uapi. and then somehow people didn't and just extended the broken mess to other compositors in the meantime?
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<zamundaaa[m]>
The new uapi is about kms offloading, not about signalling. At the HDR hackfest we agreed to just continue using HDR_OUTPUT_METADATA and Colorspace with slight changes to make them useful
* zamundaaa[m]
looks if anyone actually documented those changes
<zamundaaa[m]>
boo, they were not documented. I'll write something up later today
<pq>
mripard, FWIW, the limited range for non-8-bpc formats is also derived from the 16:235. But the YUV chroma channels do not use 16:235, no matter what bpc. They have a different range for limited. But YUV luma channel does use it.
<vsyrjala>
someone needs to then rip out all the non-sensical values from that prop, and figure out what values are actually left and how each interacts with rgb vs. yuv output. for both hdmi and dp since the values are different
<vsyrjala>
yeah, 16:235 when thought as a ratio is correct for deep color rgb as well
<pq>
vsyrjala, I think that is what amdgpu did when they added support for "Colorspace".
<pq>
at least that's where doc patches I recall seeing went
<vsyrjala>
we still have all those non-sensical values in the prop. and iirc the last discussion we had concluded that there are problems with the current values in making the automagic yuv fallback actually correct
<vsyrjala>
i think the problem was that for non-bt2020 cases there was technically no common colorspace between the rgb and yuv values
<zamundaaa[m]>
according to drm_info, amdgpu only supports Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC
<vsyrjala>
isn't opRGB the renamed adobeRGB? so that defintiely doesn't make sense
<pq>
BT2020_RGB and BT2020_YCC are equivalent, too, but preserved for backward compat
<pq>
I'm slightly surprised to see BT709_YCC and opRGB.
<JoshuaAshton>
I don't really see why we need a new prop, the old one with the fudging works fine for us on SteamOS.
<pq>
if you pretend the nonsense values are not a reflection of anything that could ever be useful, sure
<pq>
i.e. it's fine if all you care are "Default" and BT2020
<JoshuaAshton>
I think it's fine for the driver to figure out what to send depending on whether YCbCr vs RGB is selected, and I don't see why people are up in arms about it
<JoshuaAshton>
What's the usecase I am not seeing?
<any1>
JoshuaAshton: Robustness
<JoshuaAshton>
Robustness to what?
<zamundaaa[m]>
The problem is the other values where the driver can't automatically select these values
<JoshuaAshton>
Oh?
<pq>
the reasons why the nonsense values exist to begin with, which I don't know
<JoshuaAshton>
zamundaaa[m]: Which values?
heat has joined #dri-devel
<any1>
JoshuaAshton: When you have poor signal quality, YCbCr is likelier to work.
<zamundaaa[m]>
But IMO if there's an actual use case for those broken values, adding a new property when userspace actually knows and/or controls YUV vs RGB, would be the way to go, and not removing the one that's being used right now
<zamundaaa[m]>
JoshuaAshton: RGB_Wide_Gamut_Floating_Point would be one of the broken values for example
<JoshuaAshton>
This is about the vsc colorimetry infoframe not the pixel encoding format
<JoshuaAshton>
zamundaaa[m]: The legacy thing that to my knowledge nothing ever implemented in any physical display?
<JoshuaAshton>
I could definitely be wrong about that, but I have never seen it on the myriad of analysers and reference displays
<pq>
any1, "Colorspace" property does not control RGB vs. YUV at all. The problem is, most of its values are correct only for either RGB or YUV, and userspace won't know nor control which signal color model the driver picks.
<zamundaaa[m]>
I don't know which ones in that list are actually a thing in practice, just that they're nonsense
<JoshuaAshton>
Oh I totally agree that they are nonsense to be exposed at all :D
<pq>
The "Colorspace" values exist in HDMI and DP specs, but this is not a usable UAPI for setting most of them.
<JoshuaAshton>
I don't think it makes sense for userspace to set most of these anyway...
<JoshuaAshton>
Really it makes more sense to just expose eg. { "Default" "BT2020" "BT709" "DCI_P3" }, then we can actually have conversations about other values when a usecase arrives...
<JoshuaAshton>
rather than bunging random infoframe enums into drm properties in some flawed way
<JoshuaAshton>
I think we can still salvage the current property, by just deprecating the other variants completely and giving them a name like "Reserved1" or whatever
<JoshuaAshton>
Then, no driver would expose those enum values as supported, and if userspace tried to use them, it'd just get rejected because its not supported.
bmodem has joined #dri-devel
<JoshuaAshton>
That's really the only way without breaking uAPI or introducing a new prop
<JoshuaAshton>
I guess there might be userspace stuff using DP_COLORIMETRY_BT2020_YCC right now actually... nevermind, bleh
<vsyrjala>
how would DCI_P3 even work with yuv fallback?
<JoshuaAshton>
I don't think it would -- it's intended for eDP on mobile displays from what I recall
<JoshuaAshton>
Which don't ever do chroma subsampling/non-RGB pixel formats, so it was never added as it was never needed
<DemiMarie>
For KMS my biggest concern is ensuring that the kernel is secure against malicious displays.
<JoshuaAshton>
malicious displays are not a concern with any of this
<DemiMarie>
Yeah
glennk has quit [Ping timeout: 480 seconds]
<vsyrjala>
so is someone this time actually going to go and rip out most of values from those props and fully document how each reamining value interact with both inforames/msa/vsc and the actual output signal?
simondnnsn has quit [Ping timeout: 480 seconds]
<daniels>
if a display wants to display something other than what it gets fed, there are easier ways to do that than gaming colorimetry
<sima>
yeah "this is how it's actually used" docs for "Colorspace" would be great
<daniels>
^
<sima>
I was screaming quite a bit at the docs since I couldn't believe at first that was there was the actual docs and kept looking for the real thing
<vsyrjala>
does anyone recall who was working on that unified not-'Broadcast RGB' quantization range prop?
<sima>
bonus points if the common code then does stuff like limit DCI_P3 to eDP like JoshuaAshton said and stuff like that
simondnnsn has joined #dri-devel
<vsyrjala>
i can't seem to find the series in my mailbox right now
<JoshuaAshton>
vsyrjala: I think swick[m] was?
simondnnsn has quit [Read error: Connection reset by peer]
<vsyrjala>
i don't know why eDP is a factor here. eDP could use YCbCr as well
<pq>
Are you confusing not-'Broadcast RGB' with the new color pipeline design?
<vsyrjala>
pq: no. there was a proposal for a property like that quite a while back
<pq>
huh, cool
<vsyrjala>
i wanted to check if the plan there was to cover ycbcr as weell
simondnnsn has quit [Read error: Connection reset by peer]
<vsyrjala>
but i guess the whole thing fell through the cracks
<JoshuaAshton>
vsyrjala: To clarify, yes it can, but the purpose of it is mainly for Android phones etc, and those type of mobile displays only accept RGB.
simondnnsn has joined #dri-devel
<JoshuaAshton>
The check should probably only allow DCI_P3 if the display is RGB only
<JoshuaAshton>
Not eDP
<vsyrjala>
i wouldn't add anyhting that conditional into the uapi until we know it's really needed
<vsyrjala>
hence why i think wiping the slate clean would have been the right approach all along
<JoshuaAshton>
Sure, I would go as far as to say that we pull that for now even, and just keep it to { Default, 709, 2020 }
<pq>
how is 709 different from "Default"?
<JoshuaAshton>
pq: Fair point...
<JoshuaAshton>
There is no difference in the dp vsc enum for that, default is 709, but I think it makes sense to have Default separate regardless though so we don't ruin our chances of implementing stuff that is non-DP or non-HDMI down the line
<pq>
hmm... but what would be the definition of "default" then? How would you render for it?
<JoshuaAshton>
Consider that the "un colormanaged default" :b
<pq>
usually "default" is needed when drivers picked something automatically before implementing the propr, and not all drivers agreed to do the same thing.
<JoshuaAshton>
I mean... it's worth noting that even if you send 709 vsc colorimetry to most displays, you actually just get their native gamut
<JoshuaAshton>
so maybe we just don't even encode 709 and just have "Default"..?
<JoshuaAshton>
* @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
<JoshuaAshton>
* ITU-R BT.601 colorimetry format
<JoshuaAshton>
I guess you are just informing the display of the container colorspace of what you are sending -- so actually it being native gamut is just their interpretation ;b
simondnnsn has quit [Ping timeout: 480 seconds]
<pq>
"no idea", yeah, ok. Just get something out.
simondnnsn has joined #dri-devel
<pq>
funny that doc, since sRGB, BT.601 and BT.601 are all different.
<pq>
yes, I said BT.601 twice.
<vsyrjala>
because of the revisions?
<pq>
PAL vs. NTSC aka. 525 vs. 625(?) lines
<vsyrjala>
did 601 have ntsc stuff in it too?
<pq>
IIRC
<pq>
I think it just happens to match NTSC primaries & white point
<vsyrjala>
i know it originally didn't specify a bunch of things, but later revisions added them
<pq>
they share the CICP value
<pq>
H.273 is my cheatsheet nowadays
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
Haaninjo has joined #dri-devel
mripard has quit [Quit: mripard]
kzd has joined #dri-devel
simondnnsn has quit [Read error: No route to host]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
<pq>
Why wouldn't DCI_P3 work with YUV? Just pick any RGB->YUV matrix. Or is that about what hardware interface specs actually support?
<pq>
vsyrjala, IIRC it was hwentlan who went through the pains of trying to understand "Colorspace" the last time.
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<vsyrjala>
dci-p3 == rgb, according to dp and cta-861
<pq>
nothing stops anyone from taking that and converting to YUV
bolson has joined #dri-devel
<swick[m]>
so, finally had time to read the backlog
<swick[m]>
but yeah, we changed the meaning of Colorspace and HDR_OUTPUT_METADATA to be usable now
<vsyrjala>
pq: but you can't then tell the display that it's dci-p3, because to do that you have to tell it that you're transmitting rgb
<swick[m]>
doing the Colorspace selection properly simply requires use space to have control over the cable format and we don't have that
<swick[m]>
nor was there an easy way to get there
<pq>
vsyrjala, ok, so it's about signalling specs.
<swick[m]>
but user space should get control over the cable format, and there should be properties that control only the infoframe and not the color pipeline etc
Company has joined #dri-devel
<swick[m]>
and we also should start versioning the API or something so we can throw away a bunch of properties and not have to worry about their interactions
<swick[m]>
versioning, or caps, I don't really care, but we need this for the color pipeline api anyway
<vsyrjala>
just defining a new prop with a _different_ name, and ripping out the old one should be all the versioning you need
<swick[m]>
the ripping out the old one is the issue
<vsyrjala>
meh
<zamundaaa[m]>
vsyrjala: compositors are using the old one right now. Removing the property is a uAPI break
<swick[m]>
hence, versioning or caps
<swick[m]>
and we kind of should probably start doing that rather sooner than later
<vsyrjala>
zamundaaa[m]: so is changing the meaning of the uapi randomly
<vsyrjala>
at least when you rip it out you will know whether anything works or not
<zamundaaa[m]>
It's not a uAPI break to change something broken to work
<zamundaaa[m]>
Noone is relying on the property sometimes not doing the expected thing, depending on variables the compositor has no control over
kzd has joined #dri-devel
<daniels>
I believe Kodi uses the old one and very much expects that behaviour to not change, even if it is objectively bad
simondnnsn has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Kodi too is not relying on BT2020_YCC to not work with rgb signalling
<swick[m]>
how can it? you select a Colorspace that's depending on the pixel format but you get arbitrary pixel formats
<swick[m]>
indeed
<vsyrjala>
zamundaaa[m]: i915 implements the original uapi. so if someone now runs one of those compositors on i915 it will not work
<swick[m]>
it didn't work before
<swick[m]>
that's the entire point
<swick[m]>
there is literally no way anyone uses the Colorspace prop on i915 and it works
<vsyrjala>
it did because the compositor wouldn't try to use those properties
<swick[m]>
if a compositor uses them or not is however not in control of other drivers
<swick[m]>
sorry, but this is just not a useful conversation to have
<zamundaaa[m]>
If you really insist on not fixing the property, then removing it entirely from i915 is indeed the right thing to do
<vsyrjala>
it can't be fixed until someone redefines it property
<vsyrjala>
*properly
<swick[m]>
it is defined properly now
<swick[m]>
it's not great, but it works
<vsyrjala>
no. it has a kinds of values that can never work
<swick[m]>
and no one has to expose them
<vsyrjala>
and no one defined what values are supposed to be left, and how they work
<swick[m]>
we kind of did, but failed at documenting it, so that's fair
<zamundaaa[m]>
The documentation definitely needs updating to reflect userspace expectations, and I'll volunteer to do that
<zamundaaa[m]>
But i915 either needs fixing, or you need to at the very least stop advertising the property at all
<vsyrjala>
i can "fix" it once someone comes up with a solid idea what it should look like.
<zamundaaa[m]>
In terms of what's actually relevant for userspace in practice, just select the correct BT2020 variant, no matter if userspace sets BT2020_YCC or BT2020_RGB
<vsyrjala>
bt2020 is the easy part. it's the rest that's a huge mess
<zamundaaa[m]>
Indeed, but the rest also isn't actually used by anyone
<vsyrjala>
well, supposedly there is at least one value outside those two that has to work in a consistnet way
<zamundaaa[m]>
That would be "Default", which I think doesn't need fixing
JuanDaugherty has joined #dri-devel
<vsyrjala>
it needs to be defined what colorimetry we signal in each infoframe/msa/vsc case, and what we are supposed to transmit
simondnnsn has joined #dri-devel
fab has joined #dri-devel
<vsyrjala>
in the future i hope no one will again make backwards incompatible changes to an existing property. if we had defined a new property with the new semantics then i915 would not have gotten broken by compositors starting to use those new semantics
konstantin_ has joined #dri-devel
konstantin is now known as Guest2202
konstantin_ is now known as konstantin
<emersion>
all we made is make an existing property more sensible
<emersion>
the cost of introducing a new prop is too high just to fix this
<swick[m]>
the problem is that adding a new one would also have been no great because it would still rely on the kernel to figure out the actual infoframe to send
<vsyrjala>
we have literally ended up doing all the work you would have to do for a new prop. +500% more arguing
<swick[m]>
so we'd have to add one more once we give user space control over the cable format and exclusive control over the color pipeline
<zamundaaa[m]>
FWIW I think a better way to do this could've been to introduce a new enum value, "BT2020", without RGB or YCC
<zamundaaa[m]>
But it's too late for that now
Guest2202 has quit [Ping timeout: 480 seconds]
<swick[m]>
ah true
* emersion
shrugs
JuanDaugherty has quit []
<emersion>
a new enum value would be new uAPI, which means new IGT tests and all of the bikeshedding
Duke`` has joined #dri-devel
<vsyrjala>
there are igt tests for this modified behaviour?
<emersion>
this vs. just making things work when they were nonsensical before
<emersion>
if there are any IGT tests, they'd be broken if the driver picks YUV either way
<emersion>
ie, flaky
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<emersion>
anyways, i'll go do other stuff now, i have nothing else to add, and still think it was a perfectly reasonable choice
<vsyrjala>
what i'd want to see is "these S are the exactly set of enum values that you can use, they mean exactly X when transmitting RGB, and exactly Y when transmitting YCbCr"
<vsyrjala>
+ make the property registration filter out/reject all the other values
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<zamundaaa[m]>
I don't think writing such a table is really necessary. The rule for when to use which is quite straight forward
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
<Company>
alyssa: I wrote a new renderer for GTK, and it's apparently a *lot* slower specifically on Asahi - any idea what could cause specifically asahi to be slow?
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
simondnnsn has joined #dri-devel
konstantin_ has joined #dri-devel
konstantin is now known as Guest2211
konstantin_ is now known as konstantin
simondnnsn has quit [Ping timeout: 480 seconds]
Guest2211 has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
molinari has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: No route to host]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
simondnnsn has joined #dri-devel
florida has joined #dri-devel
florida has quit []
Duke`` has quit []
Duke`` has joined #dri-devel
frankbinns1 is now known as frankbinns
tomba_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
tursulin has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
jsa has joined #dri-devel
fab has quit [Quit: fab]
junaid has quit [Remote host closed the connection]
iive has joined #dri-devel
<DemiMarie>
Company: usable = “users will be able to get work done and Qubes OS doesn’t get a ton of bug reports”
sarthakbhatt has joined #dri-devel
frankbinns1 has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
sima is now known as Guest2224
sima has joined #dri-devel
<Company>
DemiMarie: the problem you will ultimately run into is that GTK is going to be modern GL/Vulkan, so you will need to either use GPUs or make sure the software renderers are capable enough
simondnnsn has quit [Read error: Connection reset by peer]
<Company>
but nobody works on optimizing those things, so I don't think it's a high priority
simondnnsn has joined #dri-devel
<Company>
note that I'm not harping on Qubes in particular here, there's a few different groups that claim they want these things
<Company>
there's random people who run age old computers for whatever reason
<Company>
and there's the kiosk use case
<Company>
which is usually just a thin client connecting to some cloud thing
simondnnsn has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
KungFuJesus has joined #dri-devel
<KungFuJesus>
Just curious, does v3d have a chance of getting the DualSrcBlend & TesselationShader features in Vulkan?
gouchi has quit [Remote host closed the connection]
<KungFuJesus>
i.e. is the hardware capable of it, or are all of the hardware capabilities features for vulkan already exposed?
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
mbrost has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
vliaskov has quit [Remote host closed the connection]
pitust has quit [Ping timeout: 480 seconds]
rpigott has quit [Ping timeout: 480 seconds]
kuruczgy has quit [Ping timeout: 480 seconds]
pitust has joined #dri-devel
rpigott has joined #dri-devel
kennylevinsen has quit [Ping timeout: 480 seconds]
mainiomano has quit [Ping timeout: 480 seconds]
cmarcelo has quit [Ping timeout: 480 seconds]
cmarcelo has joined #dri-devel
sumoon has quit [Ping timeout: 480 seconds]
mainiomano has joined #dri-devel
sumoon has joined #dri-devel
kennylevinsen has joined #dri-devel
kuruczgy has joined #dri-devel
mbrost has quit [Remote host closed the connection]
ifreund has quit [Ping timeout: 480 seconds]
kchibisov has quit [Ping timeout: 480 seconds]
ifreund has joined #dri-devel
kchibisov has joined #dri-devel
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
kuruczgy has quit [Ping timeout: 480 seconds]
ella-0 has quit [Ping timeout: 480 seconds]
kchibisov has quit [Ping timeout: 480 seconds]
ifreund has quit [Ping timeout: 480 seconds]
kennylevinsen has quit [Ping timeout: 480 seconds]
mainiomano has quit [Ping timeout: 480 seconds]
rosefromthedead has quit [Ping timeout: 480 seconds]
sumoon has quit [Ping timeout: 480 seconds]
<alyssa>
KungFuJesus: dual src, absolutely yes
<alyssa>
tess is... complicated
<KungFuJesus>
of course, with a 16k page kernel, the vulkan driver spits a hung kernel stack trace and basically hangs the system. With a 4k page kernel, it crashes X and Wayland but the system kind of survives
<KungFuJesus>
not entirely sure what to make of that, yet