coldfeet has quit [Remote host closed the connection]
leizhou has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
croissant__ has quit []
croissant has joined #dri-devel
Haaninjo has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
flom84 has joined #dri-devel
leizhou has joined #dri-devel
flom84 has quit []
leizhou has quit [Ping timeout: 480 seconds]
BesterGester2 is now known as BesterGester
siak has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
leizhou has joined #dri-devel
aljazmc has joined #dri-devel
flom84 has joined #dri-devel
leizhou has quit [Ping timeout: 480 seconds]
kaiwenjon has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
vliaskov has joined #dri-devel
davispuh has joined #dri-devel
flom84 has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
LeviYun has quit [Read error: Connection reset by peer]
davispuh has quit [Ping timeout: 480 seconds]
leizhou has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
pcercuei has joined #dri-devel
warpme has quit []
kzd has quit [Ping timeout: 480 seconds]
leizhou has joined #dri-devel
sravn has joined #dri-devel
leizhou has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
Company has joined #dri-devel
rk has joined #dri-devel
yrlf has quit [Ping timeout: 480 seconds]
bg6vml has joined #dri-devel
<bg6vml>
hi there. I'm cross-compiling the mesa 24.2 onto aarch64 platform. I created the cross file for meson tools and configured the compilers such as cc, rustc and so on. But when I build the project, I'm confronted with the error 'attempt to compute `4_usize - 8_usize`, which would overflow' in file src/gallium/frontends/rusticl/rusticl_opencl_bindings.rs. Could anyone help with it?
LeviYun has joined #dri-devel
rk has quit []
yrlf has joined #dri-devel
aljazmc has quit [Remote host closed the connection]
LeviYun has quit [Read error: Connection reset by peer]
Mike2024 has joined #dri-devel
Mike2024 has quit [Quit: Quit]
nerdopolis has joined #dri-devel
u-amarsh04 has joined #dri-devel
LeviYun has joined #dri-devel
sassefa has joined #dri-devel
leizhou has joined #dri-devel
dviola has quit [Quit: WeeChat 4.3.6]
leizhou has quit [Remote host closed the connection]
leizhou has joined #dri-devel
leizhou has quit [Remote host closed the connection]
<dj-death>
DemiMarie: if you don't know what the compositor will do, then you can't know I guess
<DemiMarie>
dj-death: will it ever matter on Linux?
<DemiMarie>
I thought the required buffer size was entirely determined by width, height, stride, offset, format, and modifiers.
<DemiMarie>
The client certainly doesn't know that information when it allocates buffers.
<Sachiel>
the client asks the driver the requirements and passes that to the allocation function
<Sachiel>
anv will check the imported bo is at least as large as the image is supposed to be and if not, it fails the import
<DemiMarie>
This seems like a Vulkan spec bug to me: to properly allocate buffers, a Wayland client must know various implementation details of the server, but it does not (and should not) know those details.
<Sachiel>
the client asks the driver "to allocate memory for this buffer/image with this characteristics, what do I need?", the driver gives back the details, client calls the vkAllocateMemory() with those details
<Sachiel>
I don't see the issue
<Company>
DemiMarie: the client and the server do not communicate Vulkan images
<DemiMarie>
Company: doesn't the client needs to be able to allocate a dmabuf that the server will be able to make a Vulkan image from?
<Company>
they communicate dmabufs and you must create a VulkanImage suited for export on the client (and then export it) and a VulkanImage suited for importing that dmabuf
<Company>
yes
<Company>
which can and does fail all the time even if both are cooperating...
<DemiMarie>
Does that mean that whether the creation succeeds must not depend on factors like VkSharingMode?
Haaninjo has joined #dri-devel
<Company>
it might eb that certain flags must be set to certain values or images cannot be exported
bmodem has joined #dri-devel
sukrutb has joined #dri-devel
<DemiMarie>
My understanding was that Mesa uses create_immed because it can't handle an error. However, that means that if image creation fails the client gets disconnected. Changing VkSharingMode must not break a non-buggy client, so this means that the client must be able to pick a buffer size that works for any VkSharingMode.
<Company>
the buffers that Mesa shares with the compositor are created by Mesa
<Company>
not by the client
gouchi has joined #dri-devel
<DemiMarie>
Mesa still doesn't know what the compositor will pass for things like VkSharingMode
<Company>
no
<Company>
but VkSharingMode is about queues, not about inter-process sharing
<DemiMarie>
Does that mean that VkSharingMode (and all of the other parameters that the client does not know or provide) are not allowed to influence the minimum buffer size required?
<DemiMarie>
Assuming that they fall within valid usage.
<Sachiel>
pretty sure all of that is already specified in the spec, go read it
<Sachiel>
there's an entire section on resources that includes all about how memory allocation works
<Company>
Vulkan is just an API that sits on top of the basic buffer sharing API anyway
<Company>
and you can share buffers without using Vulkan or GL just fine
<Company>
the thing that Vulkan and GL do is various syscalls programming GPUs in fun ways
<Company>
which again can be done entirely without Vulkan or GL, they're just syscalls
<DemiMarie>
What I need to know is how big a buffer needs to be for a given width, height, and other parameters.
<DemiMarie>
I don't want to go through Vulkan or OpenGL for that if I can avoid it.
<Company>
I don't know if gbm has that info - usually this whole PI works by just allocating a buffer on the device you intend to use and then that buffer works on that device
<Company>
and if you get a buffer from a different device and try to use it, it may fail to import
<Company>
and if it does, developers from both sides will tell you you should have known in advance that this obviously wouldn't have worked
<Company>
but as long as you run the compositor on GPU 1 and the client allocated buffers on GPU 1, everything is fine
<Company>
you tell the GPU you want a buffer for WIDTH x HEIGHT in FORMAT and it tells you to use SIZE for it
<Company>
or does it?
<DemiMarie>
How do you tell the GPU that?
<Company>
it might just allocate the buffer for you
LeviYun has quit [Read error: Connection reset by peer]
<Sachiel>
DemiMarie: the client will use what the spec says to use. You as a consumer don't allocate memory for the client to use, it's the other way around
<Company>
gbm_bo_create_*() I thin
<Sachiel>
if you don't want to use vulkan or gl, go read on gbm I guess
aljazmc has joined #dri-devel
<DemiMarie>
I'll see about getting GBM to provide the needed size without allocating.
<Company>
I don't even know if "size" is an existing concept for such buffers, because memory management can be way fancier
<DemiMarie>
“size” as in “the value passed to Wayland”
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fxkamd has joined #dri-devel
fxkamd has quit []
jani has quit []
jani has joined #dri-devel
croissant has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
<mlankhorst>
There's a size you can get from fseek on the dma-buf. :)
<Company>
mlankhorst: that only works for linear ones, or?
kzd has joined #dri-devel
<dj-death>
xantoz: all
<dj-death>
Company: all
<dj-death>
Company: kernel doesn't always knows what's in the buffer
<Company>
is that number useful for anything?
<Company>
on non-linear buffers I mean
<pinchartl>
does the buffer size depend on tiling ?
<pinchartl>
(probably a newbie question)
<emersion>
it does
<pinchartl>
for compressed formats I understand that the compressed and uncompressed sizes differ
<pinchartl>
but how does tiling affect the size in bytes ?
<Company>
I think Intel has different stride requirements for tiled vs untiled buffers
<pinchartl>
sure, but the size of the buffer in memory is still the same whether you look at it after or before tiling
<pinchartl>
if you have different formats (tiled vs. untiled) you may have different sizes for a given resolution
<emersion>
the size includes any paddinbg
<dj-death>
Company: just for mapping virtual memory
<emersion>
i don't know if there are uncompressed formats with a different effective memory usage
<dj-death>
Company: too small, no good
<pinchartl>
this reminds me I need to submit a talk proposal for XDC about buffer allocation
<Company>
I just know I VkMapMemory()ed image memory on intel a few times that I wasn't suppsoed to map and then was entirely confused about the bytes inside it
<Company>
but I didn't check the size of what I mapped, I was only interested in the bytes
rgallaispou has quit [Read error: Connection reset by peer]
<HdkR>
Get those talks submitted people, only two days left even with the week delay on the deadline!
* pinchartl
clicks "Submit new abstract"
<pinchartl>
I hope there will be people interested in buffer allocation
<emersion>
there always are
<emersion>
(i am but will not attend)
<pinchartl>
there are three steps, in order of increasing difficulty
<pinchartl>
1. agree that we need something better than what we have
<pinchartl>
2. design the outline of the solution we want
<pinchartl>
3. find someone to work on it
Calandracas_ has joined #dri-devel
rgallaispou has joined #dri-devel
<Company>
4. make the whole ecosystem actually use it
<emersion>
maybe a workshop would be better suited?
<pinchartl>
I've briefly discussed this with sima, she recommended submitting a talk proposal that can then be extended with a workshop
<pinchartl>
I'll pick a half-slot format, that will be enough to explain the problem and see if people are interested in continuing in a workshop
<emersion>
cool
<emersion>
i've discussed with sima last XDC and we had a start of an incremental plan with DMA-heaps
Calandracas has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
<pinchartl>
it would be nice to get James Jones to join too
<pinchartl>
perhaps remotely, I don't know if he plans to attend XDC