| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Add comments about the parameters to drm_bo_do_validate, along
with comments for the DRM_BO_HINT options. Remove the 'do_wait'
parameter as it is duplicated by DRM_BO_HINT_DONT_BLOCK.
|
|
One of the costs of superioctl has been the need to perform relocations
inside the kernel. The cost of mapping the buffers to the CPU and writing
data is fairly high, especially if those buffers have been mapped and read
by the GPU.
If we assume that buffers don't move around very often, we can have the
client compute the relocations itself using the previous GPU address. When
that object doesn't move, the kernel can skip computing and writing the
updated data.
Here's a patch which adds a new field to struct drm_bo_info_req called
'presumed_offset', and a new DRM_BO_HINT_PRESUMED_OFFSET that is set when
this field has been filled in by the client.
There are two separate optimizations performed when the presumed_offset is
correct:
1. i915_exec_reloc checks to see if all previous buffer offsets were guessed
correctly. If so, there's no need for it to look at *any* of the
relocations for a buffer. When this happens, it skips the whole
relocation process, simply returning success.
2. i915_apply_reloc checks to see if the target buffer offset was guessed
correctly. If so, it skips mapping the relocatee, computing the
relocation and writing the value. If no relocations are needed, the
relocatee should never be mapped to the CPU, and so the kernel shouldn't
need to wait for any fences to pass.
|
|
This flag indicates that the driver is responsible for the map.
|
|
|
|
Kernel "cleanfile" script run.
|
|
This mapping allows cached objects to be mapped in/out of the TT space
with the appropriate flushing calls.
It should put back the old CACHED functionality for snooped mappings
|
|
|
|
Set bo init minor to 0.
Add the version function to header.
|
|
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.
|
|
Add interface entry cleaning a memory type without touching NO_EVICT buffers.
|
|
Fix i915 since last commit.
|
|
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.
|
|
set pinning."
This reverts cf2d569daca6954d11a796f4d110148ae2e0c827 commit.
|
|
This reverts e7bfeb3031374653f7e55d67cc1b5c823849359f commit.
|
|
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.
|
|
|
|
Conflicts:
linux-core/drm_bo.c
linux-core/drm_fence.c
linux-core/drm_objects.h
shared-core/drm.h
|
|
|
|
Modify the TTM backend bind arguments.
Export a number of functions needed for driver-specific super-ioctls.
Add a function to map buffer objects from the kernel, regardless of where they're
currently placed.
A number of error fixes.
|
|
|
|
|
|
|
|
This cleans up the create/validate interfaces for this very uncommon path, and
makes pinned object creation much easier to use for the X Server.
|
|
|
|
This might break something, stdint.h inclusion in drm.h maybe required
but I'm not sure yet what platforms have it what ones don't.
|
|
|
|
|
|
|
|
|
|
|
|
Introduce tile members for future tiled buffer support.
Allow user-space to explicitly define a fence-class.
Remove the implicit fence-class mechanism.
64-bit wide buffer object flag member.
|
|
retain the op operation for validate/fence operations
|
|
This just cleans up the xf86drm.c to what I want and drm.h,
I need to fix up the kernel internals to suit these changes now.
I've moved to using struct instead of typedefs for the bo and it doesn't look
that bad so I'll do the same thing for mm and fence..
|
|
|
|
This is the first bunch of ioctls
|
|
|
|
The xserver no longer uses the libc-wrapper.
|
|
a user mapping.
(cherry picked from commit 2e21779992bd5026d8ec4dea52466377dbe5a0ed)
|
|
|
|
|
|
|
|
Used to request that a scheduled buffer swap be done as a flip instead of a
blit.
|
|
|
|
|
|
|
|
Flag handling and memory type selection cleanup.
glxgears won't start.
|
|
Memory types are either fixed (on-card or pre-bound AGP) or not fixed
(dynamically bound) to an aperture. They also carry information about:
1) Whether they can be mapped cached.
2) Whether they are at all mappable.
3) Whether they need an ioremap to be accessible from kernel space.
In this way VRAM memory and, for example, pre-bound AGP appear
identical to the memory manager.
This also makes support for unmappable VRAM simple to implement.
|
|
|
