ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
rcf has quit [Quit: WeeChat 3.8]
RAOF has quit [Remote host closed the connection]
<airlied>
gfxstrand: got the latest firmwares to work, so going to see if I can get Linus to allow it in 6.7 which might be a stretch
RAOF has joined #dri-devel
<airlied>
the tlb invalidation will probably have to go with the big hammer fix for now
rcf has joined #dri-devel
<airlied>
gfxstrand: you planning on nak by default once it merged?
ginnie has joined #dri-devel
<daniels>
NAK for all
<gfxstrand>
airlied: NAK for Turing+
<gfxstrand>
I want the default config to be the conformant one
<gfxstrand>
We'll fix bugs from there
<gfxstrand>
Once I figure out warp barrier spilling, we should be able to get 1.1
kzd has quit [Quit: kzd]
* gfxstrand
makes supper
* DavidHeidelberg
thanks for breaking his brain which has special category for a NAK
<DavidHeidelberg>
wish I could NAK NAK name; Thanks got we have Salad, right mupuf ? Now only Nah, Yes, No, Aladeen and Hello remains as a available names.
<DavidHeidelberg>
ok, I was too harsh, we have these options also in all other popular spoken languages :D
glennk has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<Company>
is there a good way to autodetect if a device runs better with Vulkan or with GL?
<Company>
I'm trying to figure out how to choose between my 2 renderers
<HdkR>
Microbench your renderer at runtime and select
<Company>
not sure that's a good idea with GTK - the demands of apps vary a lot
<Company>
and usually the thing people worry more about is which one has fewer bugs
<Company>
Gnome Settings is fast enough either way
luben has quit [Ping timeout: 480 seconds]
<HdkR>
That's the problem, "apps vary a lot." A render path that is faster on vulkan versus GL on one hardware and driver combination could easily change for either hardware or software changing
<Company>
I am very aware
<airlied>
I'd just pick vulkan where it exists
<airlied>
and move forward
<Company>
I think medium-term that's definitely the best way
<Company>
but I wonder if it's the right time for that yet
<airlied>
at least for all the desktop vendors it is
<airlied>
on mobile if you are on qualcomm it's probably fine
<airlied>
not sure on non-Linux
<Company>
macos doesn't have Vulkan ootb
<Company>
and on Windows, I suspect preferring Vulkan works, too - because the bad driver vendors don't ship Vulkan?
<HdkR>
Qualcomm is just starting to ship Vulkan there, not available on any current WoA devices there :)
<airlied>
yeah I think it's mostly fine if you have vulkan use vulkan
<Company>
I suppose I should bring that up internally too wrt RHEL10
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<Company>
a benefit of keeping GL is that the rest of the stack uses GL, too - compositor and XWayland
<Company>
so GTK won't be the odd one out
Daanct12 has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<gfxstrand>
Do wraps not work in the CI build containers?
yyds has joined #dri-devel
<gfxstrand>
NAK kinda depends on them for crates to work
<gfxstrand>
Ah, --wrap-mode=nofallback. Well, that's not gonna work...
luben has joined #dri-devel
<gfxstrand>
We'll have to chat about what to do about that in the morning
danylo has quit [Ping timeout: 480 seconds]
<cmarcelo>
for those familiar with hawkmoth/doxygen, is there an equivalent of "@file" section?
lemonzest has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
xantoz has quit [Ping timeout: 480 seconds]
moony has quit [Read error: Connection reset by peer]
moony has joined #dri-devel
luben has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.1.1]
luben has quit [Ping timeout: 480 seconds]
yyds has quit []
yyds has joined #dri-devel
lemonzest has joined #dri-devel
aravind has joined #dri-devel
xantoz has joined #dri-devel
JohnnyonFlame has joined #dri-devel
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
crabbedhaloablut has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<DemiMarie>
gfxstrand: distributions will hate you if they cannot build in nodownload mode. Fedora at least requires building against system packages.
<DemiMarie>
From a distribution PoV, C not having an easy way to use third party dependencies is a feature, not a bug. It means that programmers use dependencies sparingly.
<DemiMarie>
If you really want to make distro maintainers upset, have a security patch that bumps a dependency major version to something not in the distro, so the distro now has to bump that dependency and risk breakage.
<DemiMarie>
Personally I think Mesa should at least bundle LLVM but distros tend to not like that.
<DemiMarie>
Distros, especially LTS ones, prefer few and slow-moving dependencies, as that means less work for the distro vendor.
i-garrison has quit []
i-garrison has joined #dri-devel
Duke`` has joined #dri-devel
dviola has quit [Quit: WeeChat 4.1.1]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
aradhya7 has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
glennk has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
kts has joined #dri-devel
alpalcone has quit []
lplc has joined #dri-devel
glennk has quit [Read error: Connection reset by peer]
macslayer has quit [Remote host closed the connection]
<alyssa>
ideally we could get that warning caught in gcc/clang so it's hit before marge hits it
<alyssa>
failing that can we allow the warning in ci?
<alyssa>
./src/compiler/spirv/spirv_to_nir.c(7277): error C2220: the following warning is treated as an error
<alyssa>
../src/compiler/spirv/spirv_to_nir.c(7277): warning C4047: 'return': 'bool' differs in levels of indirection from 'void *'
<jenatali>
Yeah I would've expected GCC to hit that too
<alyssa>
wild.
<alyssa>
not upset about this one
<alyssa>
mostly. confused lol
<jenatali>
Werror has been useful for me, I don't want to turn it off
jhli_ has joined #dri-devel
<alyssa>
you are valid ^^
i509vcb has quit [Quit: Connection closed for inactivity]
robink_ has quit [Remote host closed the connection]
robink has joined #dri-devel
jhli has quit [Ping timeout: 480 seconds]
sgruszka has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
rasterman has quit [Quit: Gettin' stinky!]
heat_ has joined #dri-devel
glennk has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
guru_ has quit [Remote host closed the connection]
guru_ has joined #dri-devel
Ryback_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.1.1]
lstrano has quit [Ping timeout: 480 seconds]
<gfxstrand>
daniels: Oh, nice! Let me give that a go
itoral has quit [Quit: Leaving]
gouchi has joined #dri-devel
<gfxstrand>
DemiMarie: I plan to keep the number of dependent crates small. However, there is a suite of 4 crates that is basically required if you want to write proc macros. If distros are going to have any mechanism at all for packaging crates, they'll package those 4.
<gfxstrand>
daniels, DavidHeidelberg: Any ideas why my update to the CI script won't marge?
<gfxstrand>
It looks like CI is failing because there's nothing to CI.
<daniels>
gfxstrand: oh, hilarious, guess there's a crevice where it doesn't create any pipeline
<daniels>
the rules filter down to only the jobs which need to be run, but ... nothing needs to be run
<daniels>
you could either go through test-source-dep.yaml and find something to stick it on, or just roll it into your next MR
<pq>
hwentlan__, bwt. did Mario Kleiner ever tell you about their unsigned int 16 bpc research displays, and driving them with false-color mode because KMS hardware just can't do that deep?
<pq>
and that Linux is currently the best OS for driving those displays in spite of all the unknowns in KMS
<vsyrjala>
mario added proper 16bpc formats to kms at some point. i should probably get the i915 supported merged finally
<pq>
can HDMI, DVI-D or DP actually carry 16 bpc RGB?
<vsyrjala>
DP can, in theory. HDMI 2.0 has "16bpc" 4:2:0 iirc
<pq>
is there i915 hardware that can deliver 16 bpc to display, too? or would the kernel driver somehow encode that as 8 bpc double-wide image or something?
<pq>
I understood that Mario has displays that expect 8 bpc double-wide image ("false-color"), and display that as 16 bpc single-wide image.
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
sgruszka_ has joined #dri-devel
<vsyrjala>
i don't think we have support for 16bpc output even in the latest hw. so yeah, you'd still need magic tricks to make it happen
<gfxstrand>
dcbaker: Could you glance at the top half-dozen patches or so of my NAK MR when you get the chance. It's building in CI now and I would love to assign it to Marge. :)
<gfxstrand>
But I'd also like review in case I'm committing grave meson or CI sins.
<gfxstrand>
I just threw the CI and meson tags on it too in case someone else wants to take a look
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
yuq825 has left #dri-devel [#dri-devel]
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
kzd has joined #dri-devel
macslayer has joined #dri-devel
macslayer has quit []
macslayer has joined #dri-devel
greenjustin has joined #dri-devel
bmodem has joined #dri-devel
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
ced117 has quit [Ping timeout: 480 seconds]
lstrano has joined #dri-devel
tarceri has quit [Remote host closed the connection]
simon-perretta-img has quit [Ping timeout: 480 seconds]
tarceri has joined #dri-devel
Haaninjo has joined #dri-devel
simon-perretta-img has joined #dri-devel
<dcbaker>
gfxstrand: Reviewed. It looks like everything else I'd noticed had already been spotted by other people. I had one minor question, but otherwise things looked good to me
Company has joined #dri-devel
gouchi has joined #dri-devel
Ryback_ has joined #dri-devel
Aura has joined #dri-devel
anholt has joined #dri-devel
cmichael has quit [Quit: Leaving]
gouchi has quit [Quit: Quitte]
Duke`` has joined #dri-devel
<gfxstrand>
dcbaker: You happy with daniels' answer?
<dcbaker>
gfxstrand: yeah
<dcbaker>
locking to an RC makes me nervous, but I guess it isn't too big of a deal to update it to a non-rc later
<gfxstrand>
Would you look at that! I have a 32-bit driver :tada:
<gfxstrand>
dcbaker: Yeah, I'm fine with bumping to a real version the moment the RC is done.
<dcbaker>
sounds like a plan to me
<gfxstrand>
I should probably test said 32-bit driver before I declare total victory but the fact that it linked is encouraging.
<alyssa>
dcbaker: btw, is clc on i386 going to kabloom?
* dcbaker
hopes not
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
sgruszka_ has quit [Remote host closed the connection]
Ahuj has quit [Ping timeout: 480 seconds]
<alyssa>
k
<alyssa>
ty
<gfxstrand>
Okay, we're assigning this mess to Marge.
<gfxstrand>
Looks like there's two things ahead of it in the queue.
<gfxstrand>
Something something a watched MR never merges...? ¯\_(ツ)_/¯
<alyssa>
real
greenjustin_ has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
<mattst88>
I'm working on updating vulkan-cts from 1.3.6.0 to 1.3.7.1 in ChromeOS and 1.3.7.1 seems massively slower than 1.3.6.0 -- is that known or expected?
<Sachiel>
shader object tests got added there, I think
<Sachiel>
so there's roughly double the number of tests
<mattst88>
okay, thanks
<Sachiel>
my usual deqp-runner runs on one machine went from ~1:10 hours to ~2. 50 extra minutes of largely NotSupported tests
<mattst88>
looks like on a TGL 1135 the estimated duration goes from 1:15 to like 5 hours :(
<Sachiel>
that... is a bit too much
<daniels>
mattst88: yep, can confirm
<daniels>
that's the fast one too. 1.3.7.0 was worse
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<mattst88>
ouch
mbrost has joined #dri-devel
<mattst88>
are there any significant perf improvements in deqp-runner since 0.16.1?
mlankhorst has joined #dri-devel
dviola has joined #dri-devel
mlankhorst has quit [Read error: Connection reset by peer]
mlankhorst has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<gfxstrand>
mattst88: Yeah, ESO did a number on the CTS
<DemiMarie>
Why do e.g. browsers not have VA-API support?
vliaskov has quit [Remote host closed the connection]
<alyssa>
7
<alyssa>
the number it did was 7
<alyssa>
("7 what?" "7.")
aradhya7 has quit [Quit: Connection closed for inactivity]
bmodem has quit [Ping timeout: 480 seconds]
<mattst88>
DemiMarie: I think FF and Chrome do
<DemiMarie>
mattst88: Chrome doesn’t support it officially.
rasterman has joined #dri-devel
<DemiMarie>
How useful is acceleration for free codecs only.
<DemiMarie>
If acceleration with free codecs only is not worthwhile, then the answer is probably flatpaks from places where software patents are invalid.
lstrano has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
lstrano has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
<Lynne>
it's useful now that av1 has become somewhat widespread
aswar002_ has quit []
aswar002 has joined #dri-devel
<gfxstrand>
dcbaker: It'd be cool if you could take one more look at the top patch.
<gfxstrand>
Unless you trust me to write meson...
Ryback_ has joined #dri-devel
<gfxstrand>
(Narrator: He really shouldn't)
<gfxstrand>
If you're happy with that, I'll rebase it in so my git branches never existed
<jenatali>
Ugh. Why is there a "create merge request" button on an issue? How is that ever a useful thing to do straight from an issue page?
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
lstrano has quit [Ping timeout: 480 seconds]
<gfxstrand>
I don't know...
<daniels>
it's primarily intended for one-liners and smaller changes, where you can usefully and quickly do it from the web IDE
<daniels>
Mesa is obviously not that project
<Company>
I use it for docs typos or updates of links in docs all the time
Ryback_ has joined #dri-devel
<jenatali>
I mean, I get going to the web editor first and creating a MR from there, but starting from an issue seems wrong 🤷♂️
glennk has joined #dri-devel
agd5f_ has joined #dri-devel
lstrano has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
i509vcb has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
<HdkR>
Would be nice if Chrome had runtime selection between vaapi and v4l2 rather than compile time
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
<greenjustin>
Are there any devices that support both simultaneously?
<HdkR>
Bigger issue is packaging, you have to select one versus the other
ced117 has joined #dri-devel
<gfxstrand>
Are there non-Intel devices that support va-api?
<greenjustin>
Ah, I see why that would annoying for mainline.
<greenjustin>
AMD
lstrano has quit [Ping timeout: 480 seconds]
<gfxstrand>
I mean, generally anything you're likely to see on x86 isn't going to have v4l2 and anything you're likely to see on arm isn't going to have va-api
<gfxstrand>
So it's maybe not as big of a problem as it sounds
<gfxstrand>
It's still pretty terrible that they have code for both and can't select at runtime.
Ryback_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<greenjustin>
Cuts the binary size a little I suppose.
iive has joined #dri-devel
<mareko>
VAAPI is the main video API for AMD
<airlied>
vulkan video will solve it all :-P
<mareko>
ok, I'll hold your beer (and drink it)
<greenjustin>
I think we just need more video APIs in general. Two isn't enough to maintain, we gotta pump up those numbers :-P
<mareko>
3
<mareko>
VDPAU and OpenMAX
<mareko>
and the latter is required by Android
<mareko>
and then Vulkan, so 4
<greenjustin>
Still too few. We need at least a dozen competing standards imho.
phire has quit [Remote host closed the connection]
<anarsoul>
mareko: NVDEC/NVENC?
<mareko>
4 non-vendor-specific ones
<anarsoul>
and for v4l2 there are stateful and stateless decoders
phire has joined #dri-devel
<greenjustin>
Yeah and I think you can make the case that stateful V4L2 isn't exactly a single API
<Company>
mareko: while you're here and talking about video stuff
<Company>
mareko: I've been playing with imprting dmabufs into EGL/Vulkan and AMD has this annoying stride limit
<mareko>
indeed
<Company>
mareko: what's the recommended way to deal with that?
<mareko>
set it to 256
<Company>
assuming I can't do that
<mareko>
or rather aligne to that number
<Company>
because I get the dmabufs from pipewire or wherever
<emersion>
ideally there would be stride negotiation
<airlied>
tell them to set it to 256
<Company>
also, how would I know that requirement? Vulkan and EGL don't tell me - or I haven't found it
<emersion>
(1) travel to the future (2) use buffer allocation constraints
<airlied>
I think it's one of those just make everyone use 256, and hope hw manufacturers don't go 512
<mareko>
gfx6-9 can set any stride that's reasonable (not byte alignment by small enough that it shouldn't bother you), gfx10.1 (Navi1x) must use 256 alignment, gfx10.3-gfx11.x can set any N*256 alignment, in the future it will be dropped to N*128
<mareko>
*but small enough
coiaur^ has joined #dri-devel
<mareko>
you can also import the image as a buffer and do your own addressing in the shader
<Company>
in Vulkan I can probably also allocate a new image and doing a buffer copy
<mareko>
that too
<Company>
but I was mostly wondering what the recommended way to deal with it is from your side
<Company>
so I don't implement something that's considered a bad idea
<mareko>
the stride alignment is a hw constraint, nothing you can do about
<Company>
is 256 the highest one there is?
<Company>
or do some drivers require even more?
<airlied>
the recommended way is to realise we screwed up and go back and add stride negotiation
<airlied>
but now 256 seems to be where things are at
<Company>
I'm considering filing bugs against pipewire etc to make all its plugins use 256
<mareko>
the best workaround is to set the image width in bytes to N*256 in the source device
<gfxstrand>
We hard-code 256 lots of places
<gfxstrand>
Is that good? No. Does it work? Yes.
<Company>
so the best solution is (1) try and make everyone use 256, (2) write a generic fallback that handles the cases where that doesn't work
<mareko>
yes
<mareko>
(3) get a time machine and tell hw folks what to do 7 years ago
coiaur^ has quit [Ping timeout: 480 seconds]
coiaur^ has joined #dri-devel
<gfxstrand>
And hope they listen. (-:
<Company>
ndufresne: ^^^ backlog of last 15 minutes might be interesting for you
<ndufresne>
oh
<ndufresne>
Yeah, you can try and do system wide 256, happy patching though ;-P
<ndufresne>
V4L2 have stride negotiation, but some highly used driver don't implement it for no good reason (UVC)
<ndufresne>
I'm not really aware of HW that can't deal with that kind of alignment, but CODEC and blitter engineers can be creatives
<ndufresne>
and you basically depends on driver maintainer to fix it here ;-P
<Company>
ndufresne: it's mostly about "if given the choice, make sure that choice is taken"
<Company>
once it's common enough, people will remember to do it automatically
<ndufresne>
yeah, "if given the choice"
<ndufresne>
you might hit a wall with ARM devs, that consider RAM precious
<ndufresne>
(even though the RAM delta here is marginal I think)
<Company>
my camera does 640x480 - that'd be 20% extra
<ndufresne>
anyway, this "idea" will require tones of patching, its possible, but not as easy as when everything is concealed into mesa
<gfxstrand>
256B, not 256 pixels
<ndufresne>
if you camera do I420 ?
<Company>
gfxstrand: everything uses NV12
<gfxstrand>
Right...
* gfxstrand
is thinking RGBA8
<ndufresne>
kind of, cameras more naturally do packed, like YUY2
<gfxstrand>
but noooo those fancy video people and their YUV formats...
<gfxstrand>
hehe
<Company>
I think most drivers handle RGBA8 fine
<Company>
with any stride
<ndufresne>
in CODEC, sometimes reference frames format is stiff, but most of the time you endup using post processed buffer, and these are usually very flexible
<jenatali>
gfxstrand: Windows has va-api support now, including a VaOn12 video mapping layer :)
<ndufresne>
indeed, saw couple of gst patches recently
<Company>
though all the RGBA8 I got so far was from inside Mesa - with a few exceptions where I manually created something with /dev/dma_heap
<ndufresne>
which make sense no ?
<ndufresne>
cameras and codec all works mostly in YUV, and VA postproc are most of the time implemented by Mesa (on AMD I think these are just shaders)
<daniels>
jenatali: woah, vaon12 shipped?
<Company>
still, it's a bit meh that stride 1 works for R8 buffers, but not for NV12
Kwiboo has quit [Read error: Connection reset by peer]
Kwiboo has joined #dri-devel
<jenatali>
kisak: I believe the Windows target is different than the Linux target, yeah
<gfxstrand>
jenatali: Vulkan video in dozen when?
<jenatali>
I haven't looked at it... might be easy, might be nigh impossible
<kisak>
oh, that's where my undercaffinated brain misfired, win32/windows versus WSL2/windows. Oops.
<jenatali>
gfxstrand: As for when, once someone important needs Vulkan video
<jenatali>
kisak: Right, this blog is primarily about native Win32 support. Pretty sure we had a different one a while back for WSL video hardware acceleration
luben has joined #dri-devel
<jenatali>
Oh, "a while back" being 2 days earlier lol
mvlad has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
jkrzyszt has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
cmtaur^ has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<daniels>
jenatali: nice!
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
cef has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
cmtaur^ has quit [Remote host closed the connection]
<kchibisov>
Is it valid for glGetString to return a NULL?
<karolherbst>
yes
<karolherbst>
"If an error is generated, glGetString returns 0. "
<kchibisov>
huh, I was searching for NULL or something, but it just says 0 for pointer.
<kchibisov>
¯\_(ツ)_/¯
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
luben has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<mattst88>
FWIW, it looks like the number of tests executed in vulkan-cts-1.3.6.0 is 1077400 and the number in 1.3.7.1 is 3974726 /o\
mbrost has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
diego has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
<jenatali>
That's a big oof
<airlied>
yeah cts itself spend a lot of time just generating test names now
<airlied>
make sure to build release cts, otherwise you hit this horrible string compare of every test name at start
<robclark>
I guess -Dtools=all could be a bit more clever about not building tools for drivers that are not built, but that is probably more than a couple line fix (and pre-existing bug/misfeature)
Mangix has quit [Ping timeout: 480 seconds]
diego has quit []
Mangix has joined #dri-devel
mbrost has joined #dri-devel
T_UNIX has quit [Ping timeout: 480 seconds]
kelbaz[m] has quit [Ping timeout: 480 seconds]
nick1343[m] has quit [Ping timeout: 480 seconds]
tintou has quit [Ping timeout: 480 seconds]
Newbyte has quit [Ping timeout: 480 seconds]
msizanoen[m] has quit [Ping timeout: 480 seconds]
Targetball[m] has quit [Ping timeout: 480 seconds]
talcohen[m] has quit [Ping timeout: 480 seconds]
Anson[m] has quit [Ping timeout: 480 seconds]
Sumera[m] has quit [Ping timeout: 480 seconds]
zzxyb[m] has quit [Ping timeout: 480 seconds]
JosExpsito[m] has quit [Ping timeout: 480 seconds]
MotiH[m] has quit [Ping timeout: 480 seconds]
tak2hu[m] has quit [Ping timeout: 480 seconds]
swick[m] has quit [Ping timeout: 480 seconds]
tleydxdy has quit [Ping timeout: 480 seconds]
heftig has quit [Ping timeout: 480 seconds]
exp80[m] has quit [Ping timeout: 482 seconds]
aura[m] has quit [Ping timeout: 480 seconds]
yshui` has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 482 seconds]
dcbaker has quit [Ping timeout: 482 seconds]
daniliberman[m] has quit [Ping timeout: 482 seconds]
ttayar[m] has quit [Ping timeout: 480 seconds]
undvasistas[m] has quit [Ping timeout: 480 seconds]
dhirschfeld2[m] has quit [Ping timeout: 480 seconds]
BilalElmoussaoui[m] has quit [Ping timeout: 480 seconds]
shoffmeister[m] has quit [Ping timeout: 480 seconds]
Hazematman has quit [Ping timeout: 480 seconds]
pankart[m] has quit [Ping timeout: 480 seconds]
gallo[m] has quit [Ping timeout: 480 seconds]
AlaaEmad[m] has quit [Ping timeout: 480 seconds]
sergi1 has quit [Ping timeout: 480 seconds]
Armote[m] has quit [Ping timeout: 480 seconds]
tomeu has quit [Ping timeout: 480 seconds]
hch12907 has quit [Ping timeout: 480 seconds]
robertmader[m] has quit [Ping timeout: 480 seconds]
zamundaaa[m] has quit [Ping timeout: 482 seconds]
x512[m] has quit [Ping timeout: 480 seconds]
aradhya7[m] has quit [Ping timeout: 480 seconds]
treeq[m] has quit [Ping timeout: 482 seconds]
orowith2os[m] has quit [Ping timeout: 482 seconds]
doras has quit [Ping timeout: 482 seconds]
Mershl[m] has quit [Ping timeout: 482 seconds]
ofirbitt[m] has quit [Ping timeout: 482 seconds]
masush5[m] has quit [Ping timeout: 482 seconds]
nicofee[m] has quit [Ping timeout: 482 seconds]
ids1024[m] has quit [Ping timeout: 482 seconds]
cmeissl[m] has quit [Ping timeout: 482 seconds]
go4godvin has quit [Ping timeout: 480 seconds]
moben[m] has quit [Ping timeout: 480 seconds]
kallisti5[m] has quit [Ping timeout: 480 seconds]
MayeulC has quit [Ping timeout: 480 seconds]
Quinten[m] has quit [Ping timeout: 482 seconds]
enick_991 has quit [Ping timeout: 482 seconds]
enunes[m] has quit [Ping timeout: 482 seconds]
dabrain34[m]1 has quit [Ping timeout: 482 seconds]
pp123[m] has quit [Ping timeout: 480 seconds]
tomba has quit [Ping timeout: 480 seconds]
kos_tom has quit [Ping timeout: 480 seconds]
koki23[m] has quit [Ping timeout: 480 seconds]
reactormonk[m] has quit [Ping timeout: 480 seconds]
Ella[m] has quit [Ping timeout: 480 seconds]
viciouss[m] has quit [Ping timeout: 480 seconds]
q4a has quit [Ping timeout: 480 seconds]
jtatz[m] has quit [Ping timeout: 480 seconds]
kunal_10185[m] has quit [Ping timeout: 480 seconds]
kusma has quit [Ping timeout: 480 seconds]
znullptr[m] has quit [Ping timeout: 480 seconds]
DemiMarie has quit [Ping timeout: 480 seconds]
pushqrdx[m] has quit [Ping timeout: 480 seconds]
samueldr has quit [Ping timeout: 483 seconds]
zzoon_OOO_till_03_Oct[m] has quit [Ping timeout: 483 seconds]
dantob has quit [Ping timeout: 480 seconds]
ram15[m] has quit [Ping timeout: 480 seconds]
ella-0[m] has quit [Ping timeout: 480 seconds]
K0bin[m] has quit [Ping timeout: 480 seconds]
Guest4515 has quit [Ping timeout: 480 seconds]
nyorain[m] has quit [Ping timeout: 480 seconds]
bylaws has quit [Ping timeout: 480 seconds]
fkassabri[m] has quit [Ping timeout: 483 seconds]
vidal72[m] has quit [Ping timeout: 483 seconds]
vdavid003[m] has quit [Ping timeout: 483 seconds]
ohadsharabi[m] has quit [Ping timeout: 483 seconds]
halfline[m] has quit [Ping timeout: 480 seconds]
isinyaaa[m] has quit [Ping timeout: 480 seconds]
EricCurtin[m] has quit [Ping timeout: 480 seconds]
bubblethink[m] has quit [Ping timeout: 480 seconds]
Vin[m] has quit [Ping timeout: 480 seconds]
siddh has quit [Ping timeout: 480 seconds]
naheemsays[m] has quit [Ping timeout: 480 seconds]
KunalAgarwal[m][m] has quit [Ping timeout: 483 seconds]
nielsdg has quit [Ping timeout: 483 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
gdevi has quit [Ping timeout: 480 seconds]
ajhalaney[m] has quit [Ping timeout: 480 seconds]
jasuarez has quit [Ping timeout: 480 seconds]
enick_185 has quit [Ping timeout: 480 seconds]
sigmoidfunc[m] has quit [Ping timeout: 480 seconds]
doraskayo has quit [Ping timeout: 480 seconds]
egalli has quit [Ping timeout: 483 seconds]
jenatali has quit [Ping timeout: 483 seconds]
anfanite396[m] has quit [Ping timeout: 483 seconds]
knr has quit [Ping timeout: 483 seconds]
YHNdnzj[moz] has quit [Ping timeout: 483 seconds]
Vanfanel has quit [Ping timeout: 483 seconds]
FloGrauper[m] has quit [Ping timeout: 483 seconds]