[Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-07 Thread Lauri Kasanen 
v2: Moved the high priority check to r600_texture_create_object

Signed-off-by: Lauri Kasanen c...@gmx.com
---
 src/gallium/drivers/r600/r600_state_common.c| 2 +-
 src/gallium/drivers/radeon/r600_buffer_common.c | 6 --
 src/gallium/drivers/radeon/r600_pipe_common.h   | 3 ++-
 src/gallium/drivers/radeon/r600_texture.c   | 9 -
 src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c   | 4 
 src/gallium/winsys/radeon/drm/radeon_drm_bo.h   | 1 +
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c   | 2 +-
 src/gallium/winsys/radeon/drm/radeon_winsys.h   | 2 ++
 9 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index ba37af8..2f833ba 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -2106,7 +2106,7 @@ static void r600_invalidate_buffer(struct pipe_context 
*ctx, struct pipe_resourc
 
/* Create a new one in the same pipe_resource. */
r600_init_resource(rctx-screen-b, rbuffer, rbuffer-b.b.width0, 
alignment,
-  TRUE, rbuffer-b.b.usage);
+  TRUE, rbuffer-b.b.usage, FALSE);
 
/* We changed the buffer, now we need to bind it where the old one was 
bound. */
/* Vertex buffers. */
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index ac5fbcc..6083253 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -98,7 +98,8 @@ void *r600_buffer_map_sync_with_rings(struct 
r600_common_context *ctx,
 bool r600_init_resource(struct r600_common_screen *rscreen,
struct r600_resource *res,
unsigned size, unsigned alignment,
-   bool use_reusable_pool, unsigned usage)
+   bool use_reusable_pool, unsigned usage,
+   bool high_prio)
 {
uint32_t initial_domain, domains;
 
@@ -131,6 +132,7 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
 
res-buf = rscreen-ws-buffer_create(rscreen-ws, size, alignment,
   use_reusable_pool,
+  high_prio,
   initial_domain);
if (!res-buf) {
return false;
@@ -314,7 +316,7 @@ struct pipe_resource *r600_buffer_create(struct pipe_screen 
*screen,
rbuffer-b.vtbl = r600_buffer_vtbl;
util_range_init(rbuffer-valid_buffer_range);
 
-   if (!r600_init_resource(rscreen, rbuffer, templ-width0, alignment, 
TRUE, templ-usage)) {
+   if (!r600_init_resource(rscreen, rbuffer, templ-width0, alignment, 
TRUE, templ-usage, FALSE)) {
FREE(rbuffer);
return NULL;
}
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 4c35e66..75c78e3 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -278,7 +278,8 @@ void *r600_buffer_map_sync_with_rings(struct 
r600_common_context *ctx,
 bool r600_init_resource(struct r600_common_screen *rscreen,
struct r600_resource *res,
unsigned size, unsigned alignment,
-   bool use_reusable_pool, unsigned usage);
+   bool use_reusable_pool, unsigned usage,
+   bool high_prio);
 struct pipe_resource *r600_buffer_create(struct pipe_screen *screen,
 const struct pipe_resource *templ,
 unsigned alignment);
diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index caf3743..26c27c9 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -620,7 +620,14 @@ r600_texture_create_object(struct pipe_screen *screen,
unsigned usage = rtex-surface.level[0].mode = 
RADEON_SURF_MODE_1D ?
 PIPE_USAGE_STATIC : base-usage;
 
-   if (!r600_init_resource(rscreen, resource, rtex-size, 
base_align, FALSE, usage)) {
+   bool high_prio = false;
+
+   /* If it's depth or MSAA, consider it high priority */
+   if (rtex-is_depth || base-nr_samples  1)
+   high_prio = true;
+
+   if (!r600_init_resource(rscreen, resource, rtex-size,
+   base_align, FALSE, usage, high_prio)) {
FREE(rtex);
return NULL;
}
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index

[Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-06 Thread Lauri Kasanen 
Signed-off-by: Lauri Kasanen c...@gmx.com
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 8 
 src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c   | 4 
 src/gallium/winsys/radeon/drm/radeon_drm_bo.h   | 1 +
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c   | 2 +-
 src/gallium/winsys/radeon/drm/radeon_winsys.h   | 2 ++
 6 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index ac5fbcc..fb8005a 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -25,6 +25,7 @@
  */
 
 #include r600_cs.h
+#include util/u_format.h
 #include util/u_memory.h
 #include util/u_upload_mgr.h
 #include inttypes.h
@@ -101,6 +102,12 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
bool use_reusable_pool, unsigned usage)
 {
uint32_t initial_domain, domains;
+   bool high_prio = false;
+
+   /* If it's depth or MSAA, consider it high priority */
+   if (util_format_has_depth(util_format_description(res-b.b.format)) ||
+   res-b.b.nr_samples  1)
+   high_prio = true;
 
switch(usage) {
case PIPE_USAGE_STAGING:
@@ -131,6 +138,7 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
 
res-buf = rscreen-ws-buffer_create(rscreen-ws, size, alignment,
   use_reusable_pool,
+  high_prio,
   initial_domain);
if (!res-buf) {
return false;
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index 95757e3..1cc1997 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -168,7 +168,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
  struct ruvd_buffer *buffer,
  unsigned size)
 {
-   buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
+   buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false, true,
 RADEON_DOMAIN_GTT | 
RADEON_DOMAIN_VRAM);
if (!buffer-buf)
return false;
@@ -1008,7 +1008,7 @@ void ruvd_join_surfaces(struct radeon_winsys* ws, 
unsigned bind,
/* TODO: 2D tiling workaround */
alignment *= 2;
 
-   pb = ws-buffer_create(ws, size, alignment, bind, RADEON_DOMAIN_VRAM);
+   pb = ws-buffer_create(ws, size, alignment, bind, true, 
RADEON_DOMAIN_VRAM);
if (!pb)
return;
 
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 9aa1a0f..8a5eb6e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -651,6 +651,8 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
 else if (rdesc-initial_domains  RADEON_DOMAIN_GTT)
 rws-allocated_gtt += align(size, 4096);
 
+bo-stats.high_prio = rdesc-high_prio;
+
 if (ws-bo_stats_file) {
 fprintf(ws-bo_stats_file, %p created, size %u, prio %u, @%llu\n, 
bo, size,
bo-stats.high_prio, stats_time_get(ws));
@@ -871,6 +873,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
 unsigned size,
 unsigned alignment,
 boolean use_reusable_pool,
+boolean high_prio,
 enum radeon_bo_domain domain)
 {
 struct radeon_drm_winsys *ws = radeon_drm_winsys(rws);
@@ -885,6 +888,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
 /* Additional criteria for the cache manager. */
 desc.base.usage = domain;
 desc.initial_domains = domain;
+desc.high_prio = high_prio;
 
 /* Assign a buffer manager. */
 if (use_reusable_pool)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
index 651694b..e93e615 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
@@ -42,6 +42,7 @@ struct radeon_bo_desc {
 struct pb_desc base;
 
 unsigned initial_domains;
+bool high_prio;
 };
 
 struct radeon_bo_stats {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index f78b6cc..e18deb0 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -652,7 +652,7 @@ radeon_cs_create_fence(struct radeon_winsys_cs *rcs)
 struct pb_buffer *fence;
 
 /* Create a fence, which is a dummy BO. */
-fence = cs-ws-base.buffer_create(cs-ws-base, 1, 1, TRUE,
+fence =

Re: [Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-06 Thread Marek Olšák 
On Mon, Jan 6, 2014 at 12:18 PM, Lauri Kasanen c...@gmx.com wrote:
 Signed-off-by: Lauri Kasanen c...@gmx.com
 ---
  src/gallium/drivers/radeon/r600_buffer_common.c | 8 
  src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
  src/gallium/winsys/radeon/drm/radeon_drm_bo.c   | 4 
  src/gallium/winsys/radeon/drm/radeon_drm_bo.h   | 1 +
  src/gallium/winsys/radeon/drm/radeon_drm_cs.c   | 2 +-
  src/gallium/winsys/radeon/drm/radeon_winsys.h   | 2 ++
  6 files changed, 18 insertions(+), 3 deletions(-)

 diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
 b/src/gallium/drivers/radeon/r600_buffer_common.c
 index ac5fbcc..fb8005a 100644
 --- a/src/gallium/drivers/radeon/r600_buffer_common.c
 +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
 @@ -25,6 +25,7 @@
   */

  #include r600_cs.h
 +#include util/u_format.h
  #include util/u_memory.h
  #include util/u_upload_mgr.h
  #include inttypes.h
 @@ -101,6 +102,12 @@ bool r600_init_resource(struct r600_common_screen 
 *rscreen,
 bool use_reusable_pool, unsigned usage)
  {
 uint32_t initial_domain, domains;
 +   bool high_prio = false;
 +
 +   /* If it's depth or MSAA, consider it high priority */
 +   if (util_format_has_depth(util_format_description(res-b.b.format)) ||
 +   res-b.b.nr_samples  1)
 +   high_prio = true;

I think this is a wrong place to check for texture properties. It
should be in r600_texture_create_object.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-03 Thread Lauri Kasanen 
On Fri, 03 Jan 2014 01:37:22 +0100
Andreas Hartmetz ahartm...@gmail.com wrote:

  This boolean is just one component to be used in the final score (for
  the plan, see github.com/clbr/jamkthesis). It passes down information
  that's otherwise unavailable, ie whether the buffer's type means it
  should be more likely to stay in VRAM.
  
  The buffer's size and other factors (patch 3, VRAM size) also influence
  the score.
  
  The network won't care if it's a bool or an int, so the question is
  just whether having it an int would mean better decisions or not. What
  do you think?

 When you use a neural network anyway, why would you even assign a
 priority instead of just passing the buffer type and let the network
 figure out the rest?

It would greatly add complexity and thus runtime overhead. The type is
more than just one input, it would be around ~10 inputs more.

The other case is that simplifying it into one input means that all
paths will be tested by training data. With the full surface params, it
would be unlikely for all combinations to get tested, as even finding
apps that use rare combinations would be hard. Ie - less chance of bad
regressions.

 I am somewhat skeptical of the whole thing honestly, because
 predictable and repeatable performance is what you need for
 performance-critical applications, not getting close to optimal
 results most of the time and bad results sometimes.

Assuming wide enough training data, those bad results won't happen. I
agree though, Real World (tm) tends to interfere, but let's try to
minimize that ;)

 You also want good performance when you execute something for the
 first time (without training) because the first impression is so
 important.

This is a static network, ie no runtime changes, in order to minimize
runtime overhead and code complexity in mesa/kernel.

 Now I don't want to discourage you from doing that thesis, but I don't
 expect that a neural network buffer placement optimizer will be
 practical for shipping with Mesa. I would like to be proven wrong,
 though :)

In three months' time, we'll see :)

- Lauri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-03 Thread Lauri Kasanen 
Signed-off-by: Lauri Kasanen c...@gmx.com
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 8 
 src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c   | 4 
 src/gallium/winsys/radeon/drm/radeon_drm_bo.h   | 1 +
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c   | 2 +-
 src/gallium/winsys/radeon/drm/radeon_winsys.h   | 2 ++
 6 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index ac5fbcc..fb8005a 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -25,6 +25,7 @@
  */
 
 #include r600_cs.h
+#include util/u_format.h
 #include util/u_memory.h
 #include util/u_upload_mgr.h
 #include inttypes.h
@@ -101,6 +102,12 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
bool use_reusable_pool, unsigned usage)
 {
uint32_t initial_domain, domains;
+   bool high_prio = false;
+
+   /* If it's depth or MSAA, consider it high priority */
+   if (util_format_has_depth(util_format_description(res-b.b.format)) ||
+   res-b.b.nr_samples  1)
+   high_prio = true;
 
switch(usage) {
case PIPE_USAGE_STAGING:
@@ -131,6 +138,7 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
 
res-buf = rscreen-ws-buffer_create(rscreen-ws, size, alignment,
   use_reusable_pool,
+  high_prio,
   initial_domain);
if (!res-buf) {
return false;
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index 95757e3..1cc1997 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -168,7 +168,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
  struct ruvd_buffer *buffer,
  unsigned size)
 {
-   buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
+   buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false, true,
 RADEON_DOMAIN_GTT | 
RADEON_DOMAIN_VRAM);
if (!buffer-buf)
return false;
@@ -1008,7 +1008,7 @@ void ruvd_join_surfaces(struct radeon_winsys* ws, 
unsigned bind,
/* TODO: 2D tiling workaround */
alignment *= 2;
 
-   pb = ws-buffer_create(ws, size, alignment, bind, RADEON_DOMAIN_VRAM);
+   pb = ws-buffer_create(ws, size, alignment, bind, true, 
RADEON_DOMAIN_VRAM);
if (!pb)
return;
 
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 9aa1a0f..8a5eb6e 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -651,6 +651,8 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
 else if (rdesc-initial_domains  RADEON_DOMAIN_GTT)
 rws-allocated_gtt += align(size, 4096);
 
+bo-stats.high_prio = rdesc-high_prio;
+
 if (ws-bo_stats_file) {
 fprintf(ws-bo_stats_file, %p created, size %u, prio %u, @%llu\n, 
bo, size,
bo-stats.high_prio, stats_time_get(ws));
@@ -871,6 +873,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
 unsigned size,
 unsigned alignment,
 boolean use_reusable_pool,
+boolean high_prio,
 enum radeon_bo_domain domain)
 {
 struct radeon_drm_winsys *ws = radeon_drm_winsys(rws);
@@ -885,6 +888,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
 /* Additional criteria for the cache manager. */
 desc.base.usage = domain;
 desc.initial_domains = domain;
+desc.high_prio = high_prio;
 
 /* Assign a buffer manager. */
 if (use_reusable_pool)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
index 651694b..e93e615 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
@@ -42,6 +42,7 @@ struct radeon_bo_desc {
 struct pb_desc base;
 
 unsigned initial_domains;
+bool high_prio;
 };
 
 struct radeon_bo_stats {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index f78b6cc..e18deb0 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -652,7 +652,7 @@ radeon_cs_create_fence(struct radeon_winsys_cs *rcs)
 struct pb_buffer *fence;
 
 /* Create a fence, which is a dummy BO. */
-fence = cs-ws-base.buffer_create(cs-ws-base, 1, 1, TRUE,
+fence =

Re: [Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-02 Thread Lauri Kasanen 
On Thu, 02 Jan 2014 05:57:46 +0100
Andreas Hartmetz ahartm...@gmail.com wrote:

 On Wednesday 01 January 2014 16:58:46 Lauri Kasanen wrote:
  @@ -257,6 +258,7 @@ struct radeon_winsys {
  unsigned size,
  unsigned alignment,
  boolean use_reusable_pool,
  +   boolean high_prio,
  enum radeon_bo_domain domain);
  
   struct radeon_winsys_cs_handle *(*buffer_get_cs_handle)(
 
 Something I have learned about schedulers is that binary priorities
 are not a good deal. They kind of encourage special case hacks and
 two code paths, they can do less than numeric priorities, and they
 are not significantly easier to implement if you want to do it
 correctly. This is not exactly a scheduler, but it seems similar
 enough.
 So I think a numeric value and = 3 priorities would be better here,
 then you could also start assigning priority by things like buffer size
 or really any heuristic that can produce some number. Even such
 heuristics are easier to write when you don't need to limit the result
 to true / false.

Hi Andreas,

This boolean is just one component to be used in the final score (for
the plan, see github.com/clbr/jamkthesis). It passes down information
that's otherwise unavailable, ie whether the buffer's type means it
should be more likely to stay in VRAM.

The buffer's size and other factors (patch 3, VRAM size) also influence
the score.

The network won't care if it's a bool or an int, so the question is
just whether having it an int would mean better decisions or not. What
do you think?

- Lauri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-02 Thread Andreas Hartmetz 
On Thursday 02 January 2014 10:56:45 Lauri Kasanen wrote:
 On Thu, 02 Jan 2014 05:57:46 +0100
 
 Andreas Hartmetz ahartm...@gmail.com wrote:
  On Wednesday 01 January 2014 16:58:46 Lauri Kasanen wrote:
   @@ -257,6 +258,7 @@ struct radeon_winsys {
   
   unsigned size,
   unsigned alignment,
   boolean use_reusable_pool,
   
   +   boolean high_prio,
   
   enum radeon_bo_domain domain);

struct radeon_winsys_cs_handle *(*buffer_get_cs_handle)(
  
  Something I have learned about schedulers is that binary priorities
  are not a good deal. They kind of encourage special case hacks and
  two code paths, they can do less than numeric priorities, and they
  are not significantly easier to implement if you want to do it
  correctly. This is not exactly a scheduler, but it seems similar
  enough.
  So I think a numeric value and = 3 priorities would be better here,
  then you could also start assigning priority by things like buffer size
  or really any heuristic that can produce some number. Even such
  heuristics are easier to write when you don't need to limit the result
  to true / false.
 
 Hi Andreas,
 
 This boolean is just one component to be used in the final score (for
 the plan, see github.com/clbr/jamkthesis). It passes down information
 that's otherwise unavailable, ie whether the buffer's type means it
 should be more likely to stay in VRAM.
 
 The buffer's size and other factors (patch 3, VRAM size) also influence
 the score.
 
 The network won't care if it's a bool or an int, so the question is
 just whether having it an int would mean better decisions or not. What
 do you think?
 
When you use a neural network anyway, why would you even assign a
priority instead of just passing the buffer type and let the network
figure out the rest?
I am somewhat skeptical of the whole thing honestly, because
predictable and repeatable performance is what you need for
performance-critical applications, not getting close to optimal
results most of the time and bad results sometimes.
You also want good performance when you execute something for the
first time (without training) because the first impression is so
important. Resource planning isn't magic, you don't really need to
give up and use a generic AI to do it well.
I guess you can discover some tricks using that approach, but for a
final implementation you better incorporate those tricks into a more
traditional cache eviction algorithm.

Now I don't want to discourage you from doing that thesis, but I don't
expect that a neural network buffer placement optimizer will be
practical for shipping with Mesa. I would like to be proven wrong,
though :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-01 Thread Lauri Kasanen 
Signed-off-by: Lauri Kasanen c...@gmx.com
---
 src/gallium/drivers/radeon/r600_buffer_common.c | 8 
 src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
 src/gallium/winsys/radeon/drm/radeon_drm_bo.c   | 4 
 src/gallium/winsys/radeon/drm/radeon_drm_bo.h   | 1 +
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c   | 2 +-
 src/gallium/winsys/radeon/drm/radeon_winsys.h   | 2 ++
 6 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c 
b/src/gallium/drivers/radeon/r600_buffer_common.c
index ac5fbcc..fb8005a 100644
--- a/src/gallium/drivers/radeon/r600_buffer_common.c
+++ b/src/gallium/drivers/radeon/r600_buffer_common.c
@@ -25,6 +25,7 @@
  */
 
 #include r600_cs.h
+#include util/u_format.h
 #include util/u_memory.h
 #include util/u_upload_mgr.h
 #include inttypes.h
@@ -101,6 +102,12 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
bool use_reusable_pool, unsigned usage)
 {
uint32_t initial_domain, domains;
+   bool high_prio = false;
+
+   /* If it's depth or MSAA, consider it high priority */
+   if (util_format_has_depth(util_format_description(res-b.b.format)) ||
+   res-b.b.nr_samples  1)
+   high_prio = true;
 
switch(usage) {
case PIPE_USAGE_STAGING:
@@ -131,6 +138,7 @@ bool r600_init_resource(struct r600_common_screen *rscreen,
 
res-buf = rscreen-ws-buffer_create(rscreen-ws, size, alignment,
   use_reusable_pool,
+  high_prio,
   initial_domain);
if (!res-buf) {
return false;
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index 95757e3..1cc1997 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -168,7 +168,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
  struct ruvd_buffer *buffer,
  unsigned size)
 {
-   buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
+   buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false, true,
 RADEON_DOMAIN_GTT | 
RADEON_DOMAIN_VRAM);
if (!buffer-buf)
return false;
@@ -1008,7 +1008,7 @@ void ruvd_join_surfaces(struct radeon_winsys* ws, 
unsigned bind,
/* TODO: 2D tiling workaround */
alignment *= 2;
 
-   pb = ws-buffer_create(ws, size, alignment, bind, RADEON_DOMAIN_VRAM);
+   pb = ws-buffer_create(ws, size, alignment, bind, true, 
RADEON_DOMAIN_VRAM);
if (!pb)
return;
 
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 61d489c..a3751ff 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -651,6 +651,8 @@ static struct pb_buffer *radeon_bomgr_create_bo(struct 
pb_manager *_mgr,
 else if (rdesc-initial_domains  RADEON_DOMAIN_GTT)
 rws-allocated_gtt += align(size, 4096);
 
+bo-stats.high_prio = rdesc-high_prio;
+
 if (ws-bo_stats_file) {
 fprintf(ws-bo_stats_file, %p created, size %u, prio %u, @%llu\n, 
bo, size,
bo-stats.high_prio, stats_time_get());
@@ -871,6 +873,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
 unsigned size,
 unsigned alignment,
 boolean use_reusable_pool,
+boolean high_prio,
 enum radeon_bo_domain domain)
 {
 struct radeon_drm_winsys *ws = radeon_drm_winsys(rws);
@@ -885,6 +888,7 @@ radeon_winsys_bo_create(struct radeon_winsys *rws,
 /* Additional criteria for the cache manager. */
 desc.base.usage = domain;
 desc.initial_domains = domain;
+desc.high_prio = high_prio;
 
 /* Assign a buffer manager. */
 if (use_reusable_pool)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
index a18e5fb..a7fd6b9 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.h
@@ -43,6 +43,7 @@ struct radeon_bo_desc {
 struct pb_desc base;
 
 unsigned initial_domains;
+bool high_prio;
 };
 
 struct radeon_bo_stats {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index 407d8bd..c77066d 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -652,7 +652,7 @@ radeon_cs_create_fence(struct radeon_winsys_cs *rcs)
 struct pb_buffer *fence;
 
 /* Create a fence, which is a dummy BO. */
-fence = cs-ws-base.buffer_create(cs-ws-base, 1, 1, TRUE,
+fence =

Re: [Mesa-dev] [PATCH 4/4] radeon: Determine the bo priority (MSAA, depth, UVD are high)

2014-01-01 Thread Andreas Hartmetz 
On Wednesday 01 January 2014 16:58:46 Lauri Kasanen wrote:


 @@ -257,6 +258,7 @@ struct radeon_winsys {
 unsigned size,
 unsigned alignment,
 boolean use_reusable_pool,
 +   boolean high_prio,
 enum radeon_bo_domain domain);
 
  struct radeon_winsys_cs_handle *(*buffer_get_cs_handle)(

Something I have learned about schedulers is that binary priorities
are not a good deal. They kind of encourage special case hacks and
two code paths, they can do less than numeric priorities, and they
are not significantly easier to implement if you want to do it
correctly. This is not exactly a scheduler, but it seems similar
enough.
So I think a numeric value and = 3 priorities would be better here,
then you could also start assigning priority by things like buffer size
or really any heuristic that can produce some number. Even such
heuristics are easier to write when you don't need to limit the result
to true / false.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev