ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<imirkin_> there _might_ be some very pedantic difference between a non-msaa GL texture and a msaa x1 GL texture
<airlied> there is some pedantic difference, but I don't think we care for it :-P
mclasen has quit []
<airlied> like I suppose you could in theory move the sample point for a single sample MSAA
mclasen has joined #dri-devel
<imirkin_> the mesa/main code has to worry about it
<imirkin_> but afaik gallium driver backends don't
mclasen has quit []
mclasen has joined #dri-devel
<jenatali> Yeah I'm pretty sure I've seen both 0 and 1 come in
<jenatali> Right now we're just doing MAX2(nr_samples, 1)
<jenatali> Just wanted to make sure there wasn't some interesting difference between 0 or 1
<airlied> util_res_sample_count
iive has quit []
<jenatali> Hah, ok cool
mclasen has quit []
mclasen has joined #dri-devel
<imirkin_> jenatali: quick note ... with ARB_framebuffer_no_attachments, you need to grab sample count from the pipe_framebuffer_state.
<imirkin_> but if there _are_ attachments, iirc this field is not reliable, and you have to get it from the surface
<imirkin_> and/or resource
<jenatali> imirkin_: Ack. We've got a "forced sample count" feature in D3D for doing UAV-only rendering at an MSAA rate, which I think is what that extension is the equivalent of
<jenatali> But it seems that's 4.2 and requires image loads/stores, which we don't have yet in our GL driver
<imirkin_> jenatali: well, if you enable one ext it doesn't mean you have to enable them all
<imirkin_> that said, yeah, that feature without images/buffers/atomics isn't _incredibly_ useful
<imirkin_> you can use it to do sample counts :)
<imirkin_> (and there are some piglit tests which do just that)
<jenatali> Huh... interesting. I don't think we have that extension lit up? Let me look...
<airlied> util_framebuffer_get_num_samples
<jenatali> Yeah we don't set that pipe cap yet. Probably easy enough to do so
<imirkin_> jenatali: probably true of a lot of stuff. like i said, without images/etc, that's not incredibly useful
<jenatali> Yup
<imirkin_> but also probably very easy to implement
<imirkin_> so if you're paid by the extension... ;)
<jenatali> Yup :)
<jenatali> I am not :P
<imirkin_> sad for this, but good for implementing images. 1 ext. a lot of work.
<jenatali> Yeah. I'll get there eventually...
<jenatali> Our compiler has full support for it thanks to CL/WebGPU/Vk
<jenatali> Just need to hook it into the driver
<imirkin_> yes ... like a frontend guy i knew would say after completing the layout, "the website is done, just need to hook up the backend"
<jenatali> Yeah, if I had to reverse engineer how images worked in hardware I'm sure I'd still have a ways to go, but D3D and GL aren't too far apart on that front
<imirkin_> yeah, just have to make sure you get barriers right
<imirkin_> otherwise things are subtly broken
<jenatali> Ah, yes. Does GL require all draws/dispatches that access the same images/SSBOs to be serialized? Or are they allowed to overlap with API-level barriers to explicitly serialize them?
<jenatali> D3D11 is the former so I'd guess GL is too, but I never know
camus1 has joined #dri-devel
rasterman- has joined #dri-devel
<anholt_> jenatali: there are api-level barriers
camus has quit [Ping timeout: 480 seconds]
<jenatali> anholt_: Oh great, thanks
<anholt_> comes in through the memory_barrier() hook,
<jenatali> Oh I should've known this. That function has caused so much pain for me already even though we haven't implemented it, because the Windows SDK defines a MemoryBarrier macro on ARM...
rasterman has quit [Ping timeout: 480 seconds]
raster-- has joined #dri-devel
<dcbaker> If I move src/mesa in src/gallium/frontends (after the delete classic lands, or course). Does it also make sense to move egl and glx into src/gallium/targets, even though they're not strictly gallium targets?
<imirkin_> jenatali: i thought you said d3d12 was for linux running in hyperv ... when does it ever get built on _WIN32?
rasterman- has quit [Ping timeout: 480 seconds]
<jenatali> imirkin_: We use the d3d12 backend on Windows too
<imirkin_> is the gist that arm graphics drivers don't ship GL?
<jenatali> Basically
<imirkin_> makes sense
<imirkin_> (not really, since they ship it for android, but ... wtvr)
<jenatali> They ship GLES for Android
<imirkin_> ah, but the desktop applicaitons you hope to run with windows-on-arm know about GL, not GLES?
<jenatali> Yeah, Windows doesn't have any realistic GLES app catalog at all. And the ones that do, ship ANGLE
<imirkin_> does D3D12 have things for tilers?
<jenatali> Not a ton TBH, mainly just render passes
<jenatali> No subpasses though
<airlied> dcbaker: why don't we just mv src/gallium/* src/
<dcbaker> because vulkan?
<dcbaker> sorry, that sounded snarky
<airlied> ah yeah
<Sachiel> you? snarky? Never...
<imirkin_> dcbaker: it does seem like a rethink of the directories may be in order
* airlied isn't a big fan of moving src/mesa, because it's horrible for git history archaeologu
<airlied> git --follow only works for single files
<dcbaker> but we do a lot of bending over backwards in meson to make that work
<airlied> also macros.h :-P
<dcbaker> mostly gone
<dcbaker> I deleted most of it already
<dcbaker> :)
<airlied> oh I suppose if it means we can make meson interactions easier
<airlied> just seems like a bit of a pointless move without a lot of justification
<dcbaker> most of macros.h was just duplicating stuff in src/util anyway
<dcbaker> except for the parts that really were only used by core mesa
<imirkin_> might be the other way around :p
<imirkin_> things in src/util copied the stuff from macros.h they needed but couldn't import directly...
<jenatali> As a newcomer to the project, the directory structure honestly was a bit of a hindrance to understanding the actual architecture of how things worked
<imirkin_> jenatali: as a non-newcomer too. it's changed a lot in recent times.
<dcbaker> imirkin_: I think there was a lot of both
<airlied> src/freedreno/vulkan/tu_private.h:#include "main/macros.h"
<jenatali> I'm on-board with moving either src/gallium -> src, or src/mesa -> src/gallium, I think either of those would help a lot
<airlied> worst of both worlds :-P
<airlied> jenatali: I think the number of state tracker layers is more of a real hinderance
<airlied> how glx/dri works will forever remain a mystery
<jenatali> airlied: Agreed. mesa/main + mesa/state_tracker + frontends/dri is hugely complex
<airlied> we'd end up with src/gallium/frontends/mesa/state_tracker won't we :-P
<jenatali> When trying to hook up EGL to gallium the extra dri indirection was super confusing
<zmike> dri is the worst
<dcbaker> airlied: yeah, though presumably we could move that all around too, since the entire reason that existed was classic
<airlied> like shouldn't src/glsl move as well?
<airlied> and that's a lot more painful
<dcbaker> src/compiler/glsl?
<airlied> yeah that
<dcbaker> jekstrand: and I talked about that a while back
<dcbaker> the biggest annoyance is that one of our two list implementations is part of glsl
<dcbaker> airlied: all that turnip is getting is util/rounding.h (from main/macros.h)
<dcbaker> lol
<dcbaker> There's also the problem that spirv uses glsl_type information
<airlied> should probably start a mailing list discussion on what a cleaner directory structyre might looks like
<airlied> src/gallium/frontends/mesa doesn't feel like the place you'd go looking for an opengl implementation
<airlied> like really src/mesa is pretty much src/opengl from when we couldn't use the name
* airlied isn't sure we can use the name now, but it's probably less of a problem
<dcbaker> why not? that's where you'd go looking for a d3d9 implementation and an OpenCL implementation?
<airlied> dcbaker: the src/gallium bit makes not sense to a newcomer
<jenatali> Agreed. Would be nice to collapse the gallium structure into top-level
<jenatali> Though... Vulkan
<dcbaker> maybe, but having to explain "oh no, you can't use auxiliary in vulkan, that's only for gallium drivers"
<dcbaker> when gallium drivers are just src/drivers
<jenatali> src/drivers is where I'd expect to see a Vulkan driver if that was there
<jenatali> src/gallium, src/vulkan, src/common, src/include as the only top-level directories?
<dcbaker> and glx, egl, util
<dcbaker> mapi
<dcbaker> glapi
<jenatali> Those could be under gallium though, couldn't they?
<dcbaker> util glx mapi imgui compiler freedreno loader android_stub egl mesa intel vulkan hgl gallium broadcom panfrost amd microsoft drm-shim virtio getopt gbm gtest etnaviv asahi nouveau tool
<airlied> we could do src/opengl I suppose, and mv mesa,glx,glapi,mapi in there
<airlied> though I'm not sure I'd want to deal with possible legalities from history
<dcbaker> I think glx, mapi, loader, egl, mesa, and hgl could move to gallium?
<airlied> but they aren't really gallium related
<dcbaker> Yeah, would want in writing from Khronos that was okay, personally
<dcbaker> I mean, what else uses mapi?
xantoz has quit [Ping timeout: 480 seconds]
<imirkin_> so ... without commenting on specifics ... mesa has accumulated literally decades of cruft. if we're going to be moving stuff around, we should do one mass move.
<imirkin_> which places everything in more-currently-logical locations
<airlied> but they don't interact with gallium at all
<dcbaker> it's the MesaAPI, that maye should just get deleted in favor of glvnd...
<jenatali> dcbaker: glvnd isn't on Windows, but if you want libGLESv2.dll + OpenGL32.dll you need mapi
<jenatali> Specifically libglapi.dll
<dcbaker> ah, okay, you're supporting that
<dcbaker> VMWare doesn't (didn't) support that on Windows, and I wasn't aware that Microsoft was
mclasen has quit []
camus has joined #dri-devel
khfeng has joined #dri-devel
mclasen has joined #dri-devel
<jenatali> We haven't shipped it yet, but having an alternative to ANGLE for GLES on Windows (e.g. support for GLESv1) is probably going to be useful so I'd like to keep it working
<dcbaker> imirkin_: agreed
* zmike would like to have opengl on windows too
camus1 has quit [Ping timeout: 480 seconds]
<dcbaker> gl -> zink -> d3d12?
<jenatali> Maybe we'll get there one day :P
<jenatali> Zink does work on Windows though I think?
<imirkin_> dcbaker: my main point is (in case i didn't make it clear) _one_ move, not two or ten moves of a little bit at a time. these moves are highly disrupting, so minimizing their quantity would be strongly preferable.
<zmike> zink does indeed work on windows
<zmike> as I find out every time I break it
<dcbaker> imirkin_: yup, we're on the same page
<jenatali> I agree with airlied, a mailing list discussion sounds like a good idea
<dcbaker> It's time for me to go cook dinner. IF no one else beats me to it I'll send out mail later
Haaninjo has quit [Quit: Ex-Chat]
<zmike> jenatali: if you want an alternative to ANGLE I know a guy...
<jenatali> zmike: Something besides Mesa?
<zmike> I was going to say mesa
<jenatali> :P
<zmike> why wouldn't everyone want to ship mesa?!
<jenatali> There's some ANGLE extensions that we'd (I'd) need to implement before it'd be a drop-in replacement. And our d3d12 backend needs some more extensions too I think
<zmike> I was planning on doing more GL extensions for zink once I got other stuff in a better place
<zmike> probably some opportunity for collaboration there
<jenatali> Feel free to ping me if you think there's intersection
<zmike> still waiting on my last ping to finishing pinging :P
<jenatali> I'm really hoping that sometime in the next couple of months I'll have time to play catchup
<jenatali> Yeah ok fair
Walter_ has joined #dri-devel
raster-- has quit []
<zmike> but also (spoilers for future blog posts) I'm off the rest of the year after this week so don't expect anything soon
Walter_ has quit [Remote host closed the connection]
<zmike> perhaps we'll be playing ketchup at the same time
<jenatali> And I'm gonna disappear for a while starting in Feb sometime (probably) so I don't know when I'll have time. But eventually (TM)
<zmike> Microsoft Time
co1umbarius has joined #dri-devel
<airlied> zmike: zink video decoding is a great holiday project :-P
tursulin has quit [Read error: Connection reset by peer]
columbarius has quit [Ping timeout: 480 seconds]
<zmike> no no no no no no no
<jenatali> airlied: Dunno if you saw the mailing list mail yet (also might've gone to junk cause @microsoft.com) but I think we're getting serious about d3d12 video decoding
<zmike> airlied: will wait on you to hook up vaapi to vk video for me :P
ngcortes has quit [Remote host closed the connection]
<airlied> jenatali: oh I haven't seen it, don't seem to have anything in my spam
<jenatali> Hm
<airlied> jenatali: vaapi on d3d12?
<jenatali> Yeah
<airlied> ah that shouldn't be too insane
<jenatali> Yeah, apparently he's already got a frame decoding, but the init path is super hacky and the present path is broken
* airlied is having problem with vulkan h264 because the driver is expected to do a lot more
ybogdano has quit [Ping timeout: 480 seconds]
<airlied> jenatali: do you know if the d3d12 h264 interface is picture or slice based?
<jenatali> airlied: If the email doesn't show up by tomorrow, ping me, I think you and our dev should get in touch at least
<jenatali> Uh... I think picture based?
<jenatali> I think it's the same as Vulkan's interface
<airlied> yeah probably lke vulkan then
<airlied> just means at least for intel the slice decoding has to be done in sw inside the driver
<airlied> which is a pita
* airlied may end up taking a break from intel hw and hacking on vaapi/zink
<HdkR> Oh. I saw a game yesterday that refused to run without vaapi. I should double check what it actually wants
<jenatali> Anyway, I'm off for the night
<zmike> later!
xantoz has joined #dri-devel
camus1 has joined #dri-devel
gpuman has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
<zmike> mareko: any other comments on compute pbo MR? would really like to get that in asap
pnowack_ has joined #dri-devel
pnowack has quit [Ping timeout: 480 seconds]
pnowack_ has quit []
cphealy has quit [Remote host closed the connection]
mclasen has quit []
mclasen has joined #dri-devel
<jekstrand> dcbaker, airlied: I wouldn't worry about calling a folder opengl
mattrope has quit [Read error: Connection reset by peer]
mclasen has quit []
mclasen has joined #dri-devel
imirkin_ has quit [Quit: Leaving]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
ppascher has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
<airlied> woot, got anv to decode some p/b frames properly
* airlied will have to go back and work out much of the hacking was unnecessary :-P
<imirkin> i hate it when that happens ... you add like 100 hacks, and the 101st one makes it work, and then you realize that was the only one you needed in the first place
<imirkin> (but not before "bisecting" the rest of the hacks)
<HdkR> I feel called out
<imirkin> i don't think it's a unique experience
jcline has quit [Quit: Bye.]
jcline has joined #dri-devel
<HdkR> I was very disappointed in myself yesterday when I had to partially disable an optimization because of a bug that I couldn't find the issue for :(
agd5f_ has quit []
agd5f has joined #dri-devel
alarumbe has quit [Ping timeout: 480 seconds]
flacks has quit [Ping timeout: 480 seconds]
alarumbe has joined #dri-devel
vivijim has quit [Read error: Connection reset by peer]
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
fxkamd has joined #dri-devel
flacks has joined #dri-devel
Duke`` has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
Akari has joined #dri-devel
Akari has quit []
Akari has joined #dri-devel
Akari` has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
Akari has quit [Read error: Connection reset by peer]
Akari` has quit [Ping timeout: 480 seconds]
fxkamd has quit []
Akari has joined #dri-devel
Akari has quit []
sdutt has quit [Remote host closed the connection]
mclasen has quit []
danvet has joined #dri-devel
mclasen has joined #dri-devel
Akari has joined #dri-devel
ppascher has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
<Lynne> airlied: hey, I've been writing a hwaccel for vulkan decoding in ffmpeg using your radv code, keep it up
alanc has quit [Remote host closed the connection]
<Lynne> I'm wondering if there's any way of contacting folks who develop the extension?
alanc has joined #dri-devel
<Lynne> because the extension has some silly spec issues, and some which really make it difficult to use
mclasen has quit []
mclasen has joined #dri-devel
Company has quit [Quit: Leaving]
pnowack has joined #dri-devel
shoragan has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
apteryx_ has joined #dri-devel
hansg has joined #dri-devel
apteryx has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
tursulin has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
<danvet> mripard, airlied I'm making a bit noises about the virtio poll semantics that landed in -rc1, expect some reverts and then we need to sort this out
<danvet> randomly redefining how drm_poll works just doesn't look like smart uapi design, and if they want something else it's pretty trivial to just create another fd type with _exaclty_ what they want
<danvet> we have a pile of them already anyway
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<airlied> Lynne: I'm in contact with them via Khronos
<airlied> Lynne: I've filed a few issues with various bits already, and there are a fair few fixes queued up iternally
<airlied> Lynne: excellent new on the ffmpeg work, I'll hopefully have mostly functional intel anv h264 decode this week
<airlied> Lynne: feel free to pm/email me with spec concerns and I can go over them, probably not until tmrw
mclasen has quit []
mclasen has joined #dri-devel
adavy has quit [Read error: Connection reset by peer]
zf` has joined #dri-devel
zf has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
pcercuei has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
rasterman has joined #dri-devel
lemonzest has joined #dri-devel
<emersion> i don't think compositors need fixing, i think drivers need fixing
<emersion> either implement modifiers (especially if you're dealing with cross-driver imports)
<emersion> either force modifier-less allocations to be LINEAR in the driver allocating buffers
lemonzest has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
<pinchartl> emersion: that would require mass-patching the vast majority of the DRM/KMS drivers to explicitly support the linear modifier
<pinchartl> do we document on the kernel side what the invalid modifier means ?
<emersion> no modifier means that it can either have an arbitrary tiled layout, or can be linear
<emersion> depending on the driver
<emersion> forcing linear isn't an option, as it breaks intel/amd
<pinchartl> * The "none" format modifier doesn't actually mean that the modifier is
<pinchartl> * implicit, instead it means that the layout is linear.
<pinchartl> in drm_fourcc.h
<emersion> "none" is something else interely
<emersion> entirely*
<emersion> please read the doc from daniels
<emersion> "none" is an alias for "linear", and is different from "invalid"
<pinchartl> indeed
<pinchartl> but that doc is recent, it's nice to specify how things should look like, but it dosn't solve backward-compatibility issues
<emersion> that doc is just that: documentation for existing stuff
<pinchartl> * Linear Layout
<pinchartl> *
<pinchartl> * Just plain linear layout. Note that this is different from no specifying any
<pinchartl> * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2 ioctl),
<pinchartl> * which tells the driver to also take driver-internal information into account
<pinchartl> * and so might actually result in a tiled framebuffer.
<emersion> your drivers have had broken cross-device imports forever, so should be fixed
<pinchartl> the drivers comply with the API documentation
<pinchartl> I don't want to duplicate https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-etom@igel.co.jp/#22634255 in every driver that only supports linear
<pinchartl> can we do so in the DRM core ?
<dj-death> has anybody done a cross build that requires a tool in mesa build for the host?
<emersion> fwiw, new drivers are _required_ to implement modifiers
<emersion> even if they only have LINEAR
<pinchartl> if a driver doesn't advertise support for modifiers (which is allowed, as drm_universal_plane_init() accepts a NULL argument for the modifiers, the core should accept linear
<emersion> maybe cc danvet on this
<emersion> if a driver doesn't support modifiers, user-space won't try to use them
<emersion> if a driver doesn't support modifiers, this can't be retro-fitted in drm core, since this breaks drivers which use a tiled layout for modifier-less buffers
<pinchartl> are there drivers that don't support modifiers and only support tiled layouts ?
<pinchartl> s/drivers/devices/
<emersion> there are drivers which don't support modifiers, and support both linear and tiled
<pinchartl> those should be fixed :-)
<emersion> and you can't make drm core set an IN_FORMATS prop on these, that would make user-space always unconditonally use linear
<emersion> ideally everyone supports modifiers yes
<emersion> but the chance of getting e.g. radeon support that are pretty slim
<pinchartl> the majority of devices only support linear. I don't want to burden those with a copy of https://patchwork.kernel.org/project/linux-renesas-soc/patch/20190509054518.10781-1-etom@igel.co.jp/#22634255 each, that's something that can easily be done in the core
<emersion> that's something to discuss with the rest of the DRM core folks i guess
<emersion> at any rate, don't expect user-space to ahndle this
<pinchartl> maybe we could define a DRM_PLANE_SUPPORTS_LINEAR_ONLY = (void *)1 (name subject to bikeshedding), to be passed as the modifiers argument to drm_universal_plane_init(), and handle the rest in the core ?
<emersion> yeah maybe there could be a way to make that patch a one-liner
<pinchartl> a zero-liner would be better, but a one-liner could be ok. we could then mass-patch drivers in one go and be done with it
<emersion> danvet: ^
<daniels> emersion: I do need to finish that
<emersion> that would be very nice :)
<danvet> emersion, sounds like a reasonable plan
<danvet> rolling out modifiers consistently would be nice indeed
<danvet> maybe also DRM_PLANE_IS_VERY_SHITTY_AND_HAS_NO_MODIFIER_SUPPORT (void*)2 might be another one
<danvet> and then just require modifiers, always
nchery has joined #dri-devel
jani_ has quit []
jani has joined #dri-devel
lemonzest has joined #dri-devel
flacks has quit [Quit: Quitter]
camus1 has joined #dri-devel
flacks has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
<pq> pinchartl, I think Weston used to confuse linear mod with no/invalid mod in the past, but that should be fixed now to never make assumptions that such conversion is ok.
<pinchartl> all the mistakes we would avoid if we could rewrite the past...
<pinchartl> and all the new mistakes we would make :-)
<pq> pinchartl, I'm just saying that Weston will not assuming that no-modifier could be compatible with linear mod.
<pq> so that "fix" won't happen
<pq> it needs to be solved in kernel instead
<daniels> the only time we ever pass INVALID to KMS is if a) the KMS driver has no modifier support and it's a dumb buffer, or b) either the KMS or GPU driver have no modifier support and it's a GBM buffer allocated with USE_SCANOUT
<daniels> we never try to pass MOD_INVALID client buffers to KMS
<pq> today, yes
<pq> ISTR Leandro removed some confusion between no-mod and linear.
<daniels> correct
<emersion> pinchartl: so yeah, as daniel said maybe we can mark the few drivers which use a tiled layout with implicit modifiers with a flag
<emersion> then in DRM core add support for modifiers by default
<daniels> ++
<pinchartl> could it cause any issue with userspace that doesn't use modifiers today, or will it be backward compatible ?
camus has joined #dri-devel
<emersion> adding modifier support should never regress modifier-unaware user-space
<pinchartl> ok
<emersion> they'll just ignore the IN_FORMATS prop
<pinchartl> so we have to pick between NULL == linear only (most ARM SoCs), magic value == auto-select without explicit modifier support (e.g. radeon), and NULL == auto-select without explicit modifier support, magic value == linear only
<pinchartl> another question
<pinchartl> let's assume a driver that has no modifier support and only supports linear today
<pinchartl> it means that a userspace that doesn't set the modifiers flag will get linear
<pinchartl> if that driver then gets extended to support tiling
<pinchartl> with explicit modifier support
<pinchartl> it would need to map !DRM_MODE_FB_MODIFIERS to linear, it won't be allowed to auto-select, or it will break userspace, right ?
<emersion> we really really don't want to add more cases of drivers auto-selecting a tiled layout for modifier-less buffers
<emersion> the drivers that do it only do it because at the time modifiers didn't exist
pnowack has quit [Quit: pnowack]
<pinchartl> so auto-selection is considered legacy ?
<emersion> yeah
<pinchartl> good :-)
camus1 has quit [Ping timeout: 480 seconds]
<pinchartl> then it should be fine
<daniels> yeah, new non-modifier magic is auto-NAK at this point
<daniels> I mean it's only been what, 6 years since we added it?
<pinchartl> could someone summarize this discussion to guide Tomohito Esaki ?
<daniels> pinchartl: would be really nice if that was CCed to dri-devel@ btw
<daniels> pinchartl: can you please either bounce me the mail or CC me on a reply (daniel@fooishbar.org rather than Collabora) and I can reply?
<pq> It feels a little bit like someone accidentally CC'd dri-devel with that per-plane KMS property IGT patch set and summoned the evil pq. :-P
<pq> I let the proposal to use input events to warmp up displays have it, too. O_:-)
pnowack has joined #dri-devel
<daniels> pq: looks like we're both being bad cop today!
<pinchartl> daniels: I didn't realize the kernel patch wasn't CC'ed to dri-devel
<pinchartl> done
<daniels> thanks!
OftenTimeConsuming has quit [Remote host closed the connection]
ickle_ has joined #dri-devel
ickle has quit [Ping timeout: 480 seconds]
X-Scale` has joined #dri-devel
X-Scale has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
<daniels> pinchartl, emersion: also wrt 'cross-device', I feel like the elephant in the room is that R-Car uses a proprietary out-of-tree GPU driver :P
<daniels> dj-death: cross-build> yes, Mesa requires a host wayland-scanner
<emersion> daniels: oh, that's certainly an important thing to note, wasn't aware of this
<daniels> dj-death: the way to do that is to ship a pkg-config file which has a variable pointing to the path of the binary, then look it up in the build with dependency('foo', native: true)
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
<pinchartl> daniels: yes, it's mali as far as I know
gawin has joined #dri-devel
<daniels> pinchartl: *PVR
<daniels> unless you know something I don't :P
<daniels> huh, TIL RZ/G2L ... they can use Panfrost for that anyway :)
<pinchartl> daniels: I thought some SoCs used a mali GPU. maybe Gen2 ? or maybe I got it wrong :-)
<dj-death> daniels: yeah, my problem is that my host binary needs to be compiled from the same mesa repo we're building for the target
<daniels> pinchartl: I've only seen PVR in gen2 and 3
<daniels> dj-death: wayland-scanner has the same property, and for that we just tell people that they need to build twice for cross-builds - once for the host to get the tool, and then for the target when they have the tool - that's the only reliable way to do it, and pretty standard for this sort of thing
<pinchartl> daniels: maybe I'm missing something then
<pinchartl> or got it wrong
<pinchartl> could have been wishful thinking :-)
<daniels> pinchartl: damn, I always thought you were infallible
<pinchartl> sorry to disappoint you
<pinchartl> (actually, not even sorry :-))
Company has joined #dri-devel
<pinchartl> I've been reading about wishful thinking, heuristics, algorithms and inhibition mechanisms in the human brain recently, it's a very interesting research topic on human intelligence
<gawin> airlied: do you perhaps know if I still need to use forked valgrind for tracking all memory? (ioctls and stuff)
mclasen has quit []
<dj-death> daniels: hmm I see
mclasen has joined #dri-devel
<Lynne> airlied: I can't say I care much about intel atm, I've still got hacks I need to merge into ffmpeg's vulkan code to support exporting to drm, which I'm not too happy about
<Lynne> I submitted my feedback as of now to the Vulkan-Docs repo on github
<Lynne> really, the biggest issue is needing the entire bitstream in a single buffer
<Lynne> but it would be nice if some preprocessing or <something> could be done during the time a client receives slices
<Lynne> with multiple buffers, you could at least upload them in the meanwhile and make sure the data's right where the GPU can quickly access it
YuGiOhJCJ has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
vivijim has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
hansg has quit [Quit: Leaving]
dottedmag has left #dri-devel [#dri-devel]
Namarrgon has joined #dri-devel
macromorgan has quit [Quit: Leaving]
OftenTimeConsuming has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
sdutt has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
khfeng has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
<dj-death> robclark: question on u_trace, how do you ensure u_trace_fini() doesn't race the process_chunk() ?
<danylo> dj-death: process_chunk() processes chunks which are already taken from u_trace in u_trace_flush()
<danylo> u_trace owns chunks until they are flushed and are owned by utctx
<dj-death> danylo: ah thanks, indeed u_trace_flush() moves them to the context
<dj-death> danylo: I guess in Anv we need to do the u_trace_flush() *before* actual submission because we're threaded and the app thread could race use before we have time to call u_trace_flush()
<danylo> dj-death: I don't follow.
fxkamd has joined #dri-devel
<danylo> you mean it could destroy command buffer in-between?
gawin has quit [Ping timeout: 480 seconds]
<dj-death> danylo: exactly
<danylo> ugh
<danylo> dj-death: It doesn't really matter when you would call u_trace_flush if you could give it something to synchronize upon in u_trace_read_ts callback
<dj-death> yeah, I'll pass a syncobj to wait on there
Haaninjo has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
mdnavare_ has joined #dri-devel
dolphin` has joined #dri-devel
dolphin is now known as Guest6199
dolphin` is now known as dolphin
rsripada has joined #dri-devel
sdutt_ has joined #dri-devel
gawin has joined #dri-devel
aswar002_ has joined #dri-devel
nchery is now known as Guest6200
nchery has joined #dri-devel
Ryback_[WORK] has joined #dri-devel
unerlige1 has joined #dri-devel
shankaru has joined #dri-devel
shankaru1 has quit [Ping timeout: 480 seconds]
mclasen has quit []
sdutt has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
mclasen has joined #dri-devel
rsripada_ has quit [Ping timeout: 480 seconds]
unerlige has quit [Ping timeout: 480 seconds]
Guest6199 has quit [Ping timeout: 480 seconds]
Guest6200 has quit [Ping timeout: 480 seconds]
Ryback_ has quit [Ping timeout: 480 seconds]
mdnavare has quit [Ping timeout: 480 seconds]
aswar002 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
iive has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
cphealy has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
Namarrgon has joined #dri-devel
Duke`` has joined #dri-devel
nchery has joined #dri-devel
JohnnyonFlame has joined #dri-devel
karolherbst_ has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
karolherbst has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
neobrain has quit [Remote host closed the connection]
neobrain has joined #dri-devel
kallisti6 has joined #dri-devel
kallisti5 has quit [Read error: Connection reset by peer]
jekstrand has quit [Remote host closed the connection]
narmstrong_ has quit [Read error: Connection reset by peer]
jekstrand has joined #dri-devel
zmike has quit [Read error: Connection reset by peer]
MTCoster__ has quit [Read error: Connection reset by peer]
cwabbott has quit [Read error: Connection reset by peer]
hwentlan_ has quit [Read error: Connection reset by peer]
angular_mike_____ has quit [Remote host closed the connection]
narmstrong_ has joined #dri-devel
SanchayanMaity has quit [Read error: Connection reset by peer]
rg3igalia has quit [Read error: Connection reset by peer]
markyacoub has quit [Remote host closed the connection]
arnd_ has quit [Remote host closed the connection]
robher has quit [Remote host closed the connection]
robclark has quit [Remote host closed the connection]
cengiz_io has quit [Read error: Connection reset by peer]
jessica_24 has quit [Remote host closed the connection]
tfiga has quit [Remote host closed the connection]
ogabbay has quit [Remote host closed the connection]
jstultz has quit [Read error: Connection reset by peer]
rburton has quit [Read error: Connection reset by peer]
tchar has quit [Remote host closed the connection]
austriancoder_ has quit [Read error: Connection reset by peer]
steev has quit [Read error: Connection reset by peer]
<jenatali> Huh, looks like our video dev's mail got stuck in a moderator queue since he hadn't joined mesa-dev yet. Anyone know who the moderator is for that list?
cengiz_io has joined #dri-devel
markyacoub has joined #dri-devel
<Kayden> believe that's anholt & a few more, maybe Brian and either Dave or Daniel?
<Kayden> anholt I know for sure
<jenatali> anholt_: ^^
angular_mike_____ has joined #dri-devel
camus1 has joined #dri-devel
jonmason_ has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
rg3igalia has joined #dri-devel
jstultz has joined #dri-devel
hwentlan_ has joined #dri-devel
robher has joined #dri-devel
<daniels> there's nothing in the mesa-dev mod queue :\
<daniels> (someone else might've nuked it, not sure)
<jenatali> Huh. He's joined the list now, guess I'll tell him to try again
cwabbott has joined #dri-devel
SanchayanMaity has joined #dri-devel
robclark has joined #dri-devel
steev has joined #dri-devel
arnd_ has joined #dri-devel
austriancoder_ has joined #dri-devel
tchar has joined #dri-devel
<MrCooper> jenatali: I approved it as part of my daily listadmin run this morning
MTCoster__ has joined #dri-devel
Moiman has quit [Remote host closed the connection]
<jenatali> MrCooper: Ah, ok. Guess he sent a second one for no reason then. Sorry for the spam :(
ogabbay has joined #dri-devel
jessica_24 has joined #dri-devel
rburton has joined #dri-devel
<MrCooper> can I discard the duplicate?
<jenatali> Yep
<MrCooper> done
<MrCooper> did you not get the first one back from the list?
<jenatali> I did not get the first one back from the list, but I was CC'd so I dunno if that makes the list skip me or something
<MrCooper> it does if you enabled that mis-feature in your subscription preferences
<MrCooper> might have been enabled by default when you subscribed
<jenatali> Huh, just checked, I have it off. Weird
gawin has joined #dri-devel
<jekstrand> jenatali: Wow, that one got thrown in my spam AND got a special "Be careful! This might not actually be from microsoft" flag. :D
zmike has joined #dri-devel
<jenatali> Yeah, unfortunately I think the way the mailing list is configured that's going to happen anytime any one of us sends anything to the list
<jekstrand> It's not a mailing list thing. It's gmail being paranoid.
<jekstrand> And, frankly, most people don't get e-mailed directly by microsoft so it seems reasonable. (-:
<jenatali> It is the mailing list thing - the fact that it modifies the headers but still claims to be from the original email address
<jekstrand> Oh, that'll do it to
<jenatali> Or something like that. Someone here explained it to me but I don't know the inner workings of email very well :P
<jekstrand> Fair. Neither do i.
<jenatali> Maybe I'll see if I can convince Sil to join in here, probably more likely to actually get people to hear it if email clients don't like mails from us that go through the mailing list...
tfiga has joined #dri-devel
<jekstrand> Yeah
<jekstrand> And being on IRC is a better way to get questions answered than e-mail anyway
zf` is now known as zf
<jenatali> Yeah, I just wish it was more user-friendly... People who didn't grow up using IRC, or people who haven't touched it in decades have some trouble with it compared to other things
<HdkR> Sounds like mailing list based workflows ;)
<milek7> yeah, dkim/dmarc won't be happy if content was modified
<milek7> and even if it wasn't it depends on what headers were signed by dkim, simple/relaxed mode, etc.
<milek7> what the hell outlook did to the links...
<emersion> jenatali: curious, what are the hurdles you encounter when using IRC?
<jekstrand> It requires more effort than clicking "sign on with Google" and typing.
<emersion> (trying to improve this, so feedback is welcome)
<jenatali> emersion: I'm used to chat clients (Discord, Slack, Teams, Google Chat) that have persistence
<emersion> well, you can just join with the web UI
<jenatali> I really didn't like not being able to sign in and see a scrollback of what happened while I wasn't here
<jenatali> Eventually I found Matrix and that works well enough, but it's a huge pain to set up, especially on OFTC where auth doesn't work correctly and you can't directly start a chat with NickServ for some reason
<jekstrand> Also, while the web UI works, all the interesting channels require you to also be signed on with NickServ
<emersion> ah, yes, you need to use an extra bouncer service for this (there are a few, e.g. irccloud and -- shmaless plug -- chat.sr.ht)
<emersion> right, NickServ is a mess. we have a shiny new IRC extension to fix that, but it'll probably never make it to OFTC
<jenatali> But yeah, the hurdles of setting up a bouncer, registering with NickServ, etc, to be able to use it like any other modern chat service make it a pain to onboard new people to
<emersion> i wouldn't recommend to set up your new bouncer if you're new to IRC -- just use one of the existing ones!
<jenatali> I don't mean "setting up" as in hosting one yourself, I just mean configuring
<emersion> configuring isn't too hard, or is it?
* jekstrand uses IRSSI + screen on a rhaspbery pi
<emersion> 1. create account
<emersion> 2. click on irc:// URL for #dri-devel
<emersion> 3. done
<jenatali> On its own, nah
<jenatali> And maybe setting up a dedicated IRC bouncer instead of trying to go through Matrix would be simpler. Dunno, didn't try (mainly because I didn't know what I was looking for and stumbled on Matrix as a solution)
<jekstrand> Matrix is fine once you get it set up.
<jekstrand> The problem is that people can't tell if no one can hear them due to lack of voice
<jekstrand> And auth is a pain
<jekstrand> I played with matrix briefly
<emersion> matrix doesn't really work sadly
<jenatali> Yep, both of those are problems
<jenatali> It works great once it's set up :)
<jenatali> Worked better on FreeNode though, the bouncer integration with OFTC isn't nearly as robust
<jekstrand> There's a part of me that wouldn't mind if we switched to matrix as long as we could get all the fd.o projects to switch so we didn't all have to use both.
<jekstrand> But I'm not going to be the one to send that e-mail
<jekstrand> Also, I kind-of like IRSSI as a chat client
<jenatali> Yeah I don't want to rock the boat. I want to get more people on my team involved, but IRC is definitely a big hurdle for that, for folks who either don't use chat clients at all, or only really use Teams for work stuff. Coupled with the fact that we can't really reach out to mailing lists due to the @microsoft.com problem jekstrand mentioned makes it a bit of a pain
<milek7> probably doesn't help that oftc requires use of tls client cert to auth properly and doesn't support sasl password
<milek7> (nickserv privmsg method is so brittle it should be forgotten altogether)
gawin has quit [Remote host closed the connection]
<jekstrand> Yeah, if OFTC supported SASL, that'd probably solve a lot of the matrix integration problems.
<emersion> yeah OFTC not supporting the new stuff definitely doesn't help
<emersion> last time i asked there was no plan to improve this
<jenatali> Out of curiosity, when you say "new stuff," how new are we talking? Is IRC really evolving that much?
<jekstrand> Creating and registering an OFTC account is still an extra step, but not the worst of the problems.
<emersion> jenatali: yes, mostly via IRCv3. see e.g. https://ircv3.net/2021/11/17/spec-round-up
<jenatali> :O
<jekstrand> That's a surprisingly nice-looking website for IRC. (-:
<emersion> SASL, which isn't supported by OFTC and allows proper login, is an IRCv3 extension
<milek7> client cert for login works fine though
<HdkR> SASL would be nice. Losing auth on netsplit sucks
gouchi has joined #dri-devel
nchery is now known as Guest6218
nchery has joined #dri-devel
Guest6218 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mdnavare_ has quit []
mdnavare has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<airlied> Lynne: the vulkan ppl are pretty set on for h264 decode at least, picture level decoding, and not having the app parse slices
X-Scale has joined #dri-devel
[X-Scale] has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
X-Scale has quit [Ping timeout: 480 seconds]
<airlied> Lynne: kinda would rather parse slices and you've made a good argument for it
<airlied> Lynne: I've pointed the khronos list at your issue to make sure it's on the radar
illwieckz has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.3]
LexSfX has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
luckyxxl has joined #dri-devel
gawin has joined #dri-devel
mclasen has quit [Remote host closed the connection]
mclasen has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
aswar002_ has quit []
aswar002 has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<jekstrand> What is interpolateAtCentroid() supposed to do in a shader that's running per-sample?
<Sachiel> go sub-sample so you have a center for them
<jekstrand> Looks from the nir_lower_io code like it smashes to sample as well
<jekstrand> Cool
<jekstrand> Makes my life easier
oneforall2 has quit [Quit: Leaving]
illwieckz has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> anholt_: I hear you have deqp builds I should be interested in?
oneforall2 has joined #dri-devel
camus1 has joined #dri-devel
aravind has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
<cmarcelo> jekstrand: jenatali: can you give your general take on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13863 I'm adding test here to help my work related to SPIR-V CFG in our parser.
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand> cmarcelo: 500 LOC for an assembler isn't bad
<jekstrand> cmarcelo: Certainly better than I expected
<jekstrand> Not sure how I feel about making all the tint things unit tests, though. We could just pull them into piglit
ppascher has joined #dri-devel
<bnieuwenhuizen> VK-GL-CTS?
<jekstrand> or that
<alyssa> isn't this what amber was for?
<jekstrand> yes
luckyxxl has quit []
<alyssa> cmarcelo: IMHO +20kloc of imported tests doesn't make sense.
<alyssa> If VK-GL-CTS doesn't want them, then piglit. Still runs in CI
<jenatali> cmarcelo: Did you see we added a Windows pipeline which runs those same shaders all the way to DXIL?
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
<cmarcelo> jenatali: havent seen
<cmarcelo> is the issue here more importing Tint tests? would be OK with the non Tint ones?
<jekstrand> I guess the question for me is: What does importing them as unit tests gain us?
<cmarcelo> jekstrand: piglit could be a good choice actually
<cmarcelo> jekstrand: importing the tint ones was just easy after I wanted to have CFG tests, and wrote a parser to make my life easier (without imposing extra stuff to our build/etc).
<cmarcelo> alyssa: fair enough. I'll see how it looks to import them to piglit.
<cmarcelo> (and also check how Windows pipeline is running them)
<alyssa> cmarcelo: I suppose there's a judgement call here, I mean,
<alyssa> if rob wanted to check in 20kloc of Adreno assembly as unit tests, I wouldn't complain
<alyssa> public vs private I guess?
<cmarcelo> nuking the Tint tests from that MR, how do we feel about: (a) having tests for parser at all? (b) and if so, using the assembler?
<cmarcelo> jekstrand: 500K but to be fair incomplete, so there's that..
ybogdano has joined #dri-devel
narmstrong_ has quit []
narmstrong has joined #dri-devel
<jenatali> cmarcelo: Is SPIRV-Tools such a bad dependency to impose? Isn't it already part of the Clover pipeline? It's part of our Windows build since we need it for the CL compiler test suites
<cmarcelo> is not necessarily picking at SPIRV-Tools itself, just a generally avoiding adding extra dependencies there.
<cmarcelo> jenatali: I see windows basically pulls the files and use a spirv2dxil command line tool from mesa (?), is that it? I guess we could do something similar with the spirv2nir.
<jekstrand> depending on SPIRV-Tools for the unit tests doesn't seem terrible
<cmarcelo> jenatali: can I easily run such pipelines locally? (like call a script or something)
<jekstrand> We're going to depend on it for Vulkan soon enough with ray-tracing
<jenatali> cmarcelo: If you've got a Windows install, then yeah they're just powershell scripts
<jenatali> And yeah that's basically all it is, run the SPIRV-Tools assembler and feed that into spirv2dxil which just runs spirv_to_nir and then nir_to_dxil
<jenatali> Well, with other passes in-between, but yeah
<cmarcelo> jenatali: so I could make a similar script in .gitlab-ci somewhere, and run that locally too.
<jenatali> Note that starting from scratch to build the whole Windows pipeline will require compiling LLVM which takes... forever :(
<jenatali> cmarcelo: Yup, sure
<cmarcelo> for me particularly the spirv_to_nir step is sufficient.
<jenatali> Yeah
LexSfX has quit []
<jenatali> Sounds like this should probably be a separate pipeline if it wants the proper assembler from SPIRV-Tools rather than adding that as a dependency for SPIR-V unit tests
<jenatali> At least that's my opinion as a somewhat outsider who tries to avoid rocking the boat by changing core things too much :P
<cmarcelo> Yeah. I'm summarizing the points raised here and closing that MR.
sdutt_ has quit []
sdutt has joined #dri-devel
unerlige1 has quit [Remote host closed the connection]
unerlige1 has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
<ajax> is there tc documentation?
<jenatali> ajax: In the header is some pretty good docs
<zmike> yea header's pretty okay, otherwise it's just the usual
gawin has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
LexSfX has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
jkrzyszt has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
adjtm has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
ybogdano has joined #dri-devel
The_Company has joined #dri-devel
pnowack has quit [Quit: pnowack]
Company has quit [Ping timeout: 480 seconds]