| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
They're not used anywhere else, so keep them private
Signed-off-by: Aaron Watry <[email protected]>
Reviewed-by: Jan Vesely <[email protected]>
|
| |
|
|
|
| |
Signed-off-by: Aaron Watry <[email protected]>
Reviewed-by: Jan Vesely <[email protected]>
|
| |
|
|
|
|
| |
v2: Rebased on top of master
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows us two things: we now need less item copies when we have
to defrag+grow the pool (to just one copy per item) and, even in the
case where we don't need to defrag the pool, we reduce the data copied
to just the useful data that the items use.
Note: The fallback path is a bit ugly now, but hopefully we won't need
it much.
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
| |
This will be used in the following patch to avoid duplicated code
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
| |
v2: Remove unnecesary variables
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that we know that the pool is defragmented, we positively know
that allocated + unallocated will be the total size of the
current pool plus all the items that will be promoted. So we only
need to grow the pool once.
This will allow us to just add the new items to the end of the
item_list without the need of looking for a place to the new item.
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new member to the pool to track its status.
For now it is used only for the 'fragmented' status, but if
needed it could be used for more statuses.
The pool will be considered fragmented if: An item that isn't
the last is freed or demoted.
This 'strategy' has a problem, although it shouldn't cause any bug.
If for example we have two items, A and B. We choose to free A first,
now the pool will have the 'fragmented' status. If we now free B,
the pool will retain its 'fragmented' status even if it isn't
fragmented.
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
This new function will move items forward in the pool, so that
there's no gap between them, effectively defragmenting the pool.
For now this function is a bit dumb as it just moves items
forward without trying to see if other items in the pool could
fit in the gaps.
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function will be used in the future by compute_memory_defrag
to move items forward in the pool.
It does so by first checking for overlaping ranges, if the ranges
don't overlap it will copy the contents directly. If they overlap
it will try first to make a temporary buffer, if this buffer fails
to allocate, it will finally fall back to a mapping.
Note that it will only be needed to move items forward, it only
checks for overlapping ranges in that case. If needed, it can
easily be added by changing the first if.
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
| |
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This function will be used when we want to map an item
that it's already in the pool.
v2: Use temporary variables to avoid so many castings in functions,
as suggested by Tom Stellard
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
| |
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
| |
Now we will have a list with the items that are in the pool
(item_list) and the items that are outside it (unallocated_list)
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
These statuses will help track whether the items are mapped
or if they should be promoted to or demoted from the pool
v2: Use the new is_item_in_pool util function,
as suggested by Tom Stellard
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
| |
Every item that has been placed in the pool must have start_in_dw
different from -1.
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes completely the way buffers are added to the
compute_memory_pool. Before this, whenever we were going to
map a buffer or write to or read from it, it would get placed
into the pool. Now, every unallocated buffer has its own
r600_resource until it is allocated in the pool.
NOTE: This patch also increase the GPU memory usage at the moment
of putting every buffer in it's place. More or less, the memory
usage is ~2x(sum of every buffer size)
v2: Cleanup
v3: Use temporary variables to avoid so many castings in functions,
as suggested by Tom Stellard
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Removed compute_memory_defrag declaration because it seems
to be unimplemented.
I think that this function would have been the one that solves
the problem with fragmentation that compute_memory_finalize_pending has.
Also removed comments that are already at compute_memory_pool.c
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
In this case, NULL checks are added to compute_memory_grow_pool,
so it returns -1 when it fails. This makes necesary
to handle such cases in compute_memory_finalize_pending
when it is needed to grow the pool
Reviewed-by: Tom Stellard <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code for growing the memory pool (which is used for storing all of
the global buffers) wasn't working. There seem to be two separate issues
with the memory pool code. The first was the way it was growing the pool.
When the memory pool needed more space, it would:
1. Copy the data from the memory pool's backing texture to system memory.
2. Delete the memory pool's texture
3. Create a bigger backing texture for the memory pool.
4. Copy the data from system memory into the bigger texture.
The copy operations didn't seem to be working, and I suspect that since
they were using fragment shaders to do the copy, that there might have
been a problem with the mixing of compute and 3D state.
The other issue is that the size of 1D textures is limited, and I was
having trouble getting 2D textures to work.
I think these problems will be easier to solve once more code is shared
between 3D and compute, which is why I decided to disable it for now
rather than continue searching for a fix.
|
|
|
Tom Stellard:
- Updated for gallium interface changes
- Fixed a few bugs:
+ Set the loop counter
+ Calculate the correct number of pipes
- Added hooks into the LLVM compiler
|
