yuq825 has quit [Read error: Connection reset by peer]
yuq825 has joined #dri-devel
gnuiyl has quit [Remote host closed the connection]
aravind has joined #dri-devel
pallavim has joined #dri-devel
Duke`` has joined #dri-devel
mattst88 has quit [Read error: Connection reset by peer]
mattst88 has joined #dri-devel
Daanct12 has joined #dri-devel
tzimmermann has joined #dri-devel
khfeng_ has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
kts has joined #dri-devel
mhenning has quit [Quit: mhenning]
JohnnyonFlame has quit [Read error: No route to host]
JohnnyonFlame has joined #dri-devel
fab has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
soreau has quit [Remote host closed the connection]
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
soreau has joined #dri-devel
khfeng_ has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
nchery_ has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
<mareko>
zmike: are you sure that will help anything?
alanc has joined #dri-devel
kts has quit [Quit: Leaving]
<mareko>
Kayden: DISCARD_RANGE is implemented as "upload into a staging buffer and then copy it to the original buffer". When you map UNSYNCHRONIZED, you don't need the staging buffer dance, so that's why the flag is cleared.
kts has joined #dri-devel
<mareko>
Kayden: When you map a buffer PERSISTENTly, you want the map pointer to point to that buffer directly, not the staging buffer. DISCARD_RANGE causes buffer_map to return the pointer to the staging buffer and buffer_unmap should do the copy from staging, but PERSISTENT mappings don't expect to see buffer_unmap before use, so any upload into PERSISTENTly mapped buffers with DISCARD_RANGE would only upload
<mareko>
into the staging buffer and it would never get copied into the original buffer without buffer_unmap.
jfalempe has joined #dri-devel
glennk has quit [Remote host closed the connection]
<mareko>
UNSYNCHRONIZED and DISCARD_RANGE use entirely different codepaths, they are not compatible
glennk has joined #dri-devel
<mareko>
DISCARD_RANGE is pipelined on the CPU but it waits for idle on the GPU, so it's the second worst thing after glFinish
<Kayden>
Okay, maybe that's where the disconnect is for me
<Kayden>
If a resource is idle, I can promote things to UNSYNCHRONIZED. But at least for tiled images, I cannot map those directly, because it expects a linear view. So I have to use staging buffers.
<mareko>
TC doesn't do anything for textures
<mareko>
also TC doesn't allow drivers to promote anything to UNSYNCHRONIZED
<Kayden>
right
danvet has joined #dri-devel
nchery_ is now known as nchery
<mareko>
one reason for that is that replace_buffer_storage doesn't copy the valid range, so the range is invalid after that
kts has quit [Quit: Konversation terminated!]
<Kayden>
I guess I've been thinking about it as staging vs. direct map rather than synchronous map vs unsynchronized
<Kayden>
I want to use a staging buffer for things like...uncached reads, or active compression that the CPU can't understand, or the buffer being busy (just enqueue work rather than flushing it and waiting and CPU mapping)
<Kayden>
if I'm using a staging buffer I want to know whether the existing contents may be necessary
<Kayden>
because if you might be doing partial writes, then a staging map needs to copy the existing data into the staging buffer, then return a map, let the user change the data arbitrarily, then blit it back on unmap/flush_region
<Kayden>
a buffer might be idle, so in theory we could do an unsynchronized map of it, but it's still in VRAM that would have uncached reads...
<Kayden>
hm. I'd been looking at si_buffer_transfer_map, but I guess I need to look at si_texture_transfer_map too. they're the same for me.
itoral_ has joined #dri-devel
exit70 has joined #dri-devel
Leopold__ has quit [Remote host closed the connection]
<Kayden>
I guess for read/write buffers without discard range and unsynchronized, you always do a direct map, rather than doing a staging buffer.
srslypascal has quit [Remote host closed the connection]
<Kayden>
even if the memory is uncached
itoral has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
kts has joined #dri-devel
<Kayden>
Okay, I also note that si_texture_transfer_map only copies image data into the staging buffer if PIPE_MAP_READ is set. Which means if you only set PIPE_MAP_WRITE, and don't write the entire box, then the rest of the contents are lost
<Kayden>
iris doesn't do that. it preserves the existing contents if you send PIPE_MAP_WRITE and -not- DISCARD_RANGE.
<Kayden>
if you wanted that for radeonsi I guess you'd have to pass PIPE_MAP_READ | PIPE_MAP_WRITE
<Kayden>
which...I guess MapTextureImage is our own internal API of sorts, so we can make it work however we want
<Kayden>
but that's not exactly consistent with buffers IMO
<Kayden>
Okay, though...texstore.c has been setting GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_RANGE_BIT on MapTextureImage calls since 2012. And _mesa_access_flags_to_transfer_flags turns that into PIPE_MAP_WRITE and either PIPE_MAP_DISCARD_RANGE or PIPE_MAP_WHOLE_RESOURCE.
<Kayden>
so either it's supposed to mean something for textures, and I'm right to respect it, or it isn't, and texstore shouldn't set it
<Kayden>
Brian made that change so I suspect it's used by svga
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
tursulin has joined #dri-devel
<pq>
emersion, I've forgot all context and not really in the mood to dig into it.
<emersion>
ok
<emersion>
no worries
jkrzyszt has joined #dri-devel
mvlad has joined #dri-devel
lynxeye has joined #dri-devel
<pq>
bl4ckb0ne, gnu_symbol_visibility:hidden is a way to stop exporting *all* non-static symbols. Then you somehow mark those symbols you actually want to export.
pallavim has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
pallavim has joined #dri-devel
sarahwalker has joined #dri-devel
lvl1slime has joined #dri-devel
rgallaispou has joined #dri-devel
rgallaispou has quit []
<lvl1slime>
is the gitlab down for anyone else?
<lvl1slime>
nvm it works
lvl1slime has quit [Remote host closed the connection]
apinheiro has joined #dri-devel
rgallaispou has joined #dri-devel
rgallaispou has quit []
pallavim has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
<bl4ckb0ne>
pq: yeah i got that part, what's driving me crazy is that it works for gles but not egl
<eric_engestrom>
yeah it makes no sense to me either, but I don't really have time to dig into it right now
<bl4ckb0ne>
im poking around
<eric_engestrom>
but I don't think patching the khronos headers is something we should do
<bl4ckb0ne>
i could upstream the fix
<eric_engestrom>
yeah if the patch is upstream that's fine, but I just don't want us to carry patches on top of upstream khronos headers anymore
<bl4ckb0ne>
agreed
<emersion>
eric_engestrom: we already patch the headers for MESA_NO_X11 right?
<eric_engestrom>
yeah, that's what's being removed here
<bl4ckb0ne>
latest rev switched to USE_X11 for xlib stuff
<eric_engestrom>
daniels: in my experience `-DFOO=BAR` doesn't work well if `BAR` has `()`
<emersion>
the header defines it right?
<eric_engestrom>
different compilers expect different escaping
<eric_engestrom>
ah wait you're right
<bl4ckb0ne>
emersion: KHR header yeah
<bl4ckb0ne>
KHRONOS_APICALL
<emersion>
so i don't think we can override that
<bl4ckb0ne>
its then copied ad EGLAPI, GL_API and GL_APICALL
<eric_engestrom>
no wait (again) I just checked it's the initial define that's the issue
<eric_engestrom>
the `# define KHRONOS_APICALL __attribute__((visibility("default")))`
<emersion>
we could include the KHR header, #undef, then #define again…
<emersion>
and include the EGL header
<eric_engestrom>
we could do that yeah
<emersion>
eric_engestrom: the new header #defines KHRONOS_APICALL to be nothing
<emersion>
and we want instead to define it to be __attribute__((visibility("default"))
<eric_engestrom>
indeed
<bl4ckb0ne>
yes
<eric_engestrom>
the thing I want to understand before we go with one hack or another, is why the symbols are still exported for GL but not for EGL
<bl4ckb0ne>
but EGLAPI is only used in the egl header
<emersion>
eric_engestrom: does GL uses the same KHR header?
soreau has quit [Read error: Connection reset by peer]
<bl4ckb0ne>
yes
<bl4ckb0ne>
GLES, GLES2 and GLES3
<bl4ckb0ne>
ive ran the symbol check on all three, works just fine
soreau has joined #dri-devel
<emersion>
i mean, does GL use that KHRONOS_APICALL
<daniels>
is APICALL the right place for visibility tho? I'd expect API call to be about parameter-passing convention, not 'hey can you actually include this symbol'
<daniels>
and I think someone else noted as well that you can put the visibility attr on the definition rather than the declaration, which wouldn't require modifying any headers
<emersion>
daniels: right, that would be better
<bl4ckb0ne>
so putting PUBLIC on all the egl api functions?
<emersion>
but i'm not sure that's possible with the EGL loaders and stuff?
<bl4ckb0ne>
iirc those are not loaded
<bl4ckb0ne>
its core functions, like eglBindAPI and eglTerminate
<emersion>
so that's all about the mesa EGL entrypoints?
<bl4ckb0ne>
about symbols yeah
<emersion>
we generate these somewhere right?
<emersion>
could just add the visibility attr to the generated code
<bl4ckb0ne>
yeah, there's the PUBLIC macro in utils
<bl4ckb0ne>
im testing it atm
<bl4ckb0ne>
yup it works
<emersion>
nice
<bl4ckb0ne>
had doubts on musl with __GNUC__
<bl4ckb0ne>
but oh well it seems to be working
<emersion>
it's not about musl, it's about the compiler
<bl4ckb0ne>
works even on clang?
<emersion>
we pass default_visibility=private to the compiler
<emersion>
and then explciitly mark some functions as public
<emersion>
each compiler which supports the default visibility arg also supports the C attr
<bl4ckb0ne>
yeah i saw that in meson, we pass hidden to everything
<bl4ckb0ne>
maybe thats what we should do for wlroots
<emersion>
we already do it but in a different way
<emersion>
instead of littering C attrs everywhere, we have a rule saying that all symbols starting with "wlr_" are public
<emersion>
and the rest are private
<eric_engestrom>
emersion: GL symbols stuff is generated, but EGL symbols hard-coded
<bl4ckb0ne>
ah maybe thats why
<bl4ckb0ne>
maybe during generation the script sprinkles a bit of visibility attributes
<eric_engestrom>
maybe
<eric_engestrom>
anyway I think the suggestion of `sed s/EGLAPIENTRY/PUBLIC/ -i src/egl/main/eglapi.c` is a reasonable fix
<bl4ckb0ne>
shouldnt we keep EGLAPIENTRY?
<emersion>
yeah, i'd add PUBLIC but keep the prev one
<eric_engestrom>
right yes, I got EGLAPI and EGLAPIENTRY confused
<javierm>
tzimmermann: the combination of shadow-buffered planes with DRM_SHADOW_PLANE_MAX_*, damage areas, and buffer management sometimes makes my head hurt :)
<tzimmermann>
same here
<tzimmermann>
give me a bit to type a reply by mail
<javierm>
tzimmermann: thanks!
<pq>
javierm, welcome to winsys land? :-D
<javierm>
pq: haha
fahien has joined #dri-devel
fahien has quit []
Lucretia has quit [Remote host closed the connection]
<ccr>
"Winsys Land" sounds like a "good place to have bad time" -type unamusement park
Lucretia has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
simon-perretta-img has quit [Quit: Leaving]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
simon-perretta-img has joined #dri-devel
<eric_engestrom>
bl4ckb0ne: CI is looking very green so far :)
<bl4ckb0ne>
:D
<bl4ckb0ne>
thats nice because i have more EGL update on the way
pallavim has joined #dri-devel
<eric_engestrom>
🚅
<eric_engestrom>
ah, we only fixed the "plain egl" symbols, we forgot about glvnd
<eric_engestrom>
bl4ckb0ne: I posted the one-line patch on the MR
<bl4ckb0ne>
already added it :D
<tzimmermann>
vsyrjala, hi. this test in the helper ensures that an enabled crtc always has a primary plane attached to it. it originated from the simplekms helpers and we want to use that test in other drivers as well. added in 765831dc27ab ("drm/simple-kms-helper: Fix the check for the mismatch between plane and CRTC enabled.")
rgallaispou has quit [Read error: Connection reset by peer]
<bl4ckb0ne>
eric_engestrom: looks more green now
itoral_ has quit []
<eric_engestrom>
bl4ckb0ne: indeed, it looks ready to merge; I would wait a bit though, in case anyone has an objection
<bl4ckb0ne>
absolutely
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
Duke`` has joined #dri-devel
<vsyrjala>
tzimmermann: that looks egually strange to me. nothing there guarantees the plane to be actually enabled. so there must be some other check in the driver somewhere if that is really a hw requirement
<vsyrjala>
or is this just to deal with some other code which assumes that every crtc has a primary plane?
<vsyrjala>
i gues the setcrtc/page flip ioctls might do that
<tzimmermann>
vsyrjala, by 'enabled' you mean visible on the screen? the drivers, such as ast, call drm_atomic_helper_check_plane_state() with can_position == false for their primary plane. this will ensure that the plane is on the screen
<tzimmermann>
as you said, we want to ensure that every enabled plane has a primary plane
<javierm>
tzimmermann: s/plane/crtc right ?
<vsyrjala>
iirc that only guarantees it's either fullscreen or not visible at all
<tzimmermann>
yeah, typo
<tzimmermann>
fullscreen vs invisible is all we need
<vsyrjala>
vs. is not what i mean. i mean a 'fullscreen || invisible -> success, else -> failure'
<vsyrjala>
btw the mga driver at least could easily simulate turning off the primary plane by just making the lut all black. the lut doesn't affect the cursor or overlay
<vsyrjala>
similar thing might be possible on other old hw
<tzimmermann>
i'm not sure what the sementic difference is. but what you describe is what we want, i think.
<vsyrjala>
that implies you can turn off the primary plane, and therefore the check for the attached primary plane can't have anything to do with hw requiremets
<vsyrjala>
therefore it must be about some piece of code assuming that a primary plane is always attached to a crtc
<tzimmermann>
drivers call check_plane_state() with can_update_disabled == false
<vsyrjala>
that just means you can't update the plane when the crtc is off. it doesn't mean you can't turn off the primary plane
<vsyrjala>
iirc
<tzimmermann>
what exactly do you mean by 'turn off'?
<vsyrjala>
stop scanning out pixels
<tzimmermann>
in ast we do that when we disable the plane. and then we want the crtc to be off as well
<vsyrjala>
plane off can be achieved by either fb=NULL (plane is both logically off and actually off in hw), or by having it fully clipped (plane still logically on, but actually off in hw)
pallavim has quit [Read error: Connection reset by peer]
Leopold_ has joined #dri-devel
fahien has joined #dri-devel
<zmike>
mareko: on tilers yes, it looks to be a sizable (30%+) perf change in a number of cases
<zmike>
I suppose it also depends on how efficiently the driver can parse the call queue from set_framebuffer_state, but I thought I'd get your input before I tried to wip it
aravind has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
pcercuei has joined #dri-devel
<agd5f>
airlied, danvet, hey one last -fixes PR for recent board revisions. Sorry for the last minute changes
yuq825 has left #dri-devel [#dri-devel]
rkanwal has joined #dri-devel
frankbinns has joined #dri-devel
<Venemo>
agd5f: can you remind me where to find drm-next?
Leopold___ has quit [Remote host closed the connection]
Leopold___ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
Company has joined #dri-devel
kts has joined #dri-devel
<eric_engestrom>
PSA: the 22.3 branchpoint was originally set for 2022-10-12 (the second wednesday of october) ie. less than 2 weeks from now, but given that XDC happens the week before zmike and Venemo have suggested we push it back a couple of weeks
<eric_engestrom>
in other words, the 22.3 branchpoint is now set for 2022-10-26
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
<Venemo>
eric_engestrom: could it be pushed to the 1st week of november instead? october is not only xdc but also khronos f2f
<eric_engestrom>
sure 2022-11-02 then :)
<Venemo>
thanks
tursulin has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: bbl]
fxkamd has quit []
Soroush has quit []
Soroush has joined #dri-devel
Soroush has quit []
Soroush has joined #dri-devel
heat has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
<emersion>
vsyrjala: eh, that check is quite simple
<emersion>
vsyrjala: although many user-space programs just set all props each commit
<emersion>
so i think we need to compare old/new and error out if there's a change
<vsyrjala>
imo no one should attempt that approach with an async flip
<vsyrjala>
it's too special
<emersion>
well
<emersion>
all user-space i know does this
<emersion>
and changing it would be quite burdensome
<vsyrjala>
no userspace has atomic async flips
<vsyrjala>
i would think you also need special fallback handling for async flips. so dunno how "just blindly set the async flag, and then clear it i guess if it fails" approach would work
ella-0 has joined #dri-devel
<vsyrjala>
if you did want to do the "check that everything didn't change" approahc then it's going to require code all over the place
<emersion>
then i'd rather keep as it is right now
<emersion>
amdgpu has what's necessary
ella-0_ has quit [Read error: Connection reset by peer]
<vsyrjala>
as far as you know. with no extensive tests it's hard to prove it
<vsyrjala>
the simple check on uapi level woudln't need so much tests either since it's pretty much obviously correct. would still require some tests though
fab has quit [Read error: Connection reset by peer]
fab_ has joined #dri-devel
fab_ is now known as Guest1862
che_ has quit [Remote host closed the connection]
rkanwal has quit [Quit: rkanwal]
JohnnyonFlame has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
<karolherbst>
ajax: up for some more rust reviews? Like to land !18852 and
<karolherbst>
!18802
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
<swick>
vsyrjala: so apparently EDID content can change when the display settings change. does the kernel notice the change?
<swick>
but maybe there is so few displays that actually do that so it might not matter
<swick>
even though they really should because half of the EDID data depend on the settings
ybogdano has joined #dri-devel
<vsyrjala>
does the display pulse hpd sufficiently when that happens? that is when edid gets re-read
<swick>
mhh, no idea, I don't have access to the display
<swick>
do we get an uevent if an edid changed?
<vsyrjala>
yes. assuming the hpd triggered the re-detect
<swick>
okay, great, that means I can look for EDID changes in user space (assuming that displays behave as expected)
<vsyrjala>
drm.debug=0xe should also show a flurry of activity in dmesg when the hpd happens
<swick>
neat
<swick>
I do how widespread that behavior is though
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
Leopold___ has quit [Write error: connection closed]
lynxeye has quit [Quit: Leaving.]
MajorBiscuit has quit [Quit: WeeChat 3.5]
apinheiro has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
<RSpliet>
Newbyte: there's #lima for more in-depth questions on lima. Looks like the dev is AWOL, but is expected to be around again during working hours or something
<gawin>
Plagman: would it be possible to release win7 driver for steam deck? (just for gpu, for single gpu passthrough) RDNA2 is still covered by driver for dedicated gpus on win7
Surkow|laptop has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
fahien has quit [Quit: fahien]
warpme___ has quit []
gawin has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
sravn has quit []
<ajax>
karolherbst: i can't think of a good reason for it to set that to 0, looks like it's just always been that way
<danvet>
agd5f, I guess you mean "pls make extra pull request"?
macromorgan has quit [Read error: Network is unreachable]
macromorgan has joined #dri-devel
<danvet>
agd5f, I'll get that going if airlied doesn't beat me to it (next few hours, need to get stuffed with smoked salmon first now)
JohnnyonF has joined #dri-devel
<karolherbst>
ajax: yeah.. that's what I am thinking as well.. I want to rely on the flag to decide how to sync shadow buffers, but not entirely sure yet
JohnnyonFlame has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
ngcortes has quit [Remote host closed the connection]
gawin has joined #dri-devel
<ajax>
if swrast did say it was uma that'd be a pretty good heuristic
<ajax>
so good that i'd say it's a bug that swrast doesn't
sdutt has joined #dri-devel
<karolherbst>
yeah so my current idea is to try to map with PIPE_MAP_DIRECTLY, but only if it's UMA, and if that fails fallback to a coherent staging shadow buffer, and then copy between the pipe_resource and the shadow resource
<karolherbst>
for silly reasons I can't rely on transfers :/
<karolherbst>
at least not for CLs map APIs
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<agd5f>
danvet, yes. thanks!
<daniels>
danvet: smoked salmon in pastry?
anholt_ has quit [Remote host closed the connection]
<danvet>
daniels, nah not that fancy
anholt has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
ngcortes has joined #dri-devel
warpme___ has joined #dri-devel
macromorgan has quit [Read error: Network is unreachable]
<jstultz>
jekstrand: airlied: wanted to follow up on the idea of having DRM_IOCTL_SYNCOBJ_* ioctls be callable against an exported drm_syncobj fd... I'm thinking about a case where one of the processes doesn't have permissions access to the drm device to call the ioctls against (even to import the syncobj fd to a handle).
apinheiro has joined #dri-devel
gawin has quit [Remote host closed the connection]
<agd5f>
danvet, thanks!
chipxxx has joined #dri-devel
jewins has quit [Remote host closed the connection]
apinheiro has quit [Quit: Leaving]
Sachiel_ has joined #dri-devel
Sachiel is now known as Guest1900
Sachiel_ is now known as sachiel
sachiel is now known as Sachiel
Guest1900 has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
jfalempe has quit [Quit: Leaving]
alyssa has joined #dri-devel
<alyssa>
dcbaker: Maybe _you_ will be the hero that unifies the GenXMLs.
<DavidHeidelberg[m]>
zmike: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/29299890 something is fishy. First minio upload times out, not the job times out... this not going to finish I think, maybe the runner. But if I cancel, the pipeline will fail (because it's last job)
<DavidHeidelberg[m]>
seems like it's not a good day to merge... haha
<dcbaker>
alyssa: uh oh
<alyssa>
dcbaker: You don't seem excited :(
<alyssa>
it's admittedly unclear to me which GenXML should be canonicalized
<alyssa>
(i.e. moved from src/vendor/genxml to src/genxml and then extended to cover the other vendors)
<zmike>
DavidHeidelberg[m]: I think I saved it
<dcbaker>
You say here, but all I can think of is a book I read once where the the Hero is actually unwittingly the servant of the bad go
<alyssa>
Intel has the benefit of being the original
<dcbaker>
alyssa: we are the one true genxml :)
<alyssa>
yeah
<alyssa>
v3d needs an extension to handle unaligned packing and unpacking
<DavidHeidelberg[m]>
zmike: I see what u did, retriggered successful job and stopped & triggered this one, right?
<alyssa>
this is easy enough to do with find-and-replace if you fork Intel (as v3d does)
<zmike>
DavidHeidelberg[m]: pray with me 🙏🙏🙏
<alyssa>
Handling both cases in a unified codebase seems harder
<DavidHeidelberg[m]>
zmike: sending thoughts and prayers... :D
<zmike>
need 🙏🤞🙏 to beat the 60 minute timer now
<zmike>
don't think I'll make it
<alyssa>
panfrost has a bunch of incremental extensions: Arm-style modifiers, word:bit syntax for start, <aggregate>s though that might be dubious, printing tailored for reverse-engineering
<alyssa>
all of that could be merged back into Intel GenXML without breaking compat, I think
vliaskov has quit [Read error: Connection reset by peer]
<alyssa>
asahi is a straight up fork of panfrost
<alyssa>
imagination has gone off and done their own thing and while it's definitely in the GenXML family tree IDK if it's worth considering
<alyssa>
I have half a mind to just promote src/intel/genxml to src/genxml and then port my drivers
<zmike>
6 minutes to finish 10 minutes of job definitely not looking good
<DavidHeidelberg[m]>
ETA 9 minutes :'(
<zmike>
sigh
<alyssa>
oh, also <field/> using size attributes instead of length
<alyssa>
I think that was a v3d change that panfrost and asahi inherited
<zmike>
these Intel jobs take forever in ci
<alyssa>
Right so the GenXML family tree looks like:
<zmike>
5 mins just to start
<alyssa>
Intel ---> v3d ---> panfrost --> asahi
<alyssa>
|
<alyssa>
|---> imagination
<zmike>
oof
<alyssa>
imagination and asahi are the most distant genxmls
<DavidHeidelberg[m]>
zmike: yeah, I was thinking if would be possible prepare the runner, predownload stuff and just push it when previous steps successed
<alyssa>
which is hilarious because they're the two that share a bunch of structures identically
<DavidHeidelberg[m]>
zmike: since usually we wait for `debian-testing` it would make sense pre-download all the stuff and just assume mesa will build
<alyssa>
not sure that tree is any worse than
<alyssa>
Intel --> Intel + panfrost + asahi
<alyssa>
|
<alyssa>
|--> v3d
<alyssa>
|
<alyssa>
|--> imagination
<alyssa>
which looks like the natural result of me driving forward "unify genxml" without buy in from anyone else.
<zmike>
DavidHeidelberg[m]: could be a nice speedup