ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
gawin has quit [Ping timeout: 480 seconds]
gouchi has quit [Quit: Quitte]
Haaninjo has quit [Quit: Ex-Chat]
mbrost has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
yuq825 has joined #dri-devel
mbrost has joined #dri-devel
digetx is now known as Guest1411
digetx has joined #dri-devel
Guest1411 has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
sarnex_ has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
<jessica_24>
hey glennk, emersion, robclark: I agree that there will be a seam if we put 2 layers of different precision side by side, though I'm not sure what could be done on driver side to fix this
<jessica_24>
Maybe we could expose something like a max_bitdepth property so that userspace can pass in a color value with the matching precision? Though I don't think that this should block the solid fill feature
<jessica_24>
If we're ok with the RGB323232 color fill value being truncated, I'll move ahead with the v2 for the series
sarnex_ has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
<robclark>
jessica_24: I guess the question is, whether any hw supports scanout w/ higher precision than solid fill? (I'm not entirely sure about dpu.. but otherwise we can leave the bitdepth prop until someone shows up with hw that needs it, I guess)
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
Nyaaori has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
columbarius has joined #dri-devel
heat_ has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
heat has quit [Read error: No route to host]
<Lynne>
airlied: I got a few correct frames
<Lynne>
but for some reason, at the start of files, is a weird collection of frames that doesn't quite work right
<Lynne>
the source itself is weird, for some reason even trying to seek through the first few frames in mpv doesn't work
<jessica_24>
robclark: to fix the seam issue wouldn't the precision of the source format be more relevant? since that way we'd be able to truncate color value for the layer w/the larger bitdepth to match the smaller bitdepth
<robclark>
the source format of the non-solid-fill layer? I'm assuming that either hw or driver will truncate the solid-fill color to match the highest bitdepth layer
<abhinav__>
robclark i thought the driver would just truncate it to the max number of bits supported for each channel by the hw for the solid fill. So lets say, we got the color in RGB323232 format, but the hw has only 8 bits for each channel for the solid fill plane, it will get truncated to 8.
<abhinav__>
how would truncating it to match highest bitdepth layer help fot eh case which glennk mentioned? in the example given, the scanout layer had a lower bitdepth than the solid fill plane
<abhinav__>
so that would anyway not avoid the seam
<robclark>
well, if there is only a single non-solidfill layer, then truncating the solidfill color to that depth would avoid the seam.. but I guess we could just say this is userspace's problem, it should do the truncation if it wants (ie. just because it has 32b/channel doesn't mean it needs to use all the low bits)
<abhinav__>
robclark correct , thats what we felt too. that it should be taken care of by userspace
<abhinav__>
answering your question about scanout having higher precision than solid fill
<abhinav__>
that is not the case for DPU
<robclark>
but userspace can do it without needing any uapi, it can just realize that however many low bits of the 32b/chan value should be zero to avoid a seam
<abhinav__>
robclark correct and thats why jessica_24 wrote that she will go ahead with v2 as it should not block the driver side of things
<robclark>
ahh, ok.. then sg
mbrost has joined #dri-devel
mhenning has quit [Quit: mhenning]
<macromorgan>
hate to be a bother, but was wondering if someone could help a newbie out on his code... I'm trying to build a new function for a panel but can't seem to get it to work.
<macromorgan>
keep getting a null pointer dereference. I'm adding the function first to a driver I'm writing and if I get it working I'm going to push it upstream into a proper of_drm.c file (or another appropriate location).
<macromorgan>
the function I'm working on is titled "drm_of_get_dsi_bus()", and it throws the null pointer dereference when it calls devm_mipi_dsi_device_register_full() on line 433... I just can't figure out why...
maxzor has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
maxzor has joined #dri-devel
maxzor_ has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
mbrost has joined #dri-devel
maxzor__ has joined #dri-devel
maxzor_ has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
nchery has joined #dri-devel
aravind has joined #dri-devel
srslypascal is now known as Guest1434
srslypascal has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1436
srslypascal has joined #dri-devel
Guest1434 has quit [Ping timeout: 480 seconds]
Guest1436 has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
srslypascal is now known as Guest1438
srslypascal has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
Guest1438 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
fab has joined #dri-devel
rmckeever has quit [Quit: Leaving]
fxkamd has quit []
kts has joined #dri-devel
bgs has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
rasterman has joined #dri-devel
danvet has joined #dri-devel
dcz_ has joined #dri-devel
jlawryno has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
cheako has quit [Quit: Connection closed for inactivity]
alanc has quit [Remote host closed the connection]
<jmondi>
am I looking in the right place, and if that's the case, is there any reason why it seems to me only RGB formats are supported by the mesa libgbm implementation ?
djbw has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
gekret005 has joined #dri-devel
airlied has joined #dri-devel
tzimmermann has joined #dri-devel
vliaskov has joined #dri-devel
jkrzyszt has joined #dri-devel
sgruszka has joined #dri-devel
rgallaispou has joined #dri-devel
lynxeye has joined #dri-devel
a1batross has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
<pinchartl>
jmondi: I'm also very curious to know why the mesa gbm dri backend doesn't support YUV formats
<pinchartl>
minigbm does
heat_ has joined #dri-devel
* pinchartl
is also curious about where the gbm experts hang out :-)
pcercuei has joined #dri-devel
agd5f has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
<lynxeye>
jmondi: pinchartl: Because Mesa treats GBM as the glue between accel APIs and KMS that it was originally designed to be. Rendering (or doing anything accelerated at all) into a YUV target is somewhat exotic if supported at all.
<lynxeye>
I'm not saying that supporting YUV in GBM is a bad idea, just that nobody needed it really until now.
apinheiro has joined #dri-devel
<lynxeye>
jmondi: On non-android Linux you normally allocate on the camera side and just import the NV12 buffer into Mesa, which works fine.
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<jmondi>
lynxeye: thanks, let me check how this works with minigbm in example
OftenTimeConsuming has quit [Remote host closed the connection]
<jmondi>
with chromiumos in example, which use mingbm, I presume NV12 allocation is supported
<jmondi>
might be related as I'm working with a Rockchip SoC..
garrison has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
q4a[m] has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
fab has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
junaid has joined #dri-devel
i-garrison has joined #dri-devel
maxzor__ has quit [Remote host closed the connection]
garrison has quit [Ping timeout: 480 seconds]
maxzor__ has joined #dri-devel
jlawryno has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Remote host closed the connection]
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
jlawryno has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
heat_ has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
jlawryno has quit []
sgruszka has joined #dri-devel
jkrzyszt has joined #dri-devel
ezequielg_ has left #dri-devel [#dri-devel]
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
maxzor__ has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
maxzor__ has joined #dri-devel
Akari has joined #dri-devel
junaid has joined #dri-devel
anholt_ has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
MajorBiscuit has quit [Ping timeout: 480 seconds]
dliviu has quit [Read error: No route to host]
dliviu has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
Cyrinux has quit []
dliviu has quit [Read error: No route to host]
jkrzyszt has quit [Remote host closed the connection]
dliviu has joined #dri-devel
Cyrinux has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
MajorBiscuit has joined #dri-devel
kts has quit [Quit: Leaving]
cheako has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
junaid has quit [Quit: leaving]
junaid has joined #dri-devel
Lucretia-backup has quit []
Lucretia has joined #dri-devel
devilhorns has quit []
MajorBiscuit has quit [Quit: WeeChat 3.6]
<daniels>
pinchartl: 'gbm experts'? plural?
<daniels>
jmondi: indeed, Android and CrOS have a centralised memory allocator (gralloc/minigbm) because they can tune it to their very specific usecases - in our more generic cases, we can't do that, and GBM is not a generic buffer allocator. as lynxeye says, if you have a camera/codec output buffer, then allocate it there and import it into the GPU/display, which does work
<jmondi>
daniels: thanks! unfortunately I'm not in control of the buffer allocation as it's the Android camera service handling that
<jmondi>
I wonder if trying to replace mesa/libgbm with minigbm might be a possible way forward
<jmondi>
in my Android build I mean
junaid has quit [Remote host closed the connection]
<daniels>
sure, if it's a binary you can't modify then you could do something like that, though iirc CrOS have their own downstream Rockchip memory-allocation ioctl which you'd need to pull into your kernel
jewins has joined #dri-devel
<jmondi>
it's not binary distributed, as I have access to the code would your suggestion be to implement NV12 support in mesa's libgbm (not an upstreamable change if I got you two right though)
<daniels>
no, I mean in the Android camera service, make it not use GBM
<jmondi>
afaiu it's doesn't it goes through gralloc which implements standard android's API and then the gralloc module calls into libgbm
<jmondi>
when it comes to modifying the android service: I would not go there, it would make my camera system work on a very customized setup
<daniels>
in that case, probably use minigbm and make sure you pull the downstream kernel patches it depends on
yuq825 has left #dri-devel [#dri-devel]
zehortigoza has quit [Remote host closed the connection]
junaid has joined #dri-devel
<jmondi>
daniels: I'll look into that
<jmondi>
and thanks for raining on my parade :)
<daniels>
any time!
JohnnyonFlame has joined #dri-devel
aravind has joined #dri-devel
junaid has quit [Remote host closed the connection]
sgruszka has quit [Ping timeout: 480 seconds]
i-garrison has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
<Lynne>
airlied: any interest in writng encoding code?
<Lynne>
should be simpler than decoding
fxkamd has joined #dri-devel
fab has quit [Quit: fab]
sarahwalker has joined #dri-devel
aaa has joined #dri-devel
aaa has quit []
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
Didgy has joined #dri-devel
<Didgy>
Any advice on how I can breakpoint into Vulkan functions? I've compiled Mesa, set the environment variable, and at this point I'm just using CLion to breakpoint debug the VkCube app. But it instantly skips the Vulkan functions when I try to step into them
ybogdano has joined #dri-devel
<dj-death>
Didgy: have you compiled in debug?
<Didgy>
Yeah, I'm fairly certain I did
<Didgy>
I'll figure out how I can inspect the .so to see if it has any debug symbols
Duke`` has joined #dri-devel
fab has joined #dri-devel
<MrCooper>
Didgy: file will tell you
<MrCooper>
well, whether or not it's stripped, anyway
Didgy has quit [Quit: Konversation terminated!]
Didgy has joined #dri-devel
<Didgy>
I'm basically trying to learn more about how Vulkan function translates to the driver stuff
<DavidHeidelberg[m]>
MrCooper: i have brach I work on with some experimental debug info + coredumps
<DavidHeidelberg[m]>
Oh, we not talking about CI, ignore me :)
<MrCooper>
Didgy: it may be that gdb can't follow the ICD loader's dispatch code, in which case you may need to figure out the name of the Mesa function via the source code
<MrCooper>
s/gdb/CLion/
fxkamd has quit []
djbw has joined #dri-devel
<Didgy>
Ah, so I gotta manually figure out where to set the breakpoint in Mesa then? I can try that, gonna take some minutes
fxkamd has joined #dri-devel
fxkamd has quit []
alyssa has joined #dri-devel
<alyssa>
hakzsam: why does GPL fast-linking go through NIR/ACO at all?
<alyssa>
isn't it just a memcpy to concatenate the shader parts? (or an indirect branch and fast linking is absolutely trivial?)
Didgy has quit [Ping timeout: 480 seconds]
<hakzsam>
alyssa: I suppose applications can pass DISABLE_OPTIMIZATIONS like Zink does for fast-linking, so all NIR opts should be disabled to create pipelines as fast as possible in this specific case
<hakzsam>
then applications can compile the same pipeline with link-time optimizations in the background and switch to that pipeline when it's created
rgallaispou has quit [Read error: Connection reset by peer]
dliviu has quit [Remote host closed the connection]
dliviu has joined #dri-devel
<hakzsam>
there is another path though when VK_PIPELINE_CREATE_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT isn't set, in this case we import the binaries directly from the libs
<pinchartl>
daniels: I thought the plural was used for == 0 and > 1 in English, as in "there are no experts". seems appropriate to me ;-)
vliaskov has quit [Remote host closed the connection]
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
<alyssa>
hakzsam: what I meant, fast linking without LTO shouldn't go through the compiler at all, no?
Didgy has joined #dri-devel
dliviu has quit [Read error: No route to host]
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
<ishitatsuyuki>
not sure I'm missing something here, don't we just emit the shader jump pointers for fast linking in RADV?
<ishitatsuyuki>
If you can compile the partial libraries (VS-only/FS-only) upfront, I don't think VK_PIPELINE_CREATE_DISABLE_OPTIMIZATION_BIT is relevant here. It controls the code optimization itself, not link-time optimization.
<ishitatsuyuki>
Link-time optimization is controlled solely through VK_PIPELINE_CREATE_LINK_TIME_OPTIMIZATION_BIT_EXT, if it's specified, optimize, if it's not, "implementations should instead perform linking as rapidly as possible"
dliviu has joined #dri-devel
apinheiro has joined #dri-devel
<hakzsam>
alyssa: yeah, it doesn't, only in libs and binaries are then imported when creating the pipeline
rgallaispou has joined #dri-devel
<qyliss>
alyssa: do you have the asahi driver working on M2 on macOS?
<qyliss>
(I hope this is the right channel to ask!)
<qyliss>
Maybe I can improve that error message about requiring a non-swrast gallium driver then, to make it clear it can't be just any other driver.
junaid has quit [Read error: No route to host]
Didgy has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
Cyrinux has quit []
Cyrinux has joined #dri-devel
kts has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
tursulin has joined #dri-devel
<alyssa>
sure
<alyssa>
a hw gallium driver that supports nine
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
zehortigoza has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
tursulin has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
<airlied>
Lynne: interested kinda, time for it maybe not, but would need to dig in
<airlied>
not sure if anv decode is more value than amd encode
mhenning has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
gouchi has joined #dri-devel
Didgy has joined #dri-devel
<Lynne>
airlied: amd encode > anv decode
<Lynne>
consider this - amf exists, and it's awful
Didgy has quit []
Didgy has joined #dri-devel
<Lynne>
vaapi encode on amd has been kinda buggy, we get plenty of users resorting to amf which none of us has ever used or even touched since it got merged
Didgy has quit [Remote host closed the connection]
jfalempe_ has quit []
maxzor__ has quit [Remote host closed the connection]
maxzor__ has joined #dri-devel
warpme____ has quit []
maxzor_ has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
maxzor__ has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: the problem is vaapi is buggy, is that it's the only reference I have :-P
<airlied>
so anything I implement will be similarly buggy
<bnieuwenhuizen>
can we trace amf?
<bnieuwenhuizen>
with amdgpu_intercept etc?
<airlied>
good question, no idea, never even heard about amf until now :-P
* airlied
also isn't that invested in video that I want to trace things
<airlied>
I suppose if there are h264 encoder CTS tests I could start looking into it
* airlied
will see what next week airlied thinks
<Lynne>
I'll try to get some I-frame encoding working during the weekend on nvidia so there's code to write drivers to
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
dliviu has quit [Read error: No route to host]
dliviu has joined #dri-devel
Haaninjo has joined #dri-devel
Akari has joined #dri-devel
vhebert has joined #dri-devel
<Lynne>
err, weekend? I forgot today's monday; I'll get to it as soon as I figure out the ref frame ordering
<jenatali>
It's... Friday?
<kisak>
not when you have a day ordering issue ^_^
<Lynne>
on some hardware sunday's the start of the week, right? have to remember to specialcase this...
dliviu has quit [Remote host closed the connection]
rgallaispou has joined #dri-devel
dliviu has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
rgallaispou has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Duke`` has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
fab has quit [Quit: fab]
<DavidHeidelberg[m]>
Who is going to the FOSDEM 2023?
ybogdano has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
maxzor_ has quit [Remote host closed the connection]
maxzor_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]