<iyes>
Where can I find various general developer documentation for mesa? Whatever would be helpful to figure out the codebase, architecture, apis, dev workflows, etc.? I kinda want to contribute (specifically, with Asahi), but first I gotta find my way around the project. :)
yyds has joined #dri-devel
heat has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<iyes>
I mean, if there is anything else besides mesa-docs.readthedocs.io and docs.mesa3d.org . I'm already reading those. I'm asking in case ppl know of more things I should know about. With some projects, there are useful resources that don't show up with a quick google search. :)
yyds has quit [Remote host closed the connection]
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
f11f12 has joined #dri-devel
<FLHerne>
iyes: not really documentation as such, but there are a number of developer blogs with some technical detail
<iyes>
Thank you all! I was disconnected but found an irc log with your responses. Non-gfx-filtered is fine, I'm pretty good at sifting through lots of content/headlines.
neobrain has joined #dri-devel
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
novaisc has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
tonyk has joined #dri-devel
mairacanal has joined #dri-devel
greenjustin_ has joined #dri-devel
greenjustin has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
kts has joined #dri-devel
gcarlos has joined #dri-devel
rasterman has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
junaid has quit [Remote host closed the connection]
Ahuj has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
bmodem has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
Peste_Bubonica has joined #dri-devel
aradhya7 has quit [Quit: Connection closed for inactivity]
Company has joined #dri-devel
DemiMarie has joined #dri-devel
mvchtz has quit [Quit: WeeChat 3.5]
mvchtz has joined #dri-devel
f11f12 has quit [Quit: Leaving]
karolherbst has quit [Quit: Konversation terminated!]
djbw has joined #dri-devel
yyds has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
iyes has joined #dri-devel
tales-aparecida has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
anujp has quit [Ping timeout: 480 seconds]
iyes has joined #dri-devel
benjaminl has joined #dri-devel
<i509vcb>
I'm trying to figure out which drivers are correct at implementing vkGetMemoryFdPropertiesKHR
<i509vcb>
some drivers: v3dv, anv and a few others will return VK_SUCCESS regardless of the file descriptor passed in
<i509vcb>
However it seems bizzare to return VK_SUCCESS for an fd created via open when you'd probably expect a prime fd to only be successful?
karolherbst has joined #dri-devel
<i509vcb>
(also means -1 being passed into vkGetMemoryFdPropertiesKHR technically returns VK_SUCCESS, but why would an invalid fd be reasonable to pass into that)?
<i509vcb>
The former with drivers not checking whether an fd is actually a prime fd in vkGetMemoryFdPropertiesKHR feels like a driver issue
<i509vcb>
but it also feels like a spec issue where fd = -1 is not explicitly said to return VK_ERROR_INVALID_EXTERNAL_HANDLE?
<emersion>
checking the type of the FD is not enough
<emersion>
not all DMA-BUFs can be imported by drivers
<emersion>
what guarantees does the spec offer?
<emersion>
does the spec specify that the driver will check the handle?
iyes has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<i509vcb>
VUID-vkGetMemoryFdPropertiesKHR-fd-00673 states
<i509vcb>
> fd must point to a valid POSIX file descriptor memory handle
<i509vcb>
Outside of that I can't seem to find much of anything else
<i509vcb>
VUID-vkGetMemoryFdPropertiesKHR-handleType-00674 forbids OPAQUE_FD as the handle type, but drivers seem to check for that already and what happens there is effectively undefined behavior
<emersion>
that is a requirement for the user of the API
<emersion>
not for the driver
<emersion>
so i think it's okay for the driver to optimize the case if it always returns the same values for all valid FDs
iyes has joined #dri-devel
<i509vcb>
I guess from that intepretation, if it's not a prime fd then you'll get the error on import
<emersion>
yeah, but i'm not sure what the guarantees are there again
<emersion>
sometimes the vulkan spec states that it's UB
sur_shrimp has joined #dri-devel
iyes has quit [Ping timeout: 480 seconds]
sur_shrimp has quit []
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
iyes has joined #dri-devel
<DemiMarie>
Has the problem of amdgpu not zeroing VRAM been fixed? That’s going to be a serious problem for virtio-GPU native contexts. I’d offer to help but neither know where to even begin nor have any AMD GPUs I could test on.
donaldrobson has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
Guest8886 has quit [Remote host closed the connection]
macromorgan_ has joined #dri-devel
<koike>
sima, airlied, robclark (and others), I'd like to check with you how would you prefer to move forward with the ci patch
<robclark>
koike, sima, airlied: unless we go back to out-of-tree ci my preference is to land it as soon as possible so that I'm not without working CI ;-)
iyes has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
iyes has quit [Ping timeout: 480 seconds]
<DemiMarie>
MrCooper: will this be mandatory, meaning that malicious userspace cannot subvert it to steal information?
yyds has quit [Remote host closed the connection]
iyes has joined #dri-devel
<MrCooper>
yeah, the point is user space won't be able to allocate un-zeroed BOs
jimc has quit [Ping timeout: 480 seconds]
iyes has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
iyes has joined #dri-devel
<DemiMarie>
MrCooper: That is great! I added a comment explaining my use-case and what the consequences would be if the feature was not implemented.
<gfxstrand>
alyssa: Naming question: For nir_src, we need three operations: Clear, set a cleared things, and rewrite. They need names.
<gfxstrand>
I don't like init/fini because all of those ops assume it's been at least memset to 0
<gfxstrand>
I don't like add/remove because the memory already exists, we're just mucking about with the source
<gfxstrand>
I like clear/rewrite well enough but I don't know what the third should be.
<gfxstrand>
assign? populate? set?
<zmike>
wrangle
<gfxstrand>
fill?
<alyssa>
gfxstrand: Can we take a step back
<gfxstrand>
okay
<alyssa>
Why do we even have unpopulated nir_srcs in the first place?
<alyssa>
I'm not saying there's not a good reason but I don't understand it
<gfxstrand>
This generally comes up when adding a source for some reason.
<gfxstrand>
for nir_tex_instr, we have nir_tex_instr_add_src and that works great.
<alyssa>
Right
<gfxstrand>
There's a couple cases where we aren't using it but we could just use the helper
<gfxstrand>
The one I'm looking at blowing up right now is parallel copies
<alyssa>
I would... strongly prefer requiring that sources are filled at all times
<alyssa>
and for the oddball cases like parallel copies, IDK, init with nir_undefs if you have to
<gfxstrand>
Hrm...
<gfxstrand>
We could possibly fix parallel copies by adding some helpers
jeeeun841351 has joined #dri-devel
<gfxstrand>
If it really is just phi nodes, I can come up with a plan for those.
<gfxstrand>
s/phi nodes/parallel copies/
grillo_0 has joined #dri-devel
heat_ has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
i-garrison has quit []
i-garrison has joined #dri-devel
rasterman has joined #dri-devel
heat has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
junaid has joined #dri-devel
oneforall2 has joined #dri-devel
<karolherbst>
gfxstrand: mhh. so I have this issue, that I have some left over scratch load/stores and I was wondering what's the proper way of getting rid of pointless ones before io lowering. Is it required to call `nir_lower_vars_to_explicit_types` before all of those deref optimizations?
benjaminl has quit [Ping timeout: 480 seconds]
egbert is now known as Guest9084
egbert has joined #dri-devel
Guest9084 has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
ngcortes has joined #dri-devel
<karolherbst>
mmhh.. anyway, I'll throw in an optimization loop between explicit_types and lower_io
benjaminl has joined #dri-devel
<zmike>
Lynne: this feels like a question for you: are there any single frame test clips? ideally some that work with mesa's vdpau?
gouchi has joined #dri-devel
<gfxstrand>
karolherbst: You'll have to be more specifdi
<gfxstrand>
*specific
<gfxstrand>
alyssa: I'm still running more CI but it looks like it really is just parallel copies that are especially stupid here.
<jannau>
zmike: `ffmpeg -i $SAMPLE -codec:v copy -vframes 1 $SAMPLE_1frame.$EXT` should generally work. $EXT should be h264, h265 and I think ivf would be the best choice for vp9/av1
karolherbst_ has joined #dri-devel
<zmike>
hm
<zmike>
so let's say I was using big buck bunny
<zmike>
seems to work
<zmike>
incredible
junaid has quit [Remote host closed the connection]
<karolherbst_>
gfxstrand: mhh.. yeah, I had a leftover store+load scratch pair, which my nir pipeline wasn't able to get rid of unless I call explicit_types on function_temp memory before optimizing
<alyssa>
gfxstrand: \o/
<gfxstrand>
alyssa: But now I'm headed down a rabbit-hole....
<gfxstrand>
alyssa: I think we might be able to make NIR faster if we're a little less dumb in nir_def_init()
<alyssa>
I like faster NIR
karolherbst has quit [Ping timeout: 480 seconds]
<gfxstrand>
Annoyingly, nir_def_init is used 243 times.
gouchi has quit [Quit: Quitte]
<alyssa>
gfxstrand: :|
<alyssa>
Lot of code that should be using the proper builders but isn't?
<gfxstrand>
Intrinsic and tex builders haven't been around that long
<alyssa>
yeah
<alyssa>
and the tex builders aren't really usable in gl
heat has quit [Read error: No route to host]
heat has joined #dri-devel
karolherbst_ has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
Guest7989 is now known as lumag
rasterman has quit [Quit: Gettin' stinky!]
apinheiro has joined #dri-devel
orowith2os has left #dri-devel [#dri-devel]
karolherbst has quit [Remote host closed the connection]
<ids1024[m]>
Or well, in this case it specifically depends what "point to a valid POSIX file descriptor memory handle" means (any file descriptor? or only one that's a "valid memory handle"? Which means what?)