<airlied>
dolphin: yeah I just saw the wrong ordering in git log on when patches were applied to next/fixes, and thought it was broken in the pull, not the resulting tree
<dolphin>
ok, I see you have applied the pull, thanks
<dolphin>
is it correct to assume that now when -gt-next is following the RFC path, -rc5 is fine for last PR?
Anorelsan has joined #dri-devel
<airlied>
dolphin: yeah rc5 is good
<dolphin>
Ok, thanks. I will proceed to backmerge drm-next now to pull in -rc2 and the TTM changes that we depend on
tzimmermann has joined #dri-devel
rgallaispou has joined #dri-devel
rgallaispou has quit []
rgallaispou has joined #dri-devel
FireBurn has joined #dri-devel
Duke`` has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
rasterman has joined #dri-devel
pendingchaos has quit [Read error: Connection reset by peer]
pendingchaos has joined #dri-devel
<danvet>
airlied, dolphin just cc'ed you on a revert from mauld
<danvet>
would be good for that to make -rc5 and then I guess another backmerge pile
<danvet>
it's the other part to make intel ci happy again
pcercuei has joined #dri-devel
<dolphin>
danvet: jani and vivijim are doing -fixes
<danvet>
drat cc'ed wrong folks
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
ramaling has joined #dri-devel
ramaling has quit []
ramaling has joined #dri-devel
ramaling has quit []
ramaling has joined #dri-devel
rgallaispou has quit [Remote host closed the connection]
shankaru has joined #dri-devel
thellstrom has joined #dri-devel
vivijim has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
<jani>
danvet: which revert? tooling didn't pick up anything
ramaling has quit []
ramaling has joined #dri-devel
<danvet>
jani, it's not landed yet in gt-next
<danvet>
mauld should push it any minute now I guess
pendingchaos has quit []
pendingchaos has joined #dri-devel
boistordu_old has joined #dri-devel
boistordu has quit [Read error: Connection reset by peer]
thellstrom has quit [Quit: thellstrom]
thellstrom has joined #dri-devel
<zmike>
mareko: ping re: !11071 !10963 !10964
pjakobsson has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
Balooga has joined #dri-devel
Balooga has quit [Remote host closed the connection]
itoral has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
iive has joined #dri-devel
Anorelsan has quit [Quit: Leaving]
thellstrom has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
Lightkey has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Lightkey has joined #dri-devel
rpigott has quit [Ping timeout: 480 seconds]
rpigott has joined #dri-devel
shankaru has quit []
gpoo has joined #dri-devel
itoral has quit [Remote host closed the connection]
Sumera has joined #dri-devel
<mareko>
does X use non-displayable modifiers for windows? if so, which X server version do I need?
deepin_ has joined #dri-devel
<emersion>
Xorg doesn't do modifiers by default AFAIK
<MrCooper>
it depends on the Xorg driver
<bnieuwenhuizen>
so the only xorg driverthat does modifiers IIRC is modesetting and even there it is disabled due to reasons
<emersion>
also I guess DCC could be an issue with its multi-planar textures?
<emersion>
s/texture/DMA-BUF/
<MrCooper>
xf86-video-amdgpu doesn't have any modifier support yet, though DRI3 clients may still use modifiers via glamor
<bnieuwenhuizen>
on xwayland there are modifiers but due to wayland limitations we will currently never use non-displayable modifiers I think?
<emersion>
bnieuwenhuizen: no, it should use them
<bnieuwenhuizen>
emersion: I think that there were limitations that wyaland couldn't change the modifier list dynamically based on fulscreen status?
<emersion>
it's the other way around: when a displayable modifier could be used to allow KMS optimizations, it won't
<bnieuwenhuizen>
oh :(
<emersion>
well it depends what the compositor advertises really
<bnieuwenhuizen>
also I think the multi-planar DMA-BUF stuff should be supported, I thought Intel did that bring-up for their compressed modifiers?
<emersion>
most compositors advertise all EGL-supported modifiers, so what i said above will happen and non-displayable modifiers will be used
<emersion>
yeah multi-planar should work fine
<emersion>
on xwayland that is
<bnieuwenhuizen>
I think Intel also did that stuff on modesetting?
<emersion>
yeah but disabled by default
<emersion>
because Y_TILED breaks stuff
<emersion>
(among other things?)
<emersion>
i'd really like to have something like DRM_CLIENT_CAP_DISABLE_ANNOYING_MODIFIERS
<Sumera>
danvet: yep, the vkms error is mostly because we are asking kzalloc for a lot of memory....but also I think it has (maybe)something to do with active_writeback not being set correctly. I peppered some printks (https://paste.ubuntu.com/p/JV6NpqKx3W/), here are logs https://paste.ubuntu.com/p/tzs6JCYPr7/
<emersion>
or ENABLE, fwiw
<bnieuwenhuizen>
what do you mean with annoying modifiers?
<emersion>
i mean Y_TILED :P
<Sumera>
danvet, unfortunately there is a buffer overrun so I think I am missing some dmesg logs when the frame allocation error starts :/
<emersion>
Y_TILED consumes more bw, so using Y_TILED makes you unable to light up CRTCs sometimes
<bnieuwenhuizen>
so you try other modifiers until it works?
<emersion>
so, that cap would disable any modifier that needs a fallback path (fallback = prune the modifier and re-try)
<bnieuwenhuizen>
I thought that was the design of KMS?
<emersion>
but it's more tricky than that
<emersion>
because you potentially need to re-allocate buffers for other CRTCs as well
<emersion>
e.g. using Y_TILED works fine for lighting up one CRTC, but prevents you from lighting up a second one
<emersion>
btw, all of this is the reason why GNOME disables modifiers by default
<emersion>
(maybe it has a "bad driver list" nowadays? not sure)
<emersion>
(in any case it's not great)
<emersion>
cc vsyrjala ^
<bnieuwenhuizen>
wait, GNOME disabled modifiers by default? O_o
<pq>
bnieuwenhuizen, It is the design of KMS, but userspace is not smart enough yet to shake the world until all pieces fall into place. :-)
<bnieuwenhuizen>
are ChromeOS and gamescope the only ones using modifiers for real?
<emersion>
Weston and anything wlroots too
<emersion>
not sure about KDE
rgallaispou has joined #dri-devel
<emersion>
MrCooper, jadahl: does Mutter still disable modifiers?
<pq>
weston indeed uses modifiers, but it too is not smart enough to shake world yet
<emersion>
shaking the world is difficult
hch12907 has quit [Remote host closed the connection]
<pq>
just a lot of typing, and potentially slow'ish :-)
<MrCooper>
emersion: it does for amdgpu & i915, but not other drivers by default
<emersion>
wlroots is smart enough to fallback to the modifier-less path when lighting up a CRTC fails, but not smart enough to re-allocate other CRTCs
<emersion>
MrCooper: why is it disabled for amdgpu?
<MrCooper>
IIRC because it breaks direct scanout for DRI3 clients
<emersion>
ah, right
<bnieuwenhuizen>
?
hch12907 has joined #dri-devel
<bnieuwenhuizen>
why does it break direct scanout for DRI3 clients?
<emersion>
bnieuwenhuizen: using modifiers will make xwayland clients use non-displayable buffers
<bnieuwenhuizen>
is that the wayland limitation?
<bnieuwenhuizen>
ah ok
<emersion>
nope
<bnieuwenhuizen>
?
<emersion>
we just need dmabuf-hints to allow clients to pick a displayable modifier when appropriate
<bnieuwenhuizen>
yes but dmabuf-hints not being in yet is the limitation no?
<MrCooper>
i.e. nope as in yes :)
<jadahl>
emersion: there is a "deny list" that it disables it for
<emersion>
bnieuwenhuizen: yes (sorry, that was confuisng)
<emersion>
jadahl: i see
<emersion>
bnieuwenhuizen: fwiw, gamescope will only advertise KMS modifiers to clients, to force them to use displayable buffers
<pq>
any compositor could do that without dmabuf-hints already, if they wanted to
sdutt has joined #dri-devel
<daniels>
emersion: btw are you planning on doing dmabuf-hints for wlroots any time soon? leandrohrb is quite close to having the Mesa MR reworked and ready for review
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
<MrCooper>
vsyrjala: it needs to wait for the unflip to complete before the modeset, otherwise the modeset may race with the pending (un)flip(s)
pekkari has joined #dri-devel
<deltasquared>
so got a lead for this channel from mesa3d.org even if I'm not sure it's the right one... got a problem with an application via steam proton having severe missing texture issues. I initially suspected the switch to ACO since the last time I tried running this program to be at fault, but I haven't had any luck with that off. (I'm really not sure if this is the right channel yet but the other #mesa* channels redirect here by topic... please don't yel
<daniels>
deltasquared: no yelling, but a bug report at https://gitlab.freedesktop.org/mesa/mesa/-/issues/new/ with screenshots, the application name, the exact kernel/Mesa/Proton versions you're running, your distribution, exact hardware revision, etc, is the best way to solve it
<MrCooper>
vsyrjala: BTW, -amdgpu/ati use async flips for unflips, modesetting could do the same if the kernel driver supports it (though I understand older Intel HW has interesting quirks with async flips)
<deltasquared>
daniels: right. I was more looking to see if I could try some debug options to fix it in the meantime, if any were possible (and because that info would be useful in the bug report if I found anything to work)
emersion has joined #dri-devel
bl4ckb0ne has joined #dri-devel
<vsyrjala>
can't really change anything except the address with async flips on intel hw
<emersion>
daniels: ah right, need to look into that
<dschuermann>
deltasquared: please use the provided template, it also contains some information for helping debug
neonking has joined #dri-devel
<deltasquared>
right, though coming up with a name for the login will have to wait until later, naming things is hard and the dang migraines are revving up again after sifting through various 'net posts looking for similar issues... thanks for the pointer in the meantime.
<deltasquared>
I guess I'll check back in if/when I run into any difficulties with the reporting process.
<neobrain[m]>
deltasquared: did you use RADV_DEBUG=llvm to disable ACO or did you try something else?
<deltasquared>
neobrain[m]: I used RADV_DEBUG=llvm, yes. it didn't improve the situation.
shankaru has joined #dri-devel
<deltasquared>
(hence why I said only initially I suspected ACO. now I'm not sure.)
<neobrain[m]>
alright, fair
<HdkR>
Saying what the application is might give an immediate lead as well :)
<deltasquared>
the option _is_ taking effect, as it affects the driver string that the application in question shows in it's setting menu (crash n.sane trilogy). I should note that I did try looking up issues with that game in particular but those were all old and trying their suggestions anyway did not work.
<deltasquared>
I can show screenshots if that would help illustrate the brokenness
<deltasquared>
(... he says, after closing it out of frustration, that may take a few minutes)
<deltasquared>
I'm failing to find any recent issues with that application, though my google-fu is meh at best.
deltasquared has quit [Remote host closed the connection]
Duke`` has quit []
Duke`` has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
deltasquared has joined #dri-devel
<deltasquared>
... apologies, I think the web client broke. just loaded it up into irssi instead.
<deltasquared>
anyway, in case it didn't come through:
<deltasquared>
neobrain, HdkR: https://a.uguu.se/QK2M6ttRZsW7_encode.mp4 is a somewhat slide-show-y screenrec of the game loading and me attempting to get into a level. mostly blind due to most of the textures being missing.
<deltasquared>
interesting that in some cases things become solid colour polygons...
<deltasquared>
(given missing textures and possibly geometry based on that, I already took the liberty of steam's verify local files thing just in case I was suddenly missing something, but that seems to think everything is fine.)
<neobrain[m]>
could this be a regression in proton? have you updated that recently by any chance?
ppascher has quit [Ping timeout: 480 seconds]
<deltasquared>
neobrain: I tried several versions, including what it had been set to last (and had been known to work).
<deltasquared>
erm, neobrain[m]
<deltasquared>
they all exhibited the same issue.
<neobrain[m]>
(both nicks highlight me, but thanks)
<deltasquared>
the precise textures missing did not seem to remain consistent however. I noticed from run to run for instance that the feathers on aku aku (the floating mask) during the loading screen would change their minds individually about whether they wanted to exist.
<neobrain[m]>
I think your time is best spent on creating an issue report for now, but all of that is useful information
<neobrain[m]>
if you can, recording a gfxreconstruct or renderdoc capture of a frame showing the missing textures would be useful for debugging too
williage_ has joined #dri-devel
<HdkR>
Can't reproduce locally on RX 5700. APU might be a reason. Weird interaction with new SAM bits? :)
<deltasquared>
HdkR: it's an older APU though, a ryzen 2200G.
<deltasquared>
it did used to have it's period of being on fire sure
<deltasquared>
this game though always worked fine even when other things caught fire.
williage_ has quit []
<HdkR>
Downgrading mesa might be a test option still. I believe there were some changes around how memory is exposed on UMA still?
williage has joined #dri-devel
<deltasquared>
HdkR: new memory related things you say... well I have changed iommu related things recently, but I would have thought that if that were to cause faults I would get very loud yelling it dmesg. (I have actually got that from ruffle.rs recently, iommu fault and then the tab still seemed to get wedged.)
<deltasquared>
HdkR: that may not be doable depending on how far I need to go. I would have to consult the arch wayback machine, and that might bring along with it chained downgrades and... could get involved. but I'll hold it in the back pocket.
<bnieuwenhuizen>
might be good to just go back to the previous mesa version you used that didn't have this issue
williage has quit []
<deltasquared>
bnieuwenhuizen: any debug variables to unchange it? also that might be a couple major versions ago. health issues have prevented me from playing games in over a year.
<bnieuwenhuizen>
not really
<bnieuwenhuizen>
going back to 21.0 and then RADV_DEBUG=nosam might revert them
ppascher has joined #dri-devel
<bnieuwenhuizen>
on the other hand I woudl suspect Vega vs. RDNA more than memory issues
<deltasquared>
bnieuwenhuizen: so am I to understand 21.1 (.1, what I have specifically) would not have that debug option?
<deltasquared>
(I probably should have mentioned that sooner, d'oh)
<bnieuwenhuizen>
it has the debug option, but there were some changes 21.0 ->21.1 that did not have a debug option
<deltasquared>
I see.
<deltasquared>
bnieuwenhuizen: ugh. this is going to be a pain in the posterior, arch splits all the bits of mesa into core and optional packages for vulkan and other things... I'd theoretically have to downgrade all of them.
idr has joined #dri-devel
<deltasquared>
thanks for the tips though, I will try this later when I've gathered the downgrade packages from the distro archives.
<neobrain[m]>
for testing, it should be sufficient to downgrade libvulkan_radeon.so specifically
<urja>
i mean, you could also just get the PKGBUILD (& associated files) for the older mesa version from the repos and rebuild it
<deltasquared>
bnieuwenhuizen: 21.0.3 in the archives here, should that do it?
<bnieuwenhuizen>
deltasquared: yup
<deltasquared>
bnieuwenhuizen: ok. game ran (after full steam restart following downgrade) with 21.0.3 and RADV_DEBUG=nosam. no change.
<deltasquared>
I should start taking notes at least.
<bnieuwenhuizen>
deltasquared: you know a bug report is a good place for notes :)
<deltasquared>
bnieuwenhuizen: I said later, there's account stuff I'm not feeling up to right now.
<deltasquared>
sorry.
<deltasquared>
didn't mean to snap.
<deltasquared>
someone suggested a renderdoc run earlier though that might be a bit tricky as steam is normally in control of starting proton-supported games, and from glances at the cli from steam's terminal output and ps output it is highly convoluted to set up the prefixes and everything correctly.
bcarvalho_ has quit []
<deltasquared>
well, I guess I could try the attach to running instance thing...
<deltasquared>
... oh, that doesn't do what I thought it did. never mind.
frieder has quit [Remote host closed the connection]
orbea has quit [Ping timeout: 480 seconds]
<DrNick>
you can put ENABLE_VULKAN_RENDERDOC_CAPTURE=1 in the environment to enable the Vulkan layer
orbea has joined #dri-devel
gouchi has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
alyssa has joined #dri-devel
<deltasquared>
DrNick: that change has somehow caused the game to stop launching entirely. >_>
alyssa has left #dri-devel [#dri-devel]
rpigott has quit [Remote host closed the connection]
jernej_ has joined #dri-devel
rpigott has joined #dri-devel
jernej is now known as Guest608
jernej_ is now known as jernej
<deltasquared>
bnieuwenhuizen, neobrain: to add to bizarreness, other applications on my system, including across different user sessions, are having their buffers being filled with white while the offending program is running. occassionally with a sort of checkered pattern. I'm not sure if it'll show up in a screenshot, one moment
Guest608 has quit [Ping timeout: 480 seconds]
<deltasquared>
hmm, no. but I did get a photo of it.
<deltasquared>
at this point considering it has decided to breach program boundaries I'm tempted to try an lts kernel.
<deltasquared>
only one way to find out I guess.
<deltasquared>
thanks everyone for the help thus far. I'll try and get a bug report together in due course as this appears to no longer be a problem confined to the offending application.
<deltasquared>
bnieuwenhuizen, neobrain[m]: I will leave you with this for now: https://a.uguu.se/8WopPqwrLiKM_corrupt_crossuser_term.jpg - this is/was the irssi session I'm typing to you from. it runs under an entirely separate xorg server and user account from steam and the game... yet it's buffer is getting stamped on (this ceases when the game is terminated)
<deltasquared>
other applications get similar artefacting.
<deltasquared>
notably, the terminal emulator (gnome-terminal in this case) would redraw fine when I typed at the shell prompt there but every second refresh it would get a fresh (and random seeming) pattern drawn all over it.
pekkari has quit []
<eric_engestrom>
kusma, zmike: any new on these unexpected pass on zink?
<eric_engestrom>
*any news
vivijim has quit [Remote host closed the connection]
vivijim has joined #dri-devel
Sumera has quit [Ping timeout: 480 seconds]
<kusma>
Ugh, crap. Got a bit overloaded today, and forgot. I'll take a look a bit later, when the baby is asleep
alyssa has joined #dri-devel
<alyssa>
Could someone with a conformant GLES3.1 driver dump the NIR shaders from dEQP-GLES31.functional.separate_shader.random.35 ?
mbrost has joined #dri-devel
<alyssa>
Specifically the type and varying slot of frgVar1 in the fragment shader labeled GLSL7
<alyssa>
I'm /pretty/ sure this is a common code bug, but if the test passes on your driver...
<imirkin>
alyssa: dunno if it matches 1:1, but running with cache disabled, i get this with nouveau (when using nir): https://paste.debian.net/1199788/
<alyssa>
zmike: Oh, so this is a GLSL bug. Lovely.
<imirkin>
note that i see 3x vec2, not 1x mat3x2
<alyssa>
Yeah, you see what I would expect.
<alyssa>
Wonder what the difference is between Panfrost/Zink and Nouveau
<imirkin>
this is with NV50_PROG_USE_NIR=1
<imirkin>
(without, no nir obviously)
<alyssa>
sure
<imirkin>
how are you dumping the nir shaders?
<imirkin>
perhaps i'm dumping them "later" on?
<alyssa>
dumping post all optimizations etc
<imirkin>
yeah, it's the "etc" which might be different ;)
<imirkin>
i'm dumping from with nouveau, i expect it's the post-lowering/etc nir.
<imirkin>
alyssa: btw, the nv50 nir stuff is hardly the paragon of correctness. it's not necessarily the goto for this stuff -- i'd think intel would be the thing to look at for that. but it does *mostly* work.
<alyssa>
sure
<eric_engestrom>
kusma: no worries; I'll make the release now, this is just so that the CI doesn't report a failure when it's not
shankaru has quit []
<kusma>
Can you wait 15 minutes, and I'll find the patch for you?
<eric_engestrom>
sorry, I just did the release :]
<deltasquared>
sorry to crash the channel briefly here, but it just occurred to me to ask if any of you would know of any IRC channels where people who work on the i915 kernel drivers could be found? or if I'd be stuck prodding maintainers via email. figured as some of the driver stuff crosses into the kernel that some of you might know of such. (it's not a gpu accel issue as such hence why I wasn't going to ask
<deltasquared>
here; just some gamma correction palettes getting screwed up in the hardware on an old eee pc netbook.)
<alyssa>
-> #intel-gfx
<alyssa>
deltasquared: ^
<deltasquared>
nice, thanks. (I should hang around on OFTC more, some useful stuff here ;) )
<kusma>
eric_engestrom: Oh well. Anyway, the commit is f0f0a21f131f90274286e32aeb9582c7a3472560
<kusma>
If you want to, I can send a backport MR for the future? Or you can just cherry-pick it to the branch.
<jekstrand>
deltasquared: Some hang around here too but #intel-gfx is the better channel for i915-specific stuff
<jekstrand>
deltasquared: For gamma correction on old eee PCs, talk to vsyrjala who's also here. :)
rasterman has joined #dri-devel
<jekstrand>
deltasquared: He's on Eastern European time so he may not be around righ tnow.
<eric_engestrom>
kusma: thanks! I'll cherry-pick that right away :)
<kusma>
@eri
<kusma>
Uh. Yeah, thanks right back :)
<kusma>
(Still getting used to Element + IRC bridging etc)
<danvet>
robclark, will you pick up the patches from lee jones for msm or should I just smash them all into drm-misc-next?
<danvet>
I'll probably apply them all tomorrow or so
<robclark>
danvet: I'd normally pick them up when I make next sweep thru patchworks.. but prob won't be before tomorrow
<alyssa>
anholt: Is there a reliable way to know if a varying output is flat-shaded when tgsi_to_nir is in the mix?
<jekstrand>
airlied: How do the HSW TRex scores compare? :-P
<alyssa>
var->data.interpolation gives expected results in the VS for GLSL-to-NIR shaders (including separable programs), but ttn is marking everything flat, which seems to reflect how ureg_decl_OUTPUT is defined :|
<airlied>
jekstrand: I'm not allowed publish benchmark figures :-P
<anholt>
alyssa: don't think so. never seen HW need that before, and TGSI doesn't have it afaik.
<airlied>
(is that the usual excuse? :-P
<alyssa>
anholt: ugh..
<jekstrand>
airlied: No, *I* am not allowed to publish benchmark figures. You can do whatever you want. :P
<alyssa>
bifrost needs it for an obscure issue only
<airlied>
my hsw is tied up running GL CTS on 965 at the moment
<alyssa>
at least I can't think of a cleaner way to approach this.
<airlied>
so I have a baseline for wtf later
<anholt>
I would just stuff FS interpolation flags as a u64 in the VS key.
<jekstrand>
I'm genuinely curious to see the phoronix articles with benchmark scores.
<airlied>
I do win at drawoverhead :-P
<ccr>
quite a lot in some cases
<jekstrand>
airlied: Have you run any of those patches through Intel CI?
shankaru has joined #dri-devel
<ccr>
i965: 13465 ms total for 2376 total frames = 176.46 FPS average, crocus: 7087 ms total for 1976 total frames = 278.82 FPS average
<airlied>
jekstrand: not yet, on my todo list
<airlied>
jekstrand: I should take your delta_xy fix
<alyssa>
ccr: gears is not a benchmark
<alyssa>
:P
<ccr>
it's not gears :P
<jekstrand>
airlied: It's the one "real" patch I've got in my gen4 EXT_gpu_shader4 branch. Everything else just enables stuff.
<alyssa>
ccr: oh, in that case, how does perf compare on gears? :-p
<jekstrand>
airlied: The only reason I've not tried to land it is that nothing touches it except gpu_shader4. And, aparently, gallium. :)
<jekstrand>
airlied: And with my patch, i965 does pass some non-perspective piglit tests. :)
<jekstrand>
Kayden: Feel free to ack !11145 if you'd like. Or feel free to not care because it's i965. :)
<ccr>
on ET:Legacy crocus performs about equally with i965
<alyssa>
anholt: Actually, found a workaround :)
<imirkin>
alyssa: fyi, there's also glShadeModel(GL_FLAT)
<imirkin>
which, contrary to what one might imagine, does not force flat interp
<alyssa>
...
<imirkin>
it only forces flat interp for "color" varyings
<imirkin>
but not for texcoords/everything else
<deltasquared>
jekstrand: oh shoot. glad I stuck around now, thanks. (I actually nailed down the commit even that caused it but had no idea what the correct "fix" was, because that's kernel land and I was _not_ ready to be "roasted for the greater good" lol)
<imirkin>
i.e. gl_(Front|Back)Color/gl_Secondary(Front|Back)Color