FOSDEM graphics DevRoom CFP
Hi, At FOSDEM on Sunday the 4th of February, there will the 15th Graphics DevRoom. URL: https://fosdem.org/2024/ The talk topics of the graphics devroom encompass: * graphics drivers: display, 2d engines, 3d engines, at bootloader, kernel and userspace levels. * media drivers: camera/capture engines, hardware media encoders and decoders on all levels. * input drivers for bootloaders, kernels and userspace on all levels. * windowing systems (X, wayland, others) and window managers. * graphics toolkits (QT, GTK, others). * 3D and Compute APIs (OpenGL, Vulkan, DirectX, others), and 3d and game engines. * Virtual reality hardware and toolkits. * Artificial Intelligence HW acceleration. * Media encode and decode applications. And the tools needed to help configure and run the above. Like with so many DevRooms, we got a surprise half a day only, so there will have to be 8 slots of 20 minutes (with 5 minutes of setup, and 5 mins of Q&A) on half an hour boundaries. Submission deadline is the 10th of december, but do not count on this date, once the schedule has filled with enough solid talks, we will accept no more. You can submit your talk here: https://fosdem.org/submit FOSDEM has moved away from the clunky but known quantity that was Pentabarf to pretalx. Accounts from Pentabarf are no longer valid, and you will have to create a new account. Please put some time and effort in the title and at least abstract. FOSDEM is a massive and thoroughly organized event, which produces a printed scheduled booklet every time, and many thousand copies will be in the hands of many thousand visitors. Since this an open source community event, please refrain from turning in a talk that is a pure corporate or product commercial. Also, this is a highly technical devroom on a conference aimed at developers and advanced users, so please only submit talks on a subject you actually worked on. If you are unsure on whether you can come or not, perhaps you are unsure about corporate sponsorship of your travels (this is FOSDEM, why are you not there anyway?), wait with submitting your talk until you are certain that you can be present. All talks will be recorded and made available as CC-By-Sa or CC-By. The FOSDEM CoC will have to be agreed as well (https://fosdem.org/2024/practical/conduct/) If there are any issues, just email graphics-devroom-mana...@fosdem.org, where you can reach the team of graphics devroom managers, Pierre Moreau, Arek Hiler, Martin Roukala, and myself, who will also schedule and review your talk submissions. We will be keeping a keen eye on submissions and scheduling, and hope to see you all at FOSDEM. Thanks! Luc Verhaegen.
Re: GBM as standalone buffer allocator
There’s
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26038. It is
quite appealing to me considering a VK only scenario.
On Thu, Nov 2, 2023 at 5:50 AM Srinivas Pullakavi (QUIC) <
quic_spull...@quicinc.com> wrote:
> Hi Rob,
>
> Thanks for your inputs.
>
> We are planning to use DMA-Buf for GBM backend. DMA-buf supported heaps
> are listed in /dev/dma_heap/
> Gbm backend selects the best heap based on usage. For example: Secure
> buffers will be allocated from secure heap.
>
> Sample output:
> # ls /dev/dma_heap
> reserved system
>
> Sample code to allocate a buffer from system heap:
> int heap_fd = open(/dev/dma_heap/system, O_RDONLY | O_CLOEXEC))
> struct dma_heap_allocation_data heap_data {
> .len = size, // length of data to be
> allocated in bytes
> .fd_flags = O_RDWR | O_CLOEXEC, // permissions for the
> memory to be allocated
> };
> int status = ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &heap_data)
> if (status == 0) {
> int buffer_fd = heap_data.fd;
> }
>
> In this case, there is no dependency on display / Graphics driver. But
> still GBM create device expects a device fd to be passed.
>
> Can we make it optional to pass device fd ?
>
> Thanks,
> Srinivas
>
> -Original Message-
> From: Rob Clark
> Sent: Tuesday, October 24, 2023 1:06 AM
> To: Srinivas Pullakavi (QUIC)
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: GBM as standalone buffer allocator
>
> On Mon, Oct 23, 2023 at 6:22 AM Srinivas Pullakavi (QUIC) <
> quic_spull...@quicinc.com> wrote:
> >
> > Hi,
> >
> >
> >
> > We are planning to enhance GBM as a standalone buffer allocator, which
> > can be used for all multi-media clients. Ex: video, camera, display
> > etc;
> >
> >
> >
> > GBM create device expects a file descriptor to be passed, which points
> to drm node. This brings in a dependency on display for buffer allocation.
> On headless devices where display driver is not present, GBM cannot be used
> for buffer allocations. E.g. Recording cases where pipeline is setup
> between Camera, Video, Graphics.
> >
>
> Note that you need some sort of device to allocate buffers from. With
> mesa and upstream kernel, that would be the drm device. (However as Adam
> points out, a drm device does not necessarily need a display..
> for example, several vendors have compute-only GPUs (pci) which have no
> display outputs.)
>
> You might want to look at ChromeOS's minigbm. It already handles these
> cases (buffer sharing across display/gpu/video/camera).
>
> BR,
> -R
>
> [1] https://chromium.googlesource.com/chromiumos/platform/minigbm/
>
> >
> > Could you please share your comments on what will be a good design to
> make GBM flexible for above?
> >
> >
> >
> > Thanks,
> >
> > Srinivas
> >
> >
>
