Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
aravind has joined #dri-devel
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
aravind has joined #dri-devel
Duke`` has joined #dri-devel
srslypascal is now known as Guest3436
srslypascal has joined #dri-devel
Guest3436 has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest3437
srslypascal has joined #dri-devel
Guest3437 has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
vsyrjala_ is now known as vsyrjala
kts has joined #dri-devel
fab has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
xroumegue has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
xroumegue has joined #dri-devel
srslypascal is now known as Guest3439
srslypascal has joined #dri-devel
Guest3439 has quit [Ping timeout: 480 seconds]
dviola has left #dri-devel [WeeChat 3.7]
dviola has joined #dri-devel
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
itoral has joined #dri-devel
rasterman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
tursulin has joined #dri-devel
jkrzyszt has joined #dri-devel
fab has joined #dri-devel
<pq>
kchibisov, I guess you could try changing rectKind from uniform to #define/const and compile the same source with different values. Dead code elimination should work. I do that in Weston.
lplc has joined #dri-devel
anshuma1 has joined #dri-devel
<kchibisov>
pq: that is what I've decided to do. Thx.
<javierm>
tzimmermann: I notice that the driver is exposing DRM_FORMAT_RGB565 but it converts to RGB666 internally
<tzimmermann>
yeah, it shouldn't
<tzimmermann>
i just scrolled over it. it's outdated in many ways
swalker__ has joined #dri-devel
<javierm>
tzimmermann: yeah, it's a similar to the trick we do in repaper and ssd130x XRGB8888, but I would argue that was a particular case to allow monochrome devices to be used with unmodified user-space
<tzimmermann>
cma -> shmem, no shadow-plane helpers, format conversion
<javierm>
tzimmermann: in this case I think should add DRM_FORMAT_RGB666 and wire that in libdrm, etc
<tzimmermann>
indeed. AFAIK our policy is to expose the native format to userspace
<javierm>
tzimmermann: yes. And even if those format conversions are needed (if RGB656 really needs to be exposed) then it should be in the drm format helpers, not the driver
swalker_ has joined #dri-devel
<tzimmermann>
exactly
<javierm>
tzimmermann: thanks for the confirmation. I wanted to double check that was the policy before answering in the patch
<tzimmermann>
BTW, is there a reason why all the mipi drivers use damage_merged?
swalker_ is now known as Guest3452
<javierm>
tzimmermann: I don't think so. I would say is just due copy&paste from other drivers
<tzimmermann>
ah, ok.
<javierm>
tzimmermann: and as we discussed the other day, even the mipi_dbi_pipe_update() helper uses it
<tzimmermann>
i was wondering if it's better to send one big package then two small ones with MIPI. but without HW, i cannot say
<tzimmermann>
yeah, it looks as if it's intentional, but maybe it's just copy-paste
<javierm>
tzimmermann: I'll ask that in my answer. Maybe the author or Noralf can shed some light
<tzimmermann>
ok, great.
<tzimmermann>
thanks a lot
<javierm>
I do have a st7735r here that's a MIPI DBI display so I should be able to experiment
<vsyrjala>
doing multiple writes per-frame while avoiding the raster scan is hard
swalker__ has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I dropped the damage_merged usage in the ssd130x driver and didn't have a noticeable difference
MajorBiscuit has joined #dri-devel
<tzimmermann>
it sounds like copy-paste then
guru_ has joined #dri-devel
<tzimmermann>
javierm, i have patches that improve mipi's usage of shadow planes
<tzimmermann>
but i need those new plane helpers first
<javierm>
tzimmermann: great. Happy to test if you post them
kts has quit [Quit: Leaving]
<danvet>
tzimmermann, lgtm
<tzimmermann>
thanks
<tzimmermann>
danvet, can i take this as an a-b ?
<danvet>
only bikeshed I have that two hooks called in the exact same place feels a bit silly, personally I'd just document that and leave the abi slighly unsymmetric
<danvet>
but meh
<tzimmermann>
you mean in prepare_fb?
<danvet>
maybe clarify that being_fb_access is called right after prepare_fb
<danvet>
yeah
<danvet>
but I don't feel strongly, I see the argument for symmetry too
<tzimmermann>
i like symmetric apis
<danvet>
I figured :-)
<danvet>
tzimmermann, I think also adding the same "pin in prepare, vmap in access" text to prepare_fb would be good too
<danvet>
and explaining in both places what the calling order is
pcercuei has joined #dri-devel
<tzimmermann>
that makes sense
<danvet>
I think then the docs are perfect and the entire thing is a-b:me
<danvet>
tzimmermann, wait a bit, something just crossed my mind
<tzimmermann>
yeah?
<danvet>
so the only userspace visible thing that tells you when the commit is over is the vblank/flip_complete event
<tzimmermann>
?
guru_ has quit [Remote host closed the connection]
<danvet>
tzimmermann, ok sry ack retracted
<danvet>
minimally I'm really confused what you're trying to achieve
<danvet>
since reading a bit of code I just realized you've put >end_fb_access into drm_atomic_helper_cleanup_planes()
<danvet>
and that seems pointless since we have the ->cleanup_fb hook there already
<danvet>
also your loop doesn't do the old vs new state switch
<tzimmermann>
that's the point
<danvet>
hm then I'm really confused
<danvet>
oh wait
<tzimmermann>
cleanup_fb receives the old or new state
<tzimmermann>
end_fb_access always receives the new state
<javierm>
danvet: the goal I believe is to avoid the need to have explicit CPU access to GEM BOs sync in all the drivers
<javierm>
danvet: since you asked what the series are trying to achieve
<tzimmermann>
i want to release the CPU-access reservation and vmap
<tzimmermann>
the ones that i took at the beginning of the atomic commit
<tzimmermann>
if i release that in cleanup_fb, the CPU access reservation would be in place for an unbounded time; seems problematic to me. vmap is the same, but not so critical
oneforall2 has joined #dri-devel
<danvet>
tzimmermann, ok I need to actually grab some coffee and read a ton of code
<tzimmermann>
haha
<tzimmermann>
the original problem is that drm_fb_gem_begin_cpu_access() runs in the plane's atomic_update. which is too late to handle errors correctly.
djbw has quit [Read error: Connection reset by peer]
<tzimmermann>
this call could be moved into prepare_fb, but the corresponding drm_gem_fb_end_cpu_access() cannot go into cleanup_fb (because of the possibly unbounded reservation time)
<tzimmermann>
hence, i added new callbacks
<danvet>
ok, I need to prep the spätzle dough otherwise not much lunch today, and I'll ponder what I think is the story here (it's over 10 years old, lol)
<tzimmermann>
spätzle
<emersion>
can recommend
<tzimmermann>
enjoy your lunch
<javierm>
tzimmermann: so you are adding a shadow-plane to mipi_dbi_pipe_update() ?
Company has joined #dri-devel
<danvet>
tzimmermann, so I think the crux here is that dma_buf_begin_cpu_access is a rather terrible api
<danvet>
because it has served 3 totally different use-cases
<tzimmermann>
javierm, i intent to
<javierm>
danvet: one more reason then for not having explict calls to them in drivers :)
<tzimmermann>
danvet, ok. you mean the 3 possible directions?
<danvet>
first is cpu access for mmap, which should never fail if dma_buf_mmap succeeded, except it can fail in out of memory situations
<tzimmermann>
from/to/bidi
<javierm>
tzimmermann: Ok, I won't mention shadow-planes to the author then since I'm mentioning that their callback is basically mipi_dbi_pipe_update()
<danvet>
tzimmermann, nah
<danvet>
2nd one was as prep step for kmap/kunmap, which is gone now
<danvet>
again that could fail, because it had to pin the memory because kmap/kunmap was _not_ allowed to fail
<danvet>
this one is gone now
<danvet>
3rd is for vmap
<danvet>
this one is _not_ allowed to fail, because vmap should have already done any pinning/moving
<danvet>
and if you read drivers, that's actually the case
<danvet>
so that's one problem here
<danvet>
the other one is that for the vmap case, there's 2 things left to do
<danvet>
a) cpu cache management. this should be done as closely around the actual access as possible. doing it at prepare/cleanup fb time isn't functionally wrong, but at least very unusual
<danvet>
b) waiting for the dma fence in the reservation for implicit sync. we've added that to the dma-buf.c code because too many drivers got that wrong
<danvet>
that's what breaks things since doing that in prepare_fb makes all atomic flip blocking
<danvet>
not good
<danvet>
so what I think might be a good idea here is to split up the dma_buf_begin_cpu_access api a bit
<danvet>
and have a separate one (optional) for vmap for the dynamic drivers
<danvet>
where the mmap one can fail
<danvet>
and the vmap one just checks that the buffer is in the right place (or that a vmap exists or something like that)
<danvet>
and cannot ever fail
<danvet>
I have vague memories that I discussed this with noralf since iirc he also asked why it's ok to put that failing call into the commit flow
<danvet>
it's because it's not allowed to fail
<danvet>
anyway I read all the begin_cpu_access implementations, and I think this still holds
<danvet>
the only fishy one is omap, but that doesn't do vmap
<danvet>
I think we could make a dma_buf_begin/end_vmap_access entirely in generic code
<tzimmermann>
danvet, is there a required ordering between vmap and begin_cpu_access?
<danvet>
by tracking vmaps and warning if there's none, and warning if the driver fails the ->begin_cpu_access for any reason in that case
sdutt_ has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, yeah vmap first, which is supposed to pin stuff and make sure ->begin_cpu_access can't fail
<tzimmermann>
ok, at least that's correct :)
<danvet>
but because it's shitty api you can also call it the other way round in the userspace mmap case
<danvet>
it's just that with the only real dynamic memory manager that moves stuff being ttm it works out :-)
apinheiro has joined #dri-devel
<tzimmermann>
danvet, i have to look through the code understand all this. could you somehow condense your reply into a review comment and reply to my patchset?
<danvet>
also strictly speaking for the atomic commit the dma_resv_wait is overkill, because we already fish out the fences in prepare_fb
<danvet>
but I think there's no real harm in keeping this
<danvet>
since the drivers which do need cpu access for buffer flip are not going to be the performance kings used together with latest vulkan games where the absolutely minor difference might actually matter
<danvet>
plus vk implicit sync is getting fixed anyway
<danvet>
tzimmermann, I mean one thing is for sure, you did discover a bit a messy situation :-)
<tzimmermann>
danvet, i'll what i can can make of this. i really have to look through the code to understand it.
<tzimmermann>
thanks for your feedback
<lygstate>
seems the ci slow now...
MajorBiscuit has quit [Ping timeout: 480 seconds]
aravind has quit [Read error: Connection reset by peer]
slattann has quit [Quit: Leaving.]
slattann has joined #dri-devel
MajorBiscuit has joined #dri-devel
<lygstate>
After stopping piplines that not fnished btween one day ago, the ci recovered
<lygstate>
seems recovered, I am not sure related
chipxxx has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
devilhorns has joined #dri-devel
chipxxx has joined #dri-devel
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
<tzimmermann>
javierm, i've been thinking about a different approach towards the fbdev emulation
fahien has joined #dri-devel
kts has joined #dri-devel
fahien has quit []
MajorBiscuit has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #dri-devel
MajorBiscuit has quit []
mvlad has joined #dri-devel
<javierm>
tzimmermann: do tell?
<tzimmermann>
the idea has always been to create a generic fbdev emulation that can handle all cases in all backends (ttm, shmem, dma, driver-specific) in an optimal way. but that does not really fly
MajorBiscuit has joined #dri-devel
<tzimmermann>
the idea is to clean up the fb helpers and the generic fbdev emulation. the helpers should be shuitable for all fbdev implementation (generic and in drivers).
<tzimmermann>
as various DRM memory managers have different properties, there could be an optimized fbdev emulation in each
<daniels>
lygstate: yes, the Windows runners are getting overwhelmed due to the volume of jobs coming from the ongoing GStreamer hackfest, which is something they'll try to fix on their side by making their pipelines quicker. when there is enormous contention, GStreamer jobs always get scheduled before Mesa jobs due to a terribly unfortunate accident of hash calculation
<tzimmermann>
the problem is always in fb_mmap, which differs between memory managers
<tzimmermann>
for each memory manager there would be an fbdev emulation that has mmap tailored towards the manager
<tzimmermann>
and drivers can still do their own thing, if needed
<tzimmermann>
including hw-accelerated blitting, if they really want to
<javierm>
tzimmermann: I see. Interesting
<tzimmermann>
the generic fbdev emulation would handle the most generic case (just as is does now). it's effectivly the fallback for drivers/memmgrs that don't bother
<javierm>
tzimmermann: and this will remove the constraint to use a shadow-buffer for deferred I/O ?
<tzimmermann>
i hope so
<javierm>
tzimmermann: got it
<tzimmermann>
at least, if the gem buffer does not move, there's usually no good excuse to use the deferred I/O
<tzimmermann>
but each memmgr is different in its own way. putting all that into the generic code is unreadable
<javierm>
tzimmermann: yes, agreed that would be more clean to split the really generic logic from the per manager logic
<javierm>
that will require quite a bit of refactoring of the drm fb helpers though
<tzimmermann>
working on it...
<javierm>
tzimmermann: I'm always surprised at your ability to work on many complex series in parallel :)
<tzimmermann>
easy: i post a simple patch and danvet's review tells me to refactor half of drm. so i move on to the next simple patch. rinse repeat. so i end up with many patchseries :D
* danvet
feels guilty
<javierm>
:D
anshuma11 has joined #dri-devel
anshuma11 has quit []
karolherbst has quit [Read error: Connection reset by peer]
anshuma11 has joined #dri-devel
kts has quit [Quit: Leaving]
karolherbst has joined #dri-devel
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Leaving]
dviola has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
dviola has joined #dri-devel
kts has joined #dri-devel
kts has quit []
devilhorns has quit []
devilhorns has joined #dri-devel
<MrCooper>
danvet: guilty for eating yummy Spätzle?
lygstate has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<danvet>
MrCooper, nah there's no guilt in that :-P
<danvet>
it's maaaayyyybee not entirely healthy though ...
<emersion>
looking good!
<daniels>
'maybe'
<danvet>
daniels, it's all developed to survive frigid alpine winters after all ...
<danvet>
not that those frigid winters have a good chance of surviving here :-/
<danvet>
21°C right now in late Oct wtf
<daniels>
I have to say looking at that whilst hungrily wondering what to go get for lunch has really derailed things
<daniels>
before: maybe Vietnamese salad with prawns? / after: CARBS AND CHEESE
MajorBiscuit has quit [Ping timeout: 480 seconds]
<danvet>
daniels, no cheese in this one
<danvet>
plenty of animal fat and proteins though, on that you're definitely covered
ahajda has joined #dri-devel
MajorBiscuit has joined #dri-devel
srslypascal has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
<jenatali>
lygstate: daniels discovered that there is an unintended prioritization for jobs based on project, with mesa unfortunately randomly towards the bottom, so yeah CI can sometimes end up starved for machines to pick up jobs :(
<mlankhorst>
mripard: can I pm you?
lemonzest has joined #dri-devel
jewins has joined #dri-devel
sdutt has joined #dri-devel
<swick>
making spätzle probably takes the same amount of energy they provide
<swick>
at least that's what I tell myself
heat has joined #dri-devel
fxkamd has joined #dri-devel
flibitijibibo has quit [Quit: Leaving]
srslypascal has quit [Ping timeout: 480 seconds]
chipxxx has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
zehortigoza has quit [Remote host closed the connection]
danilo has quit [Read error: No route to host]
dakr has joined #dri-devel
<emersion>
danvet: i'm trying out the atomic save/restore on VT switch, and i'm hitting a few issues
<emersion>
one of them is DPMS
<emersion>
it feels wrong to litter special cases all around
<emersion>
currently wondering if it would make sense to report DPMS as immutable for atomic clients
lplc has quit [Read error: Connection reset by peer]
dakr has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
dakr has joined #dri-devel
<zamundaaa[m]>
A client that sets the atomic cap doesn't necessarily need to use it. So you might cause breakage if you do that
Haaninjo has joined #dri-devel
<mripard>
mlankhorst: yep
mbrost has joined #dri-devel
<emersion>
zamundaaa[m]: the context is blind atomic save/restore of all KMS props
<LaserEyess>
is this something that userspace is supposed to provide?
<danvet>
emersion, what's the hold-up for dpms?
<danvet>
oh the fact we reject it in atomic commit?
<emersion>
danvet: yeah
<danvet>
emersion, so it should be the only special case ever, since we're not going to add funky legacy props, ever
<emersion>
hm… there's also content protection
<danvet>
emersion, but yeah maybe some clever trick like marking it immutable could help
<danvet>
emersion, uh :-(
<danvet>
how did we screw that one up?
<emersion>
kernel will reject setting content protection = enabled
<danvet>
the idea at least was that for anything new they should be save/restore compliant
<emersion>
it's a tri-state disabled/desired/enabled
<danvet>
oh crap
* danvet
failed
<emersion>
could downgrade to desired i suppose
dakr has quit [Read error: No route to host]
<danvet>
emersion, or maybe we should have a special atomic flag ATOMIC_RESTORE
<danvet>
which is a tad more lenient with these?
dakr has joined #dri-devel
<LaserEyess>
ok so the hint that I ignored on that page was "HDR Metadata Infoframe as per CTA 861.G spec. This is expected to match exactly with the spec." and I found that spec online which defined that
<LaserEyess>
interesting that this isn't enumerated somewhere in libdrm but ok
lyudess has quit []
Lyude has joined #dri-devel
<danvet>
emersion, one worry I have is that if we do add an ATOMIC_RESTORE flag, then how do we make sure we really get this right
<danvet>
like I have no idea how to type up a generic igt that could catch these issues
kem has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
carbonfiber has joined #dri-devel
co1umbarius has joined #dri-devel
kem has joined #dri-devel
<eric_engestrom>
PSA: Mesa 22.3 branchpoint is in 2 weeks, on 2022-11-02 (at around 18:00 UTC), so merge everything now and fix it later! (please don't 🙃)
<eric_engestrom>
Any issues that should block the release of 22.3.0 (or maybe even the branchpoint) should be added to https://gitlab.freedesktop.org/mesa/mesa/-/milestones/35 (and ping me if it should block the branchpoint)
slattann has quit []
AndrewR has quit [Quit: Leaving]
warpme___ has quit []
srslypascal has joined #dri-devel
srslypascal has quit []
kts has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
Guest3452 has quit [Remote host closed the connection]
anshuma11 has quit []
flibitijibibo has joined #dri-devel
frieder has quit [Remote host closed the connection]
sarnex_ has quit []
srslypascal has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
sarnex has quit [Remote host closed the connection]
sarnex has joined #dri-devel
apinheiro has joined #dri-devel
ngcortes has joined #dri-devel
jeeeun8413 has quit []
<karolherbst>
jekstrand: I am acurrently thinking about if we could move rusticl/OpenCL even closer to GL by actually using sampler vars for the dimension and everything and move the "cl_sampler" stuff out of the shader completely... but not really sure how that should all work out... maybe we need a new type thing for actual samplers, and sampler_views/texture_refs are what the current sampler thing is?
<karolherbst>
thoughts?
<karolherbst>
I totally don't like how all of that works atm
jeeeun8413 has joined #dri-devel
<jekstrand>
karolherbst: Not sure exactly what you're suggesting we change.
MajorBiscuit has joined #dri-devel
<karolherbst>
jekstrand: atm zink has the problem it can't infer the image's type from txl/txf, because we don't actually have a proper sampler object
<karolherbst>
*var
<karolherbst>
it needs this information e.g. for detecing TEXEL_BUFFER images
<karolherbst>
so texture would become the sampler uniform thing and sampler would be... something
<karolherbst>
not sure how much all of that makes sense though. Just talked about this with zmike yesterday and that it might actually make more sense to treat it more like GL overall
<karolherbst>
the sampler ref could potentially just point to the gallium samplers and don't even need anything in the vars or something
<zamundaaa[m]>
emersion: I'm aware of the context. I just don't think making properties immutable is a good solution
<karolherbst>
more or less adding vsampler1D/... etc things, so drivers won't have to do this weird parsing with using image vars instead of the sampler as they do with GL
<jenatali>
karolherbst: You can't though, because you can use one texture with multiple samplers in CL, where it's 1:1 in GL
<karolherbst>
sure
<karolherbst>
but the sampler just points to the bound gallium sampler and that's it
<karolherbst>
so that's infe
<karolherbst>
the "sampler" in the nir var list is closer to being an image anyway
<karolherbst>
or could be
<karolherbst>
maybe we should rename it to "texture"
<jenatali>
The "sampler" in the nir var list is both a texture (a gallium sampler view) *and* a sampler
<karolherbst>
sure
<karolherbst>
but that doesn't matter much
<zamundaaa[m]>
emersion: Tbh in general I'm not a big fan of "restore all properties to what they were before", because among other things it relies on the initial state being correct
<zamundaaa[m]>
emersion: I think a better approacg would be to have an API that populates an atomic req with some sane default state, and the compositor can then add its own state on top and commit that
devilhorns has quit [Ping timeout: 480 seconds]
<karolherbst>
so in gl drivers should just look up the var based on the texture and be done with it. Same for CL
<karolherbst>
and sampler is just an index into the sampler
<jenatali>
Yep
<jenatali>
In GL, texture == sampler always, but in CL they can be different
<karolherbst>
though not sure how much work that would require to fix like all the drivers/code/whatever
<karolherbst>
right
<karolherbst>
but I mean from a shader perspective it doesn't matter. Or are there any actual sampler properties inside gl shaders attached to the var?
<karolherbst>
the annoying part is just that for CL we actually encode the CL samplers as samplers as well
<karolherbst>
so this conflicts with GL
<jenatali>
Not sure what you're asking. A GL shader will always have a typed sampler, implying both a texture with its properties like type/dimension, and a sampler
<jenatali>
For CL, you'll have textures which encode that information, and you'll have "bare" samplers with no information at all
<karolherbst>
sure, but I mean, the sampler stuff is all in the runtime
<jenatali>
Yeah, the actual sampler properties are all external to the shader
<karolherbst>
for the sahder it doens't matter how the sampler looks like
<karolherbst>
so we could just ignore "samplers" exist at all even for GL and we would be fine
tzimmermann has quit [Quit: Leaving]
<jenatali>
For CL, yes, a sampler is a sampler
kxkamil has quit []
<jenatali>
Oh I see what you're saying. Our backend would still want a var to indicate that the sampler exists, and we need to differentiate between shadow and non-shadow samplers in the shader
MajorBiscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
jenatali: the shader info could tell that though
<jenatali>
We have a pass we run that splits GL-style samplers (texture+sampler) into separate vars
<karolherbst>
there is a sampler_used thing
<karolherbst>
yeah...
<cwabbott>
karolherbst: fwiw, vulkan already has separate samplers and textures
<karolherbst>
so the idea is to make that split more explicit
<jenatali>
True, we'd probably just need a second bitfield then of which samplers are shadow samplers
<karolherbst>
and maybe rename the glsl_type sampler stuff to texture instead
<cwabbott>
so NIR does have the concept already
<karolherbst>
because that's what they more or less actually are
<jenatali>
Yeah, nir already has a "texture" concept
<karolherbst>
cwabbott: sure, but how do you decode split texture/samplers in the var list then?
<jekstrand>
karolherbst: Can we still do separate sampler/texture or do you want to combine them?
<cwabbott>
vulkan actually has both - there are combined image/samplers, just samplers, and just images
<karolherbst>
nah, they should be always split, just for GL the ref just points to the same numeric index
<jekstrand>
Combining seems problematic
<karolherbst>
ahh
apinheiro has quit [Ping timeout: 480 seconds]
<karolherbst>
alternative we could get rid of all the "texture" speak and just use image vars for everything
<jenatali>
Right, so nir encodes combined as a typed sampler (e.g. sampler2D), a split texture as a texture type (e.g. texture2D), and a split sampler as a "bare" sampler (sampler or shadowSampler)
<karolherbst>
and tex ops reference images
<karolherbst>
but that's probably an even bigger change overall
<jenatali>
That'll get a NAK from me... we treat textures and images very differently
<jekstrand>
Well, tex vs. image is going to be bound differently by the back-end driver
<jenatali>
Images can't be sampled from, only textures can
<karolherbst>
okay, so that needs to be known by the driver.. I see
<karolherbst>
so could we bind a typed sampler and a bare one at the same slot?
<karolherbst>
like have a sampler2D thing at binding 0 and a bare sampler at 0
<karolherbst>
and a tex op using texture 1 and sampler 0 would still not confuse those two?
<karolherbst>
because that's more or less what I probably will need long term
<karolherbst>
or huh....
<karolherbst>
we do have GLSL_TYPE_TEXTURE mhhh
<karolherbst>
guess that's not used in GL?
<karolherbst>
we even have all the vtexture1D thingies... why didn't I know that
pcercuei has quit [Remote host closed the connection]
<karolherbst>
jenatali: is there currently a way to get those texture types for CL as well?
pcercuei has joined #dri-devel
<karolherbst>
so txl/txf actually refence them via the texture ref?
<jenatali>
karolherbst: You can move the pass I wrote for DXIL into core nir and run it on CL
<karolherbst>
yeah... I think that's probably the least amount of work for now
<jenatali>
Oh I should clarify:
<jenatali>
Our backend always wants texture + sampler, we don't have a combined concept
<karolherbst>
right...
<karolherbst>
that's fine
<jenatali>
For GL, I split the GL combined samplers into texture + sampler
<karolherbst>
yeah, for CL that's a more sane approach
<jenatali>
For CL, we get images + samplers, so I have a pass that converts read-only images into textures
<karolherbst>
the thing I am missing for zink is simple those texture things
<jenatali>
So then we still end up with texture + sampler for sampled images
<karolherbst>
yeah.. was thinking about doing the same, but wanted to think about a proper long term plan as well
<jekstrand>
combined texture+sampler need to be considered a bit of GL legacy
<karolherbst>
but if we could get drivers to support split texture + sampler things in their backend, maybe we can drop the combined stuff at some point
<karolherbst>
maybe not
<jenatali>
IIRC it's some NV hardware that prefers combined
<karolherbst>
but requiring dealing with the split stuff for CL seems acceptable
<karolherbst>
jenatali: yeah.. fermi and older I think
<jenatali>
I don't think it's even that legacy considering that it was carried forward into Vulkan
<jenatali>
karolherbst: The pass I linked you is overly complicated for what you need because I also need to inject types into it (float, int, uint)
<karolherbst>
anyway.. at least now I have a plan for fixing buffer images for zink (and cleaning up all the hacks we have now)
<jekstrand>
karolherbst: Combined is dropped, mostly.
jeeeun8413 has quit []
* karolherbst
dealt too much with nouveau
<jekstrand>
karolherbst: It's just that if you only care about GL, you can assume the texture and sampler deref will be the same.
<karolherbst>
yeaeh.....
<jekstrand>
karolherbst: nouveau needs to be fixed. NAK will have this fixed.
<jenatali>
And there will only be a single var (if you care about vars)
<karolherbst>
of course it will :)
<karolherbst>
the other issue I need to get fixed is split vars for private/local me and that sounds like a super painful fix :( I already dislike it
piggz has joined #dri-devel
<jekstrand>
Yes, fixing private/local will be a pain
<jekstrand>
IMO, that's zink/12 pain
<karolherbst>
yep
<karolherbst>
maybe I just yolo it for now
<piggz>
hi, just dropping in to say thx for reverting the dmabuf requirements ... Mesa 22.2.1 is working with the Sailfish Lipstick compositor once again
mriesch_ has quit []
mriesch has joined #dri-devel
jeeeun8413 has joined #dri-devel
kxkamil has joined #dri-devel
apinheiro has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<piggz>
i think it broke circa 22.0
kts has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<pinchartl>
is the i915 driver known to totally hang the GPU when loading shadertoy.com in a web browser, or should I try the latest kernel and mesa before reporting a bug ?
<pinchartl>
(webgl is evil)
<karolherbst>
that's just shadertoy
<HdkR>
Hopefully the hang-check recovery is working well enough that after a few minutes it loads :D
ngcortes has quit [Ping timeout: 480 seconds]
<Sachiel>
loaded fine here
<pinchartl>
I had to hard-reboot after a few minutes
<pinchartl>
Oct 19 21:08:45 [kernel] [ 99.299949] i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
<pinchartl>
Oct 19 21:08:45 [kernel] [ 99.299968] i915 0000:00:02.0: [drm] chrome[5156] context reset due to GPU hang
<pinchartl>
Oct 19 21:08:45 [kernel] [ 99.328703] i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85d7fffb, in chrome [5156]
<pinchartl>
on the positive side, it does detect a hang
<pinchartl>
on the negative side, the recovery isn't quite working :-)
<pinchartl>
lots of "Asynchronous wait on fence" and "Fence expiration time out" after that
<pinchartl>
so maybe the GPU recovers fine, but the system doesn't
mvlad has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
luc4 has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
linkmauve has left #dri-devel [#dri-devel]
mbrost has quit [Ping timeout: 480 seconds]
carbonfiber has quit [Quit: Connection closed for inactivity]
MajorBiscuit has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.6]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
linkmauve has joined #dri-devel
elongbug has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
dakr has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
mbrost has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
luc4 has quit []
dakr has joined #dri-devel
piggz has quit [Ping timeout: 480 seconds]
<jenatali>
jekstrand: When you get a chance I'd appreciate a skim of !16200 - mainly looking for whether you think it's on the right track or if you think it needs to go back to the drawing board
JohnnyonFlame has joined #dri-devel
<jekstrand>
jenatali: oof
<jekstrand>
jenatali: Not this week. :) Maybe next.
<jenatali>
jekstrand: Fair enough, I'm not in too much of a hurry. Plenty of other stuff to do :P
fxkamd has quit []
rasterman has quit [Quit: Gettin' stinky!]
ybogdano has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
off^ has joined #dri-devel
apinheiro has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
vliaskov has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<karolherbst>
ohh, I am sure I already asked, but what's the proper way of hooking up a meson/ninja project in VSCode so it actually resolves all the include paths and stuff? the compile_commands.json file doesn't seem to be enough
<jenatali>
That's always worked for me
<karolherbst>
weird...
<karolherbst>
which extension(s) do you use for that? just the official C/C++ and meson one or something else?
<jenatali>
Just the official C/C++ one
<jenatali>
Had it work for MSVC on Windows, GCC in Linux, and Clang for Android cross-compiling
<karolherbst>
mhh
<jenatali>
You do have to explicitly point it at the compile_commands.json FWIW
<karolherbst>
yeah, I did that
<karolherbst>
ahh now it works after I nuked a bunch of extensions
<karolherbst>
maybe the embedded kernel dev one messed with the c/c++ one