leandrohrb has quit [Remote host closed the connection]
fahien2 has quit [Remote host closed the connection]
italove has joined #dri-devel
italove has quit [Remote host closed the connection]
leandrohrb has joined #dri-devel
leandrohrb has quit [Remote host closed the connection]
sdutt_ has quit [Ping timeout: 480 seconds]
<gawin>
anholt_: maybe for r600 some thin client based on AMD G-T44R (9tdp for both cpu/gpu but only one cpu core) like for example futro s900 (I have one but unfortunately I don't have no place for hosting CI)
italove has joined #dri-devel
<gawin>
anholt_: with r300 it's more tricky, just chipset with igpu has tdp 14w and there's no combo igpu + small efficient cores (seen mostly motherboards with socket 754 or 939)
<hakzsam>
jekstrand: well the vk_object_base_init/finish logic is basically broken for internal meta operations
slattann has quit []
tomeu has joined #dri-devel
lynxeye has joined #dri-devel
danvet has joined #dri-devel
pcercuei has joined #dri-devel
Ahuj has joined #dri-devel
slattann has joined #dri-devel
frieder has joined #dri-devel
frieder_ has quit [Read error: Connection reset by peer]
slattann has quit []
slattann has joined #dri-devel
shadeslayer has joined #dri-devel
join_subline has quit [Remote host closed the connection]
join_subline has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
Akari has joined #dri-devel
elongbug has joined #dri-devel
camus has joined #dri-devel
join_subline has quit [Remote host closed the connection]
camus1 has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
join_subline has joined #dri-devel
fahien2 has joined #dri-devel
fahien2 is now known as fahien
vivijim has joined #dri-devel
columbarius has joined #dri-devel
lemonzest has joined #dri-devel
itoral has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
<karolherbst>
danvet, airlied: regarding maintaining the CI files in-tree. Do you have a preference on the name etc..? .* is gitignored, but we could add our own .gitignore file inside drivers/gpu/drm with !.gitlab-ci* or so
<karolherbst>
any preferences here?
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<airlied>
karolherbst: do we want to maintain them in tree, I'm not sure they'd be accepted upstream, but maybe danvet has some better ideas
<MrCooper>
karolherbst: gitlab-ci.yml with no dot?
<MrCooper>
that's what we use in Mesa
<karolherbst>
MrCooper: well, we can do this as well, I just think that people prefer using dots to preorder the annoying files away
<karolherbst>
no
<karolherbst>
in mesa we use .gitlab-ci.yml
<MrCooper>
ll **/*.yml disagrees
<MrCooper>
Mesa puts them under ci/ subdirectories, maybe something like that could work for the kernel as well
<karolherbst>
what are you talking about?
<karolherbst>
it's all inside .gitlab-ci
<karolherbst>
and the root ci file is .gitlab-ci.yml
<karolherbst>
ls: cannot access '**/*.yml': No such file or directory
itoral has quit [Remote host closed the connection]
<MrCooper>
try zsh or "find -name \*.yml" then
<karolherbst>
airlied: we've discussed this with danvet at some point and I think Daniel was fine with moving it in-tree, but maybe we should discuss this again before I rely on anything here
<karolherbst>
MrCooper: doesn't change that we have all prefixed with a dot
<karolherbst>
mhh
<MrCooper>
do we? :)
<karolherbst>
we just have driver files we do include
<karolherbst>
we still have the dot ones
<karolherbst>
sooo
<karolherbst>
we have to set a custom path anyway, because we can't use /.gitlab-ci.yml
<MrCooper>
exactly
<karolherbst>
so not using dots _might_ be feasible, but in mesa we rely on ./.gitlab-ci.yml :D
<karolherbst>
and that's prefixed with a dot
<MrCooper>
.gitlab-ci.yml will be the final boss
<karolherbst>
sure
<karolherbst>
I think not using dot is fine, but using it gives us the advantage that the files are sorted
<karolherbst>
and the gitlab files are not in the middle or something
<MrCooper>
hence a subdirectory
<karolherbst>
then ci/ is in the middle
<karolherbst>
but I mean.. in the end it doesn't matter
<karolherbst>
I was just asking for a preference anyway
<MrCooper>
seems fine in Mesa?
linearcannon has quit [Remote host closed the connection]
linearcannon has joined #dri-devel
<HdkR>
Looks like I've resolved all my pointer ownership issues with xcb \o/
<HdkR>
Just run three globally visible memory allocators at any given moment to flush out the bugs. EZ :P
thellstrom has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
<danvet>
karolherbst, I still think it's fine in-tree
<danvet>
just maybe as a separate pull and heads-up for linus and not sneaking in
<danvet>
karolherbst, MrCooper I think drivers/gpu/ci is fine and probably less triggers for Linus "this is ugly" senses
<danvet>
also would give maybe a more clear path to eventually move stuff into scripts/gitlab-ci or so
<danvet>
airlied, ^^ was my thinking at least on this
<danvet>
airlied, I also think we can make a solid case that ci stuff (like broken testcase lists) should be included with the code pull and not separate
gawin has joined #dri-devel
DPA- has joined #dri-devel
<ogabbay>
748578
<ogabbay>
sorry, please ignore
DPA has quit [Ping timeout: 480 seconds]
<HdkR>
Oops, 2FA pins :P
<ogabbay>
hehe
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
slattann has quit []
Lucretia has quit []
DPA has joined #dri-devel
Lucretia has joined #dri-devel
DPA- has quit [Ping timeout: 480 seconds]
DPA- has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
DPA has joined #dri-devel
DPA- has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
DPA- has joined #dri-devel
sdutt has joined #dri-devel
<jekstrand>
hakzsam: In what way?
<jekstrand>
hakzsam: I know there are a couple ways in which it might be problematic but I didn't expect anything fundamental.
<jekstrand>
Other drivers are using it fine
DPA has quit [Ping timeout: 480 seconds]
<jekstrand>
hakzsam: I know the trick I did for vk_error with marking "client-visible" objects via object_to_handle is a little on the busted side.
<hakzsam>
most of the internal objects created for meta operations don't use the VkCreateXXX() helpers, so the base object type isn't initialized and it asserts when you try to get handles
<jekstrand>
Ah
<jekstrand>
Do you stick them on the stack and radv_init_foo()?
<hakzsam>
yes
<jekstrand>
Ah
<hakzsam>
so, there is two solutions: 1) add few radv_object_init/finish() helpers and keep them in the stack 2) use VkCreateXXX() directly for meta operations
<jekstrand>
Right
<jekstrand>
keeping them on the stack seems fine
<jekstrand>
Oh, so are you using initializers to init them instead of calling a function?
<hakzsam>
yes
<jekstrand>
Yeah, I can see how that'd be really convenient for certain objects.
<hakzsam>
vkCreateXXX() is like alloc->init->get_handle
<jekstrand>
We already struggled through that a bit with vk_shader_module
<jekstrand>
And.... I just realized vk_shader_module_handle_from_nir is busted...
<hakzsam>
I will finish solution #1 then
<hakzsam>
it's just a bit annoying to have to call finish() everywhere
DPA- has quit []
<jekstrand>
Yeah... :-(
<jekstrand>
hakzsam: You could also add versions of the entrypoints that just take a pointer.
<jekstrand>
If it's a couple specific things
<jekstrand>
But if it's something like image views, you wouldn't want to duplicate all the descriptor fill structs.
<jekstrand>
Maybe the GL headers aren't getting pulled in for some reason?
<dj-death>
but most of the nir stuff would fail to compile then
<dj-death>
that's not the case
<dj-death>
I bet I need to include glsl_types.h first
<jenatali>
Huh, nir.h has GL/gl.h, so GLenum should be there
Anorelsan has joined #dri-devel
<jenatali>
dj-death: clc_helpers.h is included before nir.h, and clc_helpers.h includes nir_types.h as its first thing. clc_helpers.h should include nir.h first I think
<jenatali>
dj-death: Once you add #include "nir.h" to the top of that header, the build and clon12compiler tests are passing for me :)
<dj-death>
yeah, let me try
<dj-death>
I've replicated what was in clc_compiler.c
<dj-death>
yep compiles \o/
<jenatali>
dj-death: Cool, once you push a working one I'm happy to give a final sign-off and then as far as I'm concerned let's merge it
<jenatali>
I don't think there's any other stakeholders on that besides jekstrand?
<dj-death>
just us indeed
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<ajax>
hmph. neither gen3 driver can draw weston correctly.
<alyssa>
ajax: ...it's weston. what exactly is there to get wrong
<ajax>
channel swizzles, apparently
Company has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<alyssa>
uff
sukbeom has joined #dri-devel
<ajax>
in both gl and gles modes, which is extra surprising
<ajax>
(measured by forcing big-gl to 1.5 so itd use gles2 instead)
<pq>
weston does not have a big-gl mode, so what do you mean?
mattrope has joined #dri-devel
<ajax>
could have sworn i saw the renderer string change in the log...
<ajax>
regardless, mutter definitely has both paths and looks exactly the same kind of wrong
<pq>
maybe weston changed between GL ES 2 and 3? which wouldn't change much if anything at all IIRC
camus1 has quit [Ping timeout: 480 seconds]
<dj-death>
jenatali: looks like I'll have to fix the clang/llvm detection on linux :(
macromorgan has joined #dri-devel
DPA has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
<dj-death>
jenatali: do you link statically with llvm?
<jenatali>
dj-death: yeah, LLVM doesn't build DLLs for Windows
<dj-death>
okay
shashank1202 has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
DPA has joined #dri-devel
DPA- has joined #dri-devel
camus has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
tomeu has quit []
iive has joined #dri-devel
Duke`` has joined #dri-devel
linearcannon has quit [Read error: Connection reset by peer]
<robclark>
airlied, karolherbst: I was leaning towards drivers/gpu/drm/ci (in-tree) but with an out of tree thing controlling which CI jobs are run (so we can disable jobs when runners are offline without needing kernel commit)... ie. something along the lines of https://gitlab.freedesktop.org/mesa/mesa/-/issues/5303
<robclark>
danvet: ^^^
<karolherbst>
yeah, makes sense
any1 has joined #dri-devel
gawin has joined #dri-devel
linearcannon has joined #dri-devel
DPA- has quit [Ping timeout: 480 seconds]
DPA has joined #dri-devel
<daniels>
++
linearcannon has quit [Remote host closed the connection]
linearcannon has joined #dri-devel
<danvet>
robclark, ah yes runner control outside makes sense
<danvet>
I was thinking of pure sw stuff like kunit/selftest or firing up a virtual machine with vkms+vgem and running igt
<karolherbst>
robclark: so I guess we will just create yml files as drivers/gpu/drm/$driver_name.yml or so?
<danvet>
these pieces imo should be all in the kernel
<karolherbst>
or subdirectories for each driver?
<MrCooper>
I'd suggest the latter
<danvet>
karolherbst, build testing imo should be all the same
<danvet>
but testing per-driver I gues makes sense
<MrCooper>
based on experience from Mesa, one file per driver may not suffice in the long run
<karolherbst>
danvet: well. kernel configs and the fun around that
<danvet>
karolherbst, yeah, but the thing is if you do this per driver the combinatorial explosion is real bad
<karolherbst>
I know :/
<danvet>
like most drivers need to be build-tested on a bunch of platforms, with a bunch of different configs
<danvet>
if we then multiply that with the 50 drivers we have we can't pay the CI bill for that
<danvet>
even with caching and everything
<robclark>
we probably don't need different builds/jobs for *each* driver (in particular build jobs, but we should be able to use same kernel build for hw tests on different drivers
<karolherbst>
I could start with a drivers/gpu/drm/ci/nouveau.yml file and if we need subdirectories later we can always add those or so
<robclark>
(but only got so far as build tests, not tests on actual hw.. but now we have some msm igt tests, I want to get around to hw tests)
<robclark>
so maybe we separate out different files per arch (for build jobs) and then start adding driver specific files as we start adding hw tests?
<karolherbst>
I will keep the patch local for now anyway
<karolherbst>
as I am sure we don't want merge commits in drm-misc, so I have to force push regularly anyway
<karolherbst>
robclark: the issue is, that testing will get annoying. Like your checkpatch won't work :)
<robclark>
I don't really want checkpatch, as much as just the checks that dim does
<karolherbst>
yeah...
<karolherbst>
checkpatch is painful
<karolherbst>
I think we may have to start fixing it
<robclark>
so I don't have to keep checking manually that fixes tags I get from qcom are actually *upstream* commit sha's :-P
<karolherbst>
I mean.. it can't be that the return code is 1 for "only warnings" and "there is an error"
<robclark>
using checkpatch with a bunch of disable flags was my workaround for not wanting to re-write dim ;-)
<karolherbst>
I think most of the checks there are great, but some drivers might want to ignore different warnings/errors
<karolherbst>
the problem is rather... pointless stuff will fail CI
<karolherbst>
robclark: you also want "FUNCTION_ARGUMENTS,FILE_PATH_CHANGES" btw
<karolherbst>
maybe not the ... well the former as well.. it's just annoying :D
<karolherbst>
but the file patch changes one is super annoying
<karolherbst>
*path
<karolherbst>
as it is important.. in case it is, but in most cases we can ignore it
<robclark>
yeah, I could have missed some.. I really don't actually like checkpatch.. but it was ok for a quick prototype when I had a couple free hours
<karolherbst>
yeah...
<karolherbst>
I think it's good though
<karolherbst>
just maybe we shouldn't fail CI
<karolherbst>
I think seeing the warnings is good as this can make some developers getting rid of bad habits
<robclark>
yeah, I think we can somehow make it just a warning
<karolherbst>
like assignments in if clauses :D
<karolherbst>
maybe we should have a list of warnings we want to fail CI for sure
<karolherbst>
and the others are just "yeah.. if you want, fix it"
<robclark>
yeah, we can probably just run it multiple times, once only enabling things which should be errors, and once with things that should be warnings?
xexaxo has quit [Read error: No route to host]
<karolherbst>
I already run it three times :D
xexaxo has joined #dri-devel
<karolherbst>
but yeah
<karolherbst>
that's my strategy
<karolherbst>
I just run it twice to generate proper logs to give it to the user and a last time ignoring some warnings
<karolherbst>
but then we have to tell the user which warnings are the critical ones...
<karolherbst>
robclark: I have an idea...
<robclark>
does it involve hacking on perl? :-|
<karolherbst>
no
linearcannon has quit [Read error: No route to host]
<karolherbst>
--types (list all types here) ...
<karolherbst>
and then we just remove the ones which are annoying
<karolherbst>
but....
<karolherbst>
you can't generate the list of all types..
linearcannon has joined #dri-devel
<gawin>
hello, how can I get log of desktop environment? I've tried adding "export MESA_LOG_FILE=.." to bashrc but doesn't seem to work
<gawin>
ofc .. is some path to file
nchery has joined #dri-devel
<karolherbst>
robclark: I will prototype something in my CI file and see if I can make it work in a non annoying way...
<robclark>
ok, cool
<ajax>
who wants to confess to understanding wsi/x11
<ajax>
in particular the comment about * Once we have a nonblocking acquire that returns a semaphore we can merge
<ajax>
'cause i can give you that. i think.
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
DPA- has joined #dri-devel
linearcannon has quit [Remote host closed the connection]
<vsyrjala>
someone borked drm-tip
<vsyrjala>
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘i915_ttm_move’:
<vsyrjala>
../drivers/gpu/drm/i915/gem/i915_gem_ttm.c:576:44: error: ‘TTM_PAGE_FLAG_ZERO_ALLOC’ undeclared (first use in this function); did you mean ‘TTM_TT_FLAG_ZERO_ALLOC’?
linearcannon has quit [Remote host closed the connection]
linearcannon has joined #dri-devel
slattann has joined #dri-devel
linearcannon has quit [Read error: Connection reset by peer]
linearcannon has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
slattann has quit []
sukbeom has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
gouchi has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
mbrost has joined #dri-devel
kmn has quit [Quit: Leaving.]
slattann has joined #dri-devel
jessica_24 has joined #dri-devel
frieder has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
nehsou^ has quit [Ping timeout: 480 seconds]
nehsou^ has joined #dri-devel
linearcannon has quit [Read error: Connection reset by peer]
slattann has quit []
<ajax>
pq: there's no question of doing gles3 on i915, so i don't think that's it.
<gawin>
hmm, r400 on r300 is failing sanity checks because doesn't recognize ddx/ddy of tgsi
<Venemo>
gawin: maybe journalctl?
<gawin>
r500 has equivalent mdh, mdv instructions for these opcodes, r300/r400 is just throwing dummy shader
<gawin>
Venemo: gonna upload in a minute
<Venemo>
I meant that as a reply to your previous question about logs
elongbug has quit [Ping timeout: 480 seconds]
<gawin>
ops, sorry ;)
cwfitzgerald[m] has quit []
cwfitzgerald[m] has joined #dri-devel
cwfitzgerald[m] is now known as cwfitzgerald
<cwfitzgerald>
Does UPDATE_AFTER_BIND have signifigant cost to intel chips?
alyssa has left #dri-devel [#dri-devel]
X-Scale` has joined #dri-devel
thellstrom has joined #dri-devel
X-Scale has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Ping timeout: 480 seconds]
Anorelsan has quit [Quit: Leaving]
pnowack has quit [Quit: pnowack]
lemonzest has quit [Quit: WeeChat 3.2]
<glennk>
gawin, r400 doesn't support ddx/ddy, the driver doesn't set PIPE_CAP_FRAGMENT_SHADER_DERIVATIVES unless its r500
<airlied>
danvet: my main worry with having them in-tree is they are from memory pretty specific to the fd.o gitlab, so not much use say for kernelci etc, but happy to experiment
<danvet>
airlied, yeah, but also drm isn't going to move to some other gitlab ...
<danvet>
also maybe linus squints over that part :-)
<karolherbst>
the main issue is just maintaining it out of tree is painful :(
<danvet>
yeah
<danvet>
also even on other CI we might have some room to share scripts and stuff
<danvet>
and move them under scripts/ if there's interest
<danvet>
that's much easier to do if these things are in-tree
<karolherbst>
yeah
<airlied>
but yeah we definitely don't want the fdo runner controls built in, the commits logs would be rather messy
mlankhorst has quit [Ping timeout: 480 seconds]
alexeymin has joined #dri-devel
<Venemo>
mareko Can we talk about that DCC patch? The Flatpak devs are very concerned that this will break them
<Venemo>
They can't guarantee that the app will use the same mesa version as the host
Hi-Angel has joined #dri-devel
enilflah is now known as halfline
<gawin>
glennk: are ddx/ddy must have (only way) for gl2.0? or it's something weird with tgsi (that is pushing ddx/ddy into r300 when it shouldn't)?
<glennk>
don't know, its an optional feature cap in dx9
ybogdano has joined #dri-devel
ybogdano_ has joined #dri-devel
ybogdano_ has quit [Remote host closed the connection]
ybogdano_ has joined #dri-devel
mlankhorst has joined #dri-devel
ybogdano_ has quit []
pnowack has joined #dri-devel
ybogdano_ has joined #dri-devel
ybogdano_ has quit [Remote host closed the connection]
<glennk>
eh, looked it up, dFdx, dFdy are in GL 2.1 but not 2.0
<glennk>
so probably just a missing check for the cap bit in the state tracker
camus has quit []
i-garrison has joined #dri-devel
<dj-death>
our mesa llvm dependencies are really messy
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<jenatali>
It's true
<jenatali>
LLVM in general is... pretty messy
<ajax>
what if we just gave you the compiler's entire object model for the api
<karolherbst>
most of it comes to deal with llvms broken build system
<karolherbst>
*from dealing
<HdkR>
llvm, it infects everything
<HdkR>
I even had to deal with it from my non-llvm app yesterday :P
<HdkR>
Although root-caused to a glibc bug that only appeared because of llvm but w/e
<bnieuwenhuizen>
HdkR: how does that happen?
<HdkR>
dlopen on a library that links to llvm
<bnieuwenhuizen>
called radeonsi?
<HdkR>
called radeonsi
<HdkR>
Or radv maybe? I forget which, static constructors inside LLVM were hecking things up
<orbea>
radv still links against llvm? I thought it was aco now?
<HdkR>
llvm, it infects everything :P
<orbea>
:P
<Venemo>
orbea: we still maintain the LLVM backend in RADV. also ACO uses the LLVM disassembler, and other things in mesa also need LLVM
<orbea>
ah
<orbea>
at least mesa doesn't have a forked llvm submodule :P
<bnieuwenhuizen>
and looks like we might be finding more LLVM usecases
DPA- has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
<gawin>
anholt_: if i see correctly in i915g you've implemented "empty" ddx/ddy? does it serve specific purpose?
<Venemo>
Is it possible for an app to know the Mesa version used by X or vice versa?
<ajax>
kinda. why do you need to know?
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
<Venemo>
ajax: trying to think of a way to avoid breaking every Flatpak app
<bnieuwenhuizen>
Venemo: is the concerning case old X + new app or new X old app?
<bnieuwenhuizen>
first order is probably debugging if there is a mismatch and what the above doe is doing
<Venemo>
bnieuwenhuizen: Josh tells me that the problem is that X doesn't understand modifiers
<Venemo>
I'm afraid I'm not familiar enough with the topic myself to judge
<airlied>
wow updating all the traces is a slogfest
<bnieuwenhuizen>
Venemo: the problem is that something seems to not work out for the non-modifier path, but I think the intention is for the non-modifier-path to still work
<airlied>
but I at least fixed one wierd virgl trace
<Venemo>
JoshuaAshton ^
dottedmag_ has joined #dri-devel
zamundaaa has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]
romangg has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]
hakzsam has quit [Remote host closed the connection]
mupuf has quit [Remote host closed the connection]
lynxeye has quit []
hakzsam has joined #dri-devel
dos11 has joined #dri-devel
mupuf has joined #dri-devel
jadahl has quit [Remote host closed the connection]
vup2 has joined #dri-devel
jadahl has joined #dri-devel
<emersion>
Xwayland can do modifiers, if you're using that
nehsou^ has quit [Remote host closed the connection]
dottedmag has quit [Ping timeout: 480 seconds]
dottedmag_ is now known as dottedmag
mauld has quit [Ping timeout: 480 seconds]
vup has quit [Ping timeout: 480 seconds]
dos1 has quit [Read error: Connection reset by peer]
Prf_Jakob has quit [Remote host closed the connection]
mauld has joined #dri-devel
Prf_Jakob has joined #dri-devel
<JoshuaAshton>
yeah this seems to affect xwayland too
<emersion>
is this GFX8- or GFX9+?
<bnieuwenhuizen>
GFX10
ngcortes has quit [resistance.oftc.net weber.oftc.net]
any1 has quit [resistance.oftc.net weber.oftc.net]
halfline has quit [resistance.oftc.net weber.oftc.net]
NiksDev has quit [resistance.oftc.net weber.oftc.net]
oneforall2 has quit [resistance.oftc.net weber.oftc.net]
cphealy has quit [resistance.oftc.net weber.oftc.net]
kem has quit [resistance.oftc.net weber.oftc.net]
bluebugs has quit [resistance.oftc.net weber.oftc.net]
sauce has quit [resistance.oftc.net weber.oftc.net]
kallisti6 has quit [resistance.oftc.net weber.oftc.net]
rpigott has quit [resistance.oftc.net weber.oftc.net]
dviola has quit [resistance.oftc.net weber.oftc.net]
tlwoerner has quit [resistance.oftc.net weber.oftc.net]
macromorgan has quit [resistance.oftc.net weber.oftc.net]
gpiccoli has quit [resistance.oftc.net weber.oftc.net]
lileo has quit [resistance.oftc.net weber.oftc.net]
jbarnes has quit [resistance.oftc.net weber.oftc.net]
CosmicPenguin has quit [resistance.oftc.net weber.oftc.net]
robink has quit [resistance.oftc.net weber.oftc.net]
Kayden has quit [resistance.oftc.net weber.oftc.net]
clever has quit [resistance.oftc.net weber.oftc.net]
ivyl has quit [resistance.oftc.net weber.oftc.net]
stuartsummers has quit [resistance.oftc.net weber.oftc.net]
unerlige has quit [resistance.oftc.net weber.oftc.net]
Ryback_ has quit [resistance.oftc.net weber.oftc.net]
austriancoder has quit [resistance.oftc.net weber.oftc.net]
ezequielg has quit [resistance.oftc.net weber.oftc.net]
mdnavare has quit [resistance.oftc.net weber.oftc.net]
aswar002 has quit [resistance.oftc.net weber.oftc.net]
kurufu has quit [resistance.oftc.net weber.oftc.net]
daniels has quit [resistance.oftc.net weber.oftc.net]
tchar has quit [resistance.oftc.net weber.oftc.net]
buhman has quit [resistance.oftc.net weber.oftc.net]
ds` has quit [resistance.oftc.net weber.oftc.net]
xyene has quit [resistance.oftc.net weber.oftc.net]
jjardon has quit [resistance.oftc.net weber.oftc.net]
mareko has quit [resistance.oftc.net weber.oftc.net]
kisak has quit [resistance.oftc.net weber.oftc.net]
rib_ has quit [resistance.oftc.net weber.oftc.net]
GreaseMonkey has quit [resistance.oftc.net weber.oftc.net]
LaserEyess has quit [resistance.oftc.net weber.oftc.net]
glisse has quit [resistance.oftc.net weber.oftc.net]
jrayhawk has quit [resistance.oftc.net weber.oftc.net]
narmstrong has quit [resistance.oftc.net weber.oftc.net]
dri-logger has quit [resistance.oftc.net weber.oftc.net]
mslusarz has quit [resistance.oftc.net weber.oftc.net]
zzag has quit [resistance.oftc.net weber.oftc.net]
jolan has quit [resistance.oftc.net weber.oftc.net]
jekstrand has quit [resistance.oftc.net weber.oftc.net]
oneforall2 has joined #dri-devel
kem has joined #dri-devel
cphealy has joined #dri-devel
sauce has joined #dri-devel
rpigott has joined #dri-devel
any1 has joined #dri-devel
kurufu has joined #dri-devel
gpiccoli has joined #dri-devel
ezequielg has joined #dri-devel
austriancoder has joined #dri-devel
stuartsummers has joined #dri-devel
aswar002 has joined #dri-devel
clever has joined #dri-devel
tchar has joined #dri-devel
glisse has joined #dri-devel
zzag has joined #dri-devel
buhman has joined #dri-devel
mdnavare has joined #dri-devel
LaserEyess has joined #dri-devel
narmstrong has joined #dri-devel
mslusarz has joined #dri-devel
Kayden has joined #dri-devel
daniels has joined #dri-devel
xyene has joined #dri-devel
robink has joined #dri-devel
dri-logger has joined #dri-devel
CosmicPenguin has joined #dri-devel
tlwoerner has joined #dri-devel
kallisti6 has joined #dri-devel
bluebugs has joined #dri-devel
lileo has joined #dri-devel
Ryback_ has joined #dri-devel
jbarnes has joined #dri-devel
rib_ has joined #dri-devel
jjardon has joined #dri-devel
mareko has joined #dri-devel
ivyl has joined #dri-devel
unerlige has joined #dri-devel
dviola has joined #dri-devel
jrayhawk has joined #dri-devel
halfline has joined #dri-devel
NiksDev has joined #dri-devel
macromorgan has joined #dri-devel
jolan has joined #dri-devel
ngcortes has joined #dri-devel
GreaseMonkey has joined #dri-devel
ds` has joined #dri-devel
kisak has joined #dri-devel
jekstrand has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<airlied>
robclark, anholt_ : a530 runners down?
fxkamd has quit []
<airlied>
a job hung completely, cancelled + restart - now it isn't getting a runner
<emersion>
Venemo: if this GNOME, or KDE, or something else?
<robclark>
according to admin panel, last ping time was 5min ago.. which I think is sort of normalish
<airlied>
that looks like a 10m timeout
<robclark>
my guess is if all the runners are busy with jobs that are 100% fail, deqp-runner will retry the failed tests a 2nd time, so jobs take 2x as long, or more
<robclark>
not sure if there is a good way to see what individual runners are running at a time, if you have other a5xx jobs running and failing at everything you might need to go cancel them
<airlied>
I can't see any others because they'd be running in user repos I assume if at all
<jekstrand>
apinheiro[m]: FYI: The test failing on my vk_error branch is dEQP-VK.api.device_init.create_device_unsupported_features
<jekstrand>
According to the CI, anyway.
<robclark>
airlied: yeah, not really sure how to tell what any given runner is doing atm.. maybe daniels or anholt_ knows
<airlied>
robclark: it seems like a530 is dead, that runner was running that job and stopped, and it never came back
<airlied>
not sure if there's a reboot timer that just hasn't kicked in yet
<robclark>
the runners themselves are rebooted between each run.. the controller has timeouts and looks for various "things didn't boot properly" msgs.. but you'd be seeing that already if that was the problem
<airlied>
well what causes what happens above in 14165649?
<robclark>
the thing that gitlab talks to is actually the controller, not the individual devices
<airlied>
that seems like a 10m timer went off, but still nothing fixed itself up
<airlied>
anholt_: yeah I think we are just seeing user jobs causing marge jobs to timeout due to runner capacity
<anholt_>
ah, latest job for a couple of them was a weirdly wedged one from a kernel uprev
<airlied>
a530 dies in the middle of a marge job, and other jobs get the runner when it resets or something
<anholt_>
so, yeah, 2 boards were out of commission with gitlab-runner failing to time out. that plus !4743 being pretty broken is tying things up right now.
<anholt_>
wait, no, that one is passing, we're just running a bit slow on our 10 minute job times apparently.
<anholt_>
(which is part of why I was hoping we could get a kernel uprev soon)
DPA has joined #dri-devel
DPA- has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
* jekstrand
runs unit tests in the hopes that he can repro the ACO test fails on !4743
<anholt_>
jekstrand: you've got ubsan on, right?
<jekstrand>
no
<anholt_>
the debian-vulkan build has that, it's a common source of ci fail that your build won't have
<jekstrand>
That explains why only debian-vulkan failed
<jekstrand>
Let's see if valgrind repros. If not, I'll try ubsan
<airlied>
arrgh a530 crashed out on my run
<airlied>
now it's not getting rescheduled
<airlied>
Failed to get fastboot prompt, restarting run..., really think you should comment out a530, I'm going on holidays for a few days, it's frustrating that I can't just get an MR to land even after babysitting it for 2-3 hours
<anarsoul>
folks, any ideas how to approach implementing texture2dproj() for mali400 where coords and projector are in the same source? Should I introduce my own texture op for that? If I keep them as a separate sources for tex they just don't play well with other optimization passes :\
pcercuei has quit [Quit: dodo]
<anarsoul>
or rather introduce new tex_src type
<anarsoul>
nir_tex_src_coord_proj
Hi-Angel has quit [Ping timeout: 480 seconds]
<anholt_>
anarsoul: see what nir_to_tgsi does for this
<jekstrand>
anholt_: Why does nir_to_tgsi have its own projector lowering?
<anholt_>
jekstrand: it wants to not lower it in many cases.
<jekstrand>
Oh, I see. It doesn't. It has a big complicated condition.
<jekstrand>
:-/
<anarsoul>
anholt_: oh, so there's nir_tex_src_backend*. Nice. Thanks a lot!
<jekstrand>
airlied: Why does lavapipe have its own copy of nir_lower_input_attachments?
<jekstrand>
I guess it leaves input attachments as images
iive has quit []
FireBurn has joined #dri-devel
SolarAquarion has quit []
<jekstrand>
airlied, zmike: Where is the code that fills out image static state for lavapipe?