Re: [Mesa-dev] [PATCH 2/2] r600g: Enable GL_ARB_gpu_shader5 extension

[Benjamin Bellec]

Le 07/10/2015 19:13, Glenn Kennard a écrit :
> On Wed, 07 Oct 2015 19:04:15 +0200, Benjamin Bellec
> <b.bel...@gmail.com> wrote:
>
>> Hi Glenn,
>>
>> The series doesn't apply on current master.
>>
>> Regard.
>>
>
> It's not meant to apply directly on master. Quoting from the notes in
> patch 1/2:
>
> This patch depends on prior patch:
>   r600g/sb: Support gs5 sampler indexing
>
>
> /Glenn

OK sorry, I read too quickly.

Is that normal glxinfo still reports GLSL 330 ? With your series applied
I still get :
OpenGL renderer string: Gallium 0.4 on AMD CYPRESS (DRM 2.42.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel
(git-6ed8fd3)
OpenGL core profile shading language version string: 3.30


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

Re: [Mesa-dev] [PATCH 2/2] r600g: Enable GL_ARB_gpu_shader5 extension

[Benjamin Bellec]

Hi Glenn,

The series doesn't apply on current master.

Regard.

--
Benjamin

2015-10-07 19:00 GMT+02:00 Ilia Mirkin :

> On Wed, Oct 7, 2015 at 12:53 PM, Marek Olšák  wrote:
> > On Wed, Oct 7, 2015 at 5:17 PM, Glenn Kennard 
> wrote:
> >> Signed-off-by: Glenn Kennard 
> >> ---
> >> Now that SB supports the GS5 features we can safely enable the
> >> extension.
> >>
> >> Note that gallium state tracker clamps the GLSL language / GL version
> >> since GL_ARB_tessellation_shader isn't implemented yet.
> >
> > Where is it clamped?
>
> There used to be a clamp in the st, but I'm not sure that it's still
> there. However _mesa_compute_version does set the GLSL version to the
> right thing now.
>
>   -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] gallium/hud: display the Celsius temperature unit

[Benjamin Bellec]

Le 05/09/2015 10:19, Samuel Pitoiset a écrit :
>
> On 09/04/2015 08:57 PM, Benjamin Bellec wrote:
>> Currently, the temperature is displayed with a "%" symbol in
>> gallium/hud, which is quite odd.
>> Marek suggested to only change the value "100" to another value so
>> that this symbol is no more displayed. That works very well. This is
>> the patch #1. I choose "125" because it can be divided nicely by 5,
>> then the threshold displayed on the hud graph are 25/50/75/100/etc.
>> And also because with this, the actual temperature value is generally
>> in the middle of the graph.
>>
>> This second patch is totally optional. It "catch" the value "125" in
>> order to display a "C" instead of nothing.
>>
>> Ref. your suggestion on PIPE_DRIVER_QUERY_TYPE_TEMPERATURE, I'm not
>> skilled enough to answer.
>>
> Your first attempt at writing this patch introduced this
> PIPE_DRIVER_QUERY_TYPE_TEMPERATURE.
> Please, re-introduce it correctly. :)

I don't think to have the skills to do that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Adaptive Vsync

[Benjamin Bellec]

Hello Lauri,

I saw that your patch implementing adaptive vsync is not committed to mesa.
Ref,
http://lists.freedesktop.org/archives/mesa-dev/2013-December/050184.html

Why not ? Is there any issue with it ? As a end user, adaptive vsync seems
a nice feature. But maybe I'm not aware of drawbacks.

Regards.

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

[Mesa-dev] [PATCH v2 2/2] gallium/hud: display the Celsius temperature unit

[Benjamin Bellec]

Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
---
 src/gallium/auxiliary/hud/hud_context.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..71529bc 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
static const char *hz_units[] =
   {" Hz", " KHz", " MHz", " GHz"};
static const char *percent_units[] = {"%"};
+   static const char *temperature_units[] = {"C"};
 
const char **units;
unsigned max_unit;
@@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
   if (max_value == 100) {
  max_unit = ARRAY_SIZE(percent_units)-1;
  units = percent_units;
+  } else if (max_value == 125) {
+ max_unit = ARRAY_SIZE(temperature_units)-1;
+ units = temperature_units;
   } else {
  max_unit = ARRAY_SIZE(metric_units)-1;
  units = metric_units;
-- 
2.4.3

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

[Mesa-dev] [PATCH v2 1/2] gallium/hud: temperature is displayed with a percentage symbol, remove it

[Benjamin Bellec]

Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
---
 src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..2a8d906 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct pipe_screen 
*screen,
{"VRAM-usage", R600_QUERY_VRAM_USAGE, 
{rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GTT-usage", R600_QUERY_GTT_USAGE, {rscreen->info.gart_size}, 
PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GPU-load", R600_QUERY_GPU_LOAD, {100}},
-   {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
+   {"temperature", R600_QUERY_GPU_TEMPERATURE, {125}},
{"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0}, 
PIPE_DRIVER_QUERY_TYPE_HZ},
{"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0}, 
PIPE_DRIVER_QUERY_TYPE_HZ},
};
-- 
2.4.3

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

[Mesa-dev] [PATCH v2 1/2] gallium/hud: temperature is displayed with a percentage symbol, remove it

[Benjamin Bellec]

Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
---
 src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..2a8d906 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct pipe_screen 
*screen,
{"VRAM-usage", R600_QUERY_VRAM_USAGE, 
{rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GTT-usage", R600_QUERY_GTT_USAGE, {rscreen->info.gart_size}, 
PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GPU-load", R600_QUERY_GPU_LOAD, {100}},
-   {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
+   {"temperature", R600_QUERY_GPU_TEMPERATURE, {125}},
{"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0}, 
PIPE_DRIVER_QUERY_TYPE_HZ},
{"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0}, 
PIPE_DRIVER_QUERY_TYPE_HZ},
};
-- 
2.4.3


From 87a3e9a0fca72facb840d8c450fe9755b41e3b83 Mon Sep 17 00:00:00 2001
From: Benjamin Bellec <b.bel...@gmail.com>
Date: Fri, 4 Sep 2015 20:02:23 +0200
Subject: [PATCH v2 2/2] gallium/hud: display the temperature unit
To: mesa-dev@lists.freedesktop.org
Cc: mesa-sta...@lists.freedesktop.org

Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
---
 src/gallium/auxiliary/hud/hud_context.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..71529bc 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
static const char *hz_units[] =
   {" Hz", " KHz", " MHz", " GHz"};
static const char *percent_units[] = {"%"};
+   static const char *temperature_units[] = {"C"};
 
const char **units;
unsigned max_unit;
@@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
   if (max_value == 100) {
  max_unit = ARRAY_SIZE(percent_units)-1;
  units = percent_units;
+  } else if (max_value == 125) {
+ max_unit = ARRAY_SIZE(temperature_units)-1;
+ units = temperature_units;
   } else {
  max_unit = ARRAY_SIZE(metric_units)-1;
  units = metric_units;
-- 
2.4.3

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

Re: [Mesa-dev] [PATCH v2 1/2] gallium/hud: temperature is displayed with a percentage symbol, remove it

[Benjamin Bellec]

Forgot this one.
I will resend correctly, just trying to understand how git-format-patch and
git-send-mail works...

2015-09-04 20:18 GMT+02:00 Benjamin Bellec <b.bel...@gmail.com>:

> Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index ed5d1da..2a8d906 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct
> pipe_screen *screen,
> {"VRAM-usage", R600_QUERY_VRAM_USAGE,
> {rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
> {"GTT-usage", R600_QUERY_GTT_USAGE,
> {rscreen->info.gart_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
> {"GPU-load", R600_QUERY_GPU_LOAD, {100}},
> -   {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
> +   {"temperature", R600_QUERY_GPU_TEMPERATURE, {125}},
> {"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0},
> PIPE_DRIVER_QUERY_TYPE_HZ},
> {"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0},
> PIPE_DRIVER_QUERY_TYPE_HZ},
> };
> --
> 2.4.3
>
>
> From 87a3e9a0fca72facb840d8c450fe9755b41e3b83 Mon Sep 17 00:00:00 2001
> From: Benjamin Bellec <b.bel...@gmail.com>
> Date: Fri, 4 Sep 2015 20:02:23 +0200
> Subject: [PATCH v2 2/2] gallium/hud: display the temperature unit
> To: mesa-dev@lists.freedesktop.org
> Cc: mesa-sta...@lists.freedesktop.org
>
> Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
> ---
>  src/gallium/auxiliary/hud/hud_context.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/auxiliary/hud/hud_context.c
> b/src/gallium/auxiliary/hud/hud_context.c
> index 95eed26..71529bc 100644
> --- a/src/gallium/auxiliary/hud/hud_context.c
> +++ b/src/gallium/auxiliary/hud/hud_context.c
> @@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t
> max_value,
> static const char *hz_units[] =
>{" Hz", " KHz", " MHz", " GHz"};
> static const char *percent_units[] = {"%"};
> +   static const char *temperature_units[] = {"C"};
>
> const char **units;
> unsigned max_unit;
> @@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t
> max_value,
>if (max_value == 100) {
>   max_unit = ARRAY_SIZE(percent_units)-1;
>   units = percent_units;
> +  } else if (max_value == 125) {
> + max_unit = ARRAY_SIZE(temperature_units)-1;
> + units = temperature_units;
>} else {
>   max_unit = ARRAY_SIZE(metric_units)-1;
>   units = metric_units;
> --
> 2.4.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] gallium/hud: display the Celsius temperature unit

[Benjamin Bellec]

Currently, the temperature is displayed with a "%" symbol in gallium/hud,
which is quite odd.
Marek suggested to only change the value "100" to another value so that
this symbol is no more displayed. That works very well. This is the patch
#1. I choose "125" because it can be divided nicely by 5, then the
threshold displayed on the hud graph are 25/50/75/100/etc. And also because
with this, the actual temperature value is generally in the middle of the
graph.

This second patch is totally optional. It "catch" the value "125" in order
to display a "C" instead of nothing.

Ref. your suggestion on PIPE_DRIVER_QUERY_TYPE_TEMPERATURE, I'm not skilled
enough to answer.

2015-09-04 20:42 GMT+02:00 Brian Paul <bri...@vmware.com>:

> On 09/04/2015 12:30 PM, Benjamin Bellec wrote:
>
>> Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
>> ---
>>   src/gallium/auxiliary/hud/hud_context.c | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/src/gallium/auxiliary/hud/hud_context.c
>> b/src/gallium/auxiliary/hud/hud_context.c
>> index 95eed26..71529bc 100644
>> --- a/src/gallium/auxiliary/hud/hud_context.c
>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>> @@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t
>> max_value,
>>  static const char *hz_units[] =
>> {" Hz", " KHz", " MHz", " GHz"};
>>  static const char *percent_units[] = {"%"};
>> +   static const char *temperature_units[] = {"C"};
>>
>>  const char **units;
>>  unsigned max_unit;
>> @@ -271,6 +272,9 @@ number_to_human_readable(uint64_t num, uint64_t
>> max_value,
>> if (max_value == 100) {
>>max_unit = ARRAY_SIZE(percent_units)-1;
>>units = percent_units;
>> +  } else if (max_value == 125) {
>> + max_unit = ARRAY_SIZE(temperature_units)-1;
>> + units = temperature_units;
>> } else {
>>max_unit = ARRAY_SIZE(metric_units)-1;
>>units = metric_units;
>>
>>
>
> This seems like a bit of a magic number approach here.  At the very least,
> this magic value should be documented somewhere.
> PIPE_DRIVER_QUERY_TYPE_TEMPERATURE seems better to me, actually.
>
> -Brian
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] fix temperature display sign in hud

[Benjamin Bellec]

Signed-off-by: Benjamin Bellec <b.bel...@gmail.com>
---
 src/gallium/auxiliary/hud/hud_context.c   | 5 +
 src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
 src/gallium/include/pipe/p_defines.h  | 1 +
 src/mesa/state_tracker/st_cb_perfmon.c| 5 +
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/hud/hud_context.c 
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..8cbd322 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context.c
@@ -243,6 +243,7 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
static const char *hz_units[] =
   {" Hz", " KHz", " MHz", " GHz"};
static const char *percent_units[] = {"%"};
+   static const char *temperature_units[] = {"C"};
 
const char **units;
unsigned max_unit;
@@ -267,6 +268,10 @@ number_to_human_readable(uint64_t num, uint64_t max_value,
   max_unit = ARRAY_SIZE(hz_units)-1;
   units = hz_units;
   break;
+   case PIPE_DRIVER_QUERY_TYPE_TEMPERATURE:
+  max_unit = ARRAY_SIZE(temperature_units)-1;
+  units = temperature_units;
+  break;
default:
   if (max_value == 100) {
  max_unit = ARRAY_SIZE(percent_units)-1;
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..d6155ac 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -722,7 +722,7 @@ static int r600_get_driver_query_info(struct pipe_screen 
*screen,
{"VRAM-usage", R600_QUERY_VRAM_USAGE, 
{rscreen->info.vram_size}, PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GTT-usage", R600_QUERY_GTT_USAGE, {rscreen->info.gart_size}, 
PIPE_DRIVER_QUERY_TYPE_BYTES},
{"GPU-load", R600_QUERY_GPU_LOAD, {100}},
-   {"temperature", R600_QUERY_GPU_TEMPERATURE, {100}},
+   {"temperature", R600_QUERY_GPU_TEMPERATURE, {120}, 
PIPE_DRIVER_QUERY_TYPE_TEMPERATURE},
{"shader-clock", R600_QUERY_CURRENT_GPU_SCLK, {0}, 
PIPE_DRIVER_QUERY_TYPE_HZ},
{"memory-clock", R600_QUERY_CURRENT_GPU_MCLK, {0}, 
PIPE_DRIVER_QUERY_TYPE_HZ},
};
diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 88e37e9..2b0c6be 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -821,6 +821,7 @@ enum pipe_driver_query_type
PIPE_DRIVER_QUERY_TYPE_BYTES= 4,
PIPE_DRIVER_QUERY_TYPE_MICROSECONDS = 5,
PIPE_DRIVER_QUERY_TYPE_HZ   = 6,
+   PIPE_DRIVER_QUERY_TYPE_TEMPERATURE  = 7,
 };
 
 enum pipe_driver_query_group_type
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c 
b/src/mesa/state_tracker/st_cb_perfmon.c
index 1bb5be3..2eec99b 100644
--- a/src/mesa/state_tracker/st_cb_perfmon.c
+++ b/src/mesa/state_tracker/st_cb_perfmon.c
@@ -383,6 +383,11 @@ st_init_perfmon(struct st_context *st)
c->Maximum.f = 100.0f;
c->Type = GL_PERCENTAGE_AMD;
break;
+case PIPE_DRIVER_QUERY_TYPE_TEMPERATURE:
+   c->Minimum.u32 = 0;
+   c->Maximum.u32 = 120;
+   c->Type = GL_UNSIGNED_INT;
+   break;
 default:
unreachable("Invalid driver query type!");
  }
-- 
2.4.3

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

Re: [Mesa-dev] [PATCH] fix temperature display sign in hud

[Benjamin Bellec]

Yes I meant "unit", "sign" is a bad translation.
In gallium/hud, the temperature is displayed as a percentage, which is
quite confusing. But maybe there is better and simpler approach to fix
that. I do not really understand the code so I tried to copy other part of
the code.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/71] target/d3dadapter9: Return Windows like card names

[Benjamin Bellec]

Don't hold your commit because of me. I haven't the skills to review this
code. I just saw this mapping and asking myself about it. It can be be
modified later if needed in any case.

2015-08-21 22:09 GMT+02:00 Axel Davy axel.d...@ens.fr:

 As far as I know, the mapping is not an official one.

 Games usually do not use the card name to apply
 card specific workarounds, instead they use the vendor
 or the device id.

 However the names are sometimes used in configuration files
 to match the user set configuration to a card (and reset if the
 card is changed).

 In general in game settings you will see the name advertised.

 Some apps may even have other usages of the names.

 Besides advertising the Windows like names, we want add in the future
 an easy way to change the card advertised. For example to advertise older
 card
 of your vendor, or advertise another vendor (some games do disable
 some features for some cards).

 Yours,

 Axel Davy

 On 17/08/2015 19:30, Benjamin Bellec write :

 Hello,

 Where does this mapping list come from ? Is this an official map (Vendor
 or Windows drivers) ? Is that used just for information ?
 Because many of them are not really precise, if not completely wrong at
 all (eg. the Radeon R400/R500 series names).

 Regards.

 --
 Benjamin




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

Re: [Mesa-dev] [PATCH 02/71] target/d3dadapter9: Return Windows like card names

[Benjamin Bellec]

Hello,

Where does this mapping list come from ? Is this an official map (Vendor or
Windows drivers) ? Is that used just for information ?
Because many of them are not really precise, if not completely wrong at all
(eg. the Radeon R400/R500 series names).

Regards.

--
Benjamin

2015-08-16 17:27 GMT+02:00 Axel Davy axel.d...@ens.fr:

 From: Patrick Rudolph s...@das-labor.org

 Add support for multiple cards and fill in Windows like card name, driver
 name and version info.
 Use fallback for unknown vendors and unknown card names.

 Reviewed-by: Axel Davy axel.d...@ens.fr
 Signed-off-by: Patrick Rudolph s...@das-labor.org
 ---
  src/gallium/targets/d3dadapter9/Makefile.am   |   1 +
  src/gallium/targets/d3dadapter9/description.c | 324
 ++
  src/gallium/targets/d3dadapter9/drm.c |  76 +++---
  3 files changed, 359 insertions(+), 42 deletions(-)
  create mode 100644 src/gallium/targets/d3dadapter9/description.c

 diff --git a/src/gallium/targets/d3dadapter9/Makefile.am
 b/src/gallium/targets/d3dadapter9/Makefile.am
 index fe5b0b1..e26ca33 100644
 --- a/src/gallium/targets/d3dadapter9/Makefile.am
 +++ b/src/gallium/targets/d3dadapter9/Makefile.am
 @@ -54,6 +54,7 @@ pkgconfigdir = $(libdir)/pkgconfig
  pkgconfig_DATA = d3d.pc

  d3dadapter9_la_SOURCES = \
 +   description.c \
 getproc.c \
 drm.c

 diff --git a/src/gallium/targets/d3dadapter9/description.c
 b/src/gallium/targets/d3dadapter9/description.c
 new file mode 100644
 index 000..c0a8678
 --- /dev/null
 +++ b/src/gallium/targets/d3dadapter9/description.c
 @@ -0,0 +1,324 @@
 +/*
 + * Copyright 2015 Patrick Rudolph s...@das-labor.org
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the
 Software),
 + * to deal in the Software without restriction, including without
 limitation
 + * on the rights to use, copy, modify, merge, publish, distribute, sub
 + * license, and/or sell copies of the Software, and to permit persons to
 whom
 + * the Software is furnished to do so, subject to the following
 conditions:
 + *
 + * The above copyright notice and this permission notice (including the
 next
 + * paragraph) shall be included in all copies or substantial portions of
 the
 + * Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT
 SHALL
 + * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
 + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
 + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
 THE
 + * USE OR OTHER DEALINGS IN THE SOFTWARE. */
 +
 +#include string.h
 +#include adapter9.h
 +
 +#define DBG_CHANNEL DBG_ADAPTER
 +
 +/* prototypes */
 +void
 +d3d_match_vendor_id( D3DADAPTER_IDENTIFIER9* drvid,
 +unsigned fallback_ven,
 +unsigned fallback_dev,
 +const char* fallback_name );
 +void d3d_fill_driver_version(D3DADAPTER_IDENTIFIER9* drvid);
 +void d3d_fill_cardname(D3DADAPTER_IDENTIFIER9* drvid);
 +
 +enum d3d_vendor_id
 +{
 +HW_VENDOR_SOFTWARE  = 0x,
 +HW_VENDOR_AMD   = 0x1002,
 +HW_VENDOR_NVIDIA= 0x10de,
 +HW_VENDOR_VMWARE= 0x15ad,
 +HW_VENDOR_INTEL = 0x8086,
 +};
 +
 +struct card_lookup_table {
 +const char *mesaname;
 +const char *d3d9name;
 +}
 +cards_amd[] = {
 +{HAWAII,  AMD Radeon R9 290},
 +{KAVERI,  AMD Radeon(TM) R7 Graphics},
 +{KABINI,  AMD Radeon HD 8400 / R3 Series},
 +{BONAIRE, AMD Radeon HD 8770},
 +{OLAND,   AMD Radeon HD 8670},
 +{HAINAN,  AMD Radeon HD 8600M Series},
 +{TAHITI,  AMD Radeon HD 7900 Series},
 +{PITCAIRN,AMD Radeon HD 7800 Series},
 +{CAPE VERDE,  AMD Radeon HD 7700 Series},
 +{ARUBA,   AMD Radeon HD 7660D},
 +{CAYMAN,  AMD Radeon HD 6900 Series},
 +{BARTS,   AMD Radeon HD 6800 Series},
 +{TURKS,   AMD Radeon HD 6600 Series},
 +{SUMO2,   AMD Radeon HD 6410D},
 +{SUMO,AMD Radeon HD 6550D},
 +{CAICOS,  AMD Radeon HD 6400 Series},
 +{PALM,AMD Radeon HD 6300 series Graphics},
 +{HEMLOCK, ATI Radeon HD 5900 Series},
 +{CYPRESS, ATI Radeon HD 5800 Series},
 +{JUNIPER, ATI Radeon HD 5700 Series},
 +{REDWOOD, ATI Radeon HD 5600 Series},
 +{CEDAR,   ATI Radeon HD 5500 Series},
 +

[Mesa-dev] [PATCH] gallium/radeon: fix r600g build if LLVM is disabled

[Benjamin Bellec]

Tested-by: Benjamin Bellec b.bel...@gmail.com

On Sat, Aug 8, 2015, at 10:05 PM, Marek Olšák wrote:
* From: Marek Olšák marek.olsak at amd.com 
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
* * MESA_LLVM_VERSION_PATCH is undefined.
** ---
**  src/gallium/drivers/radeon/r600_pipe_common.c | 9 +
**  1 file changed, 5 insertions(+), 4 deletions(-)
* * diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
** b/src/gallium/drivers/radeon/r600_pipe_common.c
** index d6b9a01..e50e768 100644
** --- a/src/gallium/drivers/radeon/r600_pipe_common.c
** +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
** @@ -891,10 +891,11 @@ bool r600_common_screen_init(struct
** r600_common_screen *rscreen,
*  *  ws-query_info(ws, rscreen-info);
*  * -   if (HAVE_LLVM)
** -   snprintf(llvm_string, sizeof(llvm_string),
** -, LLVM %i.%i.%i, (HAVE_LLVM  8)  0xff,
** -HAVE_LLVM  0xff, MESA_LLVM_VERSION_PATCH);
** +#if HAVE_LLVM
** +   snprintf(llvm_string, sizeof(llvm_string),
** +, LLVM %i.%i.%i, (HAVE_LLVM  8)  0xff,
** +HAVE_LLVM  0xff, MESA_LLVM_VERSION_PATCH);
** +#endif
*  *  snprintf(rscreen-renderer_string, 
sizeof(rscreen-renderer_string),
**  %s (DRM %i.%i.%i%s),
** --
** 2.1.4
* * ___
** mesa-dev mailing list
** mesa-dev at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
** http://lists.freedesktop.org/mailman/listinfo/mesa-dev
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
*
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] r600g: add doubles support for CAYMAN

[Benjamin Bellec]

Hello all,

Do you know a game or app using doubles ?

2015-02-20 21:08 GMT+01:00 Ilia Mirkin imir...@alum.mit.edu:

 On Fri, Feb 20, 2015 at 3:07 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
  On Thu, Feb 19, 2015 at 9:59 PM, Glenn Kennard glenn.kenn...@gmail.com
 wrote:
  +   if ((write_mask  0x3) != 0x3 
  +   (write_mask  0xc) != 0xc) {
  +   fprintf(stderr, illegal writemask for 64-bit: 0x%x\n,
  write_mask);
  +   return -1;
  +   }
 
  I think I noted this on IRC, but did you mean this to be || instead of
   ? e.g. right now this will not trigger for a .xyz writemask, since
  write_mask  3 == 3.

 Oh but it can't be || either, since write_mask == 3 should pass this.
 I guess you want like

 if (write_mask  3  write_mask  3 != 3)
   error
 if (writemask  c  writemaks  c != c)
   error

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

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

Re: [Mesa-dev] Removing out of date Mesa wiki pages

[Benjamin Bellec]

RadeonProgram page just removed.

2015-02-05 20:52 GMT+01:00 Alex Deucher alexdeuc...@gmail.com:

 On Thu, Feb 5, 2015 at 2:47 PM, Benjamin Bellec b.bel...@gmail.com
 wrote:
  And what about removing the RadeonProgram page [1] ?
 
  From my point of view, this page depicts a wrong picture of the Radeon
 Mesa
  driver. While I'm pretty sure most of the current and past games runs
 fine
  today with r300g/r600g/radeonsi, this is not what one could think at a
 first
  look when reading this page. Moreover, the table stops to the Radeon
 HD6000
  series.
 
  This page is useful if user can update their input, but the wiki access
 is
  restricted.
 
  [1] http://xorg.freedesktop.org/wiki/RadeonProgram/

 I'm fine with removing it.  It's mostly out of date anyway.

 Alex

 
 
  2015-01-14 9:52 GMT+01:00 Kenneth Graunke kenn...@whitecape.org:
 
  On Wednesday, January 14, 2015 04:27:30 PM Timothy Arceri wrote:
   Hi all,
  
   Not sure how many of you have come across the webpage Major Linux
   Problems on the Desktop 2015 edition [1]. Accurate or not it seems to
   be getting a bit of attention. Anyway Mesa gets a bit of a bashing in
   there although most of the information the author uses to backup their
   claims are out of date Phoronix articles and this Mesa wiki page [2].
  
   Anyway getting to my point maybe the wiki page should be removed as it
   seems its no longer useful and is being used to spread misinformation.
  
   Tim
  
   [1]
  
  
 http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html
   [2] http://dri.freedesktop.org/wiki/MissingFunctionality/
 
  Hooray for fact checking!  I'm all for replacing that page - it hasn't
  been
  useful in years.  How about replacing it with links to other places:
 
  Ilia's glxinfo site - shows accurate information about what specific
 GPUs
  support in actual Mesa releases:
  http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
 
  Current feature development status:
  http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
 
  which can be helpfully visualized at:
  http://mesamatrix.net/
 
  --Ken
  ___
  mesa-dev mailing list
  mesa-dev@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 
 
 
  ___
  mesa-dev mailing list
  mesa-dev@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

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

Re: [Mesa-dev] Removing out of date Mesa wiki pages

[Benjamin Bellec]

And what about removing the RadeonProgram page [1] ?

From my point of view, this page depicts a wrong picture of the Radeon Mesa
driver. While I'm pretty sure most of the current and past games runs fine
today with r300g/r600g/radeonsi, this is not what one could think at a
first look when reading this page. Moreover, the table stops to the Radeon
HD6000 series.

This page is useful if user can update their input, but the wiki access is
restricted.

[1] http://xorg.freedesktop.org/wiki/RadeonProgram/


2015-01-14 9:52 GMT+01:00 Kenneth Graunke kenn...@whitecape.org:

 On Wednesday, January 14, 2015 04:27:30 PM Timothy Arceri wrote:
  Hi all,
 
  Not sure how many of you have come across the webpage Major Linux
  Problems on the Desktop 2015 edition [1]. Accurate or not it seems to
  be getting a bit of attention. Anyway Mesa gets a bit of a bashing in
  there although most of the information the author uses to backup their
  claims are out of date Phoronix articles and this Mesa wiki page [2].
 
  Anyway getting to my point maybe the wiki page should be removed as it
  seems its no longer useful and is being used to spread misinformation.
 
  Tim
 
  [1]
 
 http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html
  [2] http://dri.freedesktop.org/wiki/MissingFunctionality/

 Hooray for fact checking!  I'm all for replacing that page - it hasn't been
 useful in years.  How about replacing it with links to other places:

 Ilia's glxinfo site - shows accurate information about what specific GPUs
 support in actual Mesa releases:
 http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html

 Current feature development status:
 http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

 which can be helpfully visualized at:
 http://mesamatrix.net/

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


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

Re: [Mesa-dev] [PATCH 1/8] mesa: remove support for GCC older than 3.3.0

[Benjamin Bellec]

Hello,
Maybe this change should be mentioned in the relnotes ?

2014-12-12 18:04 GMT+01:00 Matt Turner matts...@gmail.com:

 Thanks Timothy. The whole series looks good to me:

 Reviewed-by: Matt Turner matts...@gmail.com

 I'd wait a couple of days for objections before pushing the series.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] rv635 geometry shader texel fetch

[Benjamin Bellec]

Hello,
Did you tried with R600_DEBUG=nosb ?
Regards.
Le 19 nov. 2014 07:18, Dave Airlie airl...@gmail.com a écrit :

 Hey,

 I got piglit to run on my laptop rv635,

 two things seem to hang it

 geometry shader texel fetches (wierd incorrect values for 2D, hangs for
 2DMS)
 and
 the clip scissor msaa blits.

 The main wierdness is that texelFetch gs sampler2D is busted,

 you get wierd black lines in the middle of the result, like cache
 lines, I wonder if we have some other badly setup geom shader stuff
 and it just happens to hang these.

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

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

Re: [Mesa-dev] [PATCH] r600g, radeonsi: add debug option which forces DMA for copy_region and blit

[Benjamin Bellec]

No problem with Valley on Evergeen (CYPRESS).

Unigine Valley 1.0 (64-bit) Basic preset without forcedma :
Benchmark results:
Time:188.792
Frames:9194
FPS:48.6992
Min FPS:20.5505
Max FPS:78.946
Score:2037.5

Unigine Valley 1.0 (64-bit) Basic preset with forcedma :
Benchmark results:
Time:188.915
Frames:9180
FPS:48.5934
Min FPS:24.7402
Max FPS:77.8441
Score:2033.15

2014-09-06 19:15 GMT+02:00 Andy Furniss adf.li...@gmail.com:

 Andy Furniss wrote:

 Marek Olšák wrote:

 From: Marek Olšák marek.ol...@amd.com

 ---

 Turn this on, run piglit, and pray for mercy.
 It might be interesting to see if it makes 3D apps any faster. Or piglit.


 Well it's not piglit and I haven't benchmarked anything yet, but I get a
 couple of faults at the start of Unigine Valley.


 Forgot to put h/w is pitcairn - R9 270X



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

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

Re: [Mesa-dev] [PATCH] r600g, radeonsi: add debug option which forces DMA for copy_region and blit

[Benjamin Bellec]

Oh you're right. With the Extreme preset, the sun's lens flare are buggy.
Other than that, it seems to work.

And I get this kernel errors :
[23018.037267] radeon :01:00.0: DMA L2L, dw src buffer too small
(2097152 524288)
[23018.037270] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

2014-09-07 22:47 GMT+02:00 Andy Furniss adf.li...@gmail.com:

 Benjamin Bellec wrote:

 No problem with Valley on Evergeen (CYPRESS).

 Unigine Valley 1.0 (64-bit) Basic preset without forcedma :


 It doesn't produce them on basic for me - so maybe if you try a higher
 setting.

 It still runs after producing the errors, though for me valley is very
 glitchy. I get time stopping pauses is it smooth for you?

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

[Mesa-dev] RadeonProgram webpage access

[Benjamin Bellec]

Hello,

I would like to have an access to the RadeonProgram web page
(http://www.x.org/wiki/RadeonProgram/) in order to update and improve it.
I requested this access 9 months ago to jrayh...@freedesktop.org and
tfh...@freedesktop.org and still have no access.

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

Re: [Mesa-dev] Mesa fails to build (32 bit chroot on 64 bit machine)

[Benjamin Bellec]

Hello,

This error is due to the recent removal of --disable-64-bit and
--enable-32-bit options.
You should now replace them by --build=i686-pc-linux-gnu and
--host=i686-pc-linux-gnu

See here :
http://lists.freedesktop.org/archives/mesa-dev/2014-August/065574.html

- Benjamin


Le 17/08/2014 23:00, Kertesz Laszlo a écrit :
 Hello.
 I have an issue building mesa on a 32 bit chroot. Compiling fails with
 the below messages (the Error ones repeated 9000+ times):

 /tmp/ccvEhPCW.s: Assembler messages:
 /tmp/ccvEhPCW.s:13: Error: bad register name `%rip)'
 /tmp/ccvEhPCW.s:14: Error: bad register name `%rax)'
 /tmp/ccvEhPCW.s:15: Error: bad register name `%r11)'
 /tmp/ccvEhPCW.s:21: Error: bad register name `%rip)'
 /tmp/ccvEhPCW.s:22: Error: bad register name `%rax)'
 /tmp/ccvEhPCW.s:23: Error: bad register name `%r11)'
 /tmp/ccvEhPCW.s:29: Error: bad register name `%rip)'
 /tmp/ccvEhPCW.s:30: Error: bad register name `%rax)'

 I built mesa before with the very same config file 2 days ago. What
 could be wrong?

 Note: 64 bit builds fine.
 mesa build script:

 #!/bin/bash
 ./autogen.sh --sysconfdir=/etc --prefix=/usr \
 LDFLAGS=-L/usr/lib/i386-linux-gnu -L/usr/lib
 -L/usr/local/lib/llvm32/lib \
 --disable-64-bit --enable-32-bit \
 --libdir=/usr/lib/i386-linux-gnu --enable-debug \
 --enable-texture-float \
 --with-gallium-drivers=r600,swrast,radeonsi \
 --with-dri-drivers= \
 --enable-vdpau \
 --enable-egl --enable-gles1 --enable-gles2 \
 --enable-glx-tls \
 --with-egl-platforms=x11,drm \
 --enable-gbm \
 --enable-gallium-egl \
 --enable-gallium-osmesa \
 --with-osmesa-bits=32 \
 --disable-dri3 \
 --enable-shared-glapi \
 --enable-gallium-llvm \
 --enable-r600-llvm-compiler \
 --disable-llvm-shared-libs \
 --with-llvm-prefix=/usr/local/lib/llvm32 \
 CPPFLAGS=-m32 \
 CXXFLAGS=-m32 \
 LDFLAGS=-ltinfo -lpthread -ldl

 Its a bit messed up, but it was working before in this exact form (i
 build llvm too and static link agains it). Debian Testing 64 bit.

 --
 O zi buna,
 Kertesz Laszlo


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

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

Re: [Mesa-dev] [RFC 00/20] shader compiler cache

[Benjamin Bellec]

Hello,

This patch set prevents me from launching Steam.
I'm on r600g (Radeon HD5850 Evergreen).

Here is the log :
$ MESA_DEBUG=1 LIBGL_DEBUG=1 STEAM_RUNTIME=0 steam
Running Steam on fedora 19 64-bit
STEAM_RUNTIME is disabled by the user
Installing breakpad exception handler for
appid(steam)/version(1401381906_client)
libGL: Can't open configuration file /home/benjamin/.drirc: Aucun
fichier ou dossier de ce type.
libGL: Can't open configuration file /home/benjamin/.drirc: Aucun
fichier ou dossier de ce type.
steam: ../../src/glsl/ralloc.c :84 : get_header:  l'assertion
« info-canary == 0x5A1106 » a échoué.
[2014-06-02 19:39:21] Startup - updater built May 29 2014 09:19:23
Uploading dump (out-of-process) [proxy '']
/tmp/dumps/crash_20140602193921_1.dmp
Finished uploading minidump (out-of-process): success = yes
response: CrashID=bp-147d1385-d725-4927-9082-1dd942140602
/home/benjamin/.local/share/Steam/steam.sh : ligne 755 :  5546
Abandon (core dumped)$STEAM_DEBUGGER
$STEAMROOT/$PLATFORM/$STEAMEXE $@
Installing bootstrap /home/benjamin/.local/share/Steam/bootstrap.tar.xz
Reset complete!
Restarting Steam by request...
Running Steam on fedora 19 64-bit
STEAM_RUNTIME is disabled by the user
Installing breakpad exception handler for
appid(steam)/version(1401381906_client)
libGL: Can't open configuration file /home/benjamin/.drirc: Aucun
fichier ou dossier de ce type.
libGL: Can't open configuration file /home/benjamin/.drirc: Aucun
fichier ou dossier de ce type.
steam: ../../src/glsl/ralloc.c :84 : get_header:  l'assertion
« info-canary == 0x5A1106 » a échoué.
ILocalize::AddFile() failed to load file
public/steambootstrapper_english.txt.
[2014-06-02 19:39:25] Startup - updater built Feb 10 2014 16:03:16
Uploading dump (out-of-process) [proxy '']
/tmp/dumps/crash_20140602193925_1.dmp
/home/benjamin/.local/share/Steam/steam.sh : ligne 755 :  5645
Abandon (core dumped)$STEAM_DEBUGGER
$STEAMROOT/$PLATFORM/$STEAMEXE $@
Finished uploading minidump (out-of-process): success = yes
response: CrashID=bp-b11e236c-ada1-4479-84c5-fdd2b2140602

The canary error on Google points to a previously closed bug from
glsl-compiler :
https://bugs.freedesktop.org/show_bug.cgi?id=58039

I can bisect if you need it.

Regards.

Le 02/06/2014 14:05, Tapani Pälli a écrit :
 Hello;

 This series provides a disk cache for the shader compiler and is used 
 to 'skip glLinkProgram' like GL_ARB_get_program_binary does but under 
 the hood without api for the client.

 Many of the patches are from my 'GL_ARB_get_program_binary' series and 
 some were reviewed by Paul earlier. I've tried to split the whole thing 
 in smaller pieces when possible and added more validation in IR level 
 and also higher level. Most importantly sizeof(long) and some important 
 structure sizes must match, otherwise cache gets invalidated.

 There are some new 'uncomfortable' things that Mesa must do when having 
 a disk cache. This includes directory creation, cache size management 
 and just general file read/write. Some of these might not have been 
 written in a portable way (especially patch 20), feedback appreciated.

 This set passes all of other Piglit quick tests but not the transform 
 feedback tests. I believe most (if not all) of them can be fixed by 
 having key generation based on some of the variables used for xfb in 
 gl_shader_program and also serializing xfb related structures but I 
 have not done this yet as I think the key generation overall would need 
 some better algorithm based on the gl_shader_program contents (only 
 those contents which are always same for the same shader program), 
 would be good to get some feedback for this. Now these contents seem a 
 bit scattered, hard to generate a key.

 I've limiting the supported set of shaders by having additional checks 
 during shader serialization. This is simply because of some things may 
 not be implemented yet or not having good test cases, these will be 
 improved.

 With the series I get 50% improvement for L4D2 startup (goes down from 
 30s to ~15s) This is the time after startup video to menu screen. With 
 some other apps the improvement varies a lot (as example I measured 
 ~10% improvement with GLBenchmark 2.7). It would be nice to get some 
 more test results, especially with modern games.

 The GL_ARB_get_program_binary extension can be implemented easily on 
 top of this. Also shader backend assembly and other additional data can 
 be added later as part of the same cache.

 If no objections I would be tempted to start pushing in patches that 
 were already reviewed as this is a lot of code to carry around.

 Any comments welcome;


 Tapani Pälli (20):
   glsl: memory_writer helper class for data serialization
   glsl: glsl_type serialization
   glsl: serialize methods for IR instructions
   glsl: memory_map helper class for data deserialization
   glsl: add MESA_SHADER_CACHE_MAGIC string for shader binary cache
   glsl: export 

Re: [Mesa-dev] [Mesa-users] Problem with ARB_copy_buffer on Mesa 9.2.4

[Benjamin Bellec]

Hello Jonas,

I tested your program and on my system (Fedora 19) on an Evergreen
(Radeon HD 5850) and I have the same issue indeed.
Here is my result :

Mesa 9.2.4 (from F19 repo) = Data does NOT match up!
Mesa 9.2.5 = Data does NOT match up!
Mesa 10.0.5 = Data does NOT match up!
Mesa 10.1.0 = Data matches.

So this is fixed in newer version.
That said, Mesa 9.2 is not supported anymore and I really don't know if
there will be a new Mesa 10.0.x release given the imminence of Mesa 10.2.
If yes, I can bisect and you can open a bug.

Mesa-dev, any new 10.0.x release planned ?

Regards.

Benjamin

Le 06/05/2014 13:40, Jonas Kulla a écrit :
 Hello list,

 after about 3 days of debugging, I was able to isolate a rather weird
 behavior in Mesa GL.
 The gist of it is the following: When I create a buffer object and
 allocate uninitilaized
 memory for it (glBufferData() with nullptr as 'data'),
 then glCopyBufferSubData() data into
 it from another buffer object, then subsequently fill a part of it
 with glBufferSubData(),
 this new data isn't visible to the buffer object. In fact, it seems
 that the SubData'ed bytes
 are completely lost. Any further data uploads however work as
 expected. I will attach
 a small C test case below that demonstrates this behavior.

 I realize that I am working with an old Mesa release (on Fedora 19),
 but I'm afraid of
 upgrading my system to the newest distro release as I might break my
 working environment.
 That's why I would like to kindly ask if someone could verify that
 this problem still persists
 on the newest Mesa code, in which case I would go ahead and file a bug
 report. At the
 same time, maybe someone could spot a critical mistake in my code that
 would explain
 this strange behavior I'm seeing. I think the code paths I'm hitting
 here in the driver are
 sufficiently obscure though.

 I should probably mention that my card is a Mobility Radeon HD 3650
 (ie. r600).

 Here's the code sample (you can replace the GL setup code with your own):

 #include stdlib.h
 #include string.h
  
 #include GL/glew.h
 #include SDL2/SDL.h
  
 static SDL_Window *win;
 static SDL_GLContext *ctx;
  
 void setupGL()
 {
 SDL_Init(SDL_INIT_VIDEO);
 win = SDL_CreateWindow(CopyBufferBug,
 SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 64, 64,
 SDL_WINDOW_OPENGL);
 ctx = SDL_GL_CreateContext(win);
 glewInit();
 }
  
 static void teardownGL()
 {
 SDL_GL_DeleteContext(ctx);
 SDL_DestroyWindow(win);
  
 SDL_Quit();
 }
  
 int main(int argc, char *argv[])
 {
 setupGL();
  
 /* These don't matter I think */
 #define BLOCK_SIZE 128
 #define BUFFER1_SIZE BLOCK_SIZE
 #define BUFFER2_SIZE BLOCK_SIZE
 #define BUFFER1_TARGET GL_COPY_READ_BUFFER
 #define BUFFER2_TARGET GL_COPY_WRITE_BUFFER
 #define BUFFER1_USAGE GL_DYNAMIC_DRAW
 #define BUFFER2_USAGE GL_DYNAMIC_DRAW
  
 GLuint buffers[2];
 glGenBuffers(2, buffers);
  
 /* We allocate both buffers with undefined memory */
 glBindBuffer(BUFFER1_TARGET, buffers[0]);
 glBufferData(BUFFER1_TARGET, BUFFER1_SIZE, 0, BUFFER1_USAGE);
  
 glBindBuffer(BUFFER2_TARGET, buffers[1]);
 glBufferData(BUFFER2_TARGET, BUFFER2_SIZE, 0, BUFFER2_USAGE);
  
 /* Then copy (undefined) bytes from the first into the second
 buffer */
 /* Note: If I comment this line out, everything works */
 glCopyBufferSubData(BUFFER1_TARGET, BUFFER2_TARGET, 0, 0,
 BUFFER1_SIZE);
  
 /* Generate random string */
 FILE *rand = fopen(/dev/urandom, r);
 char data[BLOCK_SIZE];
 fread(data, 1, sizeof(data), rand);
 fclose(rand);
  
 /* We fill the second buffer with defined data */
 /* Note: If I execute this call twice (just copy paste the
 line), everything works */
 glBufferSubData(BUFFER2_TARGET, 0, sizeof(data), data);
  
 /* Then download it again to compare its contents against our
 test string */
 char data2[BLOCK_SIZE];
 glGetBufferSubData(BUFFER2_TARGET, 0, sizeof(data2), data2);
  
 if (memcmp(data, data2, sizeof(data)))
 printf(Data does NOT match up!\n);
 else
 printf(Data matches.\n);
  
 glDeleteBuffers(2, buffers);
  
 teardownGL();
  
 return 0;
 }

 Thank you very much for your time.
 Jonas


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

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

[Mesa-dev] [PATCH] fix GetStringi error message with correct name function

[Benjamin Bellec]

Signed-off-by: Benjamin Bellec b.bel...@gmail.com
---
 src/mesa/main/getstring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
index 3ac62d4..1ac92e2 100644
--- a/src/mesa/main/getstring.c
+++ b/src/mesa/main/getstring.c
@@ -166,7 +166,7 @@ _mesa_GetStringi(GLenum name, GLuint index)
   }
   return _mesa_get_enabled_extension(ctx, index);
default:
-  _mesa_error( ctx, GL_INVALID_ENUM, glGetString );
+  _mesa_error( ctx, GL_INVALID_ENUM, glGetStringi );
   return (const GLubyte *) 0;
}
 }
-- 
1.8.1.4

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

Re: [Mesa-dev] Heavy ioq3 regression in mesa (r600g/cayman/aruba)

[Benjamin Bellec]

I disabled vsync and tested with Tremulous.
I didn't see any regression on my system, I got 256-257 FPS with or
without HyperZ, with this 2 commits and also current master (git-352e06d).
So it doesn't hit Evergreen at least.

Le 18/04/2014 09:20, Lauri Kasanen a écrit :
 On Fri, 18 Apr 2014 10:16:53 +0300
 Lauri Kasanen c...@gmx.com wrote:

 On Fri, 18 Apr 2014 01:41:46 +0200
 Benjamin Bellec b.bel...@gmail.com wrote:

 Hi Lauri,

 I tested with both commit but cannot seeing something relevant, I got 60
 FPS in both case.
 I tested with the Tremulous 1.1 test case from Phoronix Test Suite 4.8.6
 (from Fedora 19 repo).

 The command used (for both commit) was:
 $ vblank_mode=0 R600_DEBUG=nohyperz phoronix-test-suite Test pts/tremulous

 I have a Radeon HD5850 (with 1 GB VRAM).

 Any idea to try to spot your issue? (decrease VRAM size?)
 Hi,

 It was visible at all VRAM sizes (both 256mb limited, and 768mb full).
 I also used hyperz to rule it out, ie 

 R600_DEBUG=hyperz phoronix-test-suite run pts/tremulous pts/smokingguns

 It's possible this bug only affects Cayman and/or APUs. Though just
 recently a similar ioq3 regression was reported on Intel.
 PS: Please disable swapbufferswait in xorg.conf so you're not limited
 to 60fps. PTS passes vblank_mode by itself.

 - Lauri

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

Re: [Mesa-dev] Heavy ioq3 regression in mesa (r600g/cayman/aruba)

[Benjamin Bellec]

Hi Lauri,

I tested with both commit but cannot seeing something relevant, I got 60
FPS in both case.
I tested with the Tremulous 1.1 test case from Phoronix Test Suite 4.8.6
(from Fedora 19 repo).

The command used (for both commit) was:
$ vblank_mode=0 R600_DEBUG=nohyperz phoronix-test-suite Test pts/tremulous

I have a Radeon HD5850 (with 1 GB VRAM).

Any idea to try to spot your issue? (decrease VRAM size?)

Regards.

Benjamin

Le 15/04/2014 09:35, Lauri Kasanen a écrit :
 Hi,

 Tremulous and Smoking Guns regressed in Mesa master, ok in 020c43f,
 broken in 4ddf51db.

 Tremulous 133 to 33 fps, Smoking Guns 153 to 40. In the ok version,
 hyperz was enabled by default; in the more recent master, it was
 disabled by default, but enabled via the R600_DEBUG env var. The env
 var applied correctly, because other games' perf reacted to it.

 This is a week old master, so it might be fixed already; just in case
 it's not, I thought I'd report this, as a release is about to be
 branched. Wouldn't do to have 4x regressions in a release ;)

 Anyway, that's a fairly wide area to bisect, and I'm busy with other
 things, so just this email instead of a bug and a bisect.

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

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

[Mesa-dev] [PATCH] add a bugfix in 10.2 release notes

[Benjamin Bellec]

Signed-off-by: Benjamin Bellec b.bel...@gmail.com

diff --git a/docs/relnotes/10.2.html b/docs/relnotes/10.2.html
index da79e7d..05fd502 100644
--- a/docs/relnotes/10.2.html
+++ b/docs/relnotes/10.2.html
@@ -51,7 +51,11 @@ Note: some of the new features are only available with certain drivers.
 
 h2Bug fixes/h2
 
-TBD.
+ul
+
+lia href=https://bugs.freedesktop.org/show_bug.cgi?id=71138;Bug 71138/a - flashlight bug in L4D2/li
+
+/ul
 
 h2Changes/h2
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] add a bugfix in 10.2 release notes

[Benjamin Bellec]

Oh OK, I wasn't aware of this process and script.
That said, the commit that fixed the bug was not intended to. And it
will not be caught by the script.

Noted for git send-email.

Benjamin

Le 11/04/2014 20:24, Emil Velikov a écrit :
 On 11/04/14 19:07, Benjamin Bellec wrote:
 Signed-off-by: Benjamin Bellec b.bel...@gmail.com

 Hi Benjamin,

 The bugfixes section is generated as part of the release process, and is
 automated via the bin/bugzilla_mesa.sh script, so I do not think that we're
 ready for this patch yet :)

 For a future reference can you please send patches via git send-email - this
 way people can easily reply in-line with questions/comments that they may 
 have.

 Thanks
 -Emil


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


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

Re: [Mesa-dev] RFC: per-driver extension lists

[Benjamin Bellec]

As Alex said, this is more like : R600/R700* support GL3.3.

* except original R600 (Radeon HD 2900 series).

I don't know if this can be easily added in your tool or it's even
important to say here. But I think this information should be mentioned
somewhere (on the RadeonFeature web page at least).

And is your tool strictly from a Mesa perspective? I mean, for instance,
GL3.3 is only supported for R600/R700 with kernel 3.14. Before, only
GL3.1 is exposed. This information is - indirectly - noted on
RadeonFeature web page though.


Benjamin

Le 31/03/2014 20:43, Ilia Mirkin a écrit :
 On Mon, Mar 31, 2014 at 2:39 PM, Benjamin Bellec b.bel...@gmail.com wrote:
 Hi,

 Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is
 not enabled on Radeon HD2900 (R600 codename) due to hardware limitation.
 I have no R600 card to check glxinfo.

 David Airlie enabled this extension with this commit:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=de48199693484fc903627ce53b007901af2e37a8

 And current code is still:
 /* Supported except the original R600. */
 case PIPE_CAP_INDEP_BLEND_ENABLE:
 case PIPE_CAP_INDEP_BLEND_FUNC:
 /* R600 doesn't support per-MRT blends */
 return family == CHIP_R600 ? 0 : 1;
 That seems likely, given the code :) I'll be happy to split up the
 R600/R700 columns should I get a R600 glxinfo output (in case there
 are further discrepancies, best to go off the real thing rather than
 hand-editing). I believe the one I have now is from a RV770 which is a
 R700.

   -ilia

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

Re: [Mesa-dev] RFC: per-driver extension lists

[Benjamin Bellec]

Hi,

Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is
not enabled on Radeon HD2900 (R600 codename) due to hardware limitation.
I have no R600 card to check glxinfo.

David Airlie enabled this extension with this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=de48199693484fc903627ce53b007901af2e37a8

And current code is still:
/* Supported except the original R600. */
case PIPE_CAP_INDEP_BLEND_ENABLE:
case PIPE_CAP_INDEP_BLEND_FUNC:
/* R600 doesn't support per-MRT blends */
return family == CHIP_R600 ? 0 : 1;


Regards.

Benjamin Bellec

Le 28/03/2014 22:38, Aaron Watry a écrit :
 On Fri, Mar 28, 2014 at 10:32 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
 On Fri, Mar 28, 2014 at 11:14 AM, Aaron Watry awa...@gmail.com wrote:
 Do people have opinions on whether it'd be useful to also gather data
 for older hardware? FWIW I threw my TNT2 in there, which is probably
 among the oldest hw supported by mesa.

 I'm not sure if it's worthwhile or not, but if you want/need it, I've
 got a Radeon x1950 at home that I can pop in for a r300g run.
 I'm uncertain of the usefulness, but if you give it to me, I'll throw
 it up there.
 I'll give it a run on a spare system later. Probably mesa 10.1, but
 I'll have to see what's installed on that machine when I get home.

 Any other suggestions? As a reminder, the current list is available at
 http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html (defaults
 to core context, so older stuff doesn't show up, click on 'compat' to
 see it).

 I like the UI in general, the one suggestion that I have at the moment
 is to split div id=table into two divs.  Anchor the driver
 names/generations to the top of the window (position:fixed) and allow
 the table content to continue to be scrolled.  That way you always
 have the card names at the top of your screen.  You'll probably need
 to add a dynamically-sized spacer to the top of the 2nd div, but I'll
 leave that as an exercise to the reader.
 Good idea. One problem with position:fixed is that it doesn't
 (didn't?) work on mobile browsers. I'll give it a shot though.
 Ahh, yeah...  I haven't tried it on mobile...  I spend my days doing
 desktop web software, not mobile. If it works, great, if not, then
 it's not the end of the world..

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

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

Re: [Mesa-dev] RFC: per-driver extension lists

[Benjamin Bellec]

I tried to get some data in the Phoronix forum, without success for the
moment:
http://www.phoronix.com/forums/showthread.php?98234-Can-someone-provides-me-an-glxinfo-output-of-Radeon-HD2900-series-%28R600%29

Maybe we should ask Michael Larabel to write an appeal to witnesses :-)

That said, is this extension is mandatory do be OpenGL 3.0 compliant?
(I don't know how really works the OpenGL specification)
Does the R600 cards can expose GL3.0 in glxinfo without this extension?

Benjamin

Le 31/03/2014 20:43, Ilia Mirkin a écrit :
 On Mon, Mar 31, 2014 at 2:39 PM, Benjamin Bellec b.bel...@gmail.com wrote:
 Hi,

 Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is
 not enabled on Radeon HD2900 (R600 codename) due to hardware limitation.
 I have no R600 card to check glxinfo.

 David Airlie enabled this extension with this commit:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=de48199693484fc903627ce53b007901af2e37a8

 And current code is still:
 /* Supported except the original R600. */
 case PIPE_CAP_INDEP_BLEND_ENABLE:
 case PIPE_CAP_INDEP_BLEND_FUNC:
 /* R600 doesn't support per-MRT blends */
 return family == CHIP_R600 ? 0 : 1;
 That seems likely, given the code :) I'll be happy to split up the
 R600/R700 columns should I get a R600 glxinfo output (in case there
 are further discrepancies, best to go off the real thing rather than
 hand-editing). I believe the one I have now is from a RV770 which is a
 R700.

   -ilia

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

Re: [Mesa-dev] Mesa git (r600g): OpenGL Error(GL_INVALID_OPERATION): initTexture2D

[Benjamin Bellec]

Hi,

Could you bisect?
Or provide an easy way to build ogl-samples!

Regards.

Le 17/03/2014 15:34, Dieter Nützel a écrit :
 Trying to run ogl-samples GL 3.2+ tests on my RV730 AGP.

 /opt/ogl-samples ./build/release/gl-320-primitive-sprite
 libGL: screen 0 does not appear to be DRI3 capable
 libGL: pci id for fd 4: 1002:9495, driver r600
 libGL: OpenDriver: trying /usr/lib/dri/updates/tls/r600_dri.so
 libGL: OpenDriver: trying /usr/lib/dri/updates/r600_dri.so
 libGL: driver does not expose __driDriverGetExtensions_r600():
 /usr/lib/dri/updates/r600_dri.so: undefined symbol:
 __driDriverGetExtensions_r600
 libGL: Can't open configuration file /home/dieter/.drirc: No such file
 or directory.
 libGL: Can't open configuration file /home/dieter/.drirc: No such file
 or directory.
 OpenGL Version Needed 3.2 ( 3.3 Found )
 OpenGL Error(GL_INVALID_OPERATION): initTexture2D
 Running Test
 Test Ended

 Worked OK ~10 days ago.

 When I run Mesa 10.1.0 final, it is OK.

 OpenGL vendor string: X.Org
 OpenGL renderer string: Gallium 0.4 on AMD RV730
 OpenGL core profile version string: 3.3 (Core Profile) Mesa
 10.2.0-devel (git-7e0396d)
 OpenGL core profile shading language version string: 3.30
 OpenGL core profile context flags: (none)
 OpenGL core profile profile mask: core profile
 OpenGL core profile extensions:
 OpenGL version string: 3.0 Mesa 10.2.0-devel (git-7e0396d)
 OpenGL shading language version string: 1.30
 OpenGL context flags: (none)
 OpenGL extensions:

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

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

Re: [Mesa-dev] How do I start contributing to Mesa?

[Benjamin Bellec]

Le 04/06/2013 21:54, Brian Paul a écrit :
 On 06/04/2013 06:37 AM, Arnas Milaševičius wrote:
 Hello,

 First of all, I'm not sure if it's the right place to ask such a
 question, but I'll try. I've started learning OpenGL and I really want
 to contribute to Mesa project, but the way to do it had always been a
 mistery for me. As a beginner contributor, I still don't understand
 which bugs should I take, how do I fix em? It's like, you take the bug,
 but... where the heck do you start fixing it? How do you find the core
 of the problem? I see many people telling that the best start is to
 start fixing bugs you have, but atm I don't have any problems that'd
 bother me.

 Probably the easiest bugs to fix are those that fail on assertions or
 crash.  With those you can at least get a stack trace in the debugger
 and get some idea of the code path involved.  With general rendering
 bugs it's often harder to know where to start looking.

 Otherwise, which driver are you using or are you interested in?  It's
 sometimes easier to focus on one particular area of mesa (such as a
 driver, or say the GLSL compiler) than to try to understand everything.


 So, could anyone point me to the right direction? Maybe share your
 experience, how did you start, what do you do when you start fixing bugs
 and how should I fix em as a beginner, etc?

 Again, if there's a particular of area of interest to you, start
 there.  Read the source code.  If you find the comments lacking, post
 patches to improve the comments as you figure things out.

 There's a terribly out-dated helpwanted.html file in the docs
 directory which was intended to list things to be worked on.  It would
 probably be better if were more active in creating Bugzilla entries
 for to-do items that we'd like to do but don't always have time for. 
 I'm sure we could come up with some easier things for newbies.  I
 could probably come up with 1 or 2 things pretty quickly...
Hello,

I also think that it would be very interesting for beginners (like me)
that experimented mesa developpers writes some easy (even trivial!) TODO
things on the wiki (for instance
http://dri.freedesktop.org/wiki/R600ToDo/) or elsewhere. Tasks that you
(as experimented) consider very easy, useless or with very low
priority... for beginners these kind of tasks could already be a hard
work to begin with.

Regards.

Benjamin


 -Brian

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

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

[Mesa-dev] bad libdrm_radeon version for scons

[Benjamin Bellec]

Hello,

Just to report that libdrm_radeon version (2.4.44) has not been updated
in scons/gallium.py too (still at version 2.4.42).

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

[Mesa-dev] r600g: status of my work on the shader optimization

[Benjamin Bellec]

Hello,

Does your branch should works on R700 ?
I tested it on a RV770 but get many corruptions on Counter Strike Source
(native). I haven't tested anything else.

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

Re: [Mesa-dev] Help for a beginner

[Benjamin Bellec]

Le 06/10/2011 08:09, Romain Failliot a écrit :
 2011/9/27 Romain Failliot romain.faill...@foolstep.com:
 I'll get my hand in the code now.
 Be right back as soon as I can run my own mesa code :)
 
 Sorry for the delay, I lost my internet connection for a week...
 So I started compiling mesa thanks to the site Benjamin Bellec gave to
 me http://forums.fedora-fr.org/viewtopic.php?id=51681
 And with this simple command line:
 
 $ ./autogen.sh --with-gallium-drivers=nouveau --with-dri-drivers=
 
 Everything went well. (I'm not sure about the empty parameter for the
 dri drivers though)
 
 But my first problem occured: although I changed my LD_LIBRARY_PATH,
 graphic drivers are still those from nvidia. Here is the result of the
 glxinfo:
 
 $ glxinfo | grep OpenGL version string
 OpenGL version string: 2.1.2 NVIDIA 280.13
 
 Any idea?

Hello Romain.

You should ask this kind of question in the related forum instead of in
the mesa-dev list ;-)

Regards.

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

Re: [Mesa-dev] Help for a beginner

[Benjamin Bellec]

Le 26/09/2011 20:25, Romain Failliot a écrit :
 At first, it would be questions like how to run my own compiled mesa drivers?
 I should handle getting the code, compiling it and editing it.
 Things I've never done (or almost never) is submitting a patch to a
 floss project.
I wrote some words on this (in french) here:
http://forums.fedora-fr.org/viewtopic.php?id=51681
Its still updated despite the title of the topic.

 But the ultimate first question would be: where is the bug tracker? :)
https://bugs.freedesktop.org/

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

[Mesa-dev] r6xx PIPE_CAP_MAX_RENDER_TARGETS

[Benjamin Bellec]

Hello,

In src/gallium/drivers/r600/r600_pipe.c I saw this :

/* Render targets. */
case PIPE_CAP_MAX_RENDER_TARGETS:
/* FIXME some r6xx are buggy and can only do 4 */
return 8;

The last line of R6xx_R7xx_3D.pdf says :
4 MRT + 8-Sample Restriction
On RV610, there is a maximum of 4 enabled render targets for 8-sample
surfaces.

Is this related ?
I don't know what is 8-sample surfaces... so I don't know if the
attached fix is as simple as this.

Regards.

Benjamin Bellec
diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c
index 48b0fe9..a82f9bb 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -398,8 +398,8 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param)
 
 	/* Render targets. */
 	case PIPE_CAP_MAX_RENDER_TARGETS:
-		/* FIXME some r6xx are buggy and can only do 4 */
-		return 8;
+		/* On RV610, there is a maximum of 4 enabled render targets for 8-sample surfaces */
+		return family == CHIP_RV610 ? 4 : 8;
 
 	/* Timer queries, present when the clock frequency is non zero. */
 	case PIPE_CAP_TIMER_QUERY:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] faster logbase2() - again

[Benjamin Bellec]

On a Roland Scheidegger idea!

Benjamin
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 3e42911..da2e72f 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -86,6 +86,12 @@ _mesa_free_texmemory(void *m)
 static GLuint
 logbase2(GLuint n)
 {
+#if defined(PIPE_CC_GCC)  (PIPE_CC_GCC_VERSION = 340)
+   if (n = 1)
+  return 0;
+   
+   return (31 - __builtin_clz(n | 1));
+#else
GLuint pos = 0;
if (n = 116) { n = 16; pos += 16; }
if (n = 1 8) { n =  8; pos +=  8; }
@@ -93,6 +99,7 @@ logbase2(GLuint n)
if (n = 1 2) { n =  2; pos +=  2; }
if (n = 1 1) {   pos +=  1; }
return pos;
+#endif
 }
 
 
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..cde9c92 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -477,6 +477,12 @@ float_to_byte_tex(float f)
 static INLINE unsigned
 util_logbase2(unsigned n)
 {
+#if defined(PIPE_CC_GCC)  (PIPE_CC_GCC_VERSION = 340)
+   if (n = 1)
+  return 0;
+   
+   return (31 - __builtin_clz(n | 1));
+#else
unsigned pos = 0;
if (n = 116) { n = 16; pos += 16; }
if (n = 1 8) { n =  8; pos +=  8; }
@@ -484,6 +490,7 @@ util_logbase2(unsigned n)
if (n = 1 2) { n =  2; pos +=  2; }
if (n = 1 1) {   pos +=  1; }
return pos;
+#endif
 }
 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] faster logbase2() - again

[Benjamin Bellec]

Le 08/06/2011 22:08, Roland Scheidegger a écrit :
 Looks good to me - but skip the special n = 1 case that's what the
 (n|1) input to the __builtin_clz is good for.
Ok, I'm not familiar with bit manipulation in fact...

 Oh and I didn't notice before but there's an error in the gcc version
 check (as that's defined as (__GNUC__ * 100 + __GNUC_MINOR__) - we're
 ignoring patchlevel). Though as said there's the popcount usage right
 next to it which doesn't do a version check neither - if that's the only
 thing requiring gcc 3.4 we should fix that otherwise could just make gcc
 3.4 a requirement.
Ok I did'nt know that.

Here is my 3 patchs fixed. I hope this are the last of the series :-)

Benjamin
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..9d82cc5 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -493,17 +493,29 @@ util_logbase2(unsigned n)
 static INLINE unsigned
 util_next_power_of_two(unsigned x)
 {
-   unsigned i;
+#if defined(PIPE_CC_GCC)
+   if (x = 1)
+   return 1;
+   
+   return (1  ((sizeof(unsigned) * 8) - __builtin_clz(x - 1)));
+#else
+   unsigned val = x;
 
-   if (x == 0)
+   if (x = 1)
   return 1;
 
-   --x;
-
-   for (i = 1; i  sizeof(unsigned) * 8; i = 1)
-  x |= x  i;
-
-   return x + 1;
+   if (util_is_power_of_two(x))
+  return x;
+
+   val--;
+   val = (val  1) | val;
+   val = (val  2) | val;
+   val = (val  4) | val;
+   val = (val  8) | val;
+   val = (val  16) | val;
+   val++;
+   return val;
+#endif
 }
 
 
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..294f964 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -477,6 +477,9 @@ float_to_byte_tex(float f)
 static INLINE unsigned
 util_logbase2(unsigned n)
 {
+#if defined(PIPE_CC_GCC)
+   return (31 - __builtin_clz(n | 1));
+#else
unsigned pos = 0;
if (n = 116) { n = 16; pos += 16; }
if (n = 1 8) { n =  8; pos +=  8; }
@@ -484,6 +487,7 @@ util_logbase2(unsigned n)
if (n = 1 2) { n =  2; pos +=  2; }
if (n = 1 1) {   pos +=  1; }
return pos;
+#endif
 }
 
 
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 3e42911..6ca1bd9 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -86,6 +86,9 @@ _mesa_free_texmemory(void *m)
 static GLuint
 logbase2(GLuint n)
 {
+#if defined(PIPE_CC_GCC)
+   return (31 - __builtin_clz(n | 1));
+#else
GLuint pos = 0;
if (n = 116) { n = 16; pos += 16; }
if (n = 1 8) { n =  8; pos +=  8; }
@@ -93,6 +96,7 @@ logbase2(GLuint n)
if (n = 1 2) { n =  2; pos +=  2; }
if (n = 1 1) {   pos +=  1; }
return pos;
+#endif
 }
 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function

[Benjamin Bellec]

Le 06/06/2011 17:34, Roland Scheidegger a écrit :
 Am 05.06.2011 03:55, schrieb Benjamin Bellec:
 Le 05/06/2011 03:05, Matt Turner a écrit :
 On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec b.bel...@gmail.com wrote:
 Le 03/06/2011 06:09, Matt Turner a écrit :
 Also, if you want to check if the value is already a power-of-two,
 instead of a case statement for every POT (including 0), just do the
 standard is-power-of-two check:

 (x  (x - 1)) == 0

 My own tests (on a Core2) shows that it's less efficient to do that, at
 least with -O2 optimization enabled. With -O0, it's equal.

 For what input set? Powers of two?
 Both, my test case loops with 29 POT and 6 NPOT.
 I'm doing this because the OpenGL games that I have tested call the
 function more often with good values.


 Doesn't really matter, since the function isn't a hot path or
 anything, but I'd suppose that the Linux kernel has its
 is_power_of_2() function for a reason--that it's pretty ugly to have
 lots of case statements like powers of two.

 Matt
 Ok, so here is a v3 patch which replace the switch statement.
 
 I like this one better too.
 Do we actually need the x == 0 special case or would it be ok if we just
 remove that (which will return 0)?
 
 Roland

If we delete this check, we need to specify (in a comment) that the
function have an undetermined behavior when passing 0 in parameters. Why
not, but then the most important thing to know is from where the
parameters came from: mesa or GL apps? If it's from GL apps it could
be dangerous to change the result of this function, even if 0 is a
stupid input (no?).

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

Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function

[Benjamin Bellec]

Le 03/06/2011 01:40, Brian Paul a écrit :
 I'd like to avoid the warning if at all possible.  If you replace (val
 32) with (val  (sizeof(unsigned) * 4)) does that silence it?

Yes it fix, but as Matt Turner said, it's not necessary to check this.
Btw we don't check that in the other functions.


Le 03/06/2011 06:09, Matt Turner a écrit :
 Also, if you want to check if the value is already a power-of-two,
 instead of a case statement for every POT (including 0), just do the
 standard is-power-of-two check:

 (x  (x - 1)) == 0

My own tests (on a Core2) shows that it's less efficient to do that, at
least with -O2 optimization enabled. With -O0, it's equal.

So here is a v2 patch with a builtin GCC optimization which is the
fastest (thx Matt to point me to this solution).

Regards.

Benjamin Bellec
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..1b984b6 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -42,7 +42,6 @@
 #include pipe/p_compiler.h
 #include util/u_debug.h
 
-
 #ifdef __cplusplus
 extern C {
 #endif
@@ -486,24 +485,49 @@ util_logbase2(unsigned n)
return pos;
 }
 
-
 /**
  * Returns the smallest power of two = x
  */
 static INLINE unsigned
 util_next_power_of_two(unsigned x)
 {
-   unsigned i;
-
+#if defined(PIPE_CC_GCC)
if (x == 0)
   return 1;
-
-   --x;
-
-   for (i = 1; i  sizeof(unsigned) * 8; i = 1)
-  x |= x  i;
-
-   return x + 1;
+   else
+  return (1  (32 - __builtin_clz(x - 1)));
+#else
+   unsigned val = x;
+
+   switch (x)
+   {
+  case 1:
+  case 2:
+  case 4:
+  case 8:
+  case 16:
+  case 32:
+  case 64:
+  case 128:
+  case 256:
+  case 512:
+  case 1024:
+  case 2048:
+  case 4096:
+ return x; /* this is the most commonly used values */
+  case 0:
+ return 1;
+  default:
+ val--;
+ val = (val  1) | val;
+ val = (val  2) | val;
+ val = (val  4) | val;
+ val = (val  8) | val;
+ val = (val  16) | val;
+ val++;
+ return val;
+   }
+#endif
 }
 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] faster util_next_power_of_two() function

[Benjamin Bellec]

Le 05/06/2011 03:05, Matt Turner a écrit :
 On Sat, Jun 4, 2011 at 7:14 PM, Benjamin Bellec b.bel...@gmail.com wrote:
 Le 03/06/2011 06:09, Matt Turner a écrit :
 Also, if you want to check if the value is already a power-of-two,
 instead of a case statement for every POT (including 0), just do the
 standard is-power-of-two check:

 (x  (x - 1)) == 0

 My own tests (on a Core2) shows that it's less efficient to do that, at
 least with -O2 optimization enabled. With -O0, it's equal.
 
 For what input set? Powers of two?
Both, my test case loops with 29 POT and 6 NPOT.
I'm doing this because the OpenGL games that I have tested call the
function more often with good values.

 
 Doesn't really matter, since the function isn't a hot path or
 anything, but I'd suppose that the Linux kernel has its
 is_power_of_2() function for a reason--that it's pretty ugly to have
 lots of case statements like powers of two.
 
 Matt
Ok, so here is a v3 patch which replace the switch statement.
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..f37d9cc 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -493,17 +493,30 @@ util_logbase2(unsigned n)
 static INLINE unsigned
 util_next_power_of_two(unsigned x)
 {
-   unsigned i;
+#if defined(PIPE_CC_GCC)
+   if (x == 0)
+   return 1;
+   else
+   return (1  (32 - __builtin_clz(x - 1)));
+#else
+   unsigned val = x;
 
if (x == 0)
   return 1;
 
-   --x;
-
-   for (i = 1; i  sizeof(unsigned) * 8; i = 1)
-  x |= x  i;
-
-   return x + 1;
+   /* check if x is already a power of two */
+   if ((x  (x - 1)) == 0)
+  return x;
+
+   val--;
+   val = (val  1) | val;
+   val = (val  2) | val;
+   val = (val  4) | val;
+   val = (val  8) | val;
+   val = (val  16) | val;
+   val++;
+   return val;
+#endif
 }
 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Optimize logbase2() function

[Benjamin Bellec]

Hello,

I performed several tests of the logbase2() function.
This function is defined and used in these files:

src/mesa/main/teximage.c
src/mesa/drivers/dri/intel/intel_tex_image.c
src/mesa/drivers/dri/unichrome/via_tex.c
src/mesa/drivers/dri/i965/intel_tex_image.c
src/mesa/drivers/dri/tdfx/tdfx_tex.c

There is also a util_logbase2() function in
src/gallium/auxiliary/util/u_math.c which do the same thing.

Both functions from src/mesa/main/teximage.c and
src/gallium/auxiliary/util/u_math.c are called when I play to ETQW
with r600g.

First thing: is it possible to merge this function in one place? The
same function is implement in different place. I have no sufficient
experience of the Mesa architecture to answer this myself.

Second thing: there is a C implementation in Wikipedia (
http://en.wikipedia.org/wiki/Binary_logarithm#Algorithm ), I merged it
in Mesa and I noted that it is *at least* twice faster than logbase2()
and util_logbase2() (with or without GCC optimization).

Third thing: I think it's better to use an unsigned int than a int for
the logbase2's parameter. At least in teximage.c and
intel_tex_image.c, the result is stored in a GLuint. But not in
via_tex.c

Here is a patch to merge it, at least in src/mesa/main/teximage.c. I
will understand any comments, especially on the relevance of this patch.
(The patch still uses a integer parameter).

Regards.

Benjamin Bellec
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4ea9a48..e2eeaa0 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -81,31 +81,25 @@ _mesa_free_texmemory(void *m)
 
 
 /*
- * Compute floor(log_base_2(n)).
+ * Returns the floor form of binary logarithm for a 32 bit integer.
  * If n  0 return -1.
  */
 static int
 logbase2( int n )
 {
-   GLint i = 1;
-   GLint log2 = 0;
+   if (n == 0)
+  return 0;
 
if (n  0)
   return -1;
 
-   if (n == 0)
-  return 0;
-
-   while ( n  i ) {
-  i *= 2;
-  log2++;
-   }
-   if (i != n) {
-  return log2 - 1;
-   }
-   else {
-  return log2;
-   }
+   int pos = 0;
+   if (n = 116) { n = 16; pos += 16; }
+   if (n = 1 8) { n =  8; pos +=  8; }
+   if (n = 1 4) { n =  4; pos +=  4; }
+   if (n = 1 2) { n =  2; pos +=  2; }
+   if (n = 1 1) {   pos +=  1; }
+   return pos;
 }
 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] faster util_next_power_of_two() function

[Benjamin Bellec]

It's me again, with a new minor optimization for the
util_next_power_of_two() function.

This patch implements a faster algorithm, still taken from Wikipedia (
http://en.wikipedia.org/wiki/Power_of_two#Algorithm_to_round_up_to_power_of_two
).
But especially, I added the most common values used by this function. I
noted that ETQW, TA Spring and ExtremeTuxRacer call often good values.
I can think that most OpenGL apps uses also these values.

I have benchmarked this. With -O2 optimization, this new function is
twice faster than the former. Without GCC optimization the difference is
even bigger.

There is no piglit regressions.

But there is an issue, during compilation there is an error (-Wall)
warning: right shift count = width of type [enabled by default].

Regards.

Benjamin Bellec
diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h
index 65a99fc..7d260ae 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -486,24 +486,44 @@ util_logbase2(unsigned n)
return pos;
 }
 
-
 /**
  * Returns the smallest power of two = x
  */
 static INLINE unsigned
 util_next_power_of_two(unsigned x)
 {
-   unsigned i;
-
-   if (x == 0)
-  return 1;
-
-   --x;
-
-   for (i = 1; i  sizeof(unsigned) * 8; i = 1)
-  x |= x  i;
-
-   return x + 1;
+   unsigned val = x;
+
+   switch (x)
+   {
+  case 1:
+  case 2:
+  case 4:
+  case 8:
+  case 16:
+  case 32:
+  case 64:
+  case 128:
+  case 256:
+  case 512:
+  case 1024:
+  case 2048:
+  case 4096:
+ return x; /* this is the most commonly used values */
+  case 0:
+ return 1;
+  default:
+ val--;
+ val = (val  1) | val;
+ val = (val  2) | val;
+ val = (val  4) | val;
+ val = (val  8) | val;
+ val = (val  16) | val;
+ if (sizeof(unsigned) == 8)
+val = (val  32) | val;
+ val++;
+ return val;
+   }
 }
 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] glewinfo vs piglit

[Benjamin Bellec]

Hello,

I have a simple question. If a feature is exposed by Mesa (checked by
glewinfo), but piglit tests about this extension fails, is it a bug
which must be reported ?

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

Re: [Mesa-dev] [PATCH] r600g: track dirty registers better.

[Benjamin BELLEC]

Le 18/04/2011 16:37, Benjamin BELLEC a écrit :
 Le 18/04/2011 10:20, Dave Airlie a écrit :
 On Mon, Apr 18, 2011 at 11:00 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 This is a first step to decreasing the CPU usage, by decreasing how much
 stuff we pass to the GPU and hence to the kernel CS checker.

 This adds a check to see if the values we need to write are actually dirty,
 and avoids writing if they are. However certain register need to always
 be written so we add a new flag to say which ones should be always written
 if used. (Note this could probably be done cleaner with a larger 
 refactoring,
  since I think the CONST_BUFFER_SIZE_PS/VS and CONST_CACHE_PS/VS might
 be better off as a special state).

 It also moves the need_bo to be a flags on the register now.

 With this, a frame of gears goes from emitting 3k dwords to emitting 2k 
 dwords,
 and I'm sure it could get a lot smaller.

 TODO:
 Currently we flush if we have a BO, this could probably be improved.
 Drop the special flush flag and move the buffer size ps/vs to a special 
 state.


 I've pushed a v2 of this to the r600g-dirty branch in my repo with
 another couple of patches on top

 the v2 just fixes the evergreen paths.

 The other patches cause regressions, but decrease further the amount
 of dwords per frame which should decrease time in the kernel parser,
 just have to figure out the regressions.

 Dave.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 
 Hello,
 
 I just test your branch, it breaks the 3 apps I tested :
 
 - glxgears, I do not see gears. I can see them quickly by moving the
 window at the border of my screen
 - nexuiz-sdl : the menu is break. (not tested ingame)
 - etqw : the menu is break too. In game, I have phantom frame. This is
 hard to describe, and I have no screenshots to show you exactly. To sum
 up, I have the impression that the frames are mixed.
 
 I will test your future patches (if any).
 
 Benjamin

All is now fixed.
Also, I have 15.50 % of framerate improvements in nexuiz-sdl on my
system (x86 - RV770 - 1680*1050 - No HDR - No sound)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: track dirty registers better.

[Benjamin BELLEC]

Le 18/04/2011 10:20, Dave Airlie a écrit :
 On Mon, Apr 18, 2011 at 11:00 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 This is a first step to decreasing the CPU usage, by decreasing how much
 stuff we pass to the GPU and hence to the kernel CS checker.

 This adds a check to see if the values we need to write are actually dirty,
 and avoids writing if they are. However certain register need to always
 be written so we add a new flag to say which ones should be always written
 if used. (Note this could probably be done cleaner with a larger refactoring,
  since I think the CONST_BUFFER_SIZE_PS/VS and CONST_CACHE_PS/VS might
 be better off as a special state).

 It also moves the need_bo to be a flags on the register now.

 With this, a frame of gears goes from emitting 3k dwords to emitting 2k 
 dwords,
 and I'm sure it could get a lot smaller.

 TODO:
 Currently we flush if we have a BO, this could probably be improved.
 Drop the special flush flag and move the buffer size ps/vs to a special 
 state.

 
 I've pushed a v2 of this to the r600g-dirty branch in my repo with
 another couple of patches on top
 
 the v2 just fixes the evergreen paths.
 
 The other patches cause regressions, but decrease further the amount
 of dwords per frame which should decrease time in the kernel parser,
 just have to figure out the regressions.
 
 Dave.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Hello,

I just test your branch, it breaks the 3 apps I tested :

- glxgears, I do not see gears. I can see them quickly by moving the
window at the border of my screen
- nexuiz-sdl : the menu is break. (not tested ingame)
- etqw : the menu is break too. In game, I have phantom frame. This is
hard to describe, and I have no screenshots to show you exactly. To sum
up, I have the impression that the frames are mixed.

I will test your future patches (if any).

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

Re: [Mesa-dev] r600g and S3TC

[Benjamin BELLEC]

You must use kernel 2.6.39. And then R600_ENABLE_S3TC is not useful anymore.

Le 07/04/2011 21:35, Alexandre Demers a écrit :

Hi all,

A simple question: is enabling S3TC supposed to work with latest git on
r600g? I'm using latest git and kernel 2.6.38.2. Libdrm is 2.4.24+ (git
from a couple of days). Libtxc_dxtn is latest version available from git.

When I try R600_ENABLE_S3TC=1 RendererFeatTest.bin64, I only see garbage
(automatic screenshots from the application are all black). If I don't
use the flag, the extension is disabled and RendererFeatTest works as
usual (still as some issues compared to another driver like i915 though
like no background and crippled text).


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

[Mesa-dev] [r600g + s3tc] bug or missing kernel piece of software ?

[Benjamin BELLEC]

Hello,

I have compiled the last Mesa code (and libtxc_dxtn from Marek Olšák's 
branch) in order to test the S3TC support recently pushed in r600g.
In his commit 
(http://cgit.freedesktop.org/mesa/mesa/commit/?id=8e0437914bb786d0b05be8f95e4ff37bf5a19f44), 
Dave Airlie says Still requires R600_ENABLE_S3TC until the kernel fixes 
are in, this has only been tested on evergreen where the kernel doesn't 
yet get in the way.


My GPU is a RV770 (Radeon 4850) and I have some mitigated results within 
Enemy Territory Quake Wars, so should I file a bug or wait for a kernel 
piece of software ? And if so which one ? (I'm currently on 2.6.38-rc8).


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