Relocation now consist of the following informations (in this order) :
handle buffer object handle identifier
start_offset start offset of first data of the buffer object used by the cs
end_offset end offset of last data of the buffer object used by the cs
read_domain read domain (either VRAM, or GTT as GPU is invalid for CS)
write_domain write domain (either VRAM, or GTT as GPU is invalid for CS)
flags flags used for further optimization (like discard previous
buffer content or forget buffer content after cs which can
help in avoiding moving content in or out)
I wanted to avoid doing this, as it's a bunch of churn, but there was a
conflict between the dri_ symbols in libdrm and the symbols that were in
Mesa in 7.2, which broke Mesa 7.2 AIGLX when the 2D driver had loaded new
libdrm symbols. The new naming was recommended by cworth for giving the
code a unique prefix identifying where the code lives.
Additionally, take the opportunity to fix up two API mistakes: emit_reloc's
arguments were in a nonsensical order, and set_tiling lacked the stride
argument that the kernel will want to use soon. API compatibility with
released code is maintained using #defines.
This relies on a new kernel ioctl to get the available aperture size.
In order to provide reasonable performance from dri_bufmgr_check_aperture, we
now require that once a buffer has been used as the target of a relocation,
it gets no further relocations added to it. This cuts the cost of
check_aperture from 10% to 1% in the 3D driver with no code changes, but
slightly complicates our plans for the 2D driver.
Don't count on ioctl returning -errno; use errno directly.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
We want to be able to use the bufmgr from multiple threads for GL, and thus
we need to protect the internal structures.
The pthread-stubs package is used so that programs not linked against
pthreads get weak symbols to stubs and don't eat most of the cost.
When using bufmgr_fake without DRM, the X server idles the ring whenever it
wants to wait for something to complete (brutal, but effective). In this
case, bufmgr_fake must treat the pending fence as having passed. However, it
wasn't recording the fences as it emitted them, nor cleaning buffers as they
passed.
Signed-off-by: Keith Packard <keithp@keithp.com>
We want to be able to use the bufmgr from multiple threads for GL, and thus
we need to protect the internal structures.
The pthread-stubs package is used so that programs not linked against
pthreads get weak symbols to stubs and don't eat most of the cost.
We need a way of getting at the underlying handle for use with mode
setting. We can either export it in the dri_bo object or provide a new
callback to get it.
I'd swapped the operands, so if we weren't in lockstep with the hardware we
said the sequence was always passed. Additionally, a race was available that
we might have failed at recovering from. Instead, I've replaced the logic
with new stuff that should be more robust and not rely on all the parties in
userland following the same IRQ_EMIT() == 1 protocol. Also, in a radical
departure from past efforts, include a long comment describing the failure
modes and how we're working around them.
Thanks to haihao for catching the original issue.
dri_bufmgr.h is replaced by intel_bufmgr.h, and several functions are renamed,
though the structures and many functions remain dri_bufmgr_* and dri_bo_*
This patch allows you to --enable-udev, and will avoid having libdrm
make device nodes. If you are using udev, you should really --enable-udev
your libdrm.
This resolves and issue on amd64 FreeBSD and it looks like the
linux ioctl syscall should be unsigned long as well.
Signed-off-by: Robert Noland <rnoland@2hip.net>
When a software fallback has completed, usermode must notify the kernel so
that any scanout buffers can be synchronized. This ioctl should be called
whenever a fallback completes to flush CPU and chipset caches.
Lots of conflicts, seems to load ok, but I'm sure some bugs snuck in.
Conflicts:
linux-core/drmP.h
linux-core/drm_lock.c
linux-core/i915_gem.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
Thanks to Thomas Hellstrom for catching the issue, no thanks to the kernel
developer who authoritatively told me that they would get restarted on their
own.
This is the create (may want location flags), pread/pwrite/mmap
(performance tuning hints), and set_domain (will 32 bits be enough for
everyone?) ioctls. Left in the generic set are just flink/open/close.
The 2D driver must be updated for this change, and API but not ABI is broken
for 3D. The driver version is bumped to mark this.
The code was discarding the dri_bo_gem structure and saving only the kernel
handle. This lost the mmap address, causing pain when the next buffer user
wanted to map the buffer.
Idea being if you want to add new crtc/output/encoder dynamically later,
you just increase the generation counter and userspace should re-read
all the resources
Okay we have crtc, encoder and connectors.
No more outputs exposed beyond driver internals
I've broken intel tv connector stuff.
Really for TV we should have one TV connector, with a sub property for the
type of signal been driven over it
Flags pending validation were stored in a misleadingly named field, 'mask'.
As 'mask' is already used to indicate pieces of a flags field which are
changing, it seems better to use a name reflecting the actual purpose of
this field. I chose 'proposed_flags' as they may not actually end up in
'flags', and in an case will be modified when they are moved over.
This affects the API, but not ABI of the user-mode interface.
so really want to get a list of modes per output not the global hammer list.
also we remove the mode ids and let the user pass back the full mode description
need to fix up add/remove mode for user modes now
This allow the user to retrieve a list of properties for an output.
Properties can either be 32-bit values or an enum with an associated name.
Range properties are to be supported.
This API is probably not all correct, I may make properties part of the general
resource get when I think about it some more.
So basically you can create properties and attached them to whatever outputs you want,
so it should be possible to create some generics and just attach them to every output.
Implement a version check IOCTL for drivers that don't use
drmMMInit from user-space.
Remove the minor check from the kernel code. That's really up
to the driver.
Bump major.
Remove need for lock for now.
May create races when we clean memory areas or on takedown.
Needs to be fixed.
Really do a validate on buffer creation in order to avoid problems with
fixed memory buffers.
We now always create a drm_ref_object for user objects and this is then the only
things that holds a reference to the user object. This way unreference on will
destroy the user object when the last drm_ref_object goes way.
The buffer object type is still tracked internally, but it is no longer
part of the user space visible ioctl interface. If the bo create ioctl
specifies a non-NULL buffer address we assume drm_bo_type_user,
otherwise drm_bo_type_dc. Kernel side allocations call
drm_buffer_object_create() directly and can still specify drm_bo_type_kernel.
Not 100% this makes sense either, but with this patch, the buffer type
is no longer exported and we can clean up the internals later on.
Jakob Bornecrantz
Jerome Glisse
Eric Anholt
Xiang, Haihao
Keith Packard
Dave Airlie
Julien Cristau
Jesse Barnes
Dave Airlie
Kristian Høgsberg
Coleman Kane
Matthieu Herrb
Maarten Maathuis
Jesse Barnes
Jesse Barnes
Thomas Hellstrom
Hasso Tepper
Dave Airlie
Alan Hourihane
Jakob Bornecrantz
Ben Skeggs