gnuiyl has quit [Remote host closed the connection]
gnuiyl has joined #dri-devel
Daanct12 has joined #dri-devel
himal has quit [Ping timeout: 480 seconds]
Guest8488 has quit [Read error: No route to host]
fab_ has joined #dri-devel
fab_ is now known as Guest8491
Guest8491 has quit []
kzd has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frankbinns has joined #dri-devel
himal has joined #dri-devel
llyyrr has left #dri-devel [#dri-devel]
llyyr has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
<Lynne>
I'm just about sure that mesa is miscompiling my shader
<Lynne>
could someone look into it?
<Lynne>
affects all mesa drivers, anv, radv, and lavapipe, so I think the issue is with NIR
kts has joined #dri-devel
<airlied>
does it work on nvidia?
rasterman has joined #dri-devel
glennk has joined #dri-devel
<mareko>
what is VUE on Intel?
tzimmermann has joined #dri-devel
warpme has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest8498
lemonzest has quit [Quit: WeeChat 4.4.2]
kts has quit [Quit: Leaving]
coldfeet has joined #dri-devel
apinheiro has joined #dri-devel
vliaskov_ has joined #dri-devel
lemonzest has joined #dri-devel
heat has joined #dri-devel
rgallaispou has joined #dri-devel
MrCooper_ has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
frankbinns has joined #dri-devel
Thymo has joined #dri-devel
Thymo_ has quit [Ping timeout: 480 seconds]
<frankbinns>
DemiMarie: the conformance submission I linked is for the open source driver (the proprietary driver passes 1.3 conformance across a large range of GPUs)
<frankbinns>
we're currently in the process of upstreaming everything for Vulkan 1.0 & GLES 3.1 (via Zink)
<frankbinns>
with all the extensions, etc we had to implement for Zink the driver can almost expose Vulkan 1.1
<Lynne>
airlied: yes
<Lynne>
also I found out that I've fixed llvm in one of my latest rebases
<jani>
airlied: sima: if *you* say we should look into the process again, we will
LeviYun has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
warpme has joined #dri-devel
<sima>
jani, airlied yeah I think we'll just keep silently shrugging
<sima>
with amd and intel doing this regularly and also misc sometimes there's really no point trying to change it, the people (on dri-devel) have spoken
<sima>
agd5f, ^^ fyi
<sima>
also my irc fails at rejoining somehow since a few weeks :-/
<jani>
sima: there just isn't a good answer to having a fix to backport a fix from a non-rebasing -next branch
LeviYun has joined #dri-devel
<jani>
-"a fix"
<jani>
the 2nd one
<sima>
jani, imo it's more fundamental
<sima>
for gregkh linus' tree is the center of the world
<sima>
for a driver developer, it's the driver tree, which often is just $driver-next
<jani>
agreed
<sima>
and gregkh doesn't understand the different perspective somehow, and not for lack of us trying to explain it
Haaninjo has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
<airlied>
jani, sima : yeah I think there's almost a deliberate not getting it going on, maybe I should write a blog post to just point at
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<jani>
drm-misc is trying to apply fixes to -fixes and -next-fixes directly instead of cherry-picking, but a) I think it's hard for the large pool of developers to consistently get right, and you end up with cherry-picks anyway, and b) if you have a series with fixes first, you won't be able to merge the entire thing but have to wait for fixes to get applied to -fixes and backmerged to -next, slowing people down
<jani>
iiuc the only way to make git really understand what's going on is via merges, but I'm also under the impression that Linus doesn't want a ton of backmerges and crossmerges either
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
<sima>
jani, yeah we'd need topic branches for every fix that is needed for a feature patch set in -next
<sima>
I think that's even harder to get committers to consistently do than the current approach
<sima>
I'm wondering whether we should lean more towards "push to -next and cherry-pick if you need some as fixes" even for drm-misc
<sima>
to avoid some of the confusion
<sima>
because it's really the simplest model for committers
<sima>
airlied, blog sounds good
<jani>
yes, that's the thing. do what's easiest for developers/committers, don't add more hurdles
<sima>
yeah
<jani>
"develop on top of drm-tip or -next, preferrably put fixes first in the series, push to -next"
<jani>
instead of, "well, you see, apply patches depending on what they do to a branch that depends on where we are in the development of the current linus' upstream, and maybe sometimes you'll get it right"
<sima>
yeah the 2nd one I screw up too since I don't do it daily anymore like way back in the committer-less model
<jani>
"yes it's a fix, but it's not small enough or important enough to be applied to -fixes at this stage"
<sima>
yeah or people just dumping their fixes in at -rc6 because "oops forgot there's a kernel release"
<sima>
into -fixes I mean, not -next
<sima>
airlied, yeah a blog that just explains how everyone has a different kernel branch that's they're center of the world is probably all that's needed ...