<airlied>
tarceri: did the first one, the struct->union one scares me :-P
<tarceri>
airlied: The original change is from like 5 or 6 years ago when I rewrote half the structs in mtypes to allows for the glsl cache. It was well tested but after committing it broke i915 as it was using some Frankenstein shaders that has asm and glsl data mixed together
<tarceri>
oh and swrast was doing the same thing too
<airlied>
tarceri: I added one other patch to 14074, I'm pretty done with it
<airlied>
apart from killing purgeable all over, I think I've burned the easy bits of dd.h out
macromorgan has quit [Ping timeout: 480 seconds]
flibitijibibo has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Quit: No Ping reply in 180 seconds.]
pendingchaos has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
macromorgan is now known as Guest7708
macromorgan has joined #dri-devel
Guest7708 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
f11f12 has quit [Quit: Leaving]
danvet has joined #dri-devel
tzimmermann has joined #dri-devel
tursulin has joined #dri-devel
rgallaispou has joined #dri-devel
<Kayden>
airlied: dropping GL_APPLE_object_purgeable sounds good to me, I don't know of any programs that really use it, either, so I don't think it's really even worth supporting
sdutt has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
camus has joined #dri-devel
pnowack has joined #dri-devel
<mripard>
danvet: hi, do you know who I should ask about how i915 deals with YUV output on HDMI?
gawin has joined #dri-devel
<daniels>
mripard: probably vsyrjala
<danvet>
yeah
mclasen has joined #dri-devel
<mripard>
thanks :)
<mripard>
I'll ask him tomorrow, today is a holiday in Finland iirc
rasterman has joined #dri-devel
jkrzyszt has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
tango_ is now known as Guest7721
tango_ has joined #dri-devel
pcercuei has joined #dri-devel
linkmauve has joined #dri-devel
Guest7721 has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
mmx_in_orbit has joined #dri-devel
exit70[m] has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
_alice has quit [Quit: Bridge terminating on SIGTERM]
cleverca22[m] has quit []
apinheiro[m] has quit []
neobrain[m] has quit []
xerpi[m] has quit []
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
MatrixTravelerbot[m] has quit []
tomba has quit [Quit: Bridge terminating on SIGTERM]
Eighth_Doctor has quit []
HayashiEsme[m] has quit []
DrNick has quit []
Venemo has quit [Quit: Bridge terminating on SIGTERM]
Strit[m] has quit []
ella-0[m] has quit []
kallisti5[m] has quit []
danylo has quit [Quit: Bridge terminating on SIGTERM]
chema has quit []
nielsdg has quit []
cwfitzgerald[m] has quit []
Anson[m] has quit []
YaLTeR[m] has quit []
gnustomp[m] has quit []
reactormonk[m] has quit []
zzoon[m] has quit [Quit: Bridge terminating on SIGTERM]
pmoreau has quit [Quit: Bridge terminating on SIGTERM]
Vin[m] has quit []
atulu[m] has quit []
gagallo7[m] has quit []
yshui` has quit []
Newbyte has quit [Quit: Bridge terminating on SIGTERM]
aura[m] has quit []
undvasistas[m] has quit []
jasuarez has quit [Quit: Bridge terminating on SIGTERM]
Sumera[m] has quit []
doras has quit [Quit: Bridge terminating on SIGTERM]
jekstrand[m] has quit []
Mershl[m] has quit []
RAOFhehis[m] has quit []
T_UNIX has quit []
MrR[m] has quit []
kusma has quit [Quit: Bridge terminating on SIGTERM]
naheemsays[m] has quit []
LaughingMan[m] has quit []
zzag[m] has quit []
pushqrdx[m] has quit []
gdevi has quit []
robertmader[m] has quit []
moben[m] has quit []
egalli has quit []
sigmoidfunc[m] has quit []
frytaped has quit [Quit: Bridge terminating on SIGTERM]
shadeslayer has quit [Quit: Bridge terminating on SIGTERM]
chivay has quit []
halfline has quit []
ivyl has quit [Quit: Bridge terminating on SIGTERM]
unrelentingtech has quit [Quit: Bridge terminating on SIGTERM]
Tooniis[m] has quit []
Dylanger has quit [Quit: Bridge terminating on SIGTERM]
tintou has quit []
PiGLDN[m] has quit []
yk has joined #dri-devel
<mmx_in_orbit>
is there something like GL_BLACKHOLE_RENDER_INTEL but for other than intel?
<mmx_in_orbit>
such as radeon
<mmx_in_orbit>
or software renderers
<Ristovski>
I don't think so, but I could be wrong
_alice has joined #dri-devel
ramaling_ has quit []
mclasen has quit [Ping timeout: 480 seconds]
<mmx_in_orbit>
is there some way to disable all rendering universally regarding mesa
flacks has quit [Quit: Quitter]
thellstrom has joined #dri-devel
flacks has joined #dri-devel
<emersion>
iirc there's a noop gallium driver
<glennk>
radeonsi and panfrost support blackhole_render too afaik
<dj-death>
it doesn't have much intel specific stuff, it was just easier to get out as a registered extension with a vendor name
<dj-death>
we mostly use it for perf/debug
<MrCooper>
it would be cooler if it could be used for rendering black holes :P
<HdkR>
Does it count as a blackhole renderer if the driver bugs means it renders a black screen? ;)
camus has joined #dri-devel
<dj-death>
just one glEnable() from correctness
yogesh_mohan has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
mmx_in_orbit_ has joined #dri-devel
mmx_in_orbit has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
f11f12 has joined #dri-devel
mmx_in_orbit_ has left #dri-devel [#dri-devel]
mmx_in_orbit has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
sneil_ has joined #dri-devel
yogesh_mohan has joined #dri-devel
sneil has quit [Ping timeout: 480 seconds]
pekkari has joined #dri-devel
<mmx_in_orbit>
is there a way to disable all mesa extensions without having to type every single one out?
<mmx_in_orbit>
via MESA_EXTENSION_OVERRIDE
Company has joined #dri-devel
vivijim has joined #dri-devel
<alyssa>
glennk: indeed.
<alyssa>
mmx_in_orbit: ^ meaning if you use the _INTEL suffix on panfrost (and apparently radeonsi) it should just work
FireBurn has quit [Quit: Konversation terminated!]
jkrzyszt has quit [Remote host closed the connection]
<mmx_in_orbit>
alyssa: i think my graphics card (Mobility Radeon HD 3650) is too old for radeonsi driver, right?
nchery has joined #dri-devel
<alyssa>
no idea \shrug/
<alyssa>
I just fo mali. and agx.
gawin has quit [Ping timeout: 480 seconds]
kmn has joined #dri-devel
mclasen has joined #dri-devel
jewins has joined #dri-devel
sdutt has joined #dri-devel
fxkamd has joined #dri-devel
<MrCooper>
mmx_in_orbit: yep, your card is supported by r600g, not radeonsi
apinheiro[m] has joined #dri-devel
atulu[m] has joined #dri-devel
aura[m] has joined #dri-devel
chema has joined #dri-devel
chivay has joined #dri-devel
RAOFhehis[m] has joined #dri-devel
cleverca22[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dcbaker has joined #dri-devel
Anson[m] has joined #dri-devel
Guest7738 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
exit70[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest7751 has joined #dri-devel
halfline[m] has joined #dri-devel
HayashiEsme[m] has joined #dri-devel
zzoon[m] has joined #dri-devel
ivyl has joined #dri-devel
jasuarez has joined #dri-devel
<mmx_in_orbit>
MrCooper: so is it possible still somehow to use radeonsi anyway?
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
kallisti5[m] has joined #dri-devel
kusma has joined #dri-devel
LaughingMan[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
moben[m] has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
nielsdg has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
MrR[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
shadeslayer[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
unrelentingtech has joined #dri-devel
Venemo__ has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zzag[m] has joined #dri-devel
ivyl is now known as Guest7762
pmoreau is now known as Guest7763
<MrCooper>
no
<MrCooper>
completely different HW architecture
<mmx_in_orbit>
how about panfrost?
<MrCooper>
it's for ARM GPUs in mobile devices
<zackr>
danvet, maintainers: my employer disconnected the only non-oauth2 smtp server we had, so i need to use a different email to use git send-email. what's the sign-off procedure when using git send-email from a different email address than the one change was written with? do i sign-off each change with both addresses or is that silly since it will results in multiple my own sign-offs?
<MrCooper>
I normally never use the address I'm sending from for S-o-b
<MrCooper>
this has never come up as an issue
jkrzyszt has joined #dri-devel
<MrCooper>
S-o-b should just match the Git commit author
<MrCooper>
(or committer, if you're just passing on a patch from someone else)
jewins has quit [Ping timeout: 480 seconds]
<zackr>
MrCooper: thanks, that makes sense to me. i just didn't want someone to get upset that the sending email address is not among the s-o-b's
shadeslayer[m] is now known as shadeslayer
<emersion>
zackr: yea that should be completely fine
<mripard>
zackr: kernel.org hosts an SMTP server as well
<zackr>
thanks! fortunately, i have a @kde.org that i can use so that part is handled. my poor employer just doesn't have the same resources as a volunteer project to maintain a secure smtp ... =)
sdutt has quit []
sdutt has joined #dri-devel
jewins has joined #dri-devel
JohnnyonFlame has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
mmx_in_orbit has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
mlankhorst_ has joined #dri-devel
mlankhorst has quit [Read error: Connection reset by peer]
mlankhorst_ has quit [Remote host closed the connection]
mlankhorst_ has joined #dri-devel
Guest7762 has quit []
enick_484 has joined #dri-devel
camus1 has joined #dri-devel
macromorgan is now known as Guest7782
Guest7782 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
mmx_in_orbit has joined #dri-devel
Duke`` has joined #dri-devel
flibitijibibo has joined #dri-devel
<ajax>
i see the great post-classic cleanup has begun, excellent
ella-0_ has quit []
jedisonz has joined #dri-devel
<ajax>
mmx_in_orbit: re disable mesa extensions: what exactly are you trying to do?
f11f12 has quit [Quit: Leaving]
<ajax>
(probably not a completely terrible idea to teach extension-forcing about globs or regexes i suppose, but)
<imirkin>
should just be able to set the max year, no?
<imirkin>
to like ... 1000
<imirkin>
;)
<imirkin>
GL was still new in the times of William the Conqueror, so not too many exts back then
<ajax>
i think if by "mesa extensions" they mean things of the form GL_MESA_* then that might be a bit drastic
<imirkin>
ah, that wasn't my reading of it
<imirkin>
there are only a handful of GL_MESA_* exts no?
<imirkin>
doesn't seem too bad to stick them in one-by-one
<ajax>
istr there's some extremely stupid apps that think they mean they're running on a software renderer (and thus refuse to run)
<ajax>
or at least i remember seeing some driconf default for those go by
<glennk>
also aren't there various interposer libraries that can filter extensions?
sneil_ has quit []
<glennk>
imirkin, i think 1000ad may be IrisGL rather than OpenGL?
sneil has joined #dri-devel
<imirkin>
:)
rgallaispou has quit [Read error: Connection reset by peer]
enick_484 has quit []
enick_484 has joined #dri-devel
FireBurn has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
ella-0 has joined #dri-devel
<imirkin>
anholt: based on your MR's, i'm guessing you're playing with nouveau + nir. just a heads-up that nv50 supports ES 3.1 as well. this support was added after the nir backend was done, so there could be some good-sized bits to deal with there.
<imirkin>
(well, nva3+ exposes ES 3.1. i guess you're on a nva8 so you should have that there too)
<anholt>
imirkin: yeah. was poking at "what's missing in nouveau NIR to see whether we should switch to NIR or switch to NTT with !8044"
<imirkin>
the larger issue with either approach is that we don't have instruction scheduling
<imirkin>
and nir likes to put all the constant loads up front
<imirkin>
er, immediate loads
<imirkin>
and stuff like that
<imirkin>
this leads to higher register usage
<anholt>
might be able to just toss nir_schedule at that problem.
<anholt>
or nir_opt_sink
<imirkin>
ah, i guess that's new?
<anholt>
sink_movs?
<imirkin>
or at least new-ish
<imirkin>
iirc last time i asked the solution was "get an instruction scheduler"
<anholt>
they're both a couple years old at this point, but :shrug:
<imirkin>
ok. i don't ask very often ;)
<anholt>
I could probably justify spending a couple weeks on nouveau nir if I could get a stable test environment. but that is proving challenging.
<imirkin>
the deqp-supplied runners are (were?) pretty good
<imirkin>
but yeah - just make sure there's no parallel anything anywhere
<ajax>
meaning surfaceless with no display server?
<imirkin>
oh, and i dunno if you started with the nva8 on purpose or that just happened to be the first nvidia gpu at the top of your closet, but the nir backend has been tested mostly with nvc0 rather than nv50
<imirkin>
ajax: that's preferable. but if you're using X and the nouveau ddx, that's fine too generally (and how i test)
<imirkin>
i would not advise to use modesetting ddx.
<anholt>
this is the one I have out of (nv40, nv4b, nv50) I have that didn't require a new power supply in the particular system I'm stuffing it in.
<imirkin>
(unfortunately, skeggsb has the inverse opinion and has landed a patch to Fedora and somehow Debian to make the X server prefer modesetting even if nouveau is there)
<imirkin>
hehe, well good choice
<imirkin>
you have an actual G80?
<anholt>
I'm not great at these numbers, but I've labeled one as a g92.
<imirkin>
oh. G92 is more reasonable
<imirkin>
G80 is nv50
<imirkin>
nv50 is both a family and an actual gpu code
<imirkin>
the family includes your nva8 (GT218 probably?)
<anholt>
yep
<imirkin>
nv50 was the original G80 which was the first DX10 GPU ever. needless to say, it had some issues.
<imirkin>
(i.e. GeForce GTS 8800 or whatever the marketing name was... 320MB VRAM -- wow!)
<anholt>
yeah, don't seem to have any of those.
<imirkin>
good.
<imirkin>
keep it that way.
<imirkin>
and the nv40/4b are served by the 'nv30' driver, not covered by 'codegen'
<imirkin>
they're DX9 parts, vector ISA, etc
<imirkin>
G92 should work fine (with a handful fewer features, nothing that matters in practice)
<anholt>
oh wait. I *do* have power for these older cards.
<imirkin>
for testing whether stuff works, the nva8 should be totally fine, and even preferable since it supports more stuff
<imirkin>
so you get a wider testing base with the same backend
<anholt>
great.
<imirkin>
the xfb works somewhat differently, so if you were messing with that, you'd definitely want to be checking both
Venemo__ is now known as Venemo
<imirkin>
(nva0+ supports pause/resume)
<imirkin>
but that's all completely unrelated to the code generation
<Venemo>
agd5f: Is it possible to add some more details to the kernel log message about GPU hangs?
<Venemo>
What is currently there does not help at all with diagnosing the problems.
idr has joined #dri-devel
<idr>
Am I correct that the only way to build softpipe and other drivers with LLVM is to do two builds? First with llvm=disabled and second with llvm=enabled?
<anholt>
you can run softpipe on your normal llvm build with just GALLIUM_DRIVER=softpipe
<anholt>
(this is how we do our testing in CI, too)
<imirkin>
note that "draw" will still use llvm
<imirkin>
if you want to disable draw's use of llvm, also add DRAW_USE_LLVM=0
<imirkin>
(draw is the pre-rast stuff)
<ajax>
(and select and feedback but whatever)
<imirkin>
hehe
<imirkin>
everyone's favorite features.
<ajax>
i kind of wish we had cs implementations of those instead
<anholt>
right?
<imirkin>
this comes up every so often
<anholt>
ajax: yeah, needing draw to be able to interpret every driver's style of backend shaders is rough.
<alyssa>
imirkin: and as usual the answer is "thanks for volunteering"
<ajax>
or, as well. or do it in gs or xfb or whatever works and is supported on the most ancient of hardware
<imirkin>
alyssa: exactly :)
<imirkin>
ajax: there are some unfortunate interactions with ... clipping iirc? which makes it tricky
<ajax>
which i'm sure i'll get to shortly after accelerated accumulation buffers
Guest7738 has left #dri-devel [#dri-devel]
DrNick has joined #dri-devel
<idr>
ajax: I actually started a branch for that once. :)
<idr>
But it was for i965 using blorp, so... yeah.
<alyssa>
ajax: ES3.1 requires compute shaders but /not/ GS
<alyssa>
so panfrost has CS but not GS
<imirkin>
same with nv50 =]
<alyssa>
(Panfrost also has XFB, that's ES3.0)
<imirkin>
er wait
<alyssa>
also, even if Panfrost gained GS support like the Arm driver has, performance would suck
<imirkin>
nv50 has GS too, duh
DrNick has left #dri-devel [#dri-devel]
DrNick has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
<anholt>
well, that nva8 run was going great until a while into gles31 when I got the g84_fifo_chan_engine_fini splat again.
<alyssa>
splat
<imirkin>
anholt: boooo
<imirkin>
anholt: i'm not _sure_ i ever ran the full suite against it? i don't remember anything hanging though
<imirkin>
def some failures in the compute/graphics sync arena
<imirkin>
and you should expect some texgather failures (since there's no support for the component being not-0)
<anholt>
there are also lots of tlb flush idle timeout fails before that, so if tlb flushing is failing then it's not surprising to me that eventually things go really badly
<imirkin>
tlb flush fail = gpu totally hung
<imirkin>
like SUPER hung
<anholt>
but presumably that's followed by some sort of reset? I see what looks like that and then presumably progress, a couple minutes before the splat
<anholt>
I should probably head to the proper channel for this
jhli has joined #dri-devel
<imirkin>
yes. it's followed by you pressing the reset button on your comp :)
Company has quit [Read error: No route to host]
Company has joined #dri-devel
FireBurn has joined #dri-devel
<ajax>
gitlab's merge review sort field should include "number of patches" and "kloc changed"
jedisonz has quit [Ping timeout: 480 seconds]
mlankhorst_ has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<ajax>
idr: lmk if you don't want me bothering you about glx changes from a decade ago anymore
<imirkin>
statute of limitations? :)
<idr>
Lol
gouchi has joined #dri-devel
<airlied>
hmmm iris lava job looks to be timing out on 16458028, is the iris machines just stuck doing something else?
<daniels>
airlied: oh grr
<daniels>
the perf jobs are limited to a subset of the chromebooks (because not all of them are at all alike), and those are currently out for ... some reason
<daniels>
I've poked internally to find out why
<daniels>
airlied: itmt you can disable the specific perf job
ngcortes has joined #dri-devel
Thymo_ has joined #dri-devel
camus has joined #dri-devel
<airlied>
daniels: oh actually that jobs turns into a warning if it times out by the looks of it
<airlied>
which yay but :( for stalling things, so I'll comment it out
camus1 has quit [Read error: Connection reset by peer]
Thymo has quit [Ping timeout: 480 seconds]
<airlied>
daniels: 14088
Thymo_ has quit [Read error: Connection reset by peer]
Thymo has joined #dri-devel
<mmx_in_orbit>
ajax: so i'm trying to make an application (this one called xemu, an original xbox emulator) get better frame rates and i don't need visuals/graphics at all
<mmx_in_orbit>
better frame rates/as good of performance as possible with as little visual/graphical rendering as possible
<mmx_in_orbit>
if any
<airlied>
adding blackhole support to r600 is probably fairly simple job
Company has quit [Read error: No route to host]
Company has joined #dri-devel
jedisonz has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
jedisonz has quit [Read error: Connection reset by peer]
<Ristovski>
mmx_in_orbit: wouldn't the easiest be to just comment out all the rendering code in xemu and compile it from source?
<mmx_in_orbit>
Ristovski: i don't think i would know how to do that
<agd5f>
Venemo, hard part is determining what else is useful to add.
rasterman has quit [Quit: Gettin' stinky!]
Haaninjo has joined #dri-devel
<HdkR>
mmx_in_orbit: Reminder that disabling rendering temporarily can break graphical effects in a ton of games. Anything that prerenders "imposters" or spritesheets in to a texture and then uses it later :)
<HdkR>
But if you're just wanting to use it for CPU benchmarking, a lot more interesting
<anholt>
agd5f: I know this is ancient stuff, but do you have any tips on stabilizing deqp runs of r300 or r600, or know anyone who does? I'm getting GPU hangs where reset never recovers.
ngcortes has quit [Ping timeout: 480 seconds]
eukara has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
gawin has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
<gawin>
anholt: r300 has fencing issue (something is writing memory, as even tests like gl-1.0-logicop gl_clear or gl-1.0-blend-func are flaking), I wasn't been able to find anything yet (busy lately)
nchery has joined #dri-devel
<gawin>
(imirkin pointed this out)
<imirkin>
well ... it's just a guess
<imirkin>
those aren't the types of tests that should falke
<imirkin>
you either implement logic ops correctly or you don't :)
Company has quit [Read error: No route to host]
danvet has quit [Ping timeout: 480 seconds]
eukara has quit [Remote host closed the connection]
eukara has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
pendingchaos has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
adjtm has joined #dri-devel
<anholt>
I haven't seen any flakes in deqp yet, just stable results or GPU wedges.
<gawin>
btw which hardware do you use? r500 is in best condition (both kernel and mesa)
gouchi has quit [Remote host closed the connection]
<anholt>
rv515
kenjigashu has joined #dri-devel
kenjigashu has quit []
mclasen has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
kenjigashu has joined #dri-devel
nchery has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
ngcortes has joined #dri-devel
idr has quit [Quit: Leaving]
<Venemo>
agd5f: would be nice to distinguish whether the hang was due to a buggy shader or something else. Would be nice if it could say which hardware unit hanged.
<Venemo>
Then we could at the very least more clearly separate display bugs from mesa bugs
<Venemo>
Also would be nice to somehow distinguish power management bugs
<Venemo>
agd5f: the problem is, even if we can reproduce these bugs, it's not at all obvious what's wrong
<imirkin>
Venemo: also, i want a pony!
<Venemo>
So, even if the user does his homework and collect all logs, there is exactly 0 useful info in there about what caused the hang
<airlied>
Venemo: if you can reproduce them, it's nearly always not powermanagement :-P
<Venemo>
imirkin: I'm sorry, I don't see how that helps
<imirkin>
Venemo: i thought you were making a list of things you wanted but were impossible to get
<Venemo>
imirkin: I don't see what you mean
<imirkin>
nevermind.
<Venemo>
airlied: not true I had very reproducible power management bugs in the past.
<imirkin>
it was a joke. but also a minor point -- these things would all be nice, but they just aren't gonna happen
<Venemo>
imirkin: it would be more helpful if you could elaborate on why you believe this can't happen and perhaps say what would be viable to happen
<imirkin>
you have to make do with what you have
<airlied>
like if you get a VM fault it's generally not power management related, but a bad shader
<imirkin>
documentation for these things is non-public, and the people who have the docs are being paid to work on new things, not ancient ones. in some cases, the docs are just gone.
<airlied>
but if you get an engine hang it's kinda hard to have any clue
<airlied>
I'm not even sure how much the hardware knows in that case
<imirkin>
yeah, that's the other point
<airlied>
and it really comes down to does the hardware tell you much more
<imirkin>
new hardware is pretty good at isolating the cause of the error
<airlied>
we've had cases in the past of cascade fails as well
<imirkin>
but older hardware is generally more like "aaaaah an error!"
<airlied>
so one pieces hangs by the time you read the debug regs all the pieces have hung
<airlied>
waiting for the first one
<airlied>
but there's no real way to know who went first
camus has joined #dri-devel
<anholt>
best you can hope for for hw helping you debug I think is like what broadcom had: you send your trace to the guy who runs it through the fpga simulator and looks at what lines are busy and maybe instruments some more, and then tells you what's the source of the fail.
<airlied>
yeah traces and simulators are kinda the crutch of debugging, and suck when it's real apps like games dying
camus1 has quit [Read error: Connection reset by peer]
* kisak
blinks at "Marge Bot marked this merge request as draft"
<imirkin>
the bot knows all
<imirkin>
iirc there was some thing with WIP?
<bnieuwenhuizen>
mostly that is gitlab and not marge-bot that does that though
<Venemo>
airlied: so RDNA2 doesn't have a capability to determine which part of it hung first?
<Venemo>
Or are you just talking in general?
<Venemo>
kisak: it marks your pull request based on some keywords from your commit messages, such as WIP
<kusma>
dcbaker: not sure if my reply went through at first, but it looks good, r-b!
<kusma>
Ah, yeah. I wasn't authenticated at first
<kusma>
Anyway, great work!
<gawin>
what about testing with "passed through" gpus? for example creating 2 or more flags (one for power management and one for mesa ), if you're doing something then the flag should be on. after crash it should become frozen state so you can check state of flags. theoretically it should work similar to idea with fpga simulator (though more false positives)