- Jul 23, 2016
-
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Andreas Boll authored
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Andreas Boll authored
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Andreas Boll authored
The plan is to use this version of virtgpu_drm.h in mesa and drop mesa's local copy. To actually use this header it needs to be shipped in the tarball. This was missed in c745e541 Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Andreas Boll authored
Generated using make headers_install. This brings the C++ guard, proper include path for drm.h and the switching to kernel types for fixed-with integers. Generated from drm-next commit c11dea5b0290984fa48111957ba3fdc5b3bdae5a Suggested-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Andreas Boll authored
Currently only some Android Makefiles are included in the release tarball. To be more consistent one could either add the remaining files or don't ship Android Makefiles altogether. According to Emil the Android folk doesn't use our release tarballs. Thus it makes sense to remove those files from distribution which also means less work for maintenance in the future. Suggested-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Andreas Boll authored
This was missed in 552de225 Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
- Jul 21, 2016
-
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org> Tested-by: Rob Herring <robh@kernel.org>
-
Rob Clark authored
The 'deprecated' #define was causing problems with bionic system headers which used __attribute__((deprecated)). Signed-off-by: Rob Clark <robclark@freedesktop.org> Tested-by: Rob Herring <robh@kernel.org>
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
- Jul 20, 2016
-
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Note: cache the last ring the bo was emitted on, to avoid excess hashtable lookups. We do this by tracking ring seqno to avoid problems with dangling pointers. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
The issue that userspace needed to solve is that there is ~two orders of magnitude size difference in cmdstream buffers (both for gmem commands and for draw commands), and that the previous practice of allocating worst-case sizes is quite wasteful. Previously a submit would be constructed (for example) like: CMD TARGET DESCRIPTION g0 N gmem/tiling commands b0 Y binning commands d0 Y draw commands Which, after the one non-IB-target cmd buffer is inserted into the kernel controlled ringbuffer, looks like (not to scale): b0: d0: +-----+ +-----+ IB1 | ... | | ... | +-----+ +-----+ ^ ^ | | +-----+ +-+---------+ g0: | | | +----+----+----+----+----+----+---- IB0 | .. | IB | .. | IB | .. | IB | ... +----+----+----+----+----+----+---- ^ tile0 tile1 | +-----------+ userspace | ~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel | ----+----+---- ringbuffer ... | IB | ... ----+----+---- Now, multiple physical cmdstream buffers per fd_ringbuffer are supported, so this becomes: CMD TARGET DESCRIPTION g0 N ... N gmem/tiling commands gN N b0 Y ... Y binning commands bN Y d0 Y ... Y draw commands dN Y Which, after the non-IB-target cmd buffers (g0..gN) are inserted into the kernel controlled ringbuffer, looks like: b0: b1 d0: d1 +-----+ +-----+ +-----+ +-----+ IB1 | ... | | ... | ... | ... | | ... | ... +-----+ +-----+ +-----+ +-----+ ^ ^ ^ ^ | | | | | +-+ | +-----+------+ +-----+ | | | | | | +--+----------+ | g0: | | | | | | +----+----+----+----+----+----+---+----+----+---- IB0 | .. | IB | IB | .. | IB | IB |.. | IB | IB |... +----+----+----+----+----+----+---+----+----+---- ^ tile0 tile1 | to b0 to b1 | | | to|d0 to|d1 | | +----+ | +-+-----------+ | | | | | | | +------+ | +-+-------------+ | | g1: | | | | | | | +----+----+----+----+----+----+---+----+----+---- IB0 | | .. | IB | IB | .. | IB | IB |.. | IB | IB |... | +----+----+----+----+----+----+---+----+----+---- | ^ tileX tileY | | | +-----------+ +-----------+ | userspace | | ~~~~~~~~~~~~~~~~~~~|~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel | | ----+----+----+---- ringbuffer ... | IB | IB | ... ----+----+----+---- Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
First step towards supporting a single logical ringbuffer mapping to multiple physical cmd buffers, which will enable dynamically growing ringbuffers. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Not actually needed. It just needs to ensure that there is a corresponding entry in the submit's cmds table. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Since they get vmap'd on the kernel side, they are a bit more costly. Don't let them mingle with the riffraff. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
If user has emit'd reloc's, and then resets or deletes the ring, we want to drop the ref's that the ring holds to the bo's to avoid a leak. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
The normal bo cache uses some intermediate steps between power of two jumps to reduce memory wastage. But for a ringbuffer bo cache, we do not need this. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
gallium needs to know if the kernel is new enough to support explicit fencing, dynamically grown ringbuffers, etc. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
With a new enough drm/msm, we can let the kernel know about buffers that are in the bo cache, so the kernel can free them under memory pressure. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
(from drm-next for 4.8) Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Split out interface to allocate from and release to bo-cache, and get rid of direct usage of bucket level API from fd_bo/etc. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Eventually we'll want a separate bo-cache for ringbuffer bo's, since ringbuffer bo's get vmap'd on the kernel side, it is preferrable to re-use them as ringbuffers rather than something else. Plus should help to add madvise support if it is a bit better decoupled from bo allocation (next patch). Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
Provide a way to insert a reference (ie. OUT_IB()) to a target ring, executing all the cmds in the target ring from the start. Sometimes the ringmarker stuff is just overkill. And it will won't really work properly once we support multiple physical cmdstream buffers per fd_ringbuffer. So in the future the old ringmarker related APIs will be deprecated in a few releases. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Rob Clark authored
No need for it to deal with ringmarkers. Signed-off-by: Rob Clark <robclark@freedesktop.org>
-
Emil Velikov authored
Print out the node we're attempting to open and a message if/why we fail to do so. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emil Velikov authored
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
-
When in multi GPU case, devices array may have some NULL "hole" in between two devices. So check all array elements and free non-NULL device. Signed-off-by: Qiang Yu <Qiang.Yu@amd.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Currently drmGetDevice always returns the first device it finds under /dev/dri/. Move the target device to the start of the list during iteration. This way during deduplication it'll preserve its place and will be returned to the user. v2: Keep the memory leak separate. v3: Move the drmFoldDuplicatedDevices description Signed-off-by: Qiang Yu <Qiang.Yu@amd.com> [Emil Velikov: move drmFoldDuplicatedDevices description, add changelog, reword commit message] Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
-
Emma Anholt authored
Signed-off-by: Eric Anholt <eric@anholt.net>
-
- Jul 15, 2016
-
-
Emma Anholt authored
This also brings over the C++ guard introduced recently in the kernel headers. Signed-off-by: Eric Anholt <eric@anholt.net>
-
- Jul 06, 2016
-
-
This header provides major/minor/makedev funcs under most Linux C libs. Pull it in to fix building with newer versions that drop the implicit include via sys/types.h. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94231 Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Remove whitespace at the end of line.
-
AOSP master now errors if LOCAL_SRC_FILES contains headers, so filter out header files from the source lists. Signed-off-by: Rob Herring <robh@kernel.org>
-
- Jun 29, 2016
-
-
Rodrigo Vivi authored
This is unusual. Usually IDs listed on early stages of platform definition are kept there as reserved for later use. However these IDs here are not listed anymore in any of steppings and devices IDs tables for Kabylake on configurations overview section of BSpec. So it is better removing them before they become used in any other future platform. v2: Rebase. Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-