ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
rmckeever has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest2332
nchery has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
<airlied> Lynne: they should, I'll dig a bit more
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
<DavidHeidelberg[m]> any chance that lavapipe reaches VK 1.3 soon?
nchery has joined #dri-devel
<airlied> isn't it 1.3 already?
mbrost has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]> looking at code it looks like that
<DavidHeidelberg[m]> but for some reason https://mesamatrix.net/ reports 1.1
<airlied> apiVersion = 4206803 (1.3.211)
<zmike> that's because the extension check there is wrong
<airlied> yeah the ext check doesn't really match how vulkan works
<zmike> and it's trying to require all extensions to determine version
<airlied> where you can be vulkan 1.3 and not support all the etxs
<zmike> the version is whatever the driver says it is
jrayhawk has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
pcercuei has quit [Quit: dodo]
<airlied> Lynne: this might help https://paste.centos.org/view/5d53abae or at least get a bit further
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
sarnex has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
sarnex has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
Guest2332 has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
Jeremy_Rand_Talos has joined #dri-devel
lemonzest has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
mbrost has joined #dri-devel
Kayden has joined #dri-devel
<Lynne> airlied: yeah, this actually works
<airlied> okay I'll push it to the radv repo
<Lynne> VK_ERROR_INVALID_EXTERNAL_HANDLE
<Lynne> hmm
<Lynne> the ptr is very minImportedHostPointerAlignment aligned
<airlied> Lynne: what driver gives that for what call?
<Lynne> found the issue, my lengtth was not aligned
<Lynne> works now, except for the very first slice
<Lynne> pushed to my repo
<Lynne> the rest of the slices get decoded fine, but the first one's not
<Lynne> hmm, maybe I should try aligning in the negative direction too
YuGiOhJCJ has joined #dri-devel
<Lynne> nope, aligning to the previous alignment point and adding offset to the slice offsets is even worse
<Lynne> if you want to test this variant, this is the diff to apply to my repo - https://0x0.st/oFXB.diff
<Lynne> err, hold on, I forgot to remove the offset
<Lynne> it works! positive alignment works!
<Lynne> still feels a bit like a hack though, negative alignment should work, combined with srcBufferOffset
i-garrison has quit [Ping timeout: 480 seconds]
<airlied> Lynne: is the api specced as int or uint?
i-garrison has joined #dri-devel
<Lynne> uint, I meant the alignment direction (negative == align to previous, positive == align to next)
<Lynne> all offsets are always positive
<airlied> ah cool was wondering
<Lynne> okay, https://0x0.st/oFXQ.diff is what ought to be working
<Lynne> err, actually not, I forgot about the bitstream buffer offset
<Lynne> *bitstream buffer offset alignment requirement special administrative investigative bureau of nomenclature
<Lynne> so the version in the repo is fine, I'll test on anv
kts has joined #dri-devel
<airlied> the repo version I have is giving the handler errors
<airlied> handle errors
<Lynne> last commit == 4439fe09?
<airlied> 53f586bce203
<Lynne> yeah, that's the old one, pull again
jrayhawk has joined #dri-devel
<Lynne> anv kinda works, but after a few tens of frames pulls a VK_ERR_DEVICE_LOST while submitting
<airlied> you pushed it? I'm not seeing it
<airlied> I think I should reduce the anv value from 4k first
<Lynne> I just pushed it again just in case
<Lynne> I am getting VK_ERROR_INVALID_EXTERNAL_HANDLE errors, was testing on a small number of frames so I didn't see it at first
<airlied> Lynne: this might help anv https://paste.centos.org/view/4f4ee7ac
<Lynne> gets a bit further, first few frames are gray, still does a device lost
<Lynne> srcBufferOffset is 0 though, so not sure why it helps
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
jewins1 has quit [Ping timeout: 480 seconds]
<airlied> Lynne: it's the kernel throwing that error
kzd has quit [Quit: kzd]
<airlied> so something is wrong with the ptr you are trying to host map
mbrost has quit [Ping timeout: 480 seconds]
<Lynne> hmm, it's definitely aligned
mbrost has joined #dri-devel
<Lynne> gpu reset while just priting values, it's not fully working yet
mbrost has quit [Read error: Connection reset by peer]
<airlied> Lynne: ah worked it out, you don't actaully allocate all the memory do you
<airlied> the fails are because the ptr + size hasn't got pages backing all of it
<Lynne> as in the size isn't enough?
<Lynne> av_fast_realloc allocs to powers of two bytes only, so it usually leaves a large amount of padding, but maybe it isn't enough
<Lynne> nope, tried aligning all slice allocs to the page size, still gpu crash
<Lynne> either way, it shouldn't really matter, should it?
<Lynne> we're not actually accessing any data past the last slice (if the file isn't corrupt)
<airlied> Lynne: you can userptr an amount of unmapped memory
<airlied> it has to be allocated and have pages in it
<airlied> to answer the size is too much I think
<airlied> host ptr 0x7f28a416c600 0x7f28a416d000 20864 24576
<airlied> so you align from the first to the second, but there isn't 24576 bytes of memory mapped after that point
aravind has joined #dri-devel
<Lynne> I aligned the size in av_fast_realloc too, so there's always enough memory, it didn't help
<airlied> I think you'd have to overallocate by the maximum delta
<airlied> so probably an extra page
<airlied> so above you allocate 20864@0x7f28a416c600 but try to map 24576@0x7f28a416d000
ngcortes has quit [Ping timeout: 480 seconds]
<Lynne> I'll try it
* Lynne braces for another hard reset
<airlied> Lynne: https://paste.centos.org/view/dc42187c that hacks seems to fix it
<Lynne> I think I get it, the bitstream size align may push the size beyond what we've allocated
<Lynne> after alignment
<airlied> yup
<Lynne> tried aligning vp->slice_size, which is the unaligned value, but that didn't work
<airlied> my hack also cleans things up on anv
<airlied> with my anv patch
<Lynne> nope, your hack didn't fix the gpu crash on radv
* Lynne wants a separate coreboot machine to avoid staring at firmware logos
<airlied> ah getting a VM fault
<airlied> I'm guessing then something is undersized in some case then
<airlied> and the bitstream reader is going off the end of allocated memory
danvet has joined #dri-devel
Duke`` has joined #dri-devel
bgs has joined #dri-devel
Leopold___ has joined #dri-devel
itoral has joined #dri-devel
thellstrom has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
bgs has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
itoral_ has joined #dri-devel
<Lynne> vlVaSyncSurface has started segfaulting for me for about a week or two now, I'll take this as a sign to finish my vulkan work instead
itoral has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
alarumbe has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
kts has quit [Quit: Leaving]
libv_ has joined #dri-devel
kts has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
frieder has joined #dri-devel
agd5f_ has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
flibitijibibo has quit [Read error: Connection reset by peer]
ernstp____ has quit [Read error: Network is unreachable]
arnd has quit [Read error: Network is unreachable]
jbarnes has quit [Read error: No route to host]
ernstp____ has joined #dri-devel
arnd has joined #dri-devel
jbarnes has joined #dri-devel
dviola has quit [Remote host closed the connection]
flibitijibibo has joined #dri-devel
zaratustra has quit [Remote host closed the connection]
dviola has joined #dri-devel
zaratustra has joined #dri-devel
fab has quit []
<jani> tzimmermann: many thanks!
pochu has joined #dri-devel
fab has joined #dri-devel
tursulin has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
clever has quit [Ping timeout: 480 seconds]
clever has joined #dri-devel
fab has quit []
dviola has left #dri-devel [#dri-devel]
fab has joined #dri-devel
dviola has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
kts has quit [Quit: Leaving]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
a-865 has joined #dri-devel
frankbinns1 has joined #dri-devel
Sachiel has quit [Ping timeout: 480 seconds]
fab has quit []
fab has joined #dri-devel
agd5f has joined #dri-devel
<MrCooper> tzimmermann: did something go wrong with the drm-misc-next pull request? It seems to touch files all over the tree, PR e-mail is almost 1 MB
frankbinns has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
vliaskov has joined #dri-devel
Sachiel has joined #dri-devel
<javierm> MrCooper: maybe due all the legacy dri1 drivers removal?
<MrCooper> don't think so
MajorBiscuit has joined #dri-devel
<MrCooper> all over the tree as in outside of the usual DRM paths
<MrCooper> e.g. net/
mvlad has joined #dri-devel
hashar has joined #dri-devel
lynxeye has joined #dri-devel
frankbinns2 has joined #dri-devel
frankbinns1 has quit [Remote host closed the connection]
elongbug has joined #dri-devel
jkrzyszt has joined #dri-devel
<jannau> MrCooper: 6f84981772535 merges drm/drm-next based on v6.2-rc2 while drm-misc-fixes was still on v6.1-rc6
<jannau> I guess the diffstat is from drm-misc-next-2023-01-19 to drm-misc-next-2023-01-24 which includes the v6.1-rc6 to v6.2-rc2 changes
<javierm> jannau: yeah, but the diffstat of commit b8f55f24bc82 ("Merge tag 'drm-misc-next-2023-01-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next") only shows change in drivers/drm/
MajorBiscuit has quit [Ping timeout: 480 seconds]
<javierm> MrCooper: ^
<MrCooper> so the PR e-mail is just misleading?
djbw has quit [Read error: Connection reset by peer]
agd5f_ has joined #dri-devel
<jannau> javierm: I assume this is for drm-misc-next-2023-01-24 (I don't see mail for that on https://lore.kernel.org/dri-devel/). the pull request email for drm-misc-next-2023-01-19 looks as expected: https://lore.kernel.org/dri-devel/Y8kDk5YX7Yz3eRhM@linux-uq9g/
pcercuei has joined #dri-devel
<javierm> jannau: yeah, I also didn't find an email for drm-misc-next-2023-01-24 but the diffstat of that merge also looks correct
<javierm> so I think is what you said, the tag being merged using a different base
agd5f has quit [Ping timeout: 480 seconds]
<MrCooper> I'm inclined not to approve this for the dri-devel mailing list
phasta has joined #dri-devel
<jannau> that happens regularly when there's a merge see https://lore.kernel.org/dri-devel/YrQeAAVvQ6jxu2dl@linux-uq9g/ for example
<jannau> it it is kind of useless, drm-misc-next-X..drm-misc-next-Y ^drm-next-Z (with drm-next-Z merged between drm-misc-next-X and drm-misc-next-Y) would be much more useful
<javierm> one way to avoid that would be to back merge whatever tag is based drm-next before sending the drm-misc-next PR
<javierm> but unsure if that would be more useful since git merge would do the right thing anyways
<MrCooper> that was over half a year ago, and sparked a similar discussion back then; I'd say avoiding the confusion would be worth it
sgruszka has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
thellstrom has joined #dri-devel
ice9 has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
frankbinns1 has joined #dri-devel
frankbinns2 has quit [Ping timeout: 480 seconds]
<frieder> Are there any DRM bridge driver maintainers around?
rmckeever has quit [Quit: Leaving]
<daniels> pinchartl: ^
<danvet> jagan should probably get commit rights too ...?
devilhorns has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
<emersion> hm, apparently this is a more general issue
ahajda has joined #dri-devel
frankbinns1 has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
phasta has joined #dri-devel
thellstrom1 has joined #dri-devel
Cyrinux has quit []
Cyrinux has joined #dri-devel
thellstrom1 has quit []
thellstrom has quit [Ping timeout: 480 seconds]
Cyrinux has quit []
Cyrinux has joined #dri-devel
frankbinns has quit []
frankbinns has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]> Yeah we got a bug report about such an issue relatively soon after changing KWin to set max bpc to 16. I changed it to use max bpc = buffer bpc (so 10 in most cases), haven't had any complaints about that yet
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #dri-devel
<MrCooper> zamundaaa: there's no direct connection between those two things
<MrCooper> the final output of the colour pipeline of current GPUs has at least 12 bpc AFAIK, regardless of the framebuffer format
<zamundaaa[m]> This is about port bandwidth limits though, not GPU bandwidth
<MrCooper> yeah, so what kwin does will artificially cap the colour accuracy on the link in some cases
jkrzyszt has joined #dri-devel
<emersion> MrCooper: is there any point in 16bps on the link, if the source buffer is 8bpc?
<emersion> bpc*
<MrCooper> it's like asking "is there a point in having apples, when there are oranges?" ;)
<emersion> hm, i'm not following... i know these are unrelated, but it's a pipeline
<MrCooper> bpc at the end of the pipeline has nothing to do with bpc of the source buffer
<emersion> if you send bad quality data into the pipe, it's no big deal if the pipe is not high quality either?
<MrCooper> even 8 bpp pseudocolour could result in 16 bpc at the end of the pipeline
<emersion> a bit like: my network adapter is 100Mbps, no need for a CAT6 Ethernet cable
<emersion> right, but the pipeline can't fix missing information in the source
<MrCooper> it can lose information though
<emersion> so your point is: if source buffer is 8bpc, and the link is 8bpc, then there can be lost info?
<MrCooper> it can result in different input values resulting in the same output values, depending on the transformations in between
<zamundaaa[m]> <MrCooper> "yeah, so what kwin does will..." <- I mean, yes, but there's not really anything better that can be done when compositors don't get any information about the restrictions on connectors
<MrCooper> zamundaaa: it's a driver issue, needs to be addressed there
<emersion> this seems very theoretical to me
<daniels> right, but in the absence of transformations it doesn't help; there is a benefit in choosing lower bpc if it lets you choose a lower link rate, because then you can run your clocks slower, or use fewer lanes which might free up more for e.g. USB
<emersion> yes, it's a driver issue, but my users an angry and the driver issue is hard to fix
<emersion> are*
<MrCooper> daniels: the driver is supposed to lower bpc automatically as needed
<emersion> yes, but no driver does this today, because it's Difficult
<emersion> for DP-MST
<MrCooper> the property is "max bpc", not "effective bpc"
<daniels> but 'I can lower my clock rate' or 'I can free up some lanes for less bad USB' aren't 'needed', they're just nice-to-haves
<emersion> i think i'll go with the same fix as kwin for now
aravind has quit [Ping timeout: 480 seconds]
<zamundaaa[m]> daniels: if the output doesn't work without it, it's absolutely needed and not just nice to have
<emersion> 4k@30Hz is not "doesn't work", but not too far :P
<daniels> zamundaaa[m]: yes
<emersion> what daniels is saying is that even if 16bpc or 10bpc works, there might be use-cases where it's better to pick a lower one
<emersion> for power savings, for instance
jdavies has joined #dri-devel
<emersion> afaiu
jdavies is now known as Guest2396
<zamundaaa[m]> That makes sense
<daniels> yeah, or because you're doing alt-mode over type-C, and if you don't use all the lanes then you can get more USB bandwidth
<emersion> right
<zamundaaa[m]> So ideally compositors should also read the EDID and check what bit depth the display actually does, and limit it to that. Or does the kernel already do that?
<emersion> i'm not sure that would help
jdavies_ has joined #dri-devel
<emersion> for me the tl;dr is that compositors really need a knob to select between quality and power savings/room for other usage
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<emersion> so it sounds reasonable to me to tie max bpc to "is high bit depth on or off"
<MrCooper> zamundaaa: it's not that simple either, due to things like temporal dithering or DSC
Guest2396 has quit [Ping timeout: 480 seconds]
bluetail3 has joined #dri-devel
libv_ is now known as libv
bluetail has quit [Ping timeout: 480 seconds]
bluetail3 has quit [Ping timeout: 480 seconds]
bluetail has joined #dri-devel
Cyrinux has quit [Remote host closed the connection]
bluetail0 has joined #dri-devel
Company has joined #dri-devel
bluetail has quit [Ping timeout: 480 seconds]
FireBurn has quit [Ping timeout: 480 seconds]
<Ristovski> It is possible to measure the effective input-to-change latency of a game for example, by mounting a photodiode on the screen and then using some external hw to fire an event (preferably something that changes the brightness of the game, like some menu, instantly) and measuring the time it takes for the brightness to change
<Ristovski> Would it be also possible if one simply cared about the pure software side?
<Ristovski> GLX/EGL_EXT_buffer_age is not quite what would be useful. I assume it would require getting the pixel contents and a timestamp of frame (but "higher up" in the chain, since then you are at the mercy of the compositor etc)
<Ristovski> Imagine a simple app that changes from black to white when you send it any input. In order to detect the change, ideally you would be able to "probe" various points in the pipeline (so from the backbuffer all the way to screen output) and do some naive pixel test on the contents. Is there something like that in mesa/drm that could help?
ice9 has joined #dri-devel
alarumbe has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
itoral_ has quit []
<zamundaaa[m]> You can definitely measure the output latency of your compositor with an app by using presentation-time, no buffer age or anything like that required
<MrCooper> emersion zamundaaa: if link bpc is capped to framebuffer bpc, any non-identity gamma transformation cannot be represented on the link directly and losslessly
angerctl has joined #dri-devel
<emersion> yes, but better have this bug than being capped at 30Hz
bluetail0 has quit []
bluetail0 has joined #dri-devel
bluetail0 has quit []
bluetail has joined #dri-devel
<karolherbst> anyone mind if I bump the meson req in CI? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19778 if not, I'm probably merge in a few hours
srslypascal is now known as Guest2403
srslypascal has joined #dri-devel
Guest2403 has quit [Ping timeout: 480 seconds]
jdavies_ has quit []
angerctl has quit [Ping timeout: 480 seconds]
phasta has quit [Quit: Leaving]
kts has quit [Quit: Leaving]
ice9 has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> I totally know how to use nir_shader_compiler_options
<alyssa> don't worry i'm a professional
<zmike> same
<alyssa> what's the reference NIR compiler these days
<alyssa> NAK is rust, ACO is C++, Intel's is nightmare fodder
<alyssa> who does that leave as the winner
<alyssa> ir3?
<zmike> "compiler" = ?
<alyssa> real hardware
<zmike> you mean backend
<alyssa> yes
<alyssa> i totally know what that word means
<alyssa> i'm a professsional remember
<zmike> I do remember
jewins has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
devilhorns has quit []
kts has joined #dri-devel
<cwabbott> ir3 is weird because it started life making a lot of "my first compiler" mistakes but has been almost completely rewritten by various people over time
<cwabbott> (no disrespect meant, everyone's gotta start somewhere)
<cwabbott> there are definitely still a few remnants of the "my first compiler" stage leftover
phasta has joined #dri-devel
<alyssa> yeah, that's fair
<alyssa> DAG-based IR?
<cwabbott> no, it wasn't DAG-based
<alyssa> * Adreno's comparisons produce a 1 for true and 0 for false, in either 16 or
<alyssa> * 32-bit registers. We use NIR's 1-bit integers to represent bools, and
<alyssa> * trust that we will only see and/or/xor on those 1-bit values, so we can
<alyssa> * safely store NIR i1s in a 32-bit reg while always containing either a 1 or
<alyssa> .............uh
<alyssa> inot?
<alyssa> (-:
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<cwabbott> that's what it used to do, but inserting inot and then removing it later is harder than just not inserting it
Jeremy_Rand_Talos has joined #dri-devel
<alyssa> weee
<cwabbott> it's basically lowering bools to 32-bit in instruction selection, but with a 0/1 representation instead of the default 0/~0
<alyssa> yeah, I see that
<alyssa> comment is just for wrong inot, I know because I had that bug in Bifrost
<cwabbott> oh, right
<alyssa> (inot is handled correctly by a special case in ir3)
<cwabbott> anyway, the biggest problem is that in the beginning it tried to map operands in the IR as closely to the assembly as possible
<cwabbott> sources and destinations had the same ir3_register type, implicit operands weren't inserted at all, and read-modify-write type things reused the same operands as source and destination
agd5f_ has quit [Read error: No route to host]
<alyssa> oh, interesting, yeah
* alyssa is guilty of some of the same
<cwabbott> and as a result there was a wrapper to iterate over "real" sources
<alyssa> ah, yeah, I remember seeing you clean that up with the SSA stuff
<cwabbott> also, no support for multiple destinations (ughhhh)
<alyssa> this is an annoying reminder I never finished either of my SSA RAs, I should probably do that at some point
agd5f has joined #dri-devel
ice9 has joined #dri-devel
Haaninjo has joined #dri-devel
fab has quit [Quit: fab]
aravind has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
bluetail has quit [Quit: The Lounge - https://thelounge.chat]
angerctl has joined #dri-devel
ajax_ has joined #dri-devel
fab has joined #dri-devel
ajax is now known as Guest2414
ajax_ is now known as ajax
Guest2414 has quit [Ping timeout: 480 seconds]
<jekstrand> jenatali, daniels: So when are we adding XBox to CI? 😅
<jenatali> Good question
<jenatali> Sounds like the FNA folks might've had a plan for it?
<daniels> reminds me, I should check if it's actually possible to buy them in the UK yet
<jenatali> Probably post-merge CI though
<daniels> although my console being old is, it turns out, not the limiting factor in my CoD performance
* jekstrand didn't expect that to have a serious answer.
<daniels> I do my best to meet your limited expectations
illwieckz has joined #dri-devel
illwieckz has quit [Read error: Connection reset by peer]
bluetail has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
angerctl has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #dri-devel
illwieckz has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
phasta has quit [Quit: Leaving]
Cyrinux has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
anarsoul has quit [Ping timeout: 480 seconds]
angerctl has quit [Ping timeout: 480 seconds]
zehortigoza has joined #dri-devel
anarsoul has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
djbw has joined #dri-devel
<eric_engestrom> jekstrand: there was already a discussion about that on the initial MR (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19022#note_1585646)
<eric_engestrom> the open question was on the license for using GDKX in a CI
neobrain has quit [Remote host closed the connection]
srslypascal has quit [Ping timeout: 480 seconds]
<jekstrand> eric_engestrom: Neat!
jeeeun8413 has quit []
sgruszka has quit [Ping timeout: 480 seconds]
jeeeun8413 has joined #dri-devel
frieder has quit [Remote host closed the connection]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<enunes> daniels: DavidHeidelberg[m]: looks like download speed is particularly bad today, it doesn't seem to be something bad on my runner as in a quick test I get my full connection download speed, I wonder if theres anything to do (other than cache proxy)?
mbrost has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<DavidHeidelberg[m]> enunes: for traces we have the etag checking (so caching traces on NFS), but that's only idea which I have right now
jeeeun8413 has quit []
<enunes> the jobs on my runners don't use the traces, what is really slow are kernel/rootfs which today are hitting <1MB/s
tursulin has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
Leopold___ has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
FireBurn has joined #dri-devel
ajax_ has joined #dri-devel
ajax has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
<alyssa> I'm ok with xbox in post-merge but not in pre-merge
<DavidHeidelberg[m]> robclark: Hey! From the latest report it seems that perf for traces dropped around 3-18% https://gitlab.freedesktop.org/mesa/mesa/-/issues/7144#note_1739532
srslypascal has joined #dri-devel
<robclark> DavidHeidelberg[m]: if it isn't something unrelated like kernel uprev, it could be https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20708
<DavidHeidelberg[m]> robclark: Emma mentioned perffeto enablement
<robclark> it's possible that has some overhead too.. but also don't really care ;-)
<robclark> I guess you should have a list of candidate MRs based on which day?
<robclark> anyways, conservative lrz can be disabled via driconf (and therefore env var) so that would be an easy way to rule out it being related
<anholt> the commit range didn't cover lrz.
<anholt> unfortunately the stats thing doesn't decide where the regression happened, so you don't get a list of candidate mrs
<anholt> you have to click the link and zoom in on the graph and log commit messages where you see the regression happen.
gouchi has joined #dri-devel
<robclark> ok, then not conservative-lrz.. if the range did include perfetto enable, that seems plausible.. but also not a thing to care about since it is apple vs orange thing
* robclark amused that android play protect thinks android cts is a sketchy application that it should protect me from
<anholt> robclark: crashes so many devices, must be some sort of attack!
<robclark> yup, lol
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
<Venemo> jekstrand, alyssa can I merge 15838 or do you have further comments or suggestions about it? also, can you guys please give an answer to dschuermann_ 's RFC here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15838#note_1738359
pallavim has joined #dri-devel
bgs has joined #dri-devel
illwieckz has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
<alyssa> deferring to dschuermann
<alyssa> if he's ok with it I probably am too
alyssa has left #dri-devel [#dri-devel]
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Leopold___ has joined #dri-devel
<anholt> ajax_: started checking how hard it would be to run deqp-vk.wsi in ci, to catch that regression. despite being a build that I think should include the tests, just enabling xvfb is not getting tests run from what I can see.
<airlied> would wsi not need dri3?
<airlied> i suppose lvp might work in its putimage path
<anholt> that's what I was thinking
Leopold_ has quit [Ping timeout: 480 seconds]
<daniels> weston-headless will give you dri3
<daniels> at least as long as you pass --xwayland
<anholt> looks like locally I can pass 76, fail 1 with lvp against xwayland with -j 1.
<jekstrand> Venemo: Done both
<anholt> weston on ci says command not found. yay for the stupid separate vk container :(
srslypascal has joined #dri-devel
<anholt> sticking an xvfb-run in locally gets the same results. and xvfb is eating some cpu, so I think the testing may even be valid
<daniels> anholt: f
<daniels> anholt: I've got somewhere in my scribbled to-do notes to check if having separate containers actually still makes sense or is just enormous annoyance for marginal gains at this point
<anholt> daniels: scribble another note in there I came up with today: x11_glx and x11_egl_glx deqp targets are I think exactly the same.
<anholt> you do need to be using default or x11_*_glx targets in order for vulkan to get x11 wsi. and we probably want to be using default so we can do both wayland and x11 in one build for vk. but then my question is what impact that has on winsys testing for EGL and GL/GLES.
<anholt> then I imagine trying to trace through the layer cake of GL platform init in deqp, and then well what do you know it's lunchtime already.
kts has quit [Quit: Leaving]
<daniels> yeah, I've just read through that and wow I cannot tell you how much it's after 8pm
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
ayaka_ has joined #dri-devel
<zmike> anyone know how to do a 32bit build with cmake
<zmike> nevermind I think I remembered
<daniels> I'm sorry to hear that
<zmike> me too
<Ristovski> thanks for ruining my otherwise perfect night by mentioning c*ake
gouchi has quit [Remote host closed the connection]
<ayaka_> any reminding problem about this MR? I didn't see any future review that I need to complete
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
agd5f has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
ayaka_ has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
ayaka_ has joined #dri-devel
srslypascal has joined #dri-devel
<airlied> zmike: I think I shove -m32 in the cflags/cxxflags for vk-gl-cts
<airlied> -m32 -mfpmath=sse -msse
<zmike> yea something like that indeed
<airlied> it's in the vulkan cts docs
<zmike> hm
<zmike> shame I'm not building cts then, but will try to remember for next time
<airlied> external/vulkancts/README.md
<airlied> some things like llvm have an option
<airlied> but yeah if you are building anything outside llvm/cts with cmake, then all I have are thoughts and prayers
<zmike> I prayed in just the right way to make it happen, but I'm not happy about it
caef^ has joined #dri-devel
iive has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
heat has joined #dri-devel
vliaskov has quit [Read error: No route to host]
bgs has quit [Remote host closed the connection]
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mbrost_ has joined #dri-devel
ajax_ is now known as ajax
illwieckz has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
illwieckz has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
krushia has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
gouchi has quit [Remote host closed the connection]
robertfoss has joined #dri-devel
robertfoss has quit []
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
frankbinns1 has joined #dri-devel
<Lynne> airlied: figured out what was not aligned?
frankbinns has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
jkrzyszt has quit [Ping timeout: 480 seconds]
bluetail9 has joined #dri-devel
bluetail has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
flto has quit [Remote host closed the connection]
abhinav__ has quit [Quit: Ping timeout (120 seconds)]
flto has joined #dri-devel
abhinav__ has joined #dri-devel
a-865 has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
mbrost_ has quit [Ping timeout: 480 seconds]