oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
fab has joined #dri-devel
tzimmermann has joined #dri-devel
bgs has joined #dri-devel
yuq825 has quit []
yuq825 has joined #dri-devel
itoral has joined #dri-devel
<zzag>
emersion: do you know what gbm_bo_import() does when importing a dmabuf buffer allocated by another gpu? would gbm_bo_import() start a transfer to another gpu or something? or would it just create a gbm_bo wrapper for the specified dmabuf attributes and that's all?
mvchtz is now known as Guest2382
mvchtz has joined #dri-devel
<zzag>
a transfer from another gpu*
Guest2382 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
benjamin1 has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
<RAOF>
zzag: *Mostly* you don't care? It's *mostly* transparent. (ie: if you try and import it as an EGL image and then sample from it the driver will do... a thing, and sampling will work)
bgs has quit [Remote host closed the connection]
<RAOF>
The mostly there is that it's almost certainly not going to let you scanout of that gbm_bo. I think all the bits necessary to make that possible are there, but nothing's hooked up (see my gbm_bo_import + ALLOW_MIGRATION proposal a couple of days ago)
<zzag>
RAOF: well, that still leave me wondering about what gbm_bo_import() does. we have some multi-gpu code which I would like to change, but it makes some assumptions about what gbm_bo_import() does, e.g. starting data transfer and allocating local storage on the gpu
<zzag>
still leaves*
<zzag>
and I wonder whether it's right thing to do
kzd has quit [Ping timeout: 480 seconds]
<RAOF>
What are you using gbm_bo_import for?
<zzag>
Multi-gpu in compositor: render on one gpu, then gbm_bo_import() that buffer on another gpu and present it
<RAOF>
Because if you've got a dmabuf then you can probably just import it directly into your rendering API of choice and use it directly?
<RAOF>
Yeah, that's the thing that doesn't work.
<RAOF>
Unless by "present" you mean "sample from in your rendering on the GPU that's going to be displaying it"
<zzag>
I mean scanout the imported buffer
<kode54>
zehortigoza: your branch fixed the frame flipping glitches
<RAOF>
Unless I misread the code, that's not expected to work.
<RAOF>
Or, rather, gbm_bo_import(, USE_SCANOUT) will check that it's scanoutable, but not do anything to make that happen, and GPUs pretty much only scanout of device-local memory.
<RAOF>
(At least, that was the state the last time I tried to scanout of foreign dmabufs and we patched the drivers to return EINVAL at add_fb time rather than silently display black when you tried)
xroumegue has quit [Ping timeout: 480 seconds]
pallavim has quit [Read error: Connection reset by peer]
<RAOF>
If I am misreading the code I'd love to know, because I'd love that to work properly :)
fab has quit [Quit: fab]
<zzag>
RAOF: "but not do anything to make that happen" yeah, that's what I'm trying to understand. I see that i915 calls drmPrimeFDToHandle() and fills other internal data structures in i915_drm_buffer_from_handle. amdgpu seems to do the same but it also does some memory stuff with amdgpu_va_range_alloc+amdgpu_bo_va_op_raw (not sure what they really do) in amdgpu_bo_from_handle
rosefromthedead has joined #dri-devel
<emersion>
i don't really know zzag
<emersion>
RAOF: where is jour proposal?
<RAOF>
"proposal" might be a bit strong; it was in this channel, a couple of days ago.
<RAOF>
Basically, add an ALLOW_MIGRATION flag to gbm_bo_import, use the dri blit infrastructure to actually do the migration if necessary, and then some wondering about maybe plumbing fences through.
<emersion>
i'd really rather not have this
<emersion>
GBM is an allocation library, not a rendering library
<RAOF>
It's not a big problem, it's just annoying and there seems like there must be a better way.
pochu has joined #dri-devel
<emersion>
why is it annoying?
heat has quit [Remote host closed the connection]
<RAOF>
I mean, mesa's gbm literally has access to a "make this work" function pointer :)
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
heat has joined #dri-devel
<emersion>
another reason:
<RAOF>
It's annoying because there's a whole bunch of setup, and a whole bunch of useless state that we hope gets mostly ignored, and it's harder to plumb explicit fences through.
<emersion>
compositors should try to import BOs only once
<emersion>
if you do a blit at import time, you need to import each frame
<emersion>
which is not very nice
<emersion>
well, it's setup you need anyways, since you're doing rendering when compositing
<emersion>
and explicit fences are in fact something which will be hard to get right with a GBM API, whereas it's already all there in GL/Vulkan
<RAOF>
Not if you're compositing on the other GPU, though.
<emersion>
i mean, you already have some kind of GL/Vulkan abstraction
<emersion>
for me it's just a few function calls to blit
<emersion>
in wlroots i mean
<emersion>
zzag: i think i asked MrCooper a while ago, and the answer was iirc something like this:
<emersion>
in theory nothing should happen on cross-device import, but some drivers might migrate the buffer to a different location
fab has joined #dri-devel
junaid has joined #dri-devel
<zzag>
hmm, okay.. it seems like the best option is just to do blits and avoid gbm_bo_import because there are no concrete guarantees how it works in multi-gpu case
mvlad has joined #dri-devel
<emersion>
i'd really like a "please fail if you're going to migrate" kind of flag
jkrzyszt has joined #dri-devel
<emersion>
client DMA-BUFs might come from anywhere, i want to try to do direct scan-out for these, but i don't want to start any kind of heavy work when doing that
sravn has joined #dri-devel
pcercuei has joined #dri-devel
tursulin has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
<karolherbst>
looks like there are failing tests and nothing has anything to do with my MR
djbw_ has quit [Remote host closed the connection]
apinheiro has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
yuq825 has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
junaid has joined #dri-devel
yuq8251 has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
yuq825 has quit [Ping timeout: 480 seconds]
<MrCooper>
zzag: curious how you plan to do blits between GPUs without gbm_bo_import or something equivalent :)
<MrCooper>
emersion zzag: a BO which is shared between devices has to be accessible by all of those devices; traditionally, this means the BO has to be in system RAM (which generally means scanout can't work with dGPUs)
<MrCooper>
on setups where PCIe P2P DMA works, the BO can stay in the exporter device's local memory in theory
<MrCooper>
(not sure scanout from another dGPU can work / is a good idea in that case)
rasterman has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
aissen has quit [Ping timeout: 480 seconds]
<zmike>
karolherbst: at least some of these were noted as having been missed in the recent piglit uprev (did someone forget to stress?), but I don't know why the CI expectations haven't been updated
<daniels>
RAOF, zzag: I'd personally be furious if gbm_bo_import was silently allocating and blitting under the hood ...
<daniels>
I mean, almost all problems on mobile hardware come down to memory bandwidth, so I absolutely don't want to be adding _more_ memory bandwidth as a silent 'helpful' action
<daniels>
but then it also pretty much breaks the whole idea of dmabuf, if the client holds one BO which it renders into, and the server holds another BO which is an older shadow copy of some content that used to be in the client's BO, and they don't realise that they no longer refer to the same storage
<daniels>
I can see the call for something like a gbm_bo_copy() which would use a DMA engine or something if necessary, but that would _have_ to be an explicit alloc+copy step, not changing import to be a hidden alloc+copy step rather than the lightweight ref it is today (MMU/TLB overhead notwithstanding)
vliaskov has joined #dri-devel
aissen has joined #dri-devel
<MrCooper>
agreed
<zzag>
Okay, thank you all for the comments! :)
<MrCooper>
zmike: no image tag bump → piglit snapshot stays the same in images used by CI → no change in results
<daniels>
yeah, the piglit-uprev script did break after the great job renaming; there's a fix in there which actually produces the right image tag bump now, as well as making it scream out erroring when it fails to substitute
<karolherbst>
soo.. should I just push the updated CI fail lists or should I wait on something else?
<daniels>
pls push
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<daniels>
enunes: eric_engestrom reports that the lima runner is out of disk
<enunes>
daniels: I'll look at it now... I wonder how, no matter how many disk cleanup scripts already run
<daniels>
enunes: are you using docker or podman? if the latter, I pushed some changes fixing failures that I saw on our shared runners
<daniels>
if you're still back on docker, you'd have to look at what was failing and why ... they seem to change their API pretty frequently :\
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
<enunes>
I still have the docker setup, but I will gladly move to podman if that is supported now
Company has joined #dri-devel
<enunes>
daniels: where did you push fixes that run on podman setups? something I need to pull and run locally too?
<enunes>
runners should be good for now
<pq>
zzag, in the end, you'll probably end up implementing all possible variations of how to get images from a GPU to a KMS device, and then you have to wonder how pick the combination that not only works but is also performant.
<alyssa>
austriancoder: congrats on the Igalia gig :~)
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
yuq825 has joined #dri-devel
kts has joined #dri-devel
<zamundaaa[m]>
pq: we already have most variations. Atm we do gbm_bo_import -> egl with blit -> CPU copy. The first one that works gets chosen
yuq8251 has quit [Ping timeout: 480 seconds]
pallavim has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
shashanks has joined #dri-devel
<pq>
zamundaaa[m], which device do you have executing the blit?
yuq8251 has joined #dri-devel
<zamundaaa[m]>
the target device
shashanks_ has quit [Ping timeout: 480 seconds]
<pq>
zamundaaa[m], do you make sure the target device is not software-rendering?
<zamundaaa[m]>
yes
<pq>
cool
<zamundaaa[m]>
If you're asking that way, I gotta ask back: does blitting with the source device have advantages over doing this?
<emersion>
i don't think blitting with the source device works
<emersion>
it would essentially render to a foreign buffer
<emersion>
(maybe it works in some cases? not sure)
* zamundaaa[m]
goes and tests it
<pq>
only fairly special case: source device blit could be faster than CPU copy into a dumb buffer if that can be accessed at all.
yuq825 has quit [Ping timeout: 480 seconds]
<pq>
I'm thinking iGPU as source device, and virtual device as target.
<pq>
but in the DisplayLink case with iGPU, the zero-copy with source-allocated buffer worked.
<pq>
so maybe source device blit doesn't have use in practice
<pq>
There is glBlitFramebuffer or something that may not have to be the same as "rendering" hardware-wise.
heat_ has joined #dri-devel
heat has quit [Remote host closed the connection]
iive has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
bmodem1 has quit [Ping timeout: 480 seconds]
<mareko>
karolherbst: I don't know if the vectorization patch works
<karolherbst>
ahhh
<karolherbst>
mareko: well, it does seem to vectorize the loads we've discussed on the issue
<karolherbst>
but it would also be nice to know if any GL workloads are impacted here
alyssa has left #dri-devel [#dri-devel]
yuq8251 has quit []
itoral has quit [Quit: Leaving]
apinheiro has quit [Quit: Leaving]
jewins has joined #dri-devel
kugel is now known as Guest2409
kugel has joined #dri-devel
Guest2409 has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
jenatali: So, I have a lowering pass to convert imageLoad to txf
<alyssa>
The problem is... that's not legal in NIR
<alyssa>
imageLoad has access qualifiers and txf doesn't
<alyssa>
this is causing a fail in KHR-GLES31 which has a test doing
<alyssa>
imageLoad()
<alyssa>
imageStore()
<alyssa>
barrier()
<alyssa>
imageLoad()
<alyssa>
as images, NIR knows better than to CSE the loads
<alyssa>
as txf, NIR will CSE and then get stale data
<alyssa>
I could do the lowering Late(TM) but that seems like a hack
<jenatali>
Yep, sounds about right
<alyssa>
you get around this by doing it only for readonly I guess
<jenatali>
Right
<alyssa>
Hmm
<alyssa>
I definitely need this for read/write
<alyssa>
So my options are either do this As Late As Possible and hope it's late enough
<jenatali>
A read-only image can be equivalent to a texture
<alyssa>
or just keep the image_load and emit the txf internally in the backend at NIR->backend IR time
<jenatali>
Yeah the latter is what I'd do here
<alyssa>
cool and good
<alyssa>
shouldn't be terrible I think
<alyssa>
will do
<alyssa>
thanks for the input
<alyssa>
also why are you online isn't it stupid early for you
<jenatali>
Both txf and image load map to the same DXIL intrinsic, so it's effectively what I do too
<jenatali>
I have a baby who wakes up at 5am
<alyssa>
womp
<jenatali>
I only do the txf translation because DXIL also cares about variable types, and an image load pointing to a texture is weird
junaid has quit [Remote host closed the connection]
<jenatali>
Oh and FYI soon enough I'll have another baby so I probably won't be around much for a few months after that
<alyssa>
congrats :)
<jenatali>
I'll still be on IRC thanks to the matrix bridge though so if you need me I'll at least hear about it
<alyssa>
=D
<austriancoder>
alyssa: thx
alyssa has left #dri-devel [#dri-devel]
kzd has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
jenatali: ugh, so the reason this is sticky is that I have a lot of txf lowerings
<alyssa>
so it would end up getting duplicated
<alyssa>
might be a lesser evil, but
ADS_Sr has quit [Remote host closed the connection]
ADS_Sr has joined #dri-devel
<jenatali>
Like what? Just curious
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<alyssa>
slice and dice of the sources into the order the hardware wants as backend1/backend2
<jenatali>
Ah fun
<jenatali>
Then maybe the very late option, after all CSE, is the right approach
<alyssa>
this sounds dodgy
egbert is now known as Guest2416
egbert has joined #dri-devel
<alyssa>
I guess duplicating the slice and dice isn't so bad
kts has joined #dri-devel
yuq825 has joined #dri-devel
<DemiMarie>
alyssa: is this in C or in Rust? In Rust pattern matching should be able to make short work of stuff like this.
Guest2416 has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<DemiMarie>
Also Mesa would be a good use for all of Linux’s work on fallible Rust allocations.
<DemiMarie>
And unlike Mesa’s C code, the Rust code actually has a chance of recovering from them, at least assuming the OS doesn’t kill it.
fxkamd has quit []
<zamundaaa[m]>
> * <@zamundaaa:kde.org> goes and tests it
<zamundaaa[m]>
so I did, and it *kinda* works with Intel + NVidia
<zamundaaa[m]>
That is, importing the buffer and rendering to it seems to work fine, until I do glFlush, where it just hangs indefinitely...
<zamundaaa[m]>
probably not worth investigating more
<MrCooper>
that was a buffer from nvidia imported into an intel context?
<zamundaaa[m]>
yes
<MrCooper>
not sure how the buffer provenance would make a difference for glFlush; do you have a backtrace where it hangs?
<MrCooper>
hmm, one possibility might be the nvidia buffer's implicit sync object having a fence which never signals, there's currently a known nvidia bug like that
<eric_engestrom>
daniels, enunes: I didn't pause the runner, I was in a meeting and didn't see your "ok" on doing it until I also saw the "no need anymore" ^^
<eric_engestrom>
enunes: thanks for cleaning it!
<enunes>
eric_engestrom: no problem, hopefully that should not be regularly needed... I'll plan some maintenance to switch to a podman runner with the new better cleanup script
<zamundaaa[m]>
MrCooper: I don't have a debug build of Mesa installed on that laptop right now, so all I can say that under a few layers of iris_dri.so it's stuck in an ioctl
<alyssa>
jenatali: k, typed the thing out
i509vcb has joined #dri-devel
<alyssa>
realized I definitely need to distinguish them, because even my backend does CSE (and soon scheduling) so needs to know if a given txf can be reordered or not
<DemiMarie>
zamundaaa: Is this nouveau or proprietary?
<zamundaaa[m]>
proprietary
jfalempe_ has quit [Read error: Connection reset by peer]
jfalempe has joined #dri-devel
<DemiMarie>
I did not realize the proprietary driver supported dmabufs. I thought that was all EXPORT_SYMBOL_GPL.
yuq825 has left #dri-devel [#dri-devel]
<zzag>
There's an open source (kinda) nvidia driver
junaid has quit [Remote host closed the connection]
idr has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
junaid has joined #dri-devel
MrCooper has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
shashanks has quit [Ping timeout: 480 seconds]
<emersion>
vulkan YCbCr question: is it a big deal to use a nearest filter for implicit chroma reconstruction?
<emersion>
or is linear really better>
<emersion>
i'm talking about VkSamplerYcbcrConversionCreateInfo.chromaFilter
<emersion>
maybe you know gfxstrand?
fab has joined #dri-devel
benjamin1 has joined #dri-devel
frieder has quit [Remote host closed the connection]
benjaminl has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
smilessh has quit [Ping timeout: 480 seconds]
<dj-death>
emersion: this is normally controlled by VkSamplerYcbcrConversionCreateInfo::chromaFilter
pochu has quit [Quit: leaving]
<emersion>
sure, but what is the effect?
<emersion>
how bad is nearest compared to linear?
<emersion>
is it reasonable to use nearest?
benjamin1 has quit [Ping timeout: 480 seconds]
<dj-death>
never tried it
shashanks has joined #dri-devel
<dj-death>
visually I mean
<dj-death>
if I remember the CTS verifies that you're using the right filter
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
shashanks_ has joined #dri-devel
shashanks has quit [Read error: Connection reset by peer]
<emersion>
yeah, and intel disables it because of a bug
<emersion>
disables the linear one
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<dj-death>
for one format
shashanks_ has quit [Ping timeout: 480 seconds]
<emersion>
for single-plane YUV formats yeah
<alyssa>
Mesa: error: GL_INVALID_VALUE in glDeleteProgram
<alyssa>
CTS, chill
lynxeye has quit [Quit: Leaving.]
<emersion>
hwentlan_: do you have a plan already to merge the HDR patches? do you want to go through the AMD tree, or drm-misc?
alyssa has left #dri-devel [#dri-devel]
<hwentlan_>
was thinking of taking the DRM patches through drm-misc, then merging the whole thing, including amdgpu patches through the AMD tree
<emersion>
hm, not sure it's a good idea to merge the DRM part via drm-misc
<emersion>
will ask danvet
<sima>
if it's just for a single tree usually just an ack for the drm parts is enough
<hwentlan_>
any reason? I don't mind taking everything through the AMD tree either but wouldn't want the DRM patches to go stale and cause merge conflicts if they're sitting in the AMD tree for while
<sima>
it'll come back pretty quickly through the drm.git pulls anyway
<sima>
hwentlan_, well if you sneak them in still now before merge window freeze it's quick
<sima>
otherwise you kinda have a bit of trouble anyway since drm-next isn't open until about -rc2 again
jewins has quit [Ping timeout: 480 seconds]
<hwentlan_>
sima, sneak them through drm-misc?
<sima>
and doesn't matter whether the drm patches are stuck in drm-misc or amdgpu during that time I think
<sima>
hwentlan_, all through amdgpu and make sure agd5f still does a pull?
<hwentlan_>
in that case I guess might as well just take the whole set through the amdgpu tree
<sima>
I mean assuming it's all ready and all, I've been drowning terrible last few weeks so now idea :-/
<hwentlan_>
I see
<hwentlan_>
I think they're finally ready for merge. Was going to give people an extra day before merging but if that means we'll miss the merge window I'll merge them today
Leopold_ has quit [Remote host closed the connection]
<emersion>
yeah the DRM core part is ready for merging now
<sima>
hwentlan_, check with agd5f I guess
<emersion>
well, let me know if you want me to merge via drm-misc
Leopold_ has joined #dri-devel
<agd5f>
hwentlan_, sima was planning to do one more -next PR this week
<agd5f>
probably friday
<hwentlan_>
I'll merge it to amd-staging-drm-next today
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
jewins has joined #dri-devel
naseer has joined #dri-devel
idr_ has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pallavim_ has joined #dri-devel
gouchi has joined #dri-devel
ngcortes has joined #dri-devel
Guest2387 has quit [Remote host closed the connection]
pallavim has quit [Ping timeout: 480 seconds]
fab has quit [Remote host closed the connection]
danilo has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
dakr has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
danilo has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
junaid has joined #dri-devel
idr_ has quit []
idr has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
djbw_ has joined #dri-devel
benjaminl has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Quit: WeeChat 3.8]
kasper93_ has joined #dri-devel
kasper93 has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
ultra has quit [Quit: ultra]
junaid has quit [Remote host closed the connection]
ultra has joined #dri-devel
pallavim has joined #dri-devel
apinheiro has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
pallavim_ has quit [Ping timeout: 480 seconds]
<karolherbst>
jenatali, gfxstrand: I'm trying to figure out what's wrong with the spec id parsing inside clc. My understanding is, that multiple values can be assigned the same spec constant id, right? clc atm asserts, that there is a string 1:1 relation between values and spec constants.
<karolherbst>
clc_helpers.cpp:340
<karolherbst>
and I think we can just remove that check
<jenatali>
Sounds reasonable without looking at it
<karolherbst>
yeah, but you also added that assert so I kinda want to understand why :)
<jenatali>
That was a long time ago, I really don't remember
<karolherbst>
okay
<karolherbst>
guess I just submit a MR ditching it
<karolherbst>
I run into this assert with spir-vs I get from HIP and SyCL
<mattst88>
I would have used an alpha, but the sparc was faster
ultra has quit [Remote host closed the connection]
<airlied>
karolherbst: your rusticl MR needs to drop the softpipe CI change, since it came in via another MR and rebase duplicated it
pallavim has joined #dri-devel
ultra has joined #dri-devel
<daniels>
airlied: thought you were all about the VAX
pallavim__ has quit [Ping timeout: 480 seconds]
<airlied>
daniels: I had a brief period of putting Linux on university sparcs when nobody was looking :-P
gouchi has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
<daniels>
I had a brief SH4 period of putting Linux on my Dreamcast, then realising I had nothing to do with it and didn't have a year to compile anything so just went back to Tony Hawk 2
<airlied>
the VAX at least had interesting but pointles problems to solve :-)
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
<idr>
SPARC was faster? mattst88, shut your mouth.
<idr>
Lololololol
<mattst88>
idr: gentoo's sparc devbox is 2x 16-core/32-thread CPUs @ 3.6 GHz with 512 GB of RAM :)
<mattst88>
it's a biiiiiit faster than my dual 1.15 GHz Alpha, and I don't have to pay for its electricity :)
<idr>
I sometimes forget that they keep making more advance SPARC CPUs.
<mattst88>
I think most people have, including maybe oracle themselves
<idr>
Ha!
<karolherbst>
airlied: CI failed anyway :)
mbrost has quit [Ping timeout: 480 seconds]
<daniels>
karolherbst: ergh yeah, the duplicate-case thing is pain; really wish we had a linter for that
<karolherbst>
well.. a job failed saying a line is there twice, but yeah.. would be nice to know that ealier
<daniels>
right, I mean something that could either be run locally or in a fast-fail check (like the existing 'sanity' job) to avoid bouncing through marge
<karolherbst>
yeah.... guess that could help with taking some load of CI, because it kinda is overloaded a lot of the times these days :'(
<airlied>
at some point if we had a job fail die we blow the pipeline up and marge would notice or was I dreaming?
<airlied>
oh maybe dreams you always had a chance to retry a job before the deadline
<daniels>
mmm
<daniels>
airlied: if all jobs in the pipeline complete and one or more fails, then marge does give up and walk away - it's not just sleep(3600); check();
<daniels>
if one job fails and others are still running, you've got a window to retry - but we did also add in automatic retries anyway
<daniels>
that has the side effect of hiding some flakes, but realistically everyone just smashed it straight back at marge regardless, so it's mostly an efficiency gain
iive has quit [Quit: They came for me...]
mdroper has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
smilessh has joined #dri-devel
q66 has quit [Quit: WeeChat 3.8]
oneforall2 has quit [Remote host closed the connection]