ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<zmike> I never disabled for zink
<zmike> crashes just make my users stronger
<zmike> user*
<kisak> zmike: that didn't work out too well last time https://www.youtube.com/watch?v=mYSSmZVYTkE (movie clip)
<Sachiel> safety critical zink when?
<HdkR> OpenGL through Vulkan SC
<zmike> I imagine it more like https://youtu.be/wuTcctu_DfM?t=32
<alyssa> Sachiel: anglesc? :p
<Sachiel> alyssa: rounded-angle
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
<alyssa> do we have any test coverage for clip distance enable masks?
<alyssa> the desktop gl kind
* zmike handwaves at piglit
<alyssa> do we have piglits for it though
<alyssa> like that would fail if you didn't respect the mask
* zmike handwaves
<alyssa> helpful
<alyssa> thanks
<zmike> there's a lot of clipdist testing
<zmike> glcts gtf has a bunch too
<alyssa> gtf oh
<alyssa> :p
<zmike> 😬
<alyssa> i love how extensivelt documented NIR_COMPACT_ARRAYS is ...
<gfxstrand> Oh, clipdist...
iive has quit [Quit: They came for me...]
<alyssa> why did we put that in vulkan again
rmckeever has joined #dri-devel
ppascher has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
a-865 has joined #dri-devel
Ryback_ has joined #dri-devel
<alyssa> meh, this is easier than making lower_clip_fs work with lowered I/O
<alyssa> and with this + late lower_blend + late lower_tex_replace, I can finally preprocess at CSO create time
<alyssa> well
<alyssa> "finally" as if I haven't been shipping that downstream for months :p
<HdkR> \o/
<alyssa> i still can't tell how any of this is supposed to work
<alyssa> what does this CAP do?!
<alyssa> Seemingly spirv-to-nir always produces clip_dist0
<alyssa> with compact=true
ngcortes_ has joined #dri-devel
<alyssa> and then the vk runtime calls nir_lower_clip_cull_distance_arrays which again gets us the compact thing
<alyssa> so... seemingly CLIP_DIST1 can't ever happen with vulkan, or with gl if NIR_COMPACT_ARRAYS is set
<alyssa> so... why do ir3/zink/etc handle it..
<zmike> can get some weird things happening when xfb is involved there
<jenatali> alyssa: With clip + cull, you can get a second var with location of clip1, or a fractional loc within clip0/1
ngcortes has quit [Ping timeout: 480 seconds]
<mareko> alyssa: yes
ngcortes__ has joined #dri-devel
ngcortes_ has quit [Read error: Connection reset by peer]
rmckeever_ has joined #dri-devel
<alyssa> jenatali: hm. I don't really know anything about cull distances.
<jenatali> IIRC clip distance can partially clip primitives, where cull distances only apply if all vertices fail the distance test
<alyssa> tbh tempted to say this is "good enough" and revisit later if needed..
<alyssa> "fs-clip-distance-interpolated.shader_test" does seem unhappy though
<jenatali> There's a separate info bit to indicate how many of them are supposed to be clip
<alyssa> i see
<alyssa> well, I don't have cull distances in my hardware
<alyssa> and don't advertise ARB_cull_distance, so
<alyssa> GL4.5 grumble
rmckeever has quit [Ping timeout: 480 seconds]
<alyssa> why we did we make this core
<alyssa> Is this even possible to lower...
<alyssa> not good.
<mareko> because directx
<alyssa> evidently
<mareko> it's possible to lower on AMD or if you have GS
<alyssa> hm, yeah, I see how you would do it with a GS
ngcortes__ has quit []
<alyssa> ok, yeah, this can be lowered with excessive cost. meh
<alyssa> or... do we actually need to cull in the geometry processing stage?
<alyssa> could we instead just discard every fragment in the primitive?
<alyssa> obviously that's not efficient but it's better than what the GS-lite approach would need
<alyssa> i'm suspicious that NV_fragment_shader_barycentric might be possible on AGX, unsure
<HdkR> Everyone loves exposed barycentrics. Unless they aren't stable :)
<mareko> using discard disables early Z
co1umbarius has joined #dri-devel
<jenatali> Unless you force enable it
<alyssa> mareko: least of my worries right now
columbarius has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
<alyssa> hmmm I wonder how my hardware interpolates NaN varyings
angerctl is now known as Namarrgon
<alyssa> seemingly the whole triangle lights up if there's just one NaN varying and the rest 0
* alyssa isn't sure what's happening
<alyssa> piglit: error: Failed to create waffle_context for OpenGL ES 4.0 Context
<alyssa> ummm
<alyssa> inexplicably AGX has decided that the interpolation of NaN, 0, and 0 is 0x7f7fffff
<alyssa> which is extremely large but finite
<alyssa> whatever, I can work with this
<alyssa> woahh infinity is different
<alyssa> I assume I'm hitting all kinds of hardware undefined behaviour lol
<alyssa> ahahaha no
bbrezill1 has joined #dri-devel
<alyssa> 0x7f7fffff is the maximum representible *finite* single precision float
<alyssa> so it's carrying the NaN through and clamping to finite at the end, seemingly
<alyssa> I can work with this!!
<jenatali> O.o
<gfxstrand> tarceri_: I'll try to get back to copy-prop-vars on Monday. I've had a lot going on this week.
kts has joined #dri-devel
<alyssa> jenatali: No this is great
<alyssa> jenatali: So here's what I'm going to do :3
<gfxstrand> alyssa: What vile magic are you attempting?
<alyssa> gfxstrand: gl_CullDistance lowering
<alyssa> on hardware with no cull distances, no geometry shaders, and no NV_fragment_shader_barycentric
<gfxstrand> Oh
<gfxstrand> This is gonna be entertaining
<alyssa> gfxstrand: faith you're gonna love this
<gfxstrand> :D
<alyssa> so, the relevant spec text is
<alyssa> > Primitives whose vertices all have a negative clip distance for plane i will be discarded.
<alyssa> Culling happens after XFB (I think) so this can be validly implemented by discarding every pixel inside the primitive
bbrezillon has quit [Ping timeout: 480 seconds]
<alyssa> So conceptually we just need to insert at the beginning of the fragment shader
<alyssa> if (cull_distance[0] < 0 && cull_distance[1] < 0 && cull_distance[2] < 0) discard;
<alyssa> The problem is that we don't have access to the cull distance varying at each vertex, we only have it at the provoking vertex (if flat) or we have the interpolation of them (if smooth)
<alyssa> Maybe interpolation is ok? Like, if the interpolated value is negative, that implies all 3 distances are negative so we discard, right?
<alyssa> True, but..
<alyssa> the converse fails
tarceri_ has quit []
<alyssa> er
<alyssa> no that's the thing that fails
<alyssa> The converse is true, that's false
tarceri has joined #dri-devel
<alyssa> If the distances are (-1, -1, 1) then any pixel along the edge between -1 and -1 will have an interpolated value of -1 regardless of how positive the 1 is
<alyssa> So we're out of luck.... or are we?
<alyssa> Recall how varying interpolation works mathemtically, it's something of the form
<tarceri> gfxstrand: sure no problem. I'm just about to push the changes you suggested. Thanks!
<alyssa> (value_0 * coefficient_0) + (value_1 * coefficient_1) + (value_2 * coefficient_2)
<alyssa> now, if that interpolation happens with IEEE 754 arithmetic, a very interesting property emerges
<alyssa> if *any* vertex's value is NaN, then the interpolated value *everywhere on the primitive* is NaN
<alyssa> even if we have (0, 0, NaN), the values along the shared 0/0 edge will *still* be NaN because NaN * 0 = NaN and NaN + 0 = NaN and the NaN poisons the whole primitive
<alyssa> but that's exactly what we needed!
<alyssa> With that property, we now have a way to check for any pixel whether a boolean condition is true for any vertex
<alyssa> or by De Morgan's, whether a boolean condition is true for all vertices
<alyssa> So here's what we're gonna do
<alyssa> In the vertex shader, `gl_CullDistance = dist` is going to become instead `lowered_value = (dist >= 0.0) ? NaN : 0.0`
<alyssa> with `out highp float lowered_value`
<alyssa> then in the fragment shader, we're going to insert a prolog
<alyssa> `if (lowered_value == 0.0) discard;`
<alyssa> To check that this works: if all cull distances are negative, then all lowered values will be 0.0 so every pixel in the primitive will interpolate 0.0 so every pixel will in the primitive will be discarded
<alyssa> otherwise, some lowered value will be NaN so every pixel in the primitive will interpolate NaN so no pixel will be discard
<alyssa> One wrinkle... at least on the M1, varying interpolation *doesn't* happen with IEEE 754 arithmetic
<gfxstrand> I wonder if you could short-cut the discard bit and just do if (gl_cullDist < 0) gl_FragCoord.x = NaN
<gfxstrand> Or .w or something
<alyssa> in the VS or the FS?
<gfxstrand> in the VS
<alyssa> no, that won't work
<gfxstrand> And hope the clipper freaks and tosses the whole thing
<alyssa> because it's an AND not an OR
<gfxstrand> Oh
<gfxstrand> Well that's dumb
<gfxstrand> But ok
<alyssa> if you're drawing triangle strips or something, you can have a vertex whose negative value contributes to culling in one primitive but not the other
<gfxstrand> sure
<gfxstrand> Makes sense, I guess
<alyssa> so no pure VS lowering is possible unless you unroll everything
<gfxstrand> :(
<alyssa> 03:19 < gfxstrand> And hope the clipper freaks
<alyssa> it's too busy freaking from when I ran t-rex this morning
<gfxstrand> Yeah, TRex is mean to clippers
lemonzest has quit [Quit: WeeChat 3.6]
<alyssa> there are some annoying details about making that scheme work with separate shaders
<alyssa> (for GL it doesn't matter. for Vulkan monolithic it doesn't either. Might screw over GPL fast link.)
<gfxstrand> Eh, it can be made to work, I think.
alanc has quit [Remote host closed the connection]
<gfxstrand> Just need to push a mask into the shader or something
alanc has joined #dri-devel
<alyssa> more thinking about how to link the internal extra varyings
<alyssa> definitely can be made to work, just unsure whether it would slow down everything separable to be conservative about it
lemonzest has joined #dri-devel
Zopolis4 has joined #dri-devel
aravind has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<alyssa> meanwhile on gl_ClipDistance
<alyssa> I need nir_lower_clip_disable, but that is in itself an early pass that I need to do a late version of for this
<alyssa> ....and I have decent evidence that AGX can't interpolate gl_ClipDistance so the varyings need to be duplicated anyway
<alyssa> so maybe I want to punt on this and figure out if I can make lower_clip_fs happen late and revisit this come Vulkan
heat has quit [Ping timeout: 480 seconds]
dliviu has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
srslypascal is now known as Guest3343
srslypascal has joined #dri-devel
dliviu has joined #dri-devel
Guest3343 has quit [Ping timeout: 480 seconds]
pallavim has quit [Ping timeout: 480 seconds]
nashpa has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
XiaoYaoBing[m] has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
kzd has quit [Quit: kzd]
danvet has joined #dri-devel
nehsou^ has joined #dri-devel
nchery is now known as Guest3355
nchery has joined #dri-devel
<RAOF> Hm. Would anyone object to me making it possible to add drirc.d directories from an environment variable?
<RAOF> It would be convenient, and it looks like it might allow removing some cludges added to support tests?
jewins has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
Guest3355 has quit [Ping timeout: 480 seconds]
Mangix has joined #dri-devel
fab has joined #dri-devel
bgs has quit [Remote host closed the connection]
<mupuf> RAOF: no objections from me, provided we find a way to make it unsurprising. Were you thinking about purely adding, or overriding the default one?
<RAOF> 🤷‍♀️
<RAOF> Purely adding would be sufficient for my purpose, but if replacing was preferred I could certainly do that.
<mupuf> I would go for whichever would be least surprising... which may be the override one or may not
<mupuf> were you planning on a coma-separated list of directories?
<RAOF> Following the vulkan loader, something like a colon-delimited MESA_ADD_DRIRC_PATH would be my first thought.
<mupuf> well, at least, it wouldn't be surprising :)
<RAOF> I guess the most surprising behaviour would be how combining multiple settings would be handled.
<RAOF> Although that's not a novel problem, since drirc.d already aggregates multiple configs.
mbrost has quit []
tlwoerner has quit [Remote host closed the connection]
rmckeever_ has quit [Remote host closed the connection]
agd5f has quit [Remote host closed the connection]
rmckeever_ has joined #dri-devel
agd5f has joined #dri-devel
tlwoerner has joined #dri-devel
Company has quit [Quit: Leaving]
alanc has quit [Remote host closed the connection]
nchery is now known as Guest3359
nchery has joined #dri-devel
alanc has joined #dri-devel
Guest3359 has quit [Ping timeout: 480 seconds]
rmckeever_ has quit []
dliviu has joined #dri-devel
sarnex_ has joined #dri-devel
nashpa has quit [Ping timeout: 480 seconds]
sarnex has quit [Ping timeout: 480 seconds]
nora has joined #dri-devel
sarnex_ has quit [Ping timeout: 480 seconds]
nora has quit []
pochu has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jkrzyszt has joined #dri-devel
mvlad has joined #dri-devel
ZenWalker has joined #dri-devel
tursulin has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
dviola has left #dri-devel [#dri-devel]
dviola has joined #dri-devel
ice9 has joined #dri-devel
arya has joined #dri-devel
sarnex has joined #dri-devel
sergi has left #dri-devel [#dri-devel]
rasterman has joined #dri-devel
fab has quit [Quit: fab]
djbw has quit [Read error: Connection reset by peer]
lynxeye has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
tzimmermann has joined #dri-devel
fab has joined #dri-devel
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
flibit has joined #dri-devel
flibitijibibo has quit [Ping timeout: 480 seconds]
flibit has quit [Read error: No route to host]
flibit has joined #dri-devel
arya has quit [Remote host closed the connection]
MajorBiscuit has joined #dri-devel
jluthra_ has quit [Remote host closed the connection]
jluthra_ has joined #dri-devel
Thymo has quit [Quit: ZNC - http://znc.in]
Thymo has joined #dri-devel
pcercuei has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
nirya has quit [Quit: The Lounge - https://thelounge.chat]
karolherbst has quit [Quit: Konversation terminated!]
fab has quit [Quit: fab]
fab has joined #dri-devel
Haaninjo has joined #dri-devel
devilhorns has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
X512 has joined #dri-devel
<X512> Is it possible to link libnir as shared library?
<tomeu> X512: it could be possible, but if you can extend on your use case, maybe somebody can give some opinions on whether that would be a good idea
<X512> It looks wasteful to duplicate libnir to each driver.
<tomeu> ah, drivers should be all together in a single .so
<tomeu> so no waste
<X512> Not for Gallium and Vulkan drivers.
<lynxeye> X512: not sure about vulkan, but gallium drivers are megadrivers, where all the drivers are linked into a single .so and the different names are just hardlinks
<danvet> mairacanal, for the rust bindings also chat with lina
<danvet> even right lina, yay
<X512> Rust bindings for internal Mesa API (Gallium etc.)?
<X512> Internal API seems often change.
devilhorns has quit []
<MrCooper> lynxeye: I think X512's point was that libnir is still duplicated between the Gallium mega-driver and Vulkan drivers at least
vliaskov has joined #dri-devel
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<melissawen> Is there any dependency between degamma and ctm atomic color properties on the DRM side? I mean, if the driver doesn't advertise degamma, it can still advertise CTM and gamma properties independently, right?
bgs has joined #dri-devel
<mairacanal> danvet, I was checking lina 's DRM bindings which are looking pretty neat btw, but I currently I'm thinking mostly on the dma-buf bindings as they are a crucial part of vgem
Zopolis4 has quit []
fab has quit [Quit: fab]
camus has quit []
<emersion> melissawen: AFAIK yes
<emersion> would be the same as DEGAMMA = null (zero object ID)
pochu has quit [Ping timeout: 480 seconds]
<melissawen> emersion, thanks for confirming. I've also double-checked with drm_info that the property keeps there, so I suspect there is a dependency between these properties in the userspace case.
<emersion> you mean some user-space expects these two to be supported together, or not at all?
<emersion> sounds like a user-space bug indeed
kts has quit [Quit: Leaving]
<melissawen> yeah, I suspect the userspace expects degamma support to advertise CTM, since I don't find any dependency on the kernel side.
konstantin has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
mbrost has joined #dri-devel
fxkamd has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
Company has joined #dri-devel
pallavim has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
LordKalma has left #dri-devel [Server has probably crashed]
pallavim has quit [Read error: Connection reset by peer]
kzd has joined #dri-devel
kts has joined #dri-devel
mbrost_ has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
ice9 has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Peuc has quit [Ping timeout: 480 seconds]
nehsou^ has quit [Remote host closed the connection]
bbrezill1 has quit []
Duke`` has joined #dri-devel
bbrezillon has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.6]
mbrost_ has quit [Ping timeout: 480 seconds]
Peuc has joined #dri-devel
gouchi has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> off by one in user-clip-all-planes hmm
mbrost_ has joined #dri-devel
<alyssa> maybe buggy test, it's failing on a lot of drivers
<alyssa> including radeonsi, the reference driver :p
ahajda__ has joined #dri-devel
<alyssa> freedreno-a420-fails.txt says
<alyssa> # The clipped polygon is off-by-one pixel from the directly drawn one
<alyssa> spec@!opengl 1.0@gl-1.0-user-clip-all-planes,Fail
<alyssa> which is what I'm seeing too
<alyssa> wonder if it's a test bug with float math or something, idk
<jenatali> I think we pass it
<alyssa> yeah, it passes with hw clip distance interpolation, just not nir_lower_clip_fs
nchery has joined #dri-devel
djbw has joined #dri-devel
jewins has joined #dri-devel
X512 has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
Zopolis4 has joined #dri-devel
Daaanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
kts has quit [Quit: Leaving]
apinheiro has joined #dri-devel
flibit has quit []
ahajda__ has quit []
ahajda__ has joined #dri-devel
Daanct12 has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost__ has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<danvet> mairacanal, I also wonder whether we should look into the drm_exec stuff that's floating around
<danvet> otoh vgem doesn't really need that
<danvet> for dma-buf bindings there's also the question of whether we need ww_mutex bindings first, or just wrap that all as a dma-buf implementation detail
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
<mairacanal> danvet, afaik we need the ww_mutex bindings first to make the safe abstraction for dma-buf, just like semaphores, rw_semaphore and other sync objects
junaid has joined #dri-devel
<danvet> mairacanal, btw are you in the rust-for-linux zulip, or need an invite?
<danvet> I quickly discussed the ww_mutex binding stuff with the rust folks this week, if you want I think would be good if you also join
<danvet> there's also some sync meeting on gpu rust upstreaming in 2 weeks again
ngcortes has joined #dri-devel
<mairacanal> danvet, yeah, I'm in zulip, I will try to take a look at the ww_mutex discussion. do you remember in which stream happened this discussion?
<DemiMarie> Any plans to deal with the "sleeping in atomic context causes UaF" unsoundness?
<DemiMarie> alyssa: mind if I DM you?
tzimmermann has quit [Quit: Leaving]
<alyssa> DemiMarie: about?
<alyssa> also, do I know you?
<alyssa> irc logs indicate yes
<DemiMarie> GuC stuff
<alyssa> I don't work on that hardware
<alyssa> try #intel-gfx
<danvet> DemiMarie, what's that atomic uaf unsoundness thing?
<DemiMarie> We’ve talked about graphics stuff before
<danvet> also no idea what uaf means and urban dict is decidely less useful
<airlied> use after free
<danvet> ah
<danvet> I guess I'm very firmly in w/e mode
junaid has quit [Ping timeout: 480 seconds]
<alyssa> DemiMarie: anyway, I don't know anything about GuC except what's been discussed in here, and I don't work on Intel hardware or (usually) the kernel at all, so I don't think I have much to say, sorry! :)
* alyssa is glad she's not touching that :-p
<alyssa> ---
<alyssa> I added some milestones for tracking MR's through the review/merge process
<alyssa> and tagged my own MR's
<zmike> is one of them Sisyphus
<alyssa> I'm not sure how well this is going to work but I figure it's a very low cost thing to try, and I've seen it for a few other projects I think
<DemiMarie> danvet: I believe that on CONFIG_PREEMPT=n, scheduling in a RCU read-side critical section will cause the critical section to end too soon.
<alyssa> and it makes it really easy for reviewers to check what they have to review
<alyssa> e.g. panfrost review backlog -- https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&state=opened&label_name[]=panfrost&milestone_title=Needs%20review
<alyssa> asahi review backlog -- https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests?scope=all&state=opened&label_name[]=asahi&milestone_title=Needs%20review
<DemiMarie> alyssa: I meant the “I don’t and you shouldn't” about the GuC firmware.
<alyssa> Hmm?
<HdkR> alyssa: Nice!
<DemiMarie> alyssa: regarding the security of that firmware against malicious inputs
<alyssa> oh
<alyssa> right. again I don't know anything, I'm just a loud rando :-p
<HdkR> Big same
jewins has quit [Remote host closed the connection]
clever_ has joined #dri-devel
clever has quit [Ping timeout: 480 seconds]
clever_ is now known as clever
<alyssa> airlied: anholt: what's the rules for landing draft UAPIs into Mesa (behind a build flag), subject to change and before they've landed in stable form in mainline?
<alyssa> I thought that was a huge no-no (and have been suffering through the rebases as a consequence) but danvet said I should ping you two about it
<danvet> probably needs something really scary like do-not-enable-unless-you-are-hacking-on-axg-drivers
<alyssa> i'm good with scary if it means an end to rebase fail
<danvet> but I think we've done that a few times in different places now
<alyssa> s/fail/pain
<airlied> i think we did it for vc4, i worry a bit with asahi though
<airlied> since there seems to be a bit of distro competition around apple hw
<airlied> if a distro is going to turnthe flag on, then i dont want it in mesa
<airlied> because when the mainline diverges, we will end up owning a can of worms, and Linus
<alyssa> airlied: Yeah, that's very fair
<alyssa> manjaro definitely would flip the flag...
<anarsoul> but does Linus run Manjaro? :)
<alyssa> ;p
<airlied> and their users will cry loudly if a new kernel breaks their desktop
<alyssa> unfortunately Linus does run Asahi Linux ....
<anarsoul> alyssa: why not to add ioctl to query uapi version?
macromorgan is now known as Guest3425
macromorgan has joined #dri-devel
Guest3425 has quit [Read error: Connection reset by peer]
alyssa has left #dri-devel [#dri-devel]
<airlied> why not create a stable api :-p
<anarsoul> airlied: for an REd driver?
<airlied> at some point you have to trust you understand enough to build on
<danvet> aren't the non-re'ed driver uapi's in the minority?
apinheiro has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Zopolis4 has quit []
danvet has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
jfalempe has quit [Quit: Leaving]
apinheiro has joined #dri-devel
gawin has joined #dri-devel
<gawin> airlied: iirc crocus is doing internally fallback for d16, maybe it would be better to not advertise d16 at all? (gallium nine fails into weird codepath, and Axel suggested avoiding it if possible)
bgs has quit [Remote host closed the connection]
<gawin> I mean d16 as real d16, but overridden later
jkrzyszt has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
ahajda__ has quit []
mattrope has quit [Remote host closed the connection]
mattrope has joined #dri-devel
heat has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
apinheiro has quit [Quit: Leaving]
jhli has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]