OpenCL 1.2 CL_MAP_WRITE_INVALIDATE_REGION sounds a lot like
PIPE_TRANSFER_DISCARD_RANGE:
>From OpenCL 1.2 spec:
The contents of the region being mapped are to be discarded.
>From p_defines.h:
Discards the memory within the mapped region.
v2: Move the code for validating flags to the fron
OpenCL 1.2 CL_MAP_WRITE_INVALIDATE_REGION sounds a lot like
PIPE_TRANSFER_DISCARD_RANGE:
>From OpenCL 1.2 spec:
The contents of the region being mapped are to be discarded.
>From p_defines.h:
Discards the memory within the mapped region.
---
src/gallium/state_trackers/clover/core/resourc
---
NOTE: if the two patches I have just send for tracking how buffers are mapped
are good, we may drop the last item from the TODO list.
src/gallium/drivers/r600/compute_memory_pool.c | 47 ++
1 file changed, 47 insertions(+)
diff --git a/src/gallium/drivers/r600/com
This patch adds a new struct: r600_transfer_global. It will
act as a wrapper around an r600_resource_global and an r600_transfer.
It will be used for calling r600_compute_global_transfer_unmap when
transfer_unmap is called. And at the same time, keep all the transfer
information, so we can call r6
try to unmap
an item, so we can decrement the map count.
Patch 2 is a bit of hack that seems to work, but any suggestions about
it are welcomed.
Thanks in advance!
Bruno
Bruno Jiménez (2):
r600g/compute: Add a member to the items to track how many maps it has
r600g/compute: Decrement map_count
This will be necessary to know how many mappings for read it has, as
the spec allows to have as many as desired.
---
src/gallium/drivers/r600/compute_memory_pool.c | 5 +++--
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
src/gallium/drivers/r600/evergreen_compute.c | 3 +--
3 files chang
I have followed the following convention:
- Positions in the pool are now 'int' (start_in_dw and related)
- Sizes are 'unsigned' (size_in_dw and related)
- IDs are 'unsigned'
The pool and item's status are left as uint32_t
The shadow has been also left as a pointer to an uint32_t
---
src/gallium/
v2: Add information about the item's starting point and size
v3: Rebased on top of master
---
src/gallium/drivers/r600/compute_memory_pool.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r6
v2: Rebased on top of master
---
src/gallium/drivers/r600/compute_memory_pool.c | 59 +-
src/gallium/drivers/r600/compute_memory_pool.h | 58 -
2 files changed, 86 insertions(+), 31 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_p
v2: Remove unnecesary variables
---
src/gallium/drivers/r600/compute_memory_pool.c | 31 +-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/
This will be used in the following patch to avoid duplicated code
---
src/gallium/drivers/r600/compute_memory_pool.c | 11 ++-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.
e
resource, data and garbage at the same time.
The fallback path for grow+defrag isn't very good, but hopefully
it won't be used much.
As usual, if you have any doubt about any of the patches, just ask.
Thanks in advance!
Bruno
Bruno Jiménez (3):
r600g/compute: Allow compute_memory_
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, bu
---
src/gallium/drivers/r600/compute_memory_pool.c | 43 ++
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool
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 fail
efer the first version of the
defragmenter, just ask. [In fact, after having written this,
I may add it for the case grow+defrag]
Also, no regressions found in piglit.
Thanks in advance!
Bruno
Bruno Jiménez (5):
r600g/compute: Add a function for moving items in the pool
r600g/compute: Add a f
This way we can avoid defragmenting the pool, even if it is needed
to defragment it, and looping again through the list of unallocated
items.
---
src/gallium/drivers/r600/compute_memory_pool.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b
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
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.
---
src/gallium/drivers/r600/c
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 witho
v2: Add information about the item's starting point and size
---
src/gallium/drivers/r600/compute_memory_pool.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 1d0ec85..6a525cf 10064
---
src/gallium/drivers/r600/compute_memory_pool.c | 54
src/gallium/drivers/r600/compute_memory_pool.h | 58 --
2 files changed, 83 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r
---
src/gallium/drivers/r600/compute_memory_pool.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 1d0ec85..6d47b1a 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/src/
Now, before moving everything to host memory, we try to create a
new resource to use as a pool. I we succeed we just use this resource
and delete the previous one. If we fail we fallback to using the
shadow.
This should make growing the pool faster, and we can also save
64KB of memory that were al
From: Jan Vesely
Signed-off-by: Jan Vesely
CC: Bruno Jimenez
---
src/gallium/drivers/r600/evergreen_compute.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index c0dd0f3..5c11
From: Jan Vesely
The important part is the change of the condition to <= 0. Otherwise the loop
gets stuck never actually growing the pool.
The change in the aux-need calculation guarantees max 2 iterations, and
avoids wasting memory in case a smaller item can't fit into a relatively larger
pool.
For the first use of a buffer, we will only need the temporary
resource in the case that a user wants to write/map to this buffer.
But in the cases where the user creates a buffer to act as an
output of a kernel, then we were creating an unneeded resource,
because it will contain garbage, and woul
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
---
src/gallium/drivers/r600/compute_memory_pool.h | 7 ++-
src/gallium/drivers/r600/evergreen
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: T
Note: This is just a proof of concept.
---
src/gallium/state_trackers/clover/api/transfer.cpp | 4 ++--
src/gallium/state_trackers/clover/core/object.hpp | 4
src/gallium/state_trackers/clover/core/resource.cpp | 2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gall
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
---
src/gallium/drivers/r600/compute_memory_pool.c | 51 ++
src/gallium/drivers/r600/c
---
src/gallium/drivers/r600/compute_memory_pool.c | 146 +++--
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
2 files changed, 91 insertions(+), 60 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_poo
All the *Enqueue* functions that read/write buffers (except
clEnqueueCopyBuffer) would map the associated resource, making
it to be demoted if it was in the pool.
But we possitively know that this transfer will end before
any kernel is launched, so there's no need to demote it.
---
src/gallium/dr
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)
---
src/gallium/drivers/r600/compute_memory_pool.c | 99 +-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 49 insertions(+),
Acording to the OpenCL spec, it is possible to have a buffer mapped
for reading and at read from it using commands or buffers.
With this we can keep the mapping (that exists against the
temporary item) and read with a kernel (from the item we have
just added to the pool) without problems.
---
src
With this we can assure that mapped buffers will never change
its position when relocating the pool.
This patch should finally solve the mapping bug.
v2: Use the new is_item_in_pool util function,
as suggested by Tom Stellard
---
src/gallium/drivers/r600/evergreen_compute.c | 10 --
7;s side it introduces and uses
'CLOVER_TRANSFER_MAP_DIRECTLY' so it doesen't collide with
any other OpenCL flag.
Please review and Thanks :)
Bruno Jiménez (11):
r600g/compute: Add an intermediate resource for OpenCL buffers
r600g/compute: Add an util function to know if an item is in
Every item that has been placed in the pool must have start_in_dw
different from -1.
---
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index e9
---
src/gallium/drivers/r600/compute_memory_pool.c | 147 +++--
src/gallium/drivers/r600/compute_memory_pool.h | 10 +-
2 files changed, 46 insertions(+), 111 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_p
---
src/gallium/drivers/r600/compute_memory_pool.c | 140 +++--
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
2 files changed, 87 insertions(+), 58 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_poo
With this we can assure that mapped buffers will never change
its position when relocating the pool.
This patch should finally solve the mapping bug.
---
src/gallium/drivers/r600/evergreen_compute.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers
This function will be used when we want to map an item
that it's already in the pool.
---
src/gallium/drivers/r600/compute_memory_pool.c | 45 ++
src/gallium/drivers/r600/compute_memory_pool.h | 3 ++
2 files changed, 48 insertions(+)
diff --git a/src/gallium/drivers/r600
AP_WRITE_INVALIDATE_REGION
Please review and Thanks :)
Bruno Jiménez (9):
r600g/compute: Add an intermediate resource for OpenCL buffers
r600g/compute: Add statuses to the compute_memory_items
r600g/compute: divide the item list in two
r600g/compute: only move to the pool the buffers marked for
---
src/gallium/drivers/r600/compute_memory_pool.c | 158 -
1 file changed, 78 insertions(+), 80 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 624b50d..26b9f98 100644
--- a/src/gallium/drive
These statuses will help track whether the items are mapped
or if they should be promoted to or demoted from the pool
---
src/gallium/drivers/r600/compute_memory_pool.h | 7 ++-
src/gallium/drivers/r600/evergreen_compute.c | 12
2 files changed, 18 insertions(+), 1 deletion(-)
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)
---
src/gallium/drivers/r600/compute_memory_pool.c | 99 +-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 49 insertions(+),
Acording to the OpenCL spec, it is possible to have a buffer mapped
for reading and at read from it using commands or buffers.
With this we can keep the mapping (that exists against the
temporary item) and read with a kernel (from the item we have
just added to the pool) without problems.
---
src
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: T
All the *Enqueue* functions that read/write buffers (except
clEnqueueCopyBuffer) would map the associated resource, making
it to be demoted if it was in the pool.
But we possitively know that this transfer will end before
any kernel is launched, so there's no need to demote it.
NOTE: As a proof o
v2:
Add RADEON_INFO_ACTIVE_CU_COUNT as a define, as suggested by
Tom Stellard
---
src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 7 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
3 files changed, 15 inser
That commit made possible that the items could be one just
after the other when their size was a multiple of ITEM_ALIGNMENT.
But compute_memory_prealloc_chunk still looked to leave a gap
between items. Resulting in that we got an infinite loop when
trying to add an item which would left no space be
2 is very big, and has a lot of comments about the data found in
said reference. For some of the chips, more than one number was listed
depending on the exact card, and I have chosen to return the lower one.
Thanks!
Bruno
Bruno Jiménez (3):
gallium: Add PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS
r
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index b292257..dde2c38 100644
--- a/src/gallium/docs/source/screen.r
The data has been extracted from:
AMD Accelerated Parallel Processing OpenCL Programming Guide (rev 2.7)
Appendix D: Device Parameters
---
src/gallium/drivers/radeon/r600_pipe_common.c | 90 +++
1 file changed, 90 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_
---
src/gallium/state_trackers/clover/api/device.cpp | 2 +-
src/gallium/state_trackers/clover/core/device.cpp | 6 ++
src/gallium/state_trackers/clover/core/device.hpp | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/device.cpp
b/src
some way of solving both bugs.
Thanks!
Bruno
Bruno Jiménez (1):
r600g/compute: solve the mapping bug
src/gallium/drivers/r600/compute_memory_pool.c | 21 -
src/gallium/drivers/r600/compute_memory_pool.h | 2 ++
src/gallium/drivers/r600/evergreen_compute.c
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.
This al
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
---
src/gallium/drivers/r600/compute_memory_pool.c | 30 --
src/ga
This fixes an issue when running cl-program-bitcoin-phatk
piglit test where some of the inputs have negative values
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drive
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
---
src/gallium/
Now, items whose size is a multiple of 1024 dw won't leave
1024 dw between itself and the following item
The rest of the cases is left as it was
---
src/gallium/drivers/r600/compute_memory_pool.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600
Explanation of the changes, as requested by Tom Stellard:
Let's take need after is calculated as
item->size_in_dw+2048 - (pool->size_in_dw - allocated)
BEFORE:
If need is positive or 0:
we calculate need += 1024 - (need % 1024), which is like
cealing to the nearest multiple of 1024, f
---
src/gallium/drivers/r600/compute_memory_pool.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index ccbb211..7143545 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/s
Hi,
Firstly, I shall introduce myself (at least more formally than just
sending some patches). My name is Bruno Jiménez, I'm studying
physics at Zaragoza's University (Spain) and I am participating in
this year's Google Summer of Code, where I will try to improve
the compute_memory
---
src/gallium/drivers/r600/compute_memory_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 2f0d4c8..ccbb211 100644
--- a/src/gallium/drivers/r600/compute_memory_po
From: Tom Stellard
v2: Updated the docs
v3: Remove trailing comma
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
From: Tom Stellard
v2: PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY instead of
PIPE_COMPUTE_MAX_CLOCK_FREQUENCY
Signed-off-by: Igor Gnatenko
clover: Correct the returned value for max_clock_frequency
According to OpenCL 1.1 spec, the returned value must be in MHz, and we
were returning it in kHz
From: Tom Stellard
v2: in define RADEON_INFO_MAX_SCLK use 0x1a instead of 0x19 (upstream changes)
Signed-off-by: Igor Gnatenko
r600: Correct the case MAX_CLOCK_FREQUENCY in get_compute_param
v3: Convert the frequency to MHz from kHz after getting it in
'do_winsys_init'
---
src/gallium/driver
From: Tom Stellard
v2: Updated the docs
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 5c255d0..3f38b28 100
This series is based in Tom Stellard's 'clover-clock' branch:
http://cgit.freedesktop.org/~tstellar/mesa/log/?h=clover-clock
And should fix this bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=73511
The only changes from the original branch are in patches 2 and 3.
Patch 2 has been updated
From: Tom Stellard
---
src/gallium/include/pipe/p_defines.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index a3a1ae1..93f9642 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/galliu
From: Tom Stellard
v2: in define RADEON_INFO_MAX_SCLK use 0x1a instead of 0x19 (upstream changes)
Signed-off-by: Igor Gnatenko
r600: Correct the case MAX_CLOCK_FREQUENCY in get_compute_param
---
src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
src/gallium/winsys/radeon/drm/radeo
From: Tom Stellard
v2: PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY instead of
PIPE_COMPUTE_MAX_CLOCK_FREQUENCY
Signed-off-by: Igor Gnatenko
clover: Correct the returned value for max_clock_frequency
According to OpenCL 1.1 spec, the returned value must be in MHz, and we
were returning it in kHz
This series is based in Tom Stellard's 'clover-clock' branch:
http://cgit.freedesktop.org/~tstellar/mesa/log/?h=clover-clock
And should fix this bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=73511
The only changes from the original branch are in patches 2 and 3.
Patch 2 has been updated
This way, we are left with only the preprocessor flags and '-std=X'
---
configure.ac | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 5b86141..2378d00 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1542,8 +1542,15 @@ strip_unwanted_llv
---
src/gallium/state_trackers/clover/Makefile.am | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/clover/Makefile.am
b/src/gallium/state_trackers/clover/Makefile.am
index ece2b38..75eae86 100644
--- a/src/gallium/state_trackers/clover/Makefile.a
Recently, llvm has changed to use c++11, so we also should use it
---
src/gallium/state_trackers/clover/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/Makefile.am
b/src/gallium/state_trackers/clover/Makefile.am
index ece2b38..
Explanation of the changes, as requested by Tom Stellard:
Let's take need after is calculated as
item->size_in_dw+2048 - (pool->size_in_dw - allocated)
BEFORE:
If need is positive or 0:
we calculate need += 1024 - (need % 1024), which is like
cealing to the nearest multiple of 1024, f
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
---
src/gallium/
---
src/gallium/drivers/r600/compute_memory_pool.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 7a7b057..da351d8 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/s
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
---
src/gallium/drivers/r600/compute_memory_pool.c | 30 --
src/ga
Hope I got everything right this time.
Thanks a lot to Marek Olšák for all the help!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
---
src/gallium/drivers/r600/compute_memory_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index fd3a04c..7a7b057 100644
--- a/src/gallium/drivers/r600/compute_memory_po
---
src/gallium/drivers/r600/compute_memory_pool.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 7a7b057..da351d8 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/s
Explanation of the changes, as requested by Tom Stellard:
Let's take need after is calculated as
item->size_in_dw+2048 - (pool->size_in_dw - allocated)
BEFORE:
If need is positive or 0:
we calculate need += 1024 - (need % 1024), which is like
cealing to the nearest multiple of 1024, f
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
---
src/gallium/drivers/r600/compute_memory_pool.c | 30 --
src/ga
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
---
src/gallium/
Hi,
Third version of the patches.
Now with r600g in the commit messages.
Patches 2 and 3 have spaces between 'if' and '('.
Patches 1,4 and 5 are the same.
Thanks!
[PATCH 1/5] [r600g] Fixing a typo and some indentation
[PATCH 2/5] [r600g] Adding checks for NULL after CALLOC
[PATCH 3/5] [r600g] A
---
src/gallium/drivers/r600/compute_memory_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index fd3a04c..7a7b057 100644
--- a/src/gallium/drivers/r600/compute_memory_po
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
---
src/gallium/
---
src/gallium/drivers/r600/compute_memory_pool.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 7a7b057..62d1a5c 100644
--- a/src/gallium/drivers/r600/compute_memory_pool.c
+++ b/s
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
---
src/gallium/drivers/r600/compute_memory_pool.c | 30 --
src/ga
Explanation of the changes, as requested by Tom Stellard:
Let's take need after is calculated as
item->size_in_dw+2048 - (pool->size_in_dw - allocated)
BEFORE:
If need is positive or 0:
we calculate need += 1024 - (need % 1024), which is like
cealing to the nearest multiple of 1024, f
Hi,
This is the second version of my previous patches.
I have cleaned a bit compute_memory_pool.c, added some
NULL checks to the code, corrected a typo and removed
an unneeded decraration of a function.
Patches 1 and 2 are the same.
Patch 3 changes Returns to @returns so doxygen can
parse it
---
src/gallium/drivers/r600/compute_memory_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index fd3a04c..7a7b057 100644
--- a/src/gallium/drivers/r600/compute_memory_po
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
---
src/gallium/drivers/r600/compute_memory_pool.c | 30 --
src/ga
Hi,
I have cleaned a bit compute_memory_pool.c, added some
NULL checks to the code, corrected a typo and removed
an unneeded decraration of a function.
Sorry if I got something wrong, this is the first
time I contribute to a project.
Thanks in advance!
[PATCH 1/5] Fixing a typo and some ind
---
src/gallium/drivers/r600/compute_memory_pool.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 5374a48..954c890 100644
--- a/src/gallium/drivers/r600/c
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.
---
src/gallium/drivers/r600/compute_memory_pool.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/r600/comp
---
src/gallium/drivers/r600/compute_memory_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index fd3a04c..7a7b057 100644
--- a/src/gallium/drivers/r600/compute_memory_po
1 - 100 of 101 matches
Mail list logo
