ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
zzyiwei has quit [Quit: Lost terminal]
feaneron has joined #dri-devel
kasper93 has quit []
kasper93 has joined #dri-devel
vjaquez has quit [Ping timeout: 480 seconds]
clever has quit [Ping timeout: 480 seconds]
clever has joined #dri-devel
karolherbst has joined #dri-devel
<karolherbst>
zmike: okay.. got intensity working, but what's the issue with 2d buffer there?
<zmike>
you can't swizzle a bufferview in vulkan
<zmike>
I've been considering whether I could reuse the 2dimport path for it
vliaskov_ has joined #dri-devel
<karolherbst>
zmike: okay sure, but we don't use buffer views for 2D from buffer in the first place
<zmike>
I said buffer views
<zmike>
not 2d buffer
<karolherbst>
mhh okay, but it's not working for 2d buffer either
<zmike>
could be the same issue
<zmike>
I assume it's related to the swizzling
<karolherbst>
yeah, and it's all RRRR
<karolherbst>
I don't think it's the swizzle
<karolherbst>
it's just returning 0 for some values
<karolherbst>
maybe something with strides or something silly
<karolherbst>
anyway.. I'm not concerned about 1dbuffer, because rusticl calls is_format_supported with PIPE_BUFFER for those, and zink hopefully just doesn't return intensity there
vliaskov__ has quit [Ping timeout: 480 seconds]
<karolherbst>
well.. zink doesn't prevent that...
<karolherbst>
I should fix that
vliaskov_ has quit [Ping timeout: 480 seconds]
<zmike>
is it actually applying the swizzle?
<karolherbst>
I would expect that if that would be the issue, the test would fail in a different way
<karolherbst>
but the vulkan side image view did have a RRRR swizzle
<karolherbst>
or at least zink did create such one
<zmike>
that's something
<karolherbst>
mhhh lvp crashes
<zmike>
can lavapipe actually do the 2d buffer import normally?
<karolherbst>
also crashes with non intensity formats...
<zmike>
I'd be surprised if lavapipe could do the dmabuf reinterpret
<karolherbst>
let me make the CTS be a bit more verbose... it's always hard to figure out what actually goes wrong
<karolherbst>
mhh yeah okay.. all reads are just 0
<karolherbst>
I'll take a look tomorrow, it seems like this failure is another regressions or unrelated or something
<karolherbst>
yeah....
<karolherbst>
it's also broken for non intensity, but at least that's a regression
The_Company has joined #dri-devel
<karolherbst>
ah no.. it was a local patch of mine, but.. mhhh weird...
<karolherbst>
mhhhh
<karolherbst>
ah no.. I just uhm... I'm tired :')
Company has quit [Ping timeout: 480 seconds]
<karolherbst>
okay.. it works on 25.1 branchpoint, it doens't on main.. good
<zmike>
probably my surface refactor broke it somehow
<zmike>
I guess that means there's a place that should be setting res->valid and isn't
<zmike>
you could probably find it pretty trivially by seeing where the resource is written before that call
<karolherbst>
mhh with that worked around.. CL_INTENSITY 2d_from_buffer does work for read_image (which is a texture read), it works for write_image (guess the shader simply ignores the other components), but for read_write images it doesn't, because the read is an actual image_read operation and as I said.. no swizzles for those
<karolherbst>
right...
<karolherbst>
I'll figure out a proper patch tomorrow
<karolherbst>
just need to figure out what to do about those image views...
<karolherbst>
might be easier if zink just sets the swizzle 🙃
<zmike>
feels like cheating if I do all the work for you
<karolherbst>
yeah but other drivers also handle it internally :P
<zmike>
I guess
<karolherbst>
or do you want to have a swizzle added to pipe_image_view?
<zmike>
I don't really want that for just this one thing, no
<karolherbst>
okay :)
<zmike>
smh being bullied now
<karolherbst>
anyway, I'll send patches tomorrow or so
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
sguddati has joined #dri-devel
jkrzyszt has joined #dri-devel
glennk has joined #dri-devel
vimproved has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
vimproved has joined #dri-devel
Calandracas has joined #dri-devel
vliaskov_ has joined #dri-devel
lynxeye has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
vliaskov__ has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
kxkamil has quit []
RAOF has quit [Remote host closed the connection]
kxkamil has joined #dri-devel
<phasta>
I've got a bug fix for a new bug in the current -rc. Applying to drm-misc-fixes fails, though. What should I do about that?
RAOF has joined #dri-devel
<phasta>
Ah wait, my bad. Outdated branch
feaneron has joined #dri-devel
<phasta>
Still. Why is it that a bug-fix that is neither in drm-next nor drm-misc-next should be applied to drm-misc-next? I thought drm-misc-next is for new features and won't be sent to Linus after feature-freeze
guludo has joined #dri-devel
Core5957 has joined #dri-devel
<tzimmermann>
sima, when pushing the reverts, dom told me: "dim: ERROR: a71e35aecc07 ("Revert "drm/etnaviv: Use dma_buf from GEM object instance""): Mandatory Maintainer Acked-by missing., aborting". is that intentional? looks like a bug to me. your r-b should be enough IMHO. i've now pushed with 'dim -f', but still...
<sima>
mripard, just matching on email and trying to canonicalize with .mailmap?
<mripard>
yeah, that's a good idea
<mripard>
possibly leveraging python's email module that we already use to parse the address properly
kts has joined #dri-devel
nerdopolis has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.6.3]
<lynxeye>
sima: I try to give acks for the etnaviv things I think should be merged through drm-misc, but TBH haven't been quite on top of it due to too much other stuff. On the other hand people seem to assume that etnaviv goes through drm-misc and don't really look into MAINTAINERS. I actually pondered moving etnaviv to drm-misc just to adjust reality to the assumption, but haven't quite made the switch yet.
fab has quit [Ping timeout: 480 seconds]
<sima>
lynxeye, yeah was more wondering whether we should put it into both
<sima>
main dev still through your tree, but kinda the more random things and subsystem stuff can officially go through drm-misc too
<sima>
which I think is where defacto we are right now, roughly
<sima>
so as long as mripard's dim check can cope with multiple git repo lines, we should be fine
<sima>
lynxeye, that way you can make any decision about moving main etnaviv dev at your own pace, and we still document a bit more accurately what's actually going on
<lynxeye>
sima: Yea, if the scripts can handle that, that would be fine. I have no intention to introduce interdependencies between drm-misc and the etnaviv tree for the subsystem wide changes that happen to touch etnaviv. Those should always go through drm-misc. Conflicts due to this mode of operation are few and easy to handle on my side.
YuGiOhJCJ has quit []
fab_ has joined #dri-devel
fab_ is now known as Guest22177
Guest22177 has quit []
fab__ has joined #dri-devel
fab__ is now known as Guest22179
Danct12 has quit [Quit: WeeChat 4.6.3]
Guest22179 has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
feaneron has joined #dri-devel
haaninjo has joined #dri-devel
kts has quit [Remote host closed the connection]
<sima>
mripard, can dim cope with that?
<mripard>
sima: I'm not sure how we could solve this, really. Because we already have multiple git repos between drm-misc, drm and linus' iirc.
<mripard>
the problem with etnaviv is that we're merging patches into a repo that isn't documented in MAINTAINERS
<karolherbst>
zmike: okay.. I learned new things: 1. for storage images the component remap needs to be an identity remap, so that just rules out intensity for storage images completely. 2. the zink_batch_reference_resource_rw calls inside zink_copy_buffer are causing the img2d_from_buf fails, and overriding them to assume src/dst are images is fixing the sisue
lemonzest has joined #dri-devel
<emersion>
hmmm, dim push-branch drm-misc-next fails with:
<emersion>
fatal: bad object refs/remotes/drm-intel/topic/core-for-CI
<emersion>
i've tried rm'ing the remote and running dim setup but that doesn't fix it
<emersion>
any ideas what's up?
kts has joined #dri-devel
jkrzyszt has quit [Quit: Konversation terminated!]
<karolherbst>
in regards to 1. in _theory_ I think writing to intensity images could be allowed, I just don't know if it's valid to assume that a vec4 write to the R image does what we want?
<zmike>
no clue
<karolherbst>
but... can't really express that in gallium anyway
<karolherbst>
I know it worked fine on anv for writing to them, but reading from intensity storage images was showing really odd behavior
<karolherbst>
I doubt anybody ever needs it, so whatever really
<zmike>
my MR should fix your not-intensity issue
<karolherbst>
quick testing tells me it does
<karolherbst>
let me push it through my testing to confirm