<mattst88>
I know you're not at VMware anymore, but do you know who is responsible for the driver these days?
camus1 has joined #dri-devel
macromorgan_ has quit []
macromorgan has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
blackbeard42015 has joined #dri-devel
blackbeard42015 has quit [Remote host closed the connection]
notgull has quit []
ddavenport has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<mareko>
zmike: do you ever sleep? ;)
<zmike>
mareko: sure, I have plenty of time while my unit tests run!
Lightkey has quit [Ping timeout: 480 seconds]
<HdkR>
If you have a really comfortable chair then that's easy
ddavenport has quit [Remote host closed the connection]
Tima-t has joined #dri-devel
Tima-t has quit [Remote host closed the connection]
<alyssa>
utt
boistordu_ex has quit [Remote host closed the connection]
Lightkey has joined #dri-devel
boistordu_ex has joined #dri-devel
xp4ns3 has quit []
mslusarz has quit [Ping timeout: 480 seconds]
glisse has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
mareko has quit [Ping timeout: 480 seconds]
dri-logger has joined #dri-devel
ddavenport has joined #dri-devel
mbrost has quit [Remote host closed the connection]
ddavenport has quit [Remote host closed the connection]
mslusarz has joined #dri-devel
glisse has joined #dri-devel
naveenk2 has joined #dri-devel
mareko_ has joined #dri-devel
khfeng has joined #dri-devel
NiksDev has joined #dri-devel
NiksDev2 has quit [Remote host closed the connection]
mareko_ has quit []
mareko has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
jrqc has joined #dri-devel
jrqc has quit [Remote host closed the connection]
casperstorm has joined #dri-devel
casperstorm has quit [Remote host closed the connection]
<cyrozap>
I just found out about the Gallium driver for Gen7 and earlier Intel graphics (clover). I know a lot of people think using hardware that's nearly 10 years old is foolish, but as someone still using a Bay Trail laptop daily, and who has other hardware with Gen7 GPUs, I'm really appreciative of the work that's been going into keeping the drivers up to date. Thank you!
<HdkR>
Crocus you mean?
<HdkR>
Clover is the CL thing I believe?
<cyrozap>
Yes, Crocus, whoops :P
<cyrozap>
I had the right flower in mind, but the wrong one got written.
<HdkR>
Luckily i965 isn't going to vanish overnight :D
bulters has joined #dri-devel
bulters has quit [Remote host closed the connection]
<robclark>
HdkR: I suppose crocus is at least a step in the direction of getting clover working
<HdkR>
Very true
<cyrozap>
HdkR: Yeah, I just remember there was talk recent-ish-ly of dropping classic Mesa drivers and IIRC some people suggested that, since the hardware was old, it wouldn't be an issue to just drop support entirely, without any solutions for those who still use that hardware.
<robclark>
(says the guy who hasn't yet had spare time to get clover working with his gallium driver :-P)
<airlied>
robclark: thought you'd want to take on qcom on compute :-P
<HdkR>
cyrozap: That's just a packaging problem. mesa versus mesa-classic :)
<robclark>
cyrozap: whatever happens it won't be dropping support.. but we will probably fork pre gallium into it's own branch
* airlied
just fixed the crocus phoronix regression, so now it's perfect and able to replace 965 tomorrow :-P
<robclark>
airlied: things I want to work on and things that are $bigger_fire are two different things.. and sadly $bigger_fire $day_job things involve a lot of things only tangentially connected to mesa
<robclark>
turns out anything that is wrong with pixels on screen is automatically a gfx driver bug ;-)
<HdkR>
oh, speaking of gfx driver bug
<robclark>
but I have an MR up for copy_image and gles32, so slowly working thru that backlog ;-)
<HdkR>
Eventually I'll figure out how to get real captures in my environment
<robclark>
HdkR: show that to danylo .. who has been having fun debugging game issues on tu side of things ;-)
<imirkin>
robclark: all those arb_copy_image failures sound pretty ominous...
<robclark>
imirkin: the piglit ones.. they aren't new.. it is all msaa + copy_image (and all dups of existing nv_copy_image piglit fails.. don't ask me why nv_copy_image is exposed without arb_copy_image)
<imirkin>
robclark: ok, but ... sounds ominous ;)
<robclark>
probably all one bug.. I'll look at it at some point.. but desktop gl isn't a thing that is high priority because it doesn't stop me from shipping updates ;-)
<HdkR>
Maybe once I get a board that isn't constantly up against the redline of memory usage then I'll slap buggy applications with renderdoc
<robclark>
imirkin: if it makes you feel better those +xfail are more than offset by my nearly -1000 xfail from a bit of weekend hacking last weekend ;-)
<imirkin>
hehe
<imirkin>
you fixed some stuff, now you get to break it again!
<robclark>
exactly :-P
<robclark>
I'd care more about the +xfail if it wasn't all duplicate of existing xfail
Net147 has quit [Ping timeout: 480 seconds]
matthewwilkes has joined #dri-devel
MylesBorins has joined #dri-devel
matthewwilkes has quit [Remote host closed the connection]
MylesBorins has quit [Remote host closed the connection]
<imirkin>
yeah, the fact that it's already existing fail makes it slightly better
<imirkin>
but the fact that stuff is failing is a bit weird
<robclark>
imirkin: btw, the lolz of that MR is why flipping the cap fixed shaders@glsl-bug-110796
<imirkin>
best not to worry about things like that
camus has joined #dri-devel
<imirkin>
just take the win
<robclark>
yeah, given the things I've fixed recently to get deqp happy, there is a 50% at best chance the fails are related to what is actually being tested
Net147 has joined #dri-devel
<robclark>
but I'll have another look at piglit side of things soon.. but I guess airlied would prefer I finish up getting kernel side of things ready for 5.14 pr first
camus1 has quit [Remote host closed the connection]
Bat`O has joined #dri-devel
Bat`O has quit [Remote host closed the connection]
naveenk2 has quit []
naveenk2 has joined #dri-devel
ramaling has quit [Read error: Connection reset by peer]
Danct12 has joined #dri-devel
ramaling has joined #dri-devel
dviola has joined #dri-devel
jewins has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
sgn has joined #dri-devel
sgn has quit [Remote host closed the connection]
shankaru has joined #dri-devel
camus1 has joined #dri-devel
sdutt_ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
dviola has quit [Quit: WeeChat 3.2]
mattrope has quit [Remote host closed the connection]
<mareko>
I wish there was a profiler would tell me about "false sharing" and other shenanigans related to CPU cache coherency protocols
<HdkR>
Hey, at least the linux kernel now gives you split lock detection
<HdkR>
For people who are...accidentally relying on that particular unfeature
itoral has joined #dri-devel
i-garrison has joined #dri-devel
<mareko>
also glxgears is much faster for some reason and I don't remember optimizing it
i-garrison has quit []
<mareko>
having a profiler that would show me in the source code where the CPU is spending time would be nice too
i-garrison has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
thellstrom has joined #dri-devel
pekkari has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
Qyriad has joined #dri-devel
Qyriad has quit [Remote host closed the connection]
<airlied>
mareko: does perf not do that? or is it missing something?
<mareko>
airlied: I use sysprof, I don't know how to do that with perf :)
dt9 has quit []
dt9 has joined #dri-devel
<airlied>
I thought sysprof gave line type info, with perf from the cmdline, perf record --call-graph dwarf then later perf report tui should let you annotate the lines of code
<airlied>
however it's a rough science and usually it's just the instruction that caused cache missies
RobertC has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
khfeng has quit [Read error: No route to host]
khfeng_ has joined #dri-devel
pnowack has joined #dri-devel
notgull has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
aswar002 has joined #dri-devel
Viciouss has quit [Ping timeout: 480 seconds]
ccokee has joined #dri-devel
ccokee has quit [Remote host closed the connection]
aswarup_ has joined #dri-devel
aswar002 has quit [Remote host closed the connection]
roman_pope[m|gr] has joined #dri-devel
roman_pope[m|gr] has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
aswarup_ has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
naveenk2 has quit []
sdutt_ has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
cen1cen1[m] has joined #dri-devel
cen1cen1[m] has quit [Remote host closed the connection]
GreaseMonkey has quit [Ping timeout: 480 seconds]
greaser|q has joined #dri-devel
Viciouss has joined #dri-devel
<danylo>
HdkR: What is that game you had a Turnip issue with?
<HdkR>
danylo: That one was Serious Sam Fusion 2017
<pepp>
mareko: I use "perf record -e cycles -e cache-misses ..." and then "perf report". Maybe some event(s) from the "Hardware cache event" category can help detect false sharing (see "perf list")
<danylo>
HdkR: If you want you can send me a trace and I'll see what's going wrong.
<HdkR>
I'll see if I can capture one
bcarvalho_ has quit []
bcarvalho has joined #dri-devel
yk has quit [Remote host closed the connection]
andrey-konovalov has joined #dri-devel
naveenk2 has joined #dri-devel
hrw[m] has joined #dri-devel
lynxeye has joined #dri-devel
hrw[m] has quit [Remote host closed the connection]
<HdkR>
Need to find what the renderdoc environment variable is for hooking vulkan again
<HdkR>
Somehow the renderdoc getting started guide doesn't have an environment variable list :|
rasterman has joined #dri-devel
<danylo>
ENABLE_VULKAN_RENDERDOC_CAPTURE=1
<HdkR>
nice. Was just about to grep the source
<HdkR>
whoa buddy. renderdoc + mangohud made things very angry
<danylo>
this happens... the saafest bet is gfxreconstruct
<pq>
jani, one big thing Weston needed from hawkmoth was to be able to group types, definitions and functions under, err, "classes". Like "everything about weston_output", and do that in the C code doc comments.
bendoin has quit [Remote host closed the connection]
<pq>
jani, while these types and functions may be spread over several files.
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
<HdkR>
danylo: If there are any problems let me know. The capture environment isn't exactly...sane
iokill has quit [Quit: leaving]
<pq>
bl4ckb0ne, fwiw, if you try to use a connector ID with a wrong DRM fd, the ID may still exist but refer to not-a-connector. Or it might ever refer to a connector, just not the one you wanted. The latter one of course cannot detect.
iokill has joined #dri-devel
<HdkR>
Rebuilding my host turnip driver as well to see if it actually plays back correctly...
<HdkR>
pfft, crash in the driver
yk has joined #dri-devel
notgull has quit []
<danylo>
HdkR: Yes, on debug build I'm getting "ra validation fail: wrong definition reaches source ssa_271:221 + 0" - that's not healthy at all
<HdkR>
:D
mihbelVOPD-t has joined #dri-devel
mihbelVOPD-t has quit [Remote host closed the connection]
<cwabbott>
woah, merged for one week and we're already finding bugs in the new RA!
* cwabbott
is proud of actually having written the ra validation pass
greaser|q is now known as GreaseMonkey
<jani>
pq: yes, I remember that
<cwabbott>
also, if the crash HdkR got is also ra validation fail, that's probably the reason for your rendering is corrupted
<cwabbott>
it's not run with release builds, and catches stuff that would result in corruption
<pq>
jani, we're not doing too well with breathe either, fwiw. One more thing I'd like is a list of all documented things that are not part of any "group" (per file?). So that their documentation ends up at least somewhere, and the grouping can be easily fixed.
<danylo>
cwabbott: would you take a look at this failures?
andrey-konovalov has quit [Ping timeout: 480 seconds]
<cwabbott>
yeah, sure
<pq>
jani, I forget if hawkmoth had a internal vs. public API doc separation, but that too is something we'd likely use.
<cwabbott>
guess it's my fault
<pq>
jani, what was the "the person wrote his own from scratch after contributing to hawkmoth a bit" project?
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
janne has joined #dri-devel
janne has quit [Remote host closed the connection]
andrey-konovalov has joined #dri-devel
kragacles19 has joined #dri-devel
kragacles19 has quit [Remote host closed the connection]
affix has joined #dri-devel
affix has quit [Remote host closed the connection]
andrey-konovalov has quit [Ping timeout: 480 seconds]
<danvet>
mripard, please move the documentation for drm_dp_aux.transfer to an inline comment
<danvet>
that stuff is a mess :-(
<danvet>
also while you're at it, maybe pull drm_dp_aux.hw_mutex into it's own inline comment, and maybe add another comment there that if the dp aux hw is shared among more than one channel, the driver must do additional locking to prevent concurrent access
<danvet>
since that's another common goof-up here, assuming it's all single-threaded already
<mripard>
I don't think I have anything else, but Ill keep that in mind, thanks :)
<mripard>
danvet: and I'm sure the property discussion doesn't help :)
<danvet>
mripard, uh mipi_dsi_host_ops would also benefit from inline comments I think ...
<danvet>
mripard, oh I already forgot about that one
<jani>
pq: I really wish they'd kept contributing to hawkmoth instead, but now there are two somewhat competing projects instead. building open source is easier than building communities. *shrug*
<mripard>
danvet: tbh, me too
<mripard>
danvet: I'm not sure how we can move forward with it at that point
<danvet>
mripard, go back to the older one, get ack from emersion and pq and merge that as minimal consensus
<danvet>
if someone wants to soften the uapi requirements, up to them imo
<danvet>
to build the consensus across the board for that
<danvet>
imo without also softening the userspace requirements I just don't think the exception is of any practical significance
<danvet>
given that compositor people said "nope, we dont want this"
<danvet>
maybe also ask hwentlan for the amdgpu take on this, dunno
<pq>
jani, they made their choice. Now you have a choice too.
<jani>
pq: ragequit? :)
<pq>
well, if you feel burdened by hawkmoth, that, or join sphinx-c-autodoc. Or is it really that bad it's not even an alternative?
jernej has joined #dri-devel
<pq>
danvet, btw. I've been spreading the "a KMS client needs to be able to save/restore properties it does not understand" idea around. Was that fine with you, or has another solution to "someone else changed KMS state while I was away" appeared?
<pq>
hmm, but it doesn't solve the initial KMS state problem.
<pq>
emersion, I've read that one. It said "fbcon sanitizes KMS state", right?
<emersion>
pq, s/fbcon/fbdev/, but yea
<pq>
emersion, that has two problems: you may not have fbcon to trigger fbdev (i.e. secondary seat), and you may not temporarily switch to fbcon when launching another KMS client from first KMS client.
<pq>
*e.g.
<emersion>
yes, it sucks.
<pq>
hmm, userspace service to record initial KMS state with a standard on how and where it is saved...
<emersion>
but kernel devs really don't want any kind of standard "default" for KMS props
<pq>
yeah, I got that, so we have to make up one. OTOH, they already have it in fbdev.
<emersion>
danvet, where exactly is the fbdev reset happening in the kernel?
<pq>
equally fbdev should not be screwed up if a KMS client does changing arbitrary KMS properties like CTM.
<emersion>
pq, it may not need to be a service. maybe just a library
<emersion>
that doesn't solve the "system without fbdev" issue
<pq>
if my HDR monitor had fbcon, would be interesting to see if it recovers from HDR mode properly :-)
<danvet>
the drm_client based fbdev emulation automatically registers the lastclose callback through drm_client infra
<danvet>
in case you wonder why not all drivers have this set
<pq>
emersion, you need a service to read out the initial KMS state before any other KMS client gets a chance to run.
<jani>
pq: I haven't really looked into the sphinx-c-autodoc codebase in detail. but I guess I'd have a hard time convincing myself to contribute to a project where the maintainer thought a rewrite from scratch is a better idea than even discussing technical opinions. *shrug*
<emersion>
pq, iirc that doesn't get reset, but my memories are fuzzy…
<emersion>
(HDR_OUTPUT_METADATA)
<danvet>
emersion, see drm_client_dev_restore, we decided to give it a slightly more meaningful name in the drm_client code
<pq>
emersion, sure it can be a one-shot service, but still something that runs at boot early enough.
<swick>
when I hacked in active color management in weston I tested the result and the colors were off, shifting more and more to the red. turned out I switched to gnome every now and then which had night light enabled.
<danvet>
pq, I think "save everything, including stuff you don't know about and restore with atomic" is still the best shot we have
<pq>
danvet, ack, thanks!
<danvet>
given that we're not very dutiful at all with even keeping the fbdev restore up to date with changes ...
<swick>
that won't really solve any problems though
<pq>
it solves one problem, but not the others
<swick>
if we have new properties which change the pixel pipeline that we don't understand our pixels get destroyed
<pq>
jani, fair.
<swick>
similarily if there is a new property which changes the display mode in what kind of color it expects the display will show wrong colors
<emersion>
hopefully the new prop's default is "retain old behavior"
<emersion>
lots of finger crossing involved with these things
<swick>
but why can't we just make that mandatory?
<pq>
swick, "retain old behavior" is already mandatory, AFAIU.
<swick>
then why can't we reset those properties when they already have a default?
<pq>
swick, the problem here is that *any* KMS client can change the property values, and they *are not reset* when it quits or switches out. Whoever gets to KMS next needs to know to reset everything.
<pq>
e.g. fbcon/fbdev, or the next active display server
NiksDev has joined #dri-devel
<swick>
I get that but properties must retain old behavior by default, so they do have a default which we could reset it to
<pq>
the reason they are not automatically reset, or why KMS clients do not reset on their way out, is that it would cause flicker: a reset followed by the next KMS client setting its own stuff. It would make smooth hand-off impossible.
<pq>
swick, yeah. That's the point where I lose track of the reasoning.
<swick>
you can still have smooth hand-off if the following client knows about all the properties the previous one used
<pq>
...those it reads back from KMS
<pq>
smooth hand-off is kinda special, too, it needs a contract of its own: don't use properties others might not understand.
<pq>
anyway, that was just a reason why you don't automatically do a reset on way out.
<MrCooper>
danvet: lastclose isn't enough for VT switch though
<swick>
right, drm should not just reset all properties but suppose atomic gets a way to tell drivers to reset everything except for a set of properites
<pq>
mripard, oh hey, you might want to spell out the "retain old behavior must be the default value" for new props.
<pq>
swick, it doesn't sound like it does.
<danvet>
MrCooper, yeah on vt-restore there's another path that goes through fbcon
<danvet>
well not vt-restore, but getting back to KD_TEXT
<danvet>
but it leads ultimately to the same code
<pq>
swick, I guess all drivers just pick their initial values *somehow*, and then fbdev reset sets some properties and forgets about the rest.
<MrCooper>
danvet: doesn't restore the gamma LUT though IME
<danvet>
MrCooper, it's just much harder to follow because there's a few layers more in the way
naveenk21 has joined #dri-devel
<MrCooper>
or maybe that was only with non-atomic again?
luzipher__ has left #dri-devel [#dri-devel]
luzipher has joined #dri-devel
<danvet>
MrCooper, I thought we unified this all for atomic
<danvet>
for legacy it's a mess, because it's all separate paths
<danvet>
and because radeon requires we whack the lut multiple times to make it stick
<danvet>
and I never figured out why
<danvet>
that's at least my recollection, would need to check the code
naveenk2 has quit [Remote host closed the connection]
<pq>
danvet, so, does atomic internally have a way to tell drivers to reset to sane state, like swick was assuming? Or is it really just "fbdev sets a bunch of properties explicitly, good luck"?
<luzipher>
Hi :-) Anyone able to provide some assistance with switchable amdgpu graphics on a laptop (Dell G5 SE)?
<luzipher>
I tried to switch GPUs with DRI_PRIME=1 and with MESA_VK_DEVICE_SELECT=1002:731f, but it seems that doesn't do anything.
<danvet>
pq, for fbdev restore, yup
iive has joined #dri-devel
<luzipher>
I'm also unable to get the Vulkan overlay working with VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay VK_LAYER_MESA_OVERLAY_CONFIG=submit,draw,pipeline_graphics ... or with RADV_HUD=1 for that matter.
<danvet>
really the only thing we have is "driver loads, let's pray it's not too screwed up"
<pq>
danvet, "yup" which way? :-)
<danvet>
pq, oh sry: fbdev doesn't have a magic access to a reasonable reset state
<danvet>
it just whacks stuff and hopes
<pq>
aha, swick ^
<luzipher>
so it's a bit difficult to know what happens (I did enable the vulkan-overlay in mesa as far as I can tell)
<danvet>
so we assume that all the fancy properties are reset by driver load to something reasonable
<danvet>
maybe fbdev should do the total save+restore too
<danvet>
unfortunately that's harder than it sounds internally, because internally we only have the decoded state
<danvet>
so would be quite some typing
camus1 has joined #dri-devel
camus1 has quit []
<pq>
danvet, I'm getting the feeling that the kernel is running out of excuses for not having a "default state" either saved or a callback to initialize an atomic state set with it. :-)
<danvet>
pq, type it up for about 100 drivers :-)
<danvet>
that's all it takes really
<pq>
right
<swick>
pq: I didn't say that the kernel does reset to a sensible default state, just that it *should*
<pq>
so it's not been rejected because it's somehow bad, but because it's a lot of work?
<DPA>
My view on the whole matter is, I don't care about a screen being black for a second or so. Who does anyway? Just keep it simple. Reset everything when taking away a lease or dropping a drm master, and call it a day, and let the next client reinitialize everything.
nurupo16 has joined #dri-devel
<swick>
there really is only a few properties where a default doesn't really make sense
nurupo16 has quit [Remote host closed the connection]
<danvet>
pq, like we don't even have a competent atomic implementation for fbdev
<danvet>
that's roughly how much people are willing to invest here
<pq>
danvet, I mean the reset facility, not fbdev reset
<danvet>
competent, as in it tries to light up fewer outputs if the full set doesn't work
<danvet>
so if you plug in enough screens, fbcon just goes blank
<danvet>
pq, yeah but if we can't even type up reset for fbdev properly, why do you think there's better chances we solve an even larger problem properly?
<danvet>
reset/reinit
<pq>
I thought there was a fundamental design reason why the kernel must not expose a default state or a reset button to userspace, and I never really understood why.
<MrCooper>
danvet: just started Xorg with modesetting driver on amdgpu DC, ran "redshift -O 2500", switched to a console VT, which shows an orange prompt (should be white)
camus has quit [Ping timeout: 480 seconds]
<pq>
danvet, because no-one cares about fbdev, but they care about Wayland?
* DPA
doesn't
<danvet>
MrCooper, oh well :-(
<swick>
seriously, what *is* the problem with giving atomic commits a "reset every property except for this set" feature?
<danvet>
swick, define semantics, type it up
<danvet>
fix all the fallout
<danvet>
no one is stopping you
<pq>
When a driver installs a KMS property, how does it get its initial value? Don't property helpers have access to the initial value?
<danvet>
there's some reset stuff we do at driver load
<pq>
I mean, when you create a propert, you have to set *some* value to it, right? So while setting that, maybe the helpers could also save that value as a default?
<pq>
so you actually don't have to patch all 100 drivers
<danvet>
so for i915 there's fastboot, so the boot-up state has some outputs enabled usually
<danvet>
should we include that or not
<danvet>
and yeah you should be able to capture something right after driver load
<danvet>
except some drivers load fbdev before that (or most), so again might or might not have stuff enabled
<pq>
ideally the reset state is "everything off and defaults", not boot-time state
<danvet>
reset/init at driver load also isn't really consistent
<danvet>
so it's not "touch 100 drivers", it's more "look at 100 drivers and check it makes sense"
<danvet>
plus also try to define what it actually means
<pq>
At least I'm happy to understand that it is not fundamentally forbidden to create a reset mechanism, just work.
<danvet>
yeah dunno where that notion came from
<pq>
The previous reasons like "the kernel does not want to waste memory saving the default state" sounded very different.
<danvet>
pq, I guess the other thing is that most users have a single compositor version they switch between
<swick>
so what would be the way forward here? define the default for all props, check all drivers and possibly adjust them, wire up a way to reset the state, expose the uapi?
<danvet>
pq, I was trying to list pros and cons of each
<swick>
gtg, brb
<pq>
ok
<danvet>
the intro has a clear off that we can figure out once we know what we want
<danvet>
I also get a feel this is mostly a developer feature request
<danvet>
and for that maybe just "reload kernel driver" is best
<danvet>
otoh that also doesn't work in all cases too well
<pq>
Right. I think the reset state should be: everything off, neutral, passthrough.
<pq>
sRGB
<danvet>
MrCooper, setcmap_atomic suggests we reset, I think this is because amdgpu only exposes the non-atomic gamma lut
<danvet>
ah no we rely on fbcon to reset the lut
<danvet>
which I guess doesn't happen on vt switch
<pq>
These are all corner-case problems, yeah. Maybe we start seeing reports once desktop compositors start using KMS color properties and HDR comes up.
pharada_ has joined #dri-devel
pharada_ has quit [Remote host closed the connection]
Anorelsan has joined #dri-devel
<danvet>
pq, I thought redshift is pretty standard, and that's already fairly busted ...
<pq>
"the gamma LUT" is fairly widely known I presume
<pq>
like you said, no-one cares if fbcon is busted
<pq>
I would not be surprised at all if most display servers already had "smash the gamma LUT" code. All desktops that have X11 style color management do, I believe.
<pq>
the catch is that the X11 style color management will never use more than "the gamma LUT" from KMS.
zakgap[m|gr] has joined #dri-devel
zakgap[m|gr] has quit [Remote host closed the connection]
NiksDev has quit [Ping timeout: 480 seconds]
naveenk21 has quit []
pcercuei has quit [Quit: brb]
<cwabbott>
HdkR: danylo: ok, i can reproduce the ra validation fail here... let's see what's going on
<danylo>
great!
pcercuei has joined #dri-devel
pastly-antispam has joined #dri-devel
<HdkR>
cwabbott: woo
<HdkR>
Hopefully it also fixes another game that is failing to compile shaders as well once fixed :)
ppascher has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Remote host closed the connection]
<cwabbott>
HdkR: well, that might be another unrelated bug
<cwabbott>
does it say "RA failed" or this "ra validation fail" message?
<cwabbott>
we haven't implemented spilling, so some things might just run out of registers and fail
<HdkR>
I'm not running a debug build, so I don't even get that message
<HdkR>
`MESA: error: compile failed! ((null):(null))` is all I get
<cwabbott>
that's probably running out of registers
<cwabbott>
i don't remember the exact error message you get when that happens, but that sounds like it
cryptk has quit [Remote host closed the connection]
Adluc has quit [Remote host closed the connection]
naveenk2 has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Remote host closed the connection]
Sumera[m] has quit []
Sumera[m] has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
Aleksey2-t has joined #dri-devel
Aleksey2-t has quit [Remote host closed the connection]
<daniels>
jani: sorry, didn't mean to imply any of that was easy or 'just' a matter of adding a small feature!
<jani>
daniels: hey, I didn't take it that way, sorry if I implied I did :)
<daniels>
not at all, se hyvä :)
NiksDev has joined #dri-devel
itoral has quit []
blue__penquin has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
blue__penquin has quit []
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
noko has joined #dri-devel
noko has quit [Remote host closed the connection]
alyssa has left #dri-devel [#dri-devel]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Remote host closed the connection]
FireBurn has joined #dri-devel
<FireBurn>
Any idea what this means:
<FireBurn>
i915 0000:00:02.0: cannot be used for peer-to-peer DMA as the client and provider (0000:01:00.0) do not share an upstream bridge or whitelisted host bridge
jammi has joined #dri-devel
jammi has quit [Remote host closed the connection]
khfeng_ has quit []
vivijim has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
khfeng has joined #dri-devel
sdutt has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
FireBurn has quit [Remote host closed the connection]
FireBurn has joined #dri-devel
<FireBurn>
Turning off pci peer to peer in my kernel config got rid of the message
<zmike>
mareko: did you have any further comments on !11312 or can we get that moving
jernej_ has joined #dri-devel
jernej has quit [Ping timeout: 480 seconds]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
dllud_ has quit [Remote host closed the connection]
<imirkin>
ah. monitor plugged in, but to the wrong gpu :)
<cwabbott>
i only have two monitors, so i have to sacrifice one screen to plug it into the device
<imirkin>
cwabbott: many monitors have multiple inputs
<imirkin>
i use this sometimes. more fun is my old monitor which allowed Picture-in-Picture with s-video
<imirkin>
so i'd just have glxgears in a PIP thing :)
<cwabbott>
yeah, but for this i need displayport for both the device and my laptop... and there's only one displayport input
<imirkin>
sadness.
<danylo>
I'm connection via vnc to avoid switching inputs, unfortunately PiP is rather useless feature on my monitor, it drops resolution and there is now way to bind a hotkey to enter PiP...
<alyssa>
jekstrand: What are your experiences with compiling anv per-gen?
<alyssa>
Asking for a friend
<alyssa>
(bbrezillon)
<alyssa>
I see the current strategy is dispatch table black magic.
<alyssa>
Kinda worried about impact on compile times and code size.
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
jernej_ has quit []
<danylo>
cwabbott: HdkR The fix doesn't affect the most major mis-rendering in that trace, there is a r16g16b16a16_float attachment becoming corrupted after the end of render pass
<jekstrand>
alyssa: It works wonders. :D
jernej has joined #dri-devel
<jekstrand>
alyssa: If you've got piles of tiny annoying differences that can mostly be sorted by having different genXML, it's fantastic.
Duke`` has joined #dri-devel
blue__penquin has joined #dri-devel
<alyssa>
jekstrand: no issues with bloating compiles/binaries?
<alyssa>
or just offset by how much of a breeze everything else is?
mbrost has joined #dri-devel
<jekstrand>
Pretty much
<alyssa>
bbrezillon: ^
<bbrezillon>
I guess we'll go for that approach then :)
<jekstrand>
When you look at how much smaller a Mesa driver is compared to anything pulling in LLVM, I'm not inclined to care.
TheAssassin4 has joined #dri-devel
TheAssassin4 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
<jekstrand>
Looks like ANV is 15M these days
<jekstrand>
Looking at .o files, it seems like it's a little under 300k per HW generation.
sdutt has quit []
sdutt has joined #dri-devel
<jekstrand>
IVB being the smallest, likely because it has less functionality over-all.
<jekstrand>
alyssa, bbrezillon: ^^
<jekstrand>
It's up to you to decide how many bytes your sanity is worth
* jekstrand
remembers when ANV fit on a floppy.....
<imirkin>
jekstrand: still does, just have to get a zip driver ;)
<imirkin>
drive*
Danct12 has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
<dj-death>
jekstrand: 90% of that might be the perf metrics
<jekstrand>
-rw-r--r--. 1 jason jason 19K Jun 16 10:22 genX_blorp_exec.c.o
<jekstrand>
-rw-r--r--. 1 jason jason 7.3K Jun 16 10:22 genX_gpu_memcpy.c.o
<jekstrand>
-rw-r--r--. 1 jason jason 36K Jun 16 10:22 genX_pipeline.c.o
<jekstrand>
-rw-r--r--. 1 jason jason 59K Jun 16 10:22 genX_query.c.o
<jekstrand>
-rw-r--r--. 1 jason jason 134K Jun 16 10:22 genX_cmd_buffer.c.o
<jekstrand>
-rw-r--r--. 1 jason jason 21K Jun 16 10:22 genX_state.c.o
<jekstrand>
-rw-r--r--. 1 jason jason 9.3K Jun 16 10:22 gfx8_cmd_buffer.c.o
RobertC has quit [Ping timeout: 480 seconds]
<alyssa>
Oh, interesting. Thanks
<alyssa>
dj-death: I read that as perf matrices like 6 times in a row and was very confused
<imirkin>
alyssa: might be a sign that you're a math major...
<alyssa>
imirkin: metrics are also a thing in math
<alyssa>
so i unfortunately don't have that excuse
<imirkin>
pfft, statistics isn't math!
<jekstrand>
As an analyst, I take offense at that. :-P
<alyssa>
metric spaces are
<imirkin>
alyssa: that's a bit advanced.
<anholt>
huh, genX_cmd_buffer.c is beating intel_perf_metrics now according to bloaty.
<imirkin>
jekstrand: i was hoping someone would :)
<imirkin>
(and thankfully it was someone who can take a joke)
<jekstrand>
imirkin: But I also take offense at people thinking linear algebra is finite-dimensional, so I'm weird. :-P
<alyssa>
jekstrand: People think that?
GloriousEggroll has joined #dri-devel
<anholt>
oops, forgot how to drive bloaty. better numbers for libvulkan_intel.so:
<JoshuaAshton>
and it doesn't have GN build system
<anholt>
you take your debug build, strip a copy of it and "bloaty --debug-file orig stripped -d compileunits"
<anholt>
(or other -d options)
<JoshuaAshton>
this is the best thing Google has made! :D
<JoshuaAshton>
./s
naveenk2 has quit []
<alyssa>
Bloaty McBloatface to the tune of Frosty the Snowman?
<JoshuaAshton>
I have an Otamatone, we can make it happen!
sneil has quit []
blue__penquin has quit []
sneil has joined #dri-devel
pecastro16 has joined #dri-devel
pecastro16 has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
reductum has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
<jekstrand>
alyssa: Only the silly narrow-minded ones.
<robclark>
imirkin: so nv/arb_copy_image multisample fails are ofc nothing to do (directly) with multisample.. we fall back to u_blitter for ms and I think that doesn't go well for 2nd `glCopyImageSubData()` which does a dst_tex to dst_tex copy
<imirkin>
robclark: when does a test fail due to what it's actually testing?
<alyssa>
robclark: it is a truth universally acknowledged that an opengl test failure has nothing to do with the thing being tested
<imirkin>
i thought it always failed for unrelated things
<imirkin>
if it's related, then it's just a pure coincidence
<robclark>
pretty much
<imirkin>
like some test that's testing weird graphics/compute image interactions... why does it fail? uniform upload fails.
spicyrice has joined #dri-devel
<imirkin>
robclark: why does u_blitter fail for ms btw?
<imirkin>
that's a thing that's supposed to work
* zmike
sweats nervously after having recently touched it
<imirkin>
we use a 2d thing on nouveau since it's easier for 1:1 copies
<robclark>
the fail is that we don't flush between `glCopyImageSubData()` because the render target doesn't change (and we don't pay attention to the fact that second blit has src==dst
<imirkin>
3d engine can be a bit annoying to use to copy ms textures
<imirkin>
oh.
<imirkin>
[you have to have per-sample shading enabled, which isn't supported on all hw]
xp4ns3 has joined #dri-devel
gouchi has joined #dri-devel
agx_ has quit [Read error: Connection reset by peer]
<jekstrand>
You also have to have MSAA texturing which isn't supported everywhere either.
<adavy>
zmike: Related to #4937, do you need some help to set a testing system ? If you don't want to install games, I can get you access to traces (apitrace) which will use various features in a 'real world' way. You'll need to use wine for that (standard wine prefix + install the wine nine standalone for the prefix which is pretty easy/fast). There's also Xnine as pointed out by imirkin, which allows to run
<adavy>
things without wine. wine tests which check various parts of the api can be run there. It's easier to debug crashes than under wine as gdb, valgrind, etc do not work with wine.
<adavy>
(in addition you'll need 32 bits build for most d3d9 apps)
<imirkin>
jekstrand: by the time you have sample shading, you have MSAA texturing, i'd hope
agx_ has joined #dri-devel
<imirkin>
jekstrand: speaking of ... is there any weirdness on intel platforms supporting ARB_texture_multisample with 2d msaa arrays vs plain 2d msaa texturing?
<zmike>
adavy: I'm mostly just interested in knowing what needs to be done to run things in general with nine; like if I LD_PRELOAD, is that enough to have an app using the d3d9 api use it?
typedlambda has joined #dri-devel
typedlambda has quit [Read error: Connection reset by peer]
<imirkin>
jekstrand: it turns out the max effective size of 2d msaa arrays is smaller than a single-layer 2d msaa texture on nv50
<imirkin>
(i.e. you can do 8k x 8k x8 msaa with 2d msaa, but not 8k x 8k x x8 x 2 layers with 2d msaa array)
<zmike>
adavy: also I didn't know you were here :)
<adavy>
zmike: the wine standalone install package does configure the d3d9.dll redirection for the target wine prefix. LD_PRELOAD won't do anything to my knowledge. As for Xnine you pass at compilation the path to the library
lemonzest has quit [Quit: Quitting]
<jekstrand>
imirkin: We shouldn't have any big problems with 2D MSAA arrays. Maybe we don on SNB but SNB is weird
<adavy>
If you have never used wine, Xnine is easier to get running
<zmike>
adavy: I think I'll try Xnine since I'm not looking to make things massively more complex just for testing purposes
<adavy>
I have ported more wine tests to Xnine locally, I can push if needed
<zmike>
it would be great if we could get some of this info into the repo now that we're starting to have real docs in html
<imirkin>
jekstrand: yeah, i think SNB is the most likely candidate for weirdness. nvidia fixed it for their DX11 hw
<imirkin>
i just wonder if DX10 had something in it allowing you to do that
<jekstrand>
The thing with SNB is that it doesn't really multi-sample as much as super-sample.
<adavy>
zmike: I recently joined the oftc chan. I used the login mannerov on freenode
<jekstrand>
It only supports 4x and it does so by blowing everything up by 2 in both directions.
<zmike>
ahh
<imirkin>
jekstrand: so then when you sample, you manually adjust coordinates, right?
<jekstrand>
imirkin: I don't remember how sampling works. I think the sampler has support for it in the TXF instruction
<imirkin>
that's what we have to do on nv50 as well. and it's why it blows through 2d array stuff.
<imirkin>
for plain 2d there's a no-mipmap "format" which allows you to have larger sizes
<imirkin>
but no such thing with arrays
<jekstrand>
But it's actually really nice, in a twisted way, for resolves because we can just sample in the corner and get the interpolation for free.
<imirkin>
jekstrand: if you don't care about sample locations ...
<imirkin>
like we don't in nouveau, coz exactly that reason :)
<jekstrand>
I don't remember the impact it has on limits off-hand. I try to keep my esoteric SNB knowledge paged out when possible. :-P
<imirkin>
wise.
<imirkin>
but i happen to be on a snb right now. might play with it.
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pekkari has quit []
<alyssa>
mareko: Do you have any objection to nir_lower_mediump_io taking a callback in lieu of modes/varying_mask?
ngcortes has joined #dri-devel
untitaker28 has joined #dri-devel
untitaker28 has quit [Remote host closed the connection]
shankaru has left #dri-devel [#dri-devel]
mbrost has quit [Remote host closed the connection]
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
sh_zam has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
sh_zam has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
aswar002 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
styx_ has joined #dri-devel
styx_ has quit [Remote host closed the connection]
Thymo_ is now known as Thymo
aswar002 has quit [Quit: Leaving]
<mareko>
alyssa: no if it doesn't change the current behavior
<alyssa>
(Bifrost has the restriction that the only 16-bit format for varying inputs is fp16. There is no way to load a flat int16 varying other than to load it as int32 and i2i16, which is the default without running the pass.)
* alyssa
still not convinced vectorization is the right approach (as opposed to partial scalarizing, to take advantage of vector inputs) but not sure
<dschuermann>
can't we already pass a function to only partially vectorize? not sure anymore
<dschuermann>
err, scalarize
<alyssa>
the callback is to only scalarize some instructions
<alyssa>
I mean partial as in "given a vec4 op, break it up into 2 vec2 ops"
<dschuermann>
ah, it could be made more sofisticated
<alyssa>
dschuermann: nir_opt_vectorize_wip with aggressive=true leads to a dramatic reduction in instruction count on the big glmark2 -bterrain shader, compared to main... before/after:
<alyssa>
it also gets me /almost/ to hitting full occupancy (a single spill is all that's needed)
gouchi has quit [Remote host closed the connection]
<dschuermann>
hm, ok I'll give it a second shot :)
<alyssa>
dschuermann: It's also possible I'm doing something silly in my backend NIR opt loop ofc :)
<alyssa>
but if you're looking for a shader to test with it's a good one
<alyssa>
is this still the same hardware errata ugh gh ugh
sdutt has quit [Remote host closed the connection]
mlankhorst has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
ngcortes has quit [Ping timeout: 480 seconds]
dabdine has joined #dri-devel
dabdine has quit [Remote host closed the connection]
andrey-konovalov has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<airlied>
was I wrong to expect 21.1.3?
<mdnavare>
airlied: imirkin:bnieuwenhuizen: What are some of the gfx benchmarking tools that I can use for performance testing with DRI_PRIME on a hybrid gfx system?
<airlied>
mdnavare: phoronix-test-suite?
<airlied>
pretty much the same tools you'd use on a normal gfx system
pcercuei has quit [Quit: dodo]
<mdnavare>
airlied: Yea phoronix test suite looks good I think and can check with Mesa CI what they use for benchmarking
<mdnavare>
has anyone used gfxbench?
<HdkR>
I've used it sparingly
<airlied>
I think intel use gfxbench and glmark over time
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #dri-devel
<bnieuwenhuizen>
HdkR: you found the way to use a public gfbench version with vulkan :P
<HdkR>
Winning
pnowack has quit [Quit: pnowack]
<alyssa>
what way is-- oh :-p
jmw has joined #dri-devel
jmw has quit [Remote host closed the connection]
merlin199110 has joined #dri-devel
merlin199110 has quit [Remote host closed the connection]
<HdkR>
I haven't tested gfxbench in a while, it might not even work anymore on AArch64. Who knows :D
<robclark>
HdkR: *ouch*..
<HdkR>
The slow tests ram out of RAM
<HdkR>
can't complain too much about it
<robclark>
HdkR: only public gfxbench for aarch64 is android.. I have a build that runs on aarch64 that I use a lot (but not public)
<HdkR>
aye
<HdkR>
Which is why I didn't use the aarch64 binary of course
<mdnavare>
okay thanks HdkR airlied and robclark
<mdnavare>
current i am just using glxgears
<mdnavare>
but thats really not a benchmarking tool
<robclark>
HdkR: tbf, gfxbench on zink on tu is kinda bad without adding x86 emu on top ;-)
<mdnavare>
so thats why looking at some more exhaustive testing
<HdkR>
It's a practice in how many layers of emulation can we stack
<alyssa>
ok am i missing something obvious or is there really a subtle errata here
<robclark>
HdkR: heheheh
<alyssa>
HdkR: throw DX9 in there somewhere
<alyssa>
oh, and PowerPC
<HdkR>
I'm sure we could do some Linux->BSD translation in there
<robclark>
if anyone reports big endian freedreno or tu bugs, I'll promptly ignore ;-)
<alyssa>
bi-endian bi-frost
<HdkR>
I refuse to support big-endian host. So it's fine
<anholt>
krh had an amazing idea for speeding up deqp runs: run deqp on a beefy x86 and just sync the BOs to an actual ARM for execution. just a short but painful step from there to big-endian support.
<alyssa>
I don't know if I want this to be satire or not :3
<HdkR>
It hurts
<alyssa>
I mean this seems to make the bug go away but ... these things keep coming back
<alyssa>
okay srsly if that didn't help performance i don't know what possible could >____>
<alyssa>
(lots of scheduler improvements so now glmark2 can have 8 texture ops in flight at once instead of 1... fps is unchanged.... hnnngh)
* alyssa
interrogates the perf counters
iive has quit []
ddavenport has joined #dri-devel
<urja>
poor counters
Sam-M1 has joined #dri-devel
<alyssa>
they identified an issue ... fixed it, fps is unchanged .....
* ccr
turns the interrogation light brighter
claw22 has joined #dri-devel
claw22 has quit [Remote host closed the connection]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
macromorgan_ has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
nanobist has joined #dri-devel
nanobist has quit [Remote host closed the connection]