ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
krumelmonster has quit [Ping timeout: 480 seconds]
krumelmonster has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
flynnjiang has joined #dri-devel
yuq825 has joined #dri-devel
yyds has joined #dri-devel
<calebccff> lumag: did some more digging into my bug, disabling fbdev emulation results in the display working first try when my DE starts, otherwise it only works after pressing thepower button twice to turn the display off/on, this is on a OnePlus 6 running 6.7-rc2
<calebccff> so it seems to be a framebuffer specific issue
<calebccff> i forgot about this revert I was carrying before, the patch "drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset" resulted in the panel prepare function never being called on my devices
<calebccff> but since 6.7 this is no longer the case, instead prepare is called but DSI commands all fail, so they have to be moved to enable instead
* calebccff doesn't know enough about DRM to debug this
kts has joined #dri-devel
kzd has quit [Quit: kzd]
Daanct12 has joined #dri-devel
luben has joined #dri-devel
mripard has quit [Ping timeout: 480 seconds]
mripard has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
luben has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
bmodem has joined #dri-devel
flynnjiang1 has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
cdsloif^ has joined #dri-devel
aravind has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
phire_ has joined #dri-devel
phire is now known as Guest7668
yuq825 has quit [Read error: Connection reset by peer]
phire_ is now known as phire
Guest7668 has quit [Ping timeout: 480 seconds]
Sachiel has quit [Quit: WeeChat 3.8]
Sachiel has joined #dri-devel
crabbedhaloablut has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.1.1]
aravind has quit [Read error: Connection reset by peer]
Company has quit [Quit: Leaving]
lemonzest has joined #dri-devel
flynnjiang has joined #dri-devel
flynnjiang1 has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
rz_ has quit [Remote host closed the connection]
rz has joined #dri-devel
itoral has joined #dri-devel
yuq825 has joined #dri-devel
tzimmermann has joined #dri-devel
babyfaceelder has joined #dri-devel
babyfaceelder was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
kts has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
flynnjiang1 has joined #dri-devel
<pinchartl> lumag: I'm afraid I don't have a good solution to propose for that problem :-(
flynnjiang1 has quit []
JohnnyonFlame has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
fab has quit [Quit: fab]
flynnjiang has joined #dri-devel
jsa has joined #dri-devel
fab has joined #dri-devel
frieder has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<lumag> pinchartl, any issues with the proposed patchset? At least we move all the drm code back to drivers/gpu/drm
<pinchartl> lumag: I'm not a big fan of it as I still feel there's something we should do better. but as I don't have a better solution to propose, I have no objection
<lumag> pinchartl, I see.
<pinchartl> so, please go ahead, you can merge the series :-)
<lumag> pinchartl, r-b?
<lumag> I must admit, I also didn't like the idea of bridge chains, however all the alternatives seem to be worse than that.
sgruszka has joined #dri-devel
<pinchartl> has any other bridge maintainer reviewed and acked the series ?
<pinchartl> or are you targetting me because I made the mistake of reviewing an earlier version ? :-)
jlawryno has joined #dri-devel
Ahuj has joined #dri-devel
rz has quit [Remote host closed the connection]
rz has joined #dri-devel
tursulin has joined #dri-devel
<jani> mripard: mlankhorst: tzimmermann: sima: acks or thoughts on this one: https://lore.kernel.org/r/87msv8o8b6.fsf@intel.com
<lumag> pinchartl, because of that :-)
<lumag> Otherwise I can probably ping narmstrong
<lumag> for drm/bridge part of the series
<pinchartl> I knew it. I shouldn't review patches, it's a trap :-)
<narmstrong> lumag: sure, I was waiting for another feedback, since pinchartl doesn't object, I'll ack it and merge it, it claealy less worse than today's solution
<lumag> narmstrong, let me ping Greg first.
<lumag> We have acks to merge all the patches in one batch except the last one.
<narmstrong> lumag: I thought he already acked to funnel the usb patches in the drm tree
<lumag> narmstrong, the first one, not the second one.
<narmstrong> oh ok
lynxeye has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
pcercuei has joined #dri-devel
jlawryno has quit [Quit: Leaving]
maxzor has joined #dri-devel
hansg has joined #dri-devel
mvlad has joined #dri-devel
<sima> jani, yeah I think drm-intel-next pr and then backmerge would be good, since we already have some other dp conflicts already
<sima> meaning acked-by: me for landing and then immediate pr, assuming mripard is fine with that too since means a backmerge into drm-misc-next
<sima> and since drm-next is open already I can process the pr right away if you ping me
<sima> airlied, ^^ fyi
tango_ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
<mripard> I can do a PR right away yes
rasterman has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
kxkamil2 has quit []
<sima> mripard, there's some dp patches that conflict already in drm-intel-next, so imo simpler if we land the others in there too
<sima> but could also land in drm-misc-next, I don't really care
<sima> I guess as long as it lands somewhere and there's a pr from both trees and then backmerge after both landed in drm-next it should sort itself out
<sima> jani, ^^
<jani> sima: what kind of timeline are you thinking of for the drm-intel-next pull request?
<jani> sima: backstory, it's rodrigovivi's turn but he's out this week
<jani> usually there's no rush so we didn't think anything of it
<sima> jani, I think with the amdgpu conflict we have already better sooner than later, especially if you toss more cross-driver dp patches on top
<jani> sima: that's what I thought
<jani> sima: so do I get this straight, it's okay to merge the patches to drm-intel-next first, as long as there's a swift pull req after that?
<sima> I think agd5f also sends the first -next pull around this time-ish, and probably want to make sure we have a cleaned-up drm-next for that
<sima> jani, yeah imo a-b: me for that
<jani> sima: roger
<jani> imre: ^
<sima> and then maybe both you & mripard do a pr on Thu or so, I try to land same day in drm-next and you could backmerge as needed
<sima> agd5f, ^^ fyi maybe wait until that's all sorted with amdgpu-next ...
<jani> sima: sounds good to me. well, apart from the fact that I need to write a changelog :p
<sima> :-P
kxkamil has joined #dri-devel
<imre> jani, sima, ok thx
tristianc6704 has quit [Read error: No route to host]
<imre> waiting for CI
aradhya7 has joined #dri-devel
tristianc6704 has joined #dri-devel
kts has joined #dri-devel
cmichael has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
tshikaboom has joined #dri-devel
macslayer has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
dschuermann has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
jimjams has quit [Ping timeout: 480 seconds]
nicolejadeyee has quit [Ping timeout: 480 seconds]
JPEW has quit [Read error: Connection reset by peer]
sgruszka has quit [Ping timeout: 480 seconds]
olv has quit [Ping timeout: 480 seconds]
robclark has quit [Ping timeout: 480 seconds]
olv has joined #dri-devel
JPEW has joined #dri-devel
nicolejadeyee has joined #dri-devel
jimjams has joined #dri-devel
robclark has joined #dri-devel
dschuermann has joined #dri-devel
jrayhawk has quit [Read error: Connection reset by peer]
jrayhawk has joined #dri-devel
hansg has quit [Quit: Leaving]
yuq825 has left #dri-devel [#dri-devel]
itoral has quit [Quit: Leaving]
Daanct12 has quit [Quit: WeeChat 4.1.1]
yyds has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
alyssa has joined #dri-devel
<alyssa> with integer render targets, does glClear clamp or truncate?
<alyssa> piglit seems to expect clamping, but i can't find spec text
<alyssa> vulkan explicitly truncates/casts.
<alyssa> v3d clamps
nashpa has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
Net147_ has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
<alyssa> delightfully unspecified.
<alyssa> i sure love gl
sumits has joined #dri-devel
<agd5f> sima, so wait for jani's PR and then send mine? Just FYI, I
<agd5f> 'll be offline mostly on thursday and friday for thanksgiving
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
yyds has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
fab has quit [Quit: fab]
pjakobsson_ has quit [Ping timeout: 480 seconds]
pjakobsson has joined #dri-devel
Company has joined #dri-devel
kzd has joined #dri-devel
macslayer has joined #dri-devel
hansg has joined #dri-devel
yyds has quit [Remote host closed the connection]
fab has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
dv_ has quit [Ping timeout: 480 seconds]
dv_ has joined #dri-devel
MrCooper has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<sima> agd5f, yeah, so next week I guess for -next
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
i509vcb has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
Duke`` has joined #dri-devel
DodoGTA has joined #dri-devel
luben has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Guest6554 has left #dri-devel [#dri-devel]
tango_ has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
hansg has quit [Remote host closed the connection]
hansg has joined #dri-devel
frieder has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
kallisti5[m] has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
dviola has quit [Quit: WeeChat 4.1.1]
donaldrobson has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
gouchi has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
demarchi` is now known as demarchi
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
Aura has quit [Ping timeout: 480 seconds]
Aura has joined #dri-devel
<airlied> alyssa: i've vague memories of amd hw getting it wrong and us doing it in software, I think the hw truncated, but we had to use shaders to clamp
rasterman has quit [Quit: Gettin' stinky!]
crabbedhaloablut has quit []
hansg has quit [Quit: Leaving]
tursulin has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
pp123[m] has left #dri-devel [#dri-devel]
apinheiro has quit [Quit: Leaving]
heat has quit [Remote host closed the connection]
cdsloif^ has quit [Remote host closed the connection]
heat has joined #dri-devel
heat_ has joined #dri-devel
maxzor has joined #dri-devel
heat has quit [Read error: No route to host]
maxzor has quit [Ping timeout: 480 seconds]
luben has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<jenatali> Any nir experts around? There's a comment in nir_opt_cse that I don't know that I agree with
<jenatali> Specifically, "It's safe to replace an exact instruction with an inexact one as long as we make it exact."
<Sachiel> that sounds counter intuitive
<jenatali> I have a case where two shaders that have the same instructions writing to an invariant value end up producing different results, because one also ends up using one of the same SSA values in a different way, which affects which optimizations are applied
<jenatali> Specifically: (('fadd(is_only_used_as_float)', 'a@16', 0.0), a, '!'+signed_zero_inf_nan_preserve_16),
<jenatali> Those kind of "future knowledge" checks for optimizations make it seem really dangerous to change which instructions consume a precise value
heat_ has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
<pendingchaos> I think that opt should be safe as long as nothing depends on the sign of zeros
<pendingchaos> looking at 4.7.1 of the GLSL 4.60 spec, I think that might not actually be the case for GL
<pendingchaos> IIRC the sign of zero is undefined, but I think it was unclear if invariant changes that
<jenatali> So in one shader, the value is used by f232, and in the other, thanks to CSE, it's also used by store_output
<jenatali> So one shader removes the add and the other doesn't. The one with the add removed then folds the f2fmp with the f2f32, while the other one doesn't...
bbhtt has quit [Ping timeout: 480 seconds]
bbhtt has joined #dri-devel
<alyssa> airlied: fun.
<pendingchaos> so f2f32(f2fmp(a)+0.0)->f2f32(f2fmp(a))->a
<pendingchaos> would that mean the f2f32(f2fmp(a))->a optimization is probably the unsafe one?
<alyssa> that one is unsafe by design
<alyssa> is mediump all kinds of broken in mesa? sure is.
<jenatali> Is the only solution lowering it to f16 ASAP?
<alyssa> well..
<jenatali> Because this is just running a basic opt loop before doing that
<alyssa> f2fmp is /defined/ in a sort of.. superpositiony way
<jenatali> CSE + opt_algebraic
<alyssa> f2fmp cannot respect invariance by definition
<alyssa> i don't remember how this was intended to work tbh
<jenatali> FWIW I don't think the problem is actually mediump
<jenatali> There's two optimizations that are considered invariant. One relies on how a value is used to determine if it's safe. CSE changes how the value is used, despite the two "common sub-expressions" having different precise qualifiers
<jenatali> The end result is the optimization applies in one shader but not the other
<alyssa> right. that's not CSE's fault, though
<alyssa> it's that f2f32(f2fmp(a))->a is fundamentally not invariant
<jenatali> Hm. Fair
<alyssa> i have no idea how this was supposed to work, but if there's an f2fmp anywhere in the chain of something invariant, you're screwed
<jenatali> Oh those optimizations are only in late, I see
<jenatali> Oh, nvm, I misread
<jenatali> Right so, back to: this is a simple opt loop before mediump is removed
<jenatali> Are there Vulkan drivers that handle mediump?
<alyssa> not sure
<alyssa> there were MRs, dont remember if merged
<alyssa> apparently yes
gouchi has quit [Remote host closed the connection]
<jenatali> Hm. Why don't they hit this
rasterman has joined #dri-devel
tshikaboom has quit []
<alyssa> \shrug/
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<jenatali> It's because I'm also using nir_lower_mediump_vars on I/O vars. Without that, the intermediates get converted back to f32 before being stored, meaning that whether or not the CSE happens doesn't matter, because in both cases it's only used as a float
<jenatali> Lovely
glennk has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
jsa has quit [Read error: Connection reset by peer]