ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<karolherbst>
because they don't want to
<jekstrand>
karolherbst: Ninja would be fine if we wrapped rustc in a bit of python
<karolherbst>
afaik
<karolherbst>
jekstrand: sure, but then you have convince dcbaker to do it this way :p
<jekstrand>
karolherbst: The idea would be to have a tiny python script that gets invoked by Ninja which parses the --env args and turns them into environment variables when it invokes rustc.
<jekstrand>
karolherbst: Yeah, it's not a great solution and it leaves you with a problem of how you want to integrate that into meson.
<cmarcelo>
karolherbst: I'm confused what's the limitation with ninja tool. does it clean up env vars?
<karolherbst>
ohh sure, I am all for it, but there were some disadvantages with that, which I think are not relevant in regards to rust
<karolherbst>
but oh well
<karolherbst>
cmarcelo: something like that
<karolherbst>
targets can't set new env vars afaik
<cmarcelo>
dcbaker: and for rust, I actually want to use the include thing sometimes, because I want to impl stuff for the types defined there.
<jekstrand>
To keep things generic, you want a rust_args: [ '--env', 'BUILD_DIR=foo' ]
<cmarcelo>
karolherbst: for the case of the hypothetical env var there, it would be "global" enough that meson might always set it
<jekstrand>
But if you do that via a wrapper and it ever does make it into rustc but uses something other than --env, you're in trouble.
<cmarcelo>
jekstrand: wrapper for rustc seems to be the "don't need meson or rustc patches" solution.
<jekstrand>
cmarcelo: Yeah...
<cmarcelo>
my general point is, I'd be happy if we had tools to fix the problem, but not (yet) fixing the general meson issue to do everything automatically
<jekstrand>
karolherbst: Is there a reason why you pass all these "use crate::foo" lines to bindgen instead of sticking them in bindings.rs?
<karolherbst>
jekstrand: the only reason I can come up with was that I wanted to have no bindgen.rs file at all
<jekstrand>
karolherbst: hehe. That's fair, I suppose. :)
<karolherbst>
also sharing some stuff with the mesa bindgen
<karolherbst>
libmesa_rust is really how it's supposed to work
<jekstrand>
Yeah, that one's nice and clean
<karolherbst>
no funny include business
<jekstrand>
If we're ok with a bit more unsafe!, we may be able to avoid some of the funny include buisiness.
<karolherbst>
potentially
<karolherbst>
although...
<karolherbst>
no I don't think so
<karolherbst>
we need cl_icd_dispatch
<karolherbst>
no matter what
<jekstrand>
Yeah
<karolherbst>
and we have to be able to declare structs with that inside to use inside the bindgens :/
<jekstrand>
have a header with `struct _cl_foo { struct cl_ice_dispatch dispatch; };` for everything
<karolherbst>
mhhhh
<jekstrand>
And then pointer cast inside an unsafe
<karolherbst>
maybe
<karolherbst>
I guess that could work
<karolherbst>
let me try on friday :D
<jekstrand>
Hehe
<jekstrand>
I may give it a try tomorrow
<jekstrand>
it's getting late here and very late there.
<karolherbst>
jekstrand: you should be able to run test_basic with it
<karolherbst>
and other tests
<karolherbst>
I know that I made memory copyreadwrite passing or something
<jekstrand>
cool. Mind throwing me a link to that stuff again? I lost it all when I left Intel.
<jekstrand>
I think I can find the CL CTS. I just have to remember how to build it.
<jekstrand>
But you had some other super simple tests somewhere
<karolherbst>
might want to implement clCreateContextFromType as well...
heat has quit [Remote host closed the connection]
<karolherbst>
wait.. it is
<karolherbst>
maybe I fixed the errors since then
ybogdano has joined #dri-devel
pcercuei has quit [Quit: dodo]
mlankhorst has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
iive has quit []
kalidows has joined #dri-devel
kalidows has quit []
zzoon has joined #dri-devel
zzoon has quit []
cworth has joined #dri-devel
ngcortes has joined #dri-devel
rasterman has joined #dri-devel
shsharma has joined #dri-devel
shsharma has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Akari has quit [Quit: segmentation fault (core dumped)]
Akari has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
jljusten has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
cworth has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
jljusten has joined #dri-devel
cworth has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
jljusten has quit [Ping timeout: 480 seconds]
jljusten has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
lemonzest has joined #dri-devel
zf has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
mattrope has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
Lyude has quit [Remote host closed the connection]
Lyude has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
maxzor_ has joined #dri-devel
mvlad has joined #dri-devel
itoral has joined #dri-devel
kts has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
<HdkR>
Anyone know where `/tmp/.X11-unix/X0` is generated in libGL/libX? I have a XServer managing to generate this in not `/tmp/` and trying to find out how to redirect
<HdkR>
Or more directly, can I just tell an application the absolute path to the socket?
danvet has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
mlankhorst has quit []
alatiera has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
maxzor_ has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
ahajda_ has joined #dri-devel
<mmind00>
question regarding drm-misc: commit c0cfbb122275 ("drm/rockchip: dw_hdmi: Do not leave clock enabled in error case") went into mainline via drm-misc-fixes, now another commit aimed for drm-misc-next changes the same area ... what's the best way to solve this?
JohnnyonFlame has quit [Ping timeout: 480 seconds]
lkw has joined #dri-devel
shsharma has joined #dri-devel
MajorBiscuit has joined #dri-devel
camus1 has joined #dri-devel
shsharma is now known as shashanks
camus has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
<mmind00>
mripard mlankhorst ^^
<pq>
gpiccoli, I guess the situations where the FB emergency show is intended for, the userspace DRM master is already dead or stuck, which is why one try to reach the emergency FB anyway. Kernel panic should freeze everything, right?
<mripard>
mmind00: usually, once an rc has that patch we would merge the rc in drm-misc-next if you ask us
rasterman has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
kts has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
pnowack has joined #dri-devel
gawin has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
<mlankhorst>
Yeah, or if it conflicts, it usually doesn't matter much either unless it depends
devilhorns has joined #dri-devel
mclasen has joined #dri-devel
punit has left #dri-devel [ERC (IRC client for Emacs 27.1)]
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
maxzor_ has quit [Ping timeout: 480 seconds]
Thymo_ has joined #dri-devel
Thymo has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
<gpiccoli>
Hi pq ! Unfortunately, not working as expected..if I switch to the emergency fb (right in the kernel panic() begin), even so I get the flickering and master is showed...
<pq>
is userspace already frozen at that point?
<pq>
well, I can't help anyway. That's a topic I think many people have fought before, as well.
ella-0 has joined #dri-devel
<gpiccoli>
we have multiple cpus right? So not all of them are frozen in this moment...userspace might be running in a non-panic cpu
ella-0_ has quit [Read error: Connection reset by peer]
<gpiccoli>
the panic code indeed stop all the other CPUs, but it's a bit later - and if I go with emergency fb restore after this point, I got stuck - no progress is made. I might need to debug more why this happens
<pq>
..or a kernel thread or interrupt service that is going to flip to the FB userspace submitted earlier
<gpiccoli>
pq, you mention a lot have fought this fight before heh - do you have some lore/ML links ?
<pq>
gpiccoli, maybe danvet can chime in on this? I mean, if emergency FB was even remotely easy to show, it would work already.
<danvet>
emergency fb restore is pretty much busted
<danvet>
at least for anything remotely resembling a modern kms driver
<danvet>
we have a todo somewhere about an emergency panic printing support on top of kms
<gpiccoli>
exactly what I was thinking, in the panic path we shouldn't play with locks the way fb restoration is doing
<danvet>
I should do a patch to update the todo entry
<danvet>
yeah the fb restore approach for panic handling is complete nonsense
<danvet>
imo rip it out
camus1 has joined #dri-devel
<danvet>
hm I think the drm one I ripped out already, but there's like entire levels of this stuff
<danvet>
like printk also has a "restore console" hack
<danvet>
and then iirc fbcon has a "forced unblank" hack
<danvet>
and it just piles on
<gpiccoli>
yeah! in the end, anything on panic path is kinda hacky heh - we're in a bad situation over there
<danvet>
just trying to get fbcon to not make everything worse so that at least the panic can go out over usb/net/serial console or whatever requires some heroics in cases
<danvet>
but I think we mostly plugged these in the drm fb helpers by simply bailing out when we're in panic context
<gpiccoli>
yeah, we have kmsg_dump, kdump, a lot of ways to collect data. My goal is to show a friendly screen in a panic!
camus has quit [Read error: Connection reset by peer]
<danvet>
see all the oops_in_progress checks
<danvet>
see the link to noralf's patches plus the entire discussion
<danvet>
imo that's the only semi-reasonable plan to make this happen
<gpiccoli>
I will, much appreciated danvet and pq, very helpful!
<javierm>
gpiccoli: another interesting read is the threaded printk patch-set that danvet shared the other day: https://lwn.net/Articles/800946/
<gpiccoli>
hehe cool! I have a direction now
<pq>
I wonder if showing a panic screen is even a useful goal... would it not be more useful to stash the panic log somewhere and reboot?
<gpiccoli>
nice javierm , will read that as well!
<gpiccoli>
pq, definitely! I'm doing both =)
<gpiccoli>
we need the logs, prio #1
<gpiccoli>
But also, maybe would be nice for (newbie) users not getting a stall, the screen remains the same as they were using on panic, and then it reboots. Would be nice to have a screen change. I don't want to use a GPU during a panic, I just want a last action from it, which is restoring the fb
<gpiccoli>
like drop_master(); restore_fb(); - with the minimum churn I can get
<gpiccoli>
But I'll read all the references you mention, I'm quite new in the DRM world...
<gpiccoli>
yeah javierm , what I'm using =)) - there are other backends as well, like a block one, efi...
<gpiccoli>
and there's kdump, which involves rebooting into a new kernel to collect the logs, works fine as well
<pq>
If it reboots, you can't see the panic screen. But on reboot, e.g. in initrd, the OS could check for a panic log, and show the "panic screen" after the fact, with options like saving it to file, no need for cell photos.
<gpiccoli>
Collecting logs is no issue here, being user friendly is ...
<javierm>
gpiccoli: gotcha
<javierm>
gpiccoli: I've seen issues with kdump and gfx drivers/devices though
<javierm>
a reboot but taking the logs from a somewhere seems more robust
<gpiccoli>
it was my first idea: just show some screen in a kdump. But guess if I could reuse the FB? heh
<pq>
gpiccoli, no no, not re-using an FB, no. Text logs.
<gpiccoli>
then I'd need to re-probe amdgpu and that is complex
<javierm>
gpiccoli: ah, those are the kind of issues with k{dump,exec} I was talking about :)
<gpiccoli>
even so, how can I print text logs in the kdump ? I need something showing them in screen
<gpiccoli>
*saving* logs is different and that is pretty much fine
<pq>
Having the logs as text has huge benefits: you don't need OCR, and it can be a lot more than a screenful.
<gpiccoli>
showing stuff in the screen is the hard part heh
<javierm>
pq: problem is that whatever system framebuffer was set up by the firmware is already gone
<gpiccoli>
agree, saving the logs is mandatory. We're doing that, just wanting to improve user experience and show some screen
<javierm>
so you can't use for example simpledrm
<danvet>
gpiccoli, email for the patch to update the todo so I can cc you?
<pq>
javierm, yeah, exactly.
<gpiccoli>
of course danvet , much appreciated! gpiccoli (a-t) igalia (dot) com
<pq>
gpiccoli, showing the panic logs *after* reboot should not be hard at all.
maxzor_ has joined #dri-devel
<javierm>
pq: right. I was talking about the kexec case
<pq>
I really mean logs, not FB.
<gpiccoli>
pq, so let's have a terminology here. We have kernel A..it crashes, panics! It jumps into kernel B, which is a kdump kernel. B collects logs from A and perform a full-reboot, i.e., goes to firmware, which resets the GPU (GOP stuff)
<gpiccoli>
So, how can I show even text in B ?
mnadrian has joined #dri-devel
camus has joined #dri-devel
<pq>
all those ramoops etc. that were mentioned, show them after you have rebooted to a fully working system again.
<gpiccoli>
_without_ re-probing the big driver
<javierm>
gpiccoli: why you need to show text in B ?
<javierm>
gpiccoli: you just need to show on C after the reboot
<pq>
gpiccoli, I'm not even talking about kdump. I'm talking about good old reboot.
camus1 has quit [Ping timeout: 480 seconds]
<gpiccoli>
ok, but that's not the thing! There are two separate issues we are mixing here: (1) log collection (and ofc I can show it later in C, that's fine); (2) a friendly message to users like "hey, you panicked", like a BSOD in windows
<javierm>
kernel A (crashes) -> kdump B (collects the logs and stores somewhere persistent) -> kernel C (full reboot as pq said, gets the logs from somewhere)
kts has joined #dri-devel
<javierm>
gpiccoli: can't you show that after reboot ? Like, your previous kernel crashed and here are the logs
<javierm>
press any key to continue
<gpiccoli>
I can...but for some reason, imagine there is lots of logs, and we require 1 min to collect, etc (be it kdump or pstore)
<javierm>
gpiccoli: hmm, I see
<gpiccoli>
During this time, users are blind-folded
lkw has quit [Remote host closed the connection]
<pq>
oh, you meant like a splash "please wait"
<gpiccoli>
there are ways of improving, but nothing is as definitive as just restoring the fbdev in a panic event, which was filled with a friendly panic message. Also, none is as complex as this one hahah
<gpiccoli>
Yeah, good word pq - splash!
<gpiccoli>
a panic splash screen =)
<pq>
back to square one, then
<gpiccoli>
like videogames - if you playstation fails, we have one of these screens I guess
<gpiccoli>
*your playstation
<javierm>
gpiccoli: thanks for explanining the issue. Shocked that we couldn't solve it here in a few minutes :P
<gpiccoli>
haha thank you folks, a lot! much appreciated
<gpiccoli>
you opened my mind
<gpiccoli>
I knew it was complex...but...maybe it's a bit more than I expected =O
nadrian has quit [Ping timeout: 480 seconds]
<pq>
Personally I'd like to solve that problem with a LED.
<pq>
but then machines would need to have a "panic" led...
<pq>
like... blinking keyboard leds?
<pq>
on panic?
<pq>
but that still takes USB nowadays, so maybe it doesn't work
<gpiccoli>
the led is pretty good, and I guess we have that, there's a panic notifier list and some users of that are led functions
<gpiccoli>
so, for some servers I guess the led approach is great. But for a gaming computer, something more aimed to end-users, gamers, maybe even a led is to "few" information heh
<vsyrjala>
are people using PANIC_ON_OOPS=y or something? don't think i've had a full kernel panic in years
<pq>
maybe you'd be able to force off the display by e.g. cutting power/clocks to the PCI device...
<pq>
I'm pretty sure all gamers realize the machine crashed if the game freezes. :-)
<gpiccoli>
vsyrjala, yes I am =) hehe - and there are more, panic on lockups, on hung tasks...choose your flavor
<danvet>
gpiccoli, wrt cool ideas, QR encoding the log in a panic screen sounded like a really neat one
<gpiccoli>
pq, good idea is well, but PCI resets are not well defined in x86, it's vendor dependent in a way. In powerpc we had a "fundamental reset" which was analogous of firmware resetting the device
<danvet>
so if you go down the proper panic handler path
<danvet>
and the goal is to grab something which users can send in easily for bug reports
<danvet>
QR encoding should be good fun, and it can encode a lot more generally than what you can print as text
<emersion>
is it time to start teaching QR code reading in schools?
<gpiccoli>
heheh danvet , that's quite a nice idea!
<gpiccoli>
emersion, maybe - all QR codes right now, even my chinese food comes with codes I use next time to get bonus hehe
<danvet>
gpiccoli, iirc there was a patch set for that too, but for fbcon
<danvet>
emersion, it would make for some good discrete math fun for sure
<danvet>
at least if it's a small one
<gpiccoli>
danvet, you mean a patch for QR-coding the panic ?
<danvet>
added QR link at the bottom + your suggestion for over each other
<gpiccoli>
And this idea is far more ambitious than me trying to recover the fb heh
<emersion>
aztec codes might be better here
<javierm>
danvet: yes, it does. Thanks!
kts has quit [Quit: Konversation terminated!]
lplc has joined #dri-devel
shashanks has joined #dri-devel
itoral has quit [Remote host closed the connection]
<Venemo>
robclark: ping
Company has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
sdutt has joined #dri-devel
jewins has joined #dri-devel
kts has joined #dri-devel
MrCooper has quit [Quit: Leaving]
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
MrCooper has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
<alyssa>
mattst88: do you understand GLSL IR because I sure don't!
MrCooper has joined #dri-devel
MrCooper has quit []
MrCooper has joined #dri-devel
<alyssa>
validation fails because ir->var->type is int16_t but ir->type is int...
<alyssa>
on a (var_ref) oh boy
sdutt has quit []
mbrost has joined #dri-devel
sdutt has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
kts_ has joined #dri-devel
MrCooper has joined #dri-devel
shashanks has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
<alyssa>
GLSL makes my head hurt
kts has joined #dri-devel
nchery has joined #dri-devel
mattrope has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
mlankhorst has quit [Quit: Konversation terminated!]
<alyssa>
mareko: it's a bug in lower_precision
mlankhorst has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
ahajda_ has quit []
ahajda has joined #dri-devel
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
hansg has quit [Remote host closed the connection]
hansg has joined #dri-devel
kts has joined #dri-devel
Haaninjo has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<mmind00>
mripard: cool thanks ... the commit is part of 5.17-rc5, so if it's possible to merge that, that would be really nice
<mmind00>
mlankhorst: it depends - sort of ... the fixes commit moved the clk-enablement, the new commit adds regulator enablement and in turn adapts the error handling for said clock-enablement ... so my guess yesterday was that things may end up slightly chaotic
<mlankhorst>
You can either wait for backmerge, or just commit and fix up drm-tip :)
<alyssa>
` is replaced by `ufloats[i + 1]` the issue is still there)
<alyssa>
The variable used in this array index is getting lowered to int16, but the dereference to the variable inside the array index is not getting its own type adjusted
<alyssa>
This breaks GLSL-to-NIR, but the bug is not in GLSL-to-NIR, it's in lower_precision (given the GLSL validation failure)
<alyssa>
In order to reproduce, all lower_precision flags must be enabled
<dcbaker>
I've added support for passing environment variables through a wrapper script to rustc
<linkmauve>
karolherbst, graphitemaster, in Grover I haven’t used a single crate in the driver code for now, the only one which would be useful so far would be the log crate.
<cmarcelo>
dcbaker: cool
shashanks has joined #dri-devel
<linkmauve>
karolherbst, jekstrand, you can also compile the bindgen-generated sources as their own crate (static_library in meson) and link against it in the rest of your code.
<karolherbst>
linkmauve: we have to forward declare structs
<karolherbst>
with fields depending on the bindgen
<linkmauve>
karolherbst, and you can’t do that if bindgen stuff is in its own crate?
<karolherbst>
you can't impl types in different crates
<linkmauve>
Right.
<karolherbst>
I mean.. we could come up with _some_ way
<karolherbst>
but...
<linkmauve>
Well, actually you can, but only if you declare the trait in your other crate.
<karolherbst>
jekstrand had the idea of just doing unsafe casts to get around that...
<linkmauve>
Sounds dangerous.
<karolherbst>
ehh, not that bad
<karolherbst>
but yeah
<linkmauve>
I’ve done that using wrapper structs around bindgen ones.
<linkmauve>
Using ProperStructCase to differentiate them.
<anholt>
yeah, wrapping the bindgen struct seems like the normal thing to do to me.
<karolherbst>
I'll try something tomorrow
mbrost has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
mbrost has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
pnowack has left #dri-devel [#dri-devel]
pnowack has joined #dri-devel
<anholt>
hmm. if an asan build is 1.7G of .o files alone, I wonder if we're just blowing out the 5G ccache and that's why it's so slow to build. going to need some debugging with CCACHE_LOGFILE I think.
<ajax>
are we building things with -g and does that always make sense?
<jekstrand>
karolherbst: I'm playing with ideas
<dcbaker>
ajax: if we're setting buildtype=debug_optimized (the default), then yes
<jekstrand>
karolherbst: I pushed a rusticl branch with a couple build fixes if you want it.
<ajax>
seems somewhat silly if we're not going to be debugging the built thing (which, sure, sometimes that's useful...)
jewins has joined #dri-devel
ahajda has joined #dri-devel
<dcbaker>
yeah, switching the buildtype to release probably makes more sense anyway if we're going to run tests, we can always set -Dc_args="-DDEBUG" if we need to keep that code
<anholt>
ajax: we definitely want to be able to take the drivers that were being tested and run them, so yes.
<anholt>
run them under gdb, that is
<anholt>
the non-testing drivers are already not built with debugoptimized, it looks like
zf has joined #dri-devel
ngcortes has joined #dri-devel
<anholt>
unfortunately it looks like a significant amount of the .o size in the asan build is that gtest is the worst.
<alyssa>
what's wrong with gtest?
<anholt>
alyssa: generates so much code.
Duke`` has quit [Ping timeout: 480 seconds]
<alyssa>
right :(
<alyssa>
and y'all said my NIH of gtest was such a bad idea...
mvlad has quit [Remote host closed the connection]
shashanks has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
ahajda has quit [Remote host closed the connection]
Bennett has joined #dri-devel
gouchi has quit [Remote host closed the connection]
cworth has quit [Ping timeout: 480 seconds]
cworth has joined #dri-devel
Company has quit [Read error: No route to host]
Company has joined #dri-devel
pcercuei has quit [Quit: dodo]
maxzor has joined #dri-devel
<anholt>
ajax: did you rig up +bs as "force automatic compositing"?
<anholt>
would love to stabilize a pile of swrast piglits using it.