<xeyler>
assuming no change is necessary and the change is agreeable, i'd like to see the patch considered before the deadline for 6.17
warpme has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
warpme has joined #dri-devel
<Shibe>
Hi, I was wondering it if is correct that when importing dmabufs with implicit modifiers you should not use VK_EXT_image_drm_format_modifier at all. In my case trying to import an image with the modifier set to FORMAT_MOD_INVALID seems to not work, but removing ImageDrmFormatModifierExplicitCreateInfo from the pnext chain in createImage works
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
yshui has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
yshui has joined #dri-devel
swfrd has joined #dri-devel
swfrd_ has quit [Remote host closed the connection]
warpme has quit [Ping timeout: 480 seconds]
yshui has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
warpme has joined #dri-devel
Duke`` has joined #dri-devel
warpme is now known as Guest21485
blaztinn has quit [Ping timeout: 480 seconds]
swfrd has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
egbert is now known as Guest21486
egbert has joined #dri-devel
swfrd has joined #dri-devel
yshui has joined #dri-devel
Guest21486 has quit [Ping timeout: 480 seconds]
yshui has quit [Ping timeout: 480 seconds]
Guest21485 has quit [Ping timeout: 480 seconds]
yshui has joined #dri-devel
swfrd has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
yshui has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
warpme is now known as Guest21489
Sid127 has joined #dri-devel
caitcatdev has joined #dri-devel
Guest21489 has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
warpme has joined #dri-devel
fab has quit [Quit: fab]
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 4.6.3]
blaztinn_ has joined #dri-devel
blaztinn has quit [Read error: Connection reset by peer]
yshui has joined #dri-devel
warpme has quit [Read error: No route to host]
warpme has joined #dri-devel
lemonzest has joined #dri-devel
ybogdano is now known as Guest21493
ybogdano has joined #dri-devel
ybogdano is now known as Guest21494
ybogdano has joined #dri-devel
tzimmermann has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
Guest21493 has quit [Ping timeout: 480 seconds]
Guest21494 has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
yshui has joined #dri-devel
apinheiro has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
cascardo_ has joined #dri-devel
cascardo has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
jsa1 has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
lsntvt has joined #dri-devel
yshui has joined #dri-devel
frieder has joined #dri-devel
jfalempe has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
jfalempe has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
yshui has joined #dri-devel
jkrzyszt_ has joined #dri-devel
yshui has quit [Read error: Connection reset by peer]
warpme is now known as Guest21495
lynxeye has joined #dri-devel
jfalempe has joined #dri-devel
f_ has quit [Read error: Connection reset by peer]
f_ has joined #dri-devel
yshui has joined #dri-devel
Guest21495 has quit []
bnilawar has joined #dri-devel
warpme has joined #dri-devel
rasterman has joined #dri-devel
yshui has quit [Read error: Connection reset by peer]
warpme is now known as Guest21496
bnilawar has quit [Ping timeout: 480 seconds]
yshui has joined #dri-devel
MrCooper has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
yshui has quit [Read error: Connection reset by peer]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
frankbinns has joined #dri-devel
Guest21496 has quit []
warpme has joined #dri-devel
yshui has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
yshui has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
bnilawar has joined #dri-devel
bnilawar has quit []
bnilawar has joined #dri-devel
feaneron has joined #dri-devel
yshui has joined #dri-devel
warpme is now known as Guest21499
bnilawar has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
yshui has joined #dri-devel
sguddati has joined #dri-devel
yshui has quit [Read error: Connection reset by peer]
bnilawar has joined #dri-devel
yshui has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
bnilawar has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
yshui has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
yshui has quit [Ping timeout: 480 seconds]
Guest21499 has quit []
warpme has joined #dri-devel
<karolherbst>
zmike: any good reason why zink_fence_server_signal is flushing the context?
Kasreyn has joined #dri-devel
<karolherbst>
though doesn't really matter as long as it's not stalling
guludo has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frankbinns has quit [Remote host closed the connection]
bnilawar has joined #dri-devel
yshui has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
yshui has quit [Ping timeout: 480 seconds]
yshui has joined #dri-devel
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
yshui has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
bnilawar has quit [Read error: Connection reset by peer]
frankbinns has joined #dri-devel
bnilawar has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
<zmike>
required by spec
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
bnilawar has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
davispuh has joined #dri-devel
<karolherbst>
I see... how can I check the status of a binary semaphore? I see how I can do that for a timeline one, but binary?
<glehmann>
you can't
<glehmann>
binary semaphores weren't meant for device->host sync, only device->device
<glehmann>
you had to use fences for device->host
<karolherbst>
I don't want to sync
<karolherbst>
I just want to know if they are signalled
<glehmann>
well you can't know that either
warpme has quit []
<karolherbst>
mhhh.. maybe I can kinda fake it enough
kondalef1[m] has left #dri-devel [#dri-devel]
yshui has joined #dri-devel
jsa1 has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
yshui has joined #dri-devel
yshui_ has joined #dri-devel
yshui has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
frankbinns has joined #dri-devel
yshui_ has quit [Ping timeout: 480 seconds]
<demarchi>
agd5f: I think you left a broken drm-tip when resolving conflict for d2f9002426a7 ("drm/amd/display: Fix annotations for dc state functions")
<agd5f>
demarchi, I didn't touch anything to drm-tip
<demarchi>
this commit went to drm-next, right?
<agd5f>
yeah
<demarchi>
so when drm-next got merged in drm-tip it had the wrong commit resolution... not by you then?
<javierm>
tzimmermann: if that doesn't work, you might need to compile your own dtbo that use compatible = "solomon,ssd1309" for the DT nodes
frankbinns has quit [Ping timeout: 480 seconds]
phasta has quit [Quit: WeeChat 4.6.2]
Guest21510 has quit [Read error: Connection reset by peer]
<tzimmermann>
javierm, thanks
<tzimmermann>
that will certainly help
<javierm>
tzimmermann: cool, let me know if you find any issues
yshui_ has joined #dri-devel
<tzimmermann>
javierm, i have not received it. it's only 2 colors. i wonder if i'll be able to recognize anything on the screen
yshui has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: it's 2 colors but because the pixels have fixed colors (e.g: a few lines in yellow and the rest in blue)
<javierm>
from a SW point of view is just R1 (1 color per pixel)
<javierm>
the ssd1306 I've one is blue-on-black for all the pixels and the other one is white-on-black
<tzimmermann>
right, that's what i meant. 1 bit -> 2 state. IIRC the shop had various colors to choose from
<javierm>
tzimmermann: right
jsa1 has joined #dri-devel
<javierm>
tzimmermann: that's one thing that I pondered, how to improve the XRGB -> R1 thresholding algorithm
<javierm>
right now, the threshold is 128 for all the pixels, but it could be smarter
yshui_ has quit [Ping timeout: 480 seconds]
<robclark>
karolherbst: any opinions about whether we should support (swallow) -qcom-accelerate-16-bit and things like that? Apps tend to decide to use blob cl flags when they encounter a qc device
<karolherbst>
robclark: if we can just ignore them then we can just ignore them
<karolherbst>
ohh I thought I already landed that one intel one...
sguddati has quit [Remote host closed the connection]
<tzimmermann>
javierm, i'll have some time available later this year for experimenting. i currently intent to spend it on dithering the results from the xrgb8888_to_ conversion helpers
<karolherbst>
but yeah.. we _can_ support them it's just a bit messy if there aren't published extensions for it and it's just "check our docs for details" or even worse, no docs
<javierm>
tzimmermann: ah, that would be great
<tzimmermann>
thanks for the link
<tzimmermann>
my biggest concern is performance overhead
<robclark>
karolherbst: I think just enabling/disabling fp16 lowering.. so far I've been hacking apps to not pass it so I guess we can remove it
<karolherbst>
huh...
<karolherbst>
what's the reason for it?
<karolherbst>
like 16 bits can be slower sometimes and applications should have control or what's up?
<javierm>
tzimmermann: honestly, I wouldn't be that worried about that since I'm pretty sure that the bottleneck is data transfer more than compute in most cases
<javierm>
tzimmermann: for example, in my rpi4 I see a huge difference in the I2C vs SPI displays
<karolherbst>
feels like uhm.. maybe we should just eat the flag and ignore it indeed if it's just a hint
<karolherbst>
I'm more concerned if those flags impact correctness
<tzimmermann>
javierm, i'm concered about fetching the data from the source buffers. some of that is currently handled as uncached memory. we can fix that, but still...
<tzimmermann>
writes remain the same AFAICS
<tzimmermann>
but i've really not spent time on it; except for basic research and some general thoughts
<javierm>
tzimmermann: I could play gameboy advance games using retroarch in the SPI displays but the I2C is unusable for that. It's only usable as a VT with fbcon
<tzimmermann>
haha
<javierm>
that's why my gut feeling is that even if the memory is uncached, it should be fine and the bottleneck will be the data write to the chip VRAM using I2C/SPI commands
<tzimmermann>
i guess, we could add suport for Cn and Rn formats to weston and emulators for simple displays. might make a difference
Duke`` has joined #dri-devel
<javierm>
tzimmermann: yeah but as a said, even the drm_fb_xrgb8888_to_mono() didn't look like the problem and more the I2C writes being slow
<javierm>
but I've to admit that only tested on an rpi4, not on less powerful arm boards
epoch101 has joined #dri-devel
<tzimmermann>
BTW, did you see the 8-bit patchset for vesadrm?
<sima>
agd5f, might also be an artifact of drm-tip or something, dunno
<sima>
also on aarch64
<tzimmermann>
if you haven't, could you add it to your todo list for friday reviews? :)
<tagr>
hm... is anyone else seeing merge conflicts when rebuilding drm-tip for drm-misc?
<tzimmermann>
its conversion to rgb332 is not great, but still recognizable. it could also benefit from dithering
<tzimmermann>
javierm ^
<jenatali>
zmike: Merging !35900 now, then if you're cool with it, I'll rebase your fence branch and add fixups. Want them as separate fixup commits or should I squash 'em in?
<zmike>
squash pls
<zmike>
and thanks
frankbinns has joined #dri-devel
<jenatali>
👍
zsoltiv____ has quit [Ping timeout: 480 seconds]
bnilawar has joined #dri-devel
frieder has quit [Remote host closed the connection]
<robclark>
karolherbst: google'ing for "-qcom-accelerate-16-bit=false" gives me an AI summary of what that flag may (or may not be).. but not really much else.. I suspect it is something that people just copy/paste all over the place, so just ignoring it is probably ok
<karolherbst>
yeah, that's why I hate those flags :D
dsimic is now known as Guest21514
dsimic has joined #dri-devel
kzd_ has joined #dri-devel
Guest21514 has quit [Ping timeout: 480 seconds]
warpme has quit []
Miko26 has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
sguddati has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: I've it in my TODO :) sorry that I couldn't review it before
bnilawar has quit [Read error: Connection reset by peer]
yshui has joined #dri-devel
bnilawar has joined #dri-devel
Miko26 has quit []
sguddati has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
bnilawar has quit [Read error: Connection reset by peer]
bnilawar has joined #dri-devel
kts has joined #dri-devel
fab has joined #dri-devel
bnilawar has quit [Read error: Connection reset by peer]
bnilawar has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
lynxeye has quit [Quit: Leaving.]
<jenatali>
zmike: Hopefully that looks okay
simon-perretta-img has quit [Ping timeout: 480 seconds]
<zmike>
jenatali: can you tl;dr me on what if anything you changed outside of d3d12/mft?
<jenatali>
That's pretty much it. Added one field to a pipe video struct for a fence value, and deleted the set_timeline_fence_value
<jenatali>
Oh it fails on Windows too. Need me to debug?
kts has joined #dri-devel
<zmike>
it's something with xml I think
<zmike>
but I'm not sure where the ordering is determined
<jenatali>
zmike: it's extensions_table.h
<zmike>
oh is it?
<jenatali>
NV_timeline_semaphore is at the end of the NV list, it needs to be in the middle
<zmike>
I see
<zmike>
there, fixed
<zmike>
hopefully
<idr>
zmike: If you do 'ninja test' locally, you will know if you got it right.
<zmike>
it passes, so I guess I did
sarnex has quit []
lsntvt has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, no worries
tzimmermann has quit [Quit: Leaving]
<karolherbst>
If I have a vulkan semaphore exported via VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT, can I import it with pipe_context::create_fence_fd and type == PIPE_FD_TYPE_NATIVE_SYNC?
<agd5f>
sima, looks like Sunil's MQD patches in drm-misc. Will ask him to fix it up
<zmike>
karolherbst: I think that would be PIPE_FD_TYPE_SYNCOBJ
<sima>
agd5f, thx
<zmike>
or at least that's what it is in zink
sarnex has joined #dri-devel
Miko26 has joined #dri-devel
Kayden has quit [Quit: Leaving]
jernej has quit [Read error: Connection reset by peer]
jernej has joined #dri-devel
Kayden has joined #dri-devel
tomaw has quit [Remote host closed the connection]