thellstrom has quit [Remote host closed the connection]
bgs has joined #dri-devel
fab has quit [Quit: fab]
pallavim has quit [Read error: Connection reset by peer]
imre is now known as Guest4200
imre has joined #dri-devel
Guest4200 has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tursulin has joined #dri-devel
frankbinns2 has joined #dri-devel
rasterman has joined #dri-devel
frankbinns1 has quit [Ping timeout: 480 seconds]
Thymo has joined #dri-devel
JohnnyonFlame has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
Haaninjo has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest4208
<bbrezillon>
mripard: I realize I queued patches to drm-misc-fixes just before the merge-window. Don't remember what happens in that case. Are you merging drm-misc-fixes into drm-misc-next, or should we wait for those fixes to be merged in Linus tree and ask for a main -> drm-misc-next backmerge?
<bbrezillon>
context => we depend on those fixes for some work we develop against drm-misc-next
swalker__ has quit [Ping timeout: 480 seconds]
cwegener has joined #dri-devel
heat has joined #dri-devel
mbrost has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
<mripard>
bbrezillon: the latter, but fixes are sent pretty much every week so it shouldn't cause you too much troubles
YuGiOhJCJ has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<bbrezillon>
mripard: sounds good, thanks!
sima has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
thellstrom has joined #dri-devel
vliaskov has joined #dri-devel
simon-perretta-img has quit [Quit: Leaving]
simon-perretta-img has joined #dri-devel
dviola has quit [Quit: WeeChat 3.8]
simon-perretta-img_ has joined #dri-devel
dviola has joined #dri-devel
simon-perretta-img__ has joined #dri-devel
Ahuj has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
cmichael has joined #dri-devel
simon-perretta-img__ has quit []
djbw has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
frankbinns2 has quit [Remote host closed the connection]
bmodem has joined #dri-devel
Leopold_ has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
bmodem1 has joined #dri-devel
illwieckz has joined #dri-devel
penguin42 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<penguin42>
karolherbst: Thanks!
<karolherbst>
no worries. Will you look into wiring up proper profiling as well?
<karolherbst>
and thanks for the help
<penguin42>
I will, yes
<penguin42>
just needs to kick a couple of other-project patches out first
sgruszka has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<karolherbst>
penguin42: in regards to the radeonsi load vectorization patch, you could also just open an MR with that with my updated patch or something
<karolherbst>
just provide some data it helps. Maybe even check if it helps with GL? dunno
<karolherbst>
though not many things actually use ssbos and I think for ssbos there are other optimizations in place
<penguin42>
karolherbst: I can't honestly say I understand the innards of the code that the patch changes
<karolherbst>
it just adds an optimization pass radeonsi calls
<karolherbst>
and moves some bits around as currently radv is using it
<karolherbst>
so it moves it into common code so it can be used by radeonsi, and then radeonsi uses it
<karolherbst>
or rather the amd llvm compiler uses it
<karolherbst>
actually...
<karolherbst>
I have an idea
<karolherbst>
mupuf: you all only test the aco radv perf in terms of performance regressions, right? Or are you also tracking changes for radeonsi and/or radv+llvm?
<mupuf>
performance? We don't do any sort of performance testing
<karolherbst>
uhh.. surprising
<karolherbst>
but okay
<mupuf>
I know ;) One day, one day!
<karolherbst>
guess you just wait for users to report regressions
<karolherbst>
:)
lordheavy has joined #dri-devel
<mupuf>
regressions? What's that word?
<mupuf>
:D
<penguin42>
mupuf: Look here! I have a particularly pointless piece of OpenCL code I want to run pointlessly fast
frieder has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah well.. it will affect everything else though
<karolherbst>
but it might be that GL just doesn't hit this particular pattern, or maybe just not often enough
<orowith2os>
karolherbst: tracking performance? not more fuel for zmike, surely ;)
<mupuf>
more seriously, running benchmarks would be good... but there aren't that many we can run for vulkan...
<karolherbst>
yeah.. but that's zink on radeonsi+aco
<penguin42>
karolherbst: I guess it might depend what crazyness they do in their shaders
<karolherbst>
and the patch in question only affects the llvm compiler
<karolherbst>
well.. the only way of hitting this in OpenGL is via SSBO
<karolherbst>
and SSBOs have 32 bit offsets
<karolherbst>
though.. the pattern could still exist, just.. dunno, might just not happen
<mupuf>
karolherbst: radv+llvm is known-broken :s
<karolherbst>
fair
<karolherbst>
ohh... we could run shader-db stuff...
<karolherbst>
anybody tracking shader-db on radeonsi with a.... useful shader set?
<mupuf>
karolherbst: it's called fossils for vulkan
<mupuf>
tracking its performance would be tracking the compilation speed
<karolherbst>
yeah sure, but the patch in question applies to the llvm compiler, so dunno what's best to do here
<karolherbst>
but I also think this patch should just land anyway
<karolherbst>
yeah, as I said, just submit it as an MR with some more detailed data there
wwheeler has quit [Ping timeout: 480 seconds]
itoral_ has joined #dri-devel
* penguin42
admits to being unsure about submitting a MR for a patch he didn't write, and doesn't understand the detail of
itoral has quit [Ping timeout: 480 seconds]
ced117 has quit [Ping timeout: 480 seconds]
<LaserEyess>
you can put `Co-Authored-By: Name <email@domain.com>` on the commit
<javierm>
mripard, tzimmermann: do you know if commit d13b5d2b2b45 ("drm/i2c: Switch i2c drivers back to use .probe()") can still make it to v6.5-rc1 ?
<javierm>
it's currently in drm-misc-next, Uwe wanted to know
<tzimmermann>
javierm, it won't, sorry
Ahuj has quit [Ping timeout: 480 seconds]
<tzimmermann>
we're past -rc6 already
<javierm>
tzimmermann: ah, right. That's OK, I just wondered whether that was the case or not
<tzimmermann>
javierm, i'd need one more review for my fbdev patchset. can you help?
itoral_ has quit [Remote host closed the connection]
<alyssa>
kusma: maybe? I'll swap you for your NIR builder series ;)
<javierm>
tzimmermann: looks good to me as well. Just answered in the list
<tzimmermann>
thank you so much
serg has joined #dri-devel
<kusma>
alyssa: I'll have to wait until tomorrow, I'm soon in back-to-back meetings :P
<alyssa>
kusma: good luck ;p
stalkerg has joined #dri-devel
Company has joined #dri-devel
wwheeler has quit [Ping timeout: 480 seconds]
<alyssa>
dj-death: does your r-b also apply to the commit adding the macros, or just the replacement commit?
<dj-death>
alyssa: I thought people still had suggestions for the first commit
<alyssa>
dj-death: I reworked that commit taking the suggestions into account
<alyssa>
Something of a compromise... I really liked Faith's solution until finding it doesn't compile (~:
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
smiles_1111 has quit [Remote host closed the connection]
<dj-death>
alyssa: I wonder why you need the 2 loops
<alyssa>
dj-death: To define two different variables of different types
frieder has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<dj-death>
alyssa: can't you do: for (impl = first_impl(shader); impl != NULL; impl = next_impl(impl->function)) ?
<alyssa>
dj-death: That's Yonggang's solution
<alyssa>
I'm not fundamentally opposed but it's definitely doing more "work" than the other approaches since the compiler can't know that fxn->impl->function == fxn
smiles_1111 has joined #dri-devel
simon-perretta-img has joined #dri-devel
frieder has joined #dri-devel
jewins has joined #dri-devel
frankbinns has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
APic has joined #dri-devel
yuq825 has quit []
<dj-death>
alyssa: I'm failing to see why it's more work, but you current change also work
<dj-death>
alyssa: left a rb
phasta has quit [Quit: Leaving]
<alyssa>
dj-death: with the impl->function approach, every iteration the code dereferences function->impl and then dereferences again impl->function instead of just remembering function
<alyssa>
(Is that actually better because of a lessened risk of spilling? well, that's a different issue I suppose.)
wwheeler has joined #dri-devel
greenjustin has joined #dri-devel
kzd has joined #dri-devel
eukara has joined #dri-devel
<dj-death>
yeah
eukara has quit []
<dj-death>
I'm not sure iterating functions is like a hot path ;)
eukara has joined #dri-devel
<alyssa>
Me neither :)
<alyssa>
But nearly every NIR pass does it
pallavim has joined #dri-devel
shashanks has joined #dri-devel
wwheeler has quit [Quit: wwheeler]
wwheeler has joined #dri-devel
vliaskov_ has joined #dri-devel
APic has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
wwheeler has quit [Quit: wwheeler]
wwheeler has joined #dri-devel
kts has joined #dri-devel
Soroush has quit []
kts has quit [Quit: Konversation terminated!]
APic has joined #dri-devel
Duke`` has joined #dri-devel
wwheeler has quit [Quit: wwheeler]
wwheeler has joined #dri-devel
frieder has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
serg has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
wwheeler has quit [Remote host closed the connection]
sgruszka has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
Guest4208 has quit [Remote host closed the connection]
bmodem1 has quit [Ping timeout: 480 seconds]
<jenatali>
Vulkan question: Can vkCmdClearAttachments be used to clear attachments that are currently not bound as color/depth-stencil attachments in the current subpass?
<jenatali>
My spec reading says yes but that seems odd
Leopold__ has joined #dri-devel
<Company>
jenatali: the command selects what to clear via the bound state, no?
<jenatali>
No, you pass in an array of attachments
<jenatali>
Oh, nevermind
<jenatali>
You pass an array of aspects and/or color indices
<jenatali>
Cool, thanks
<Company>
yeah, it's a VkClearAttachment, not a VkAttachmentReference
<jenatali>
Yeah, I'd just assumed instead of reading :P
Leopold_ has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
Ahuj has joined #dri-devel
ngcortes has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
dviola has left #dri-devel [WeeChat 4.0.0]
dviola has joined #dri-devel
<alyssa>
in GL, can shared textures (ie winsys surfaces) be used with MRT?
<alyssa>
It's my understanding they can't be bound as shader images, at least
<alyssa>
(If they can I can deal with it -- I know I'll have to deal with it for Vulkan -- but it would be for convenient if they can't)
<alyssa>
not even sure where to look in the spec for that
<alyssa>
I guess so: eglCreateImage to a renderbuffer, glFramebufferRenderbufer to a nonzero attachment
<alyssa>
Grumble grumble grumble. Ok. I'll figure out how to deal with it.
<alyssa>
(I mean, shadow and blit. But ugh.)
<HdkR>
Everyone loves their MSAA window buffers
<alyssa>
HdkR: not MSAA, MRT
<HdkR>
Oh! misread
<HdkR>
But yea, sounds about right :D
djbw has joined #dri-devel
deathmist1 has quit [Remote host closed the connection]
deathmist1 has joined #dri-devel
rasterman has joined #dri-devel
iive has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
wwheeler has joined #dri-devel
wwheeler has quit [Quit: wwheeler]
Danct12 has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
sravn has quit []
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
vliaskov_ has quit [Remote host closed the connection]
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
notpeelz has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
sravn has joined #dri-devel
ybogdano has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
frankbinns has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
agd5f_ has quit [Read error: Connection reset by peer]