Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Jan Vesely
On Wed, 2017-08-16 at 23:49 -0400, Alex Deucher wrote:
> On Wed, Aug 16, 2017 at 11:34 PM, Michel Dänzer  wrote:
> > On 17/08/17 12:33 PM, Aaron Watry wrote:
> > > On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  
> > > wrote:
> > > > On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  
> > > > wrote:
> > > > > On 17/08/17 10:52 AM, Aaron Watry wrote:
> > > > > > PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page 
> > > > > > aligned,
> > > > > > but doesn't necessarily say anything about the size of those pages.
> > > > > 
> > > > > Is there any case known so far where it's not the CPU page size?
> > > > 
> > > > It's always the CPU page size.  The limitation is not a hw limitation,
> > > > it's a sw limitation with the way the kernel handles creating BOs from
> > > > user memory.
> > > 
> > > So this won't change with the 2MB pages that are coming up for Vega?
> > 
> > I don't think it will, that's only about VRAM.
> 
> It applies to system memory as well, e.g., transparent huge pages, or
> larger page sizes in general.  I don't think that affects this
> however.

what's so special about Vega 2MB pages? I thought GPUVM fragments could
specify any size (power of 2 > 4KB) even if TLBs supports anly select
few.
I remember using 4KB, 2MB, and 1GB pages with nice performance benefits
on Kaveri (using ATS, ROCm setup).

Jan

> 
> Alex
> 
> > 
> > 
> > > If so, I guess I can just use getpagesize() in patch 2 for now and skip 
> > > the CAP.
> > 
> > Right.
> > 
> > 
> > --
> > Earthling Michel Dänzer   |   http://www.amd.com
> > Libre software enthusiast | Mesa and X developer
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] ac/nir: fixup layer/viewport export for GFX9.

2017-08-16 Thread Dave Airlie
From: Dave Airlie 

GFX9 moved where the viewport index export goes.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 7aa7567..a17a232 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5518,11 +5518,11 @@ handle_vs_outputs_post(struct nir_to_llvm_context *ctx,
 
ctx->nir->outputs[radeon_llvm_reg_index_soa(VARYING_SLOT_VIEWPORT, 0)], "");
}
 
-   uint32_t mask = ((outinfo->writes_pointsize == true ? 1 : 0) |
-(outinfo->writes_layer == true ? 4 : 0) |
-(outinfo->writes_viewport_index == true ? 8 : 0));
-   if (mask) {
-   pos_args[1].enabled_channels = mask;
+   if (outinfo->writes_pointsize ||
+   outinfo->writes_layer ||
+   outinfo->writes_viewport_index) {
+   pos_args[1].enabled_channels = ((outinfo->writes_pointsize == 
true ? 1 : 0) |
+   (outinfo->writes_layer == true 
? 4 : 0));
pos_args[1].valid_mask = 0;
pos_args[1].done = 0;
pos_args[1].target = V_008DFC_SQ_EXP_POS + 1;
@@ -5536,8 +5536,26 @@ handle_vs_outputs_post(struct nir_to_llvm_context *ctx,
pos_args[1].out[0] = psize_value;
if (outinfo->writes_layer == true)
pos_args[1].out[2] = layer_value;
-   if (outinfo->writes_viewport_index == true)
-   pos_args[1].out[3] = viewport_index_value;
+   if (outinfo->writes_viewport_index == true) {
+   if (ctx->options->chip_class >= GFX9) {
+   /* GFX9 has the layer in out.z[10:0] and the 
viewport
+* index in out.z[19:16].
+*/
+   LLVMValueRef v = viewport_index_value;
+   v = to_integer(>ac, v);
+   v = LLVMBuildShl(ctx->builder, v,
+LLVMConstInt(ctx->i32, 16, 
false),
+"");
+   v = LLVMBuildOr(ctx->builder, v,
+   to_integer(>ac, 
pos_args[1].out[2]), "");
+
+   pos_args[1].out[2] = to_float(>ac, v);
+   pos_args[1].enabled_channels |= 1 << 2;
+   } else {
+   pos_args[1].out[3] = viewport_index_value;
+   pos_args[1].enabled_channels |= 1 << 3;
+   }
+   }
}
for (i = 0; i < 4; i++) {
if (pos_args[i].out[0])
-- 
2.9.4

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


Re: [Mesa-dev] [PATCH] clover/device: Calculate CL_DEVICE_MEM_BASE_ADDR_ALIGN in device

2017-08-16 Thread Jan Vesely
On Wed, 2017-08-16 at 22:54 -0500, Aaron Watry wrote:
> The CL CTS queries CL_DEVICE_MEM_BASE_ADDR_ALIGN for a device and
> then allocates user pointers aligned to that value for its tests.
> 
> The minimum value is defined as:
>   the size (in bits) of the largest OpenCL built-in data type supported
>   by the device (long16 in FULL profile, long16 or int16 in EMBEDDED
>   profile) for devices that are not of type CL_DEVICE_TYPE_CUSTOM.
> 
> At the moment, all known devices that support user pointers require
> CPU page alignment for buffers created from user pointers, so just
> query that from sysconf.
> 
> v2: Use system page size instead of a new pipe cap

system page size makes sense.
LGTM. Reviewed-by: Jan Vesely 

Jan

> 
> Signed-off-by: Aaron Watry 
> Cc: Francisco Jerez 
> Cc: Jan Vesely 
> ---
>  src/gallium/state_trackers/clover/api/device.cpp  | 3 ++-
>  src/gallium/state_trackers/clover/core/device.cpp | 5 +
>  src/gallium/state_trackers/clover/core/device.hpp | 1 +
>  3 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
> b/src/gallium/state_trackers/clover/api/device.cpp
> index b1b7917e4e..b5ffe110be 100644
> --- a/src/gallium/state_trackers/clover/api/device.cpp
> +++ b/src/gallium/state_trackers/clover/api/device.cpp
> @@ -205,7 +205,8 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
>break;
>  
> case CL_DEVICE_MEM_BASE_ADDR_ALIGN:
> -  buf.as_scalar() = 128 * 8;
> +  buf.as_scalar() = 8 *
> + MAX2(dev.mem_base_addr_align(), sizeof(cl_long) * 16);
>break;
>  
> case CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE:
> diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
> b/src/gallium/state_trackers/clover/core/device.cpp
> index f6bbc38a98..c5964bc6e3 100644
> --- a/src/gallium/state_trackers/clover/core/device.cpp
> +++ b/src/gallium/state_trackers/clover/core/device.cpp
> @@ -194,6 +194,11 @@ device::has_unified_memory() const {
> return pipe->get_param(pipe, PIPE_CAP_UMA);
>  }
>  
> +cl_uint
> +device::mem_base_addr_align() const {
> +   return sysconf(_SC_PAGESIZE);
> +}
> +
>  std::vector
>  device::max_block_size() const {
> auto v = get_compute_param(pipe, ir_format(),
> diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
> b/src/gallium/state_trackers/clover/core/device.hpp
> index efc217aedb..4e11519421 100644
> --- a/src/gallium/state_trackers/clover/core/device.hpp
> +++ b/src/gallium/state_trackers/clover/core/device.hpp
> @@ -68,6 +68,7 @@ namespace clover {
>bool image_support() const;
>bool has_doubles() const;
>bool has_unified_memory() const;
> +  cl_uint mem_base_addr_align() const;
>  
>std::vector max_block_size() const;
>cl_uint subgroup_size() const;

-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] clover/device: Calculate CL_DEVICE_MEM_BASE_ADDR_ALIGN in device

2017-08-16 Thread Aaron Watry
The CL CTS queries CL_DEVICE_MEM_BASE_ADDR_ALIGN for a device and
then allocates user pointers aligned to that value for its tests.

The minimum value is defined as:
  the size (in bits) of the largest OpenCL built-in data type supported
  by the device (long16 in FULL profile, long16 or int16 in EMBEDDED
  profile) for devices that are not of type CL_DEVICE_TYPE_CUSTOM.

At the moment, all known devices that support user pointers require
CPU page alignment for buffers created from user pointers, so just
query that from sysconf.

v2: Use system page size instead of a new pipe cap

Signed-off-by: Aaron Watry 
Cc: Francisco Jerez 
Cc: Jan Vesely 
---
 src/gallium/state_trackers/clover/api/device.cpp  | 3 ++-
 src/gallium/state_trackers/clover/core/device.cpp | 5 +
 src/gallium/state_trackers/clover/core/device.hpp | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index b1b7917e4e..b5ffe110be 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -205,7 +205,8 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_MEM_BASE_ADDR_ALIGN:
-  buf.as_scalar() = 128 * 8;
+  buf.as_scalar() = 8 *
+ MAX2(dev.mem_base_addr_align(), sizeof(cl_long) * 16);
   break;
 
case CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index f6bbc38a98..c5964bc6e3 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -194,6 +194,11 @@ device::has_unified_memory() const {
return pipe->get_param(pipe, PIPE_CAP_UMA);
 }
 
+cl_uint
+device::mem_base_addr_align() const {
+   return sysconf(_SC_PAGESIZE);
+}
+
 std::vector
 device::max_block_size() const {
auto v = get_compute_param(pipe, ir_format(),
diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
b/src/gallium/state_trackers/clover/core/device.hpp
index efc217aedb..4e11519421 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -68,6 +68,7 @@ namespace clover {
   bool image_support() const;
   bool has_doubles() const;
   bool has_unified_memory() const;
+  cl_uint mem_base_addr_align() const;
 
   std::vector max_block_size() const;
   cl_uint subgroup_size() const;
-- 
2.11.0

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


Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Alex Deucher
On Wed, Aug 16, 2017 at 11:34 PM, Michel Dänzer  wrote:
> On 17/08/17 12:33 PM, Aaron Watry wrote:
>> On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  wrote:
>>> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  wrote:
 On 17/08/17 10:52 AM, Aaron Watry wrote:
> PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
> but doesn't necessarily say anything about the size of those pages.

 Is there any case known so far where it's not the CPU page size?
>>>
>>> It's always the CPU page size.  The limitation is not a hw limitation,
>>> it's a sw limitation with the way the kernel handles creating BOs from
>>> user memory.
>>
>> So this won't change with the 2MB pages that are coming up for Vega?
>
> I don't think it will, that's only about VRAM.

It applies to system memory as well, e.g., transparent huge pages, or
larger page sizes in general.  I don't think that affects this
however.

Alex

>
>
>> If so, I guess I can just use getpagesize() in patch 2 for now and skip the 
>> CAP.
>
> Right.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Michel Dänzer
On 17/08/17 12:33 PM, Aaron Watry wrote:
> On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  wrote:
>> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  wrote:
>>> On 17/08/17 10:52 AM, Aaron Watry wrote:
 PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
 but doesn't necessarily say anything about the size of those pages.
>>>
>>> Is there any case known so far where it's not the CPU page size?
>>
>> It's always the CPU page size.  The limitation is not a hw limitation,
>> it's a sw limitation with the way the kernel handles creating BOs from
>> user memory.
> 
> So this won't change with the 2MB pages that are coming up for Vega?

I don't think it will, that's only about VRAM.


> If so, I guess I can just use getpagesize() in patch 2 for now and skip the 
> CAP.

Right.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Aaron Watry
On Wed, Aug 16, 2017 at 9:48 PM, Alex Deucher  wrote:
> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  wrote:
>> On 17/08/17 10:52 AM, Aaron Watry wrote:
>>> PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
>>> but doesn't necessarily say anything about the size of those pages.
>>
>> Is there any case known so far where it's not the CPU page size?
>
> It's always the CPU page size.  The limitation is not a hw limitation,
> it's a sw limitation with the way the kernel handles creating BOs from
> user memory.

So this won't change with the 2MB pages that are coming up for Vega?

If so, I guess I can just use getpagesize() in patch 2 for now and skip the CAP.

--Aaron

>
> Alex
>
>>
>>
>> --
>> Earthling Michel Dänzer   |   http://www.amd.com
>> Libre software enthusiast | Mesa and X developer
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Michel Dänzer
On 17/08/17 11:48 AM, Alex Deucher wrote:
> On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  wrote:
>> On 17/08/17 10:52 AM, Aaron Watry wrote:
>>> PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
>>> but doesn't necessarily say anything about the size of those pages.
>>
>> Is there any case known so far where it's not the CPU page size?
> 
> It's always the CPU page size.  The limitation is not a hw limitation,
> it's a sw limitation with the way the kernel handles creating BOs from
> user memory.

Right, I suspect "page" in the PIPE_CAP_RESOURCE_FROM_USER_MEMORY
documentation was always intended as "CPU page". Maybe that just needs
to be clarified.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Alex Deucher
On Wed, Aug 16, 2017 at 10:39 PM, Michel Dänzer  wrote:
> On 17/08/17 10:52 AM, Aaron Watry wrote:
>> PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
>> but doesn't necessarily say anything about the size of those pages.
>
> Is there any case known so far where it's not the CPU page size?

It's always the CPU page size.  The limitation is not a hw limitation,
it's a sw limitation with the way the kernel handles creating BOs from
user memory.

Alex

>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Michel Dänzer
On 17/08/17 10:52 AM, Aaron Watry wrote:
> PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
> but doesn't necessarily say anything about the size of those pages.

Is there any case known so far where it's not the CPU page size?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 0/3] mesa: Modify drirc options

2017-08-16 Thread QuRyu
This serie of patches changes drirc's semanticaclly boolean options, options 
that are enum type options but which in essence are boolean options e.g. 
pp_shalde, into actual boolean optioinns. 

Backwawrd compatbility is maintained by relaxinig xmlconfig parser so that xml 
files before this change can still be parsed correctly. 
Driconf, unfortunately, will be affected by this. The issue will be addressedd 
later by releasing a new version of Driconf.

Also note that these changes are made to fulfil requirementss to participate in 
EVoC (Endless Vacaction of Code) hosted by X.org. 

QuRyu (3):
  mesa: Modify type of drirc options
  mesa: Modify drirc's default option values
  mesa: Fix backward compatbility for XML parser

 .../auxiliary/pipe-loader/driinfo_gallium.h|  8 
 src/util/xmlconfig.c   | 22 --
 src/util/xmlpool/t_options.h   |  8 
 3 files changed, 28 insertions(+), 10 deletions(-)

-- 
2.7.4

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


[Mesa-dev] [PATCH 3/3] mesa: Fix backward compatbility for XML parser

2017-08-16 Thread QuRyu
After changing the type of drirc values, the parser will be unable to
recognize xml files before the change. To achieve backward compatbility,
the parser is relaxed to recognize boolean type options with enum values.
---
 src/util/xmlconfig.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/util/xmlconfig.c b/src/util/xmlconfig.c
index d3f47ec..2999f24 100644
--- a/src/util/xmlconfig.c
+++ b/src/util/xmlconfig.c
@@ -317,8 +317,26 @@ parseValue(driOptionValue *v, driOptionType type, const 
XML_Char *string)
 v->_bool = true;
 tail = string + 4;
 }
-else
-return false;
+else {
+/** Some drirc options, such as pp_shalde, were formerly enum 
values.
+ *  Now that they have been turned into boolean values, to achieve 
+ *  backward compatbility relax the check here a little bit */
+XML_Char *start = string; 
+int value = strToI(string, , 0);
+if (tail == start) {
+/* no enum value found  */
+string = start; 
+return false;
+} else {
+if (value == 1) 
+v->_bool = true;
+else if (value == 0) 
+v->_bool = false;
+else 
+return false; /* wrong value here */
+}
+   }
+
 break;
   case DRI_ENUM: /* enum is just a special integer */
   case DRI_INT:
-- 
2.7.4

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


[Mesa-dev] [PATCH 1/3] mesa: Modify type of drirc options

2017-08-16 Thread QuRyu
Turn all drirc's semantically boolean options into actual boolean options.
---
 src/util/xmlpool/t_options.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index d3f31fc..4ea3615 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -220,22 +220,22 @@ DRI_CONF_OPT_BEGIN_B(float_depth, def) \
 DRI_CONF_OPT_END
 
 #define DRI_CONF_PP_CELSHADE(def) \
-DRI_CONF_OPT_BEGIN_V(pp_celshade,enum,def,"0:1") \
+DRI_CONF_OPT_BEGIN_B(pp_celshade,def) \
 DRI_CONF_DESC(en,gettext("A post-processing filter to cel-shade the 
output")) \
 DRI_CONF_OPT_END
 
 #define DRI_CONF_PP_NORED(def) \
-DRI_CONF_OPT_BEGIN_V(pp_nored,enum,def,"0:1") \
+DRI_CONF_OPT_BEGIN_B(pp_nored,def) \
 DRI_CONF_DESC(en,gettext("A post-processing filter to remove the red 
channel")) \
 DRI_CONF_OPT_END
 
 #define DRI_CONF_PP_NOGREEN(def) \
-DRI_CONF_OPT_BEGIN_V(pp_nogreen,enum,def,"0:1") \
+DRI_CONF_OPT_BEGIN_B(pp_nogreen,def) \
 DRI_CONF_DESC(en,gettext("A post-processing filter to remove the green 
channel")) \
 DRI_CONF_OPT_END
 
 #define DRI_CONF_PP_NOBLUE(def) \
-DRI_CONF_OPT_BEGIN_V(pp_noblue,enum,def,"0:1") \
+DRI_CONF_OPT_BEGIN_B(pp_noblue,def) \
 DRI_CONF_DESC(en,gettext("A post-processing filter to remove the blue 
channel")) \
 DRI_CONF_OPT_END
 
-- 
2.7.4

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


[Mesa-dev] [PATCH 2/3] mesa: Modify drirc's default option values

2017-08-16 Thread QuRyu
To complement the last change made to drirc options, default option values 
should also be changed.
---
 src/gallium/auxiliary/pipe-loader/driinfo_gallium.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h 
b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
index 48a57c9..2327446 100644
--- a/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
+++ b/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h
@@ -8,10 +8,10 @@ DRI_CONF_SECTION_END
 
 DRI_CONF_SECTION_QUALITY
DRI_CONF_FORCE_S3TC_ENABLE("false")
-   DRI_CONF_PP_CELSHADE(0)
-   DRI_CONF_PP_NORED(0)
-   DRI_CONF_PP_NOGREEN(0)
-   DRI_CONF_PP_NOBLUE(0)
+   DRI_CONF_PP_CELSHADE("false")
+   DRI_CONF_PP_NORED("false")
+   DRI_CONF_PP_NOGREEN("false")
+   DRI_CONF_PP_NOBLUE("false")
DRI_CONF_PP_JIMENEZMLAA(0, 0, 32)
DRI_CONF_PP_JIMENEZMLAA_COLOR(0, 0, 32)
 DRI_CONF_SECTION_END
-- 
2.7.4

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


[Mesa-dev] [PATCH] glsl: add a few missing int64 constant propagation cases

2017-08-16 Thread Ilia Mirkin
Fixes KHR-GL45.shader_ballot_tests.ShaderBallotAvailability, which
causes some silly swizzles to appear, triggering this optimization to
get hit.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/compiler/glsl/ir_constant_expression.cpp   | 2 ++
 src/compiler/glsl/opt_constant_propagation.cpp | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/src/compiler/glsl/ir_constant_expression.cpp 
b/src/compiler/glsl/ir_constant_expression.cpp
index 25b00a749f2..2fc23baba79 100644
--- a/src/compiler/glsl/ir_constant_expression.cpp
+++ b/src/compiler/glsl/ir_constant_expression.cpp
@@ -732,6 +732,8 @@ ir_swizzle::constant_expression_value(void *mem_ctx,
  case GLSL_TYPE_FLOAT: data.f[i] = v->value.f[swiz_idx[i]]; break;
  case GLSL_TYPE_BOOL:  data.b[i] = v->value.b[swiz_idx[i]]; break;
  case GLSL_TYPE_DOUBLE:data.d[i] = v->value.d[swiz_idx[i]]; break;
+ case GLSL_TYPE_UINT64:data.u64[i] = v->value.u64[swiz_idx[i]]; break;
+ case GLSL_TYPE_INT64: data.i64[i] = v->value.i64[swiz_idx[i]]; break;
  default:  assert(!"Should not get here."); break;
  }
   }
diff --git a/src/compiler/glsl/opt_constant_propagation.cpp 
b/src/compiler/glsl/opt_constant_propagation.cpp
index 52e3937bb11..05dc71efb72 100644
--- a/src/compiler/glsl/opt_constant_propagation.cpp
+++ b/src/compiler/glsl/opt_constant_propagation.cpp
@@ -238,6 +238,12 @@ 
ir_constant_propagation_visitor::constant_propagation(ir_rvalue **rvalue) {
   case GLSL_TYPE_BOOL:
 data.b[i] = found->constant->value.b[rhs_channel];
 break;
+  case GLSL_TYPE_UINT64:
+data.u64[i] = found->constant->value.u64[rhs_channel];
+break;
+  case GLSL_TYPE_INT64:
+data.i64[i] = found->constant->value.i64[rhs_channel];
+break;
   default:
 assert(!"not reached");
 break;
-- 
2.13.0

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


Re: [Mesa-dev] [PATCH] winsys/svga/drm: Include sys/types.h

2017-08-16 Thread Brian Paul

On 08/16/2017 08:11 PM, Khem Raj wrote:

vmw_screen.h uses dev_t which is defines in sys/types.h
this header is required to be included for getting dev_t
definition. This issue happens on musl C library, it is hidden
on glibc since sys/types.h is included through another
system headers

Signed-off-by: Khem Raj 
---
  src/gallium/winsys/svga/drm/vmw_screen.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen.h 
b/src/gallium/winsys/svga/drm/vmw_screen.h
index f21cabb51f..4c972fdaa9 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen.h
+++ b/src/gallium/winsys/svga/drm/vmw_screen.h
@@ -41,6 +41,7 @@
  #include "svga_winsys.h"
  #include "pipebuffer/pb_buffer_fenced.h"
  #include 
+#include 

  #define VMW_GMR_POOL_SIZE (16*1024*1024)
  #define VMW_QUERY_POOL_SIZE (8192)



Reviewed-by: Brian Paul 

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


Re: [Mesa-dev] [PATCH v2] configure: Check llvm-config --shared-mode

2017-08-16 Thread Dieter Nützel

Tested-by: Dieter Nützel 

with

./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-gallium-drivers=r600,radeonsi,swrast --with-platforms=drm,x11 
--enable-nine --enable-texture-float --enable-opencl --enable-opencl_icd 
--with-vulkan-drivers=radeon


again.

Dieter

Am 16.08.2017 08:40, schrieb Michel Dänzer:

From: Michel Dänzer 

https://bugs.llvm.org/show_bug.cgi?id=6823 still affects current LLVM.
llvm-config --libs only reports the single shared library if LLVM was
built with -DLLVM_LINK_LLVM_DYLIB=ON. llvm-config --shared-mode reports
"shared" in that case, "static" otherwise (even if LLVM was built with
-DLLVM_BUILD_LLVM_DYLIB=ON).

v2: Keep the LLVM < 4.0 test. (llvm-config --shared-mode is actually
available since LLVM 3.8, but that would make the test too
complicated :)

Fixes: 3d8da1f678e1 ("configure: Trust LLVM >= 4.0 llvm-config --libs
  for shared libraries")
Tested-by: Dieter Nützel  # v1
Signed-off-by: Michel Dänzer 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index e3babd3909..52645bb44f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2646,7 +2646,7 @@ if test "x$enable_llvm" = xyes; then
 LLVM_LIBS="`$LLVM_CONFIG --libs ${LLVM_COMPONENTS}`"

 if test "x$enable_llvm_shared_libs" = xyes; then
-if test $LLVM_VERSION_MAJOR -lt 4; then
+if test $LLVM_VERSION_MAJOR -lt 4 -o "`$LLVM_CONFIG
--shared-mode ${LLVM_COMPONENTS}`" = static; then
 dnl llvm-config may not give the right answer when llvm
is a built as a
 dnl single shared library, so we must work the library 
name out for

 dnl ourselves.

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


[Mesa-dev] [PATCH 1/2] gallium: Add PIPE_CAP_USER_MEMORY_PAGE_SIZE for page size of user pointers

2017-08-16 Thread Aaron Watry
PIPE_CAP_RESOURCE_FROM_USER_MEMORY says that size must be page aligned,
but doesn't necessarily say anything about the size of those pages.

Signed-off-by: Aaron Watry 
---
 src/gallium/docs/source/screen.rst   | 4 
 src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
 src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
 src/gallium/drivers/i915/i915_screen.c   | 1 +
 src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
 src/gallium/drivers/r300/r300_screen.c   | 1 +
 src/gallium/drivers/r600/r600_pipe.c | 3 +++
 src/gallium/drivers/radeonsi/si_pipe.c   | 3 +++
 src/gallium/drivers/softpipe/sp_screen.c | 1 +
 src/gallium/drivers/svga/svga_screen.c   | 1 +
 src/gallium/drivers/swr/swr_screen.cpp   | 1 +
 src/gallium/drivers/vc4/vc4_screen.c | 1 +
 src/gallium/drivers/virgl/virgl_screen.c | 1 +
 src/gallium/include/pipe/p_defines.h | 1 +
 17 files changed, 24 insertions(+)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index be14ddd0c0..47b4bb7637 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -256,6 +256,10 @@ The integer capabilities:
   existing user memory into the device address space for direct device access.
   The create function is pipe_screen::resource_from_user_memory. The address
   and size must be page-aligned.
+* ``PIPE_CAP_USER_MEMORY_PAGE_SIZE``: When the driver supports
+  PIPE_CAP_RESOURCE_FROM_USER_MEMORY, this is the page size supported
+  for resources created from user memory allocations. A value of 0 is only
+  allowed when PIPE_CAP_RESOURCE_FROM_USER_MEMORY is not supported.
 * ``PIPE_CAP_DEVICE_RESET_STATUS_QUERY``:
   Whether pipe_context::get_device_reset_status is implemented.
 * ``PIPE_CAP_MAX_SHADER_PATCH_VARYINGS``:
diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
b/src/gallium/drivers/etnaviv/etnaviv_screen.c
index f400e423de..f8c717d136 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
@@ -209,6 +209,7 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_POLYGON_OFFSET_CLAMP:
case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
+   case PIPE_CAP_USER_MEMORY_PAGE_SIZE:
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index b26f67e4e2..9e0d2d49d3 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -281,6 +281,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
+   case PIPE_CAP_USER_MEMORY_PAGE_SIZE:
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
case PIPE_CAP_DEPTH_BOUNDS_TEST:
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index e700e294da..7c46b7fe67 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -243,6 +243,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
case PIPE_CAP_POLYGON_OFFSET_CLAMP:
case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
+   case PIPE_CAP_USER_MEMORY_PAGE_SIZE:
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 6c64133b90..c5fb7cd176 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -311,6 +311,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
   return 1;
case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
+   case PIPE_CAP_USER_MEMORY_PAGE_SIZE:
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
case PIPE_CAP_DEPTH_BOUNDS_TEST:
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 72f886c911..4e54110e3f 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -168,6 +168,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_POLYGON_OFFSET_CLAMP:
case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
case 

[Mesa-dev] [PATCH 2/2] clover/device: Query PIPE_CAP_USER_MEMORY_PAGE_SIZE from device

2017-08-16 Thread Aaron Watry
The CL CTS queries CL_DEVICE_MEM_BASE_ADDR_ALIGN for a device, and
then allocates user pointers aligned to that value for tests.

The minimum value is defined as:
  the size (in bits) of the largest OpenCL built-in data type supported
  by the device (long16 in FULL profile, long16 or int16 in EMBEDDED
  profile) for devices that are not of type CL_DEVICE_TYPE_CUSTOM.

Signed-off-by: Aaron Watry 
Cc: Francisco Jerez 
Cc: Jan Vesely 
---
 src/gallium/state_trackers/clover/api/device.cpp  | 3 ++-
 src/gallium/state_trackers/clover/core/device.cpp | 5 +
 src/gallium/state_trackers/clover/core/device.hpp | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/clover/api/device.cpp 
b/src/gallium/state_trackers/clover/api/device.cpp
index b1b7917e4e..b5ffe110be 100644
--- a/src/gallium/state_trackers/clover/api/device.cpp
+++ b/src/gallium/state_trackers/clover/api/device.cpp
@@ -205,7 +205,8 @@ clGetDeviceInfo(cl_device_id d_dev, cl_device_info param,
   break;
 
case CL_DEVICE_MEM_BASE_ADDR_ALIGN:
-  buf.as_scalar() = 128 * 8;
+  buf.as_scalar() = 8 *
+ MAX2(dev.mem_base_addr_align(), sizeof(cl_long) * 16);
   break;
 
case CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE:
diff --git a/src/gallium/state_trackers/clover/core/device.cpp 
b/src/gallium/state_trackers/clover/core/device.cpp
index f6bbc38a98..13111fd03a 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -194,6 +194,11 @@ device::has_unified_memory() const {
return pipe->get_param(pipe, PIPE_CAP_UMA);
 }
 
+cl_uint
+device::mem_base_addr_align() const {
+   return pipe->get_param(pipe, PIPE_CAP_USER_MEMORY_PAGE_SIZE);
+}
+
 std::vector
 device::max_block_size() const {
auto v = get_compute_param(pipe, ir_format(),
diff --git a/src/gallium/state_trackers/clover/core/device.hpp 
b/src/gallium/state_trackers/clover/core/device.hpp
index efc217aedb..4e11519421 100644
--- a/src/gallium/state_trackers/clover/core/device.hpp
+++ b/src/gallium/state_trackers/clover/core/device.hpp
@@ -68,6 +68,7 @@ namespace clover {
   bool image_support() const;
   bool has_doubles() const;
   bool has_unified_memory() const;
+  cl_uint mem_base_addr_align() const;
 
   std::vector max_block_size() const;
   cl_uint subgroup_size() const;
-- 
2.11.0

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


[Mesa-dev] [Bug 102268] anv_batch_chain.c:1475: undefined reference to `anv_gem_sync_file_merge'

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102268

Jason Ekstrand  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Jason Ekstrand  ---
This is fixed by the following commit in master:

commit bf1d2e84f34b7e63656c15c11ed4d01077e95047
Author: Jason Ekstrand 
Date:   Wed Aug 16 18:43:11 2017 -0700

anv/gem: Add a stub for sync_file_merge

This fixes make check

Fixes: 5c4e4932e02164e18cba9ae2cf3ec56afa2f2a6b

Thanks for pointing it out!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 101832] [regression][bisect] Xorg fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101832

Bernhard Rosenkraenzer  changed:

   What|Removed |Added

Summary|[regression][bisect] sddm   |[regression][bisect] Xorg
   |fails to start after|fails to start after
   |f50aa21456d82c8cb6fbaa56583 |f50aa21456d82c8cb6fbaa56583
   |5f1acc1720a5d   |5f1acc1720a5d

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/4] ac/nir: fix 64-bit shifts

2017-08-16 Thread Connor Abbott
I didn't enable the Int64 capability for radv until the next patch in
this series, so the problem this fixes was never exposed to users at
all. I just ran into it when enabling VK_EXT_shader_ballot -- the
extension doesn't require it, but the only way to generate SPIR-V
using it with glslang is with the ARB_shader_ballot GLSL extension
that does use 64-bit integers.

P.S. it would be nice to have some Int64 tests in the Vulkan CTS so we
can catch stuff like this easier.

On Wed, Aug 16, 2017 at 8:49 PM, Andres Gomez  wrote:
> Connor, it looks like we could want this patch in 17.1 (?)
>
> On Fri, 2017-06-30 at 19:56 -0700, Connor Abbott wrote:
>> From: Connor Abbott 
>>
>> NIR always makes the shift amount 32 bits, but LLVM asserts if the two
>> sources aren't the same type. Zero-extend the shift amount to make LLVM
>> happy.
>>
>> Signed-off-by: Connor Abbott 
>> ---
>>  src/amd/common/ac_nir_to_llvm.c | 15 ---
>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c 
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 88f3f44..e72747a 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -1621,13 +1621,22 @@ static void visit_alu(struct nir_to_llvm_context 
>> *ctx, const nir_alu_instr *inst
>>   result = LLVMBuildXor(ctx->builder, src[0], src[1], "");
>>   break;
>>   case nir_op_ishl:
>> - result = LLVMBuildShl(ctx->builder, src[0], src[1], "");
>> + result = LLVMBuildShl(ctx->builder, src[0],
>> +   LLVMBuildZExt(ctx->builder, src[1],
>> + LLVMTypeOf(src[0]), ""),
>> +   "");
>>   break;
>>   case nir_op_ishr:
>> - result = LLVMBuildAShr(ctx->builder, src[0], src[1], "");
>> + result = LLVMBuildAShr(ctx->builder, src[0],
>> +LLVMBuildZExt(ctx->builder, src[1],
>> +  LLVMTypeOf(src[0]), ""),
>> +"");
>>   break;
>>   case nir_op_ushr:
>> - result = LLVMBuildLShr(ctx->builder, src[0], src[1], "");
>> + result = LLVMBuildLShr(ctx->builder, src[0],
>> +LLVMBuildZExt(ctx->builder, src[1],
>> +  LLVMTypeOf(src[0]), ""),
>> +"");
>>   break;
>>   case nir_op_ilt:
>>   result = emit_int_cmp(>ac, LLVMIntSLT, src[0], src[1]);
> --
> Br,
>
> Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/4] ac/nir: fix 64-bit shifts

2017-08-16 Thread Andres Gomez
Connor, it looks like we could want this patch in 17.1 (?)

On Fri, 2017-06-30 at 19:56 -0700, Connor Abbott wrote:
> From: Connor Abbott 
> 
> NIR always makes the shift amount 32 bits, but LLVM asserts if the two
> sources aren't the same type. Zero-extend the shift amount to make LLVM
> happy.
> 
> Signed-off-by: Connor Abbott 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 88f3f44..e72747a 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1621,13 +1621,22 @@ static void visit_alu(struct nir_to_llvm_context 
> *ctx, const nir_alu_instr *inst
>   result = LLVMBuildXor(ctx->builder, src[0], src[1], "");
>   break;
>   case nir_op_ishl:
> - result = LLVMBuildShl(ctx->builder, src[0], src[1], "");
> + result = LLVMBuildShl(ctx->builder, src[0],
> +   LLVMBuildZExt(ctx->builder, src[1],
> + LLVMTypeOf(src[0]), ""),
> +   "");
>   break;
>   case nir_op_ishr:
> - result = LLVMBuildAShr(ctx->builder, src[0], src[1], "");
> + result = LLVMBuildAShr(ctx->builder, src[0],
> +LLVMBuildZExt(ctx->builder, src[1],
> +  LLVMTypeOf(src[0]), ""),
> +"");
>   break;
>   case nir_op_ushr:
> - result = LLVMBuildLShr(ctx->builder, src[0], src[1], "");
> + result = LLVMBuildLShr(ctx->builder, src[0],
> +LLVMBuildZExt(ctx->builder, src[1],
> +  LLVMTypeOf(src[0]), ""),
> +"");
>   break;
>   case nir_op_ilt:
>   result = emit_int_cmp(>ac, LLVMIntSLT, src[0], src[1]);
-- 
Br,

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


Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] swr: use the correct variable for no undefined symbols

2017-08-16 Thread Andres Gomez
Emil, this patch breaks SWR build in 17.1, although it states that
fixes 9475251145174882b532.

Should I assume that this should be dropped for 17.1 or are you
planning to send some backport (?).

On Fri, 2017-07-21 at 19:05 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The variable name was missing a leading LD_, which resulted in the
> backend binaries having unresolved symbols.
> 
> With the link addressed with earlier patches, we can correct the typo.
> 
> Thanks to Laurent for the help spotting this.
> 
> v2: Split from a larger patch.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> Cc: Bruce Cherniak 
> Cc: Tim Rowley 
> Cc: Laurent Carlier 
> Fixes: 9475251145174882b532 "swr: standardize linkage and check for
>  unresolved symbols"
> Reviewed-by: Eric Engestrom 
> Reported-by: Laurent Carlier 
> Signed-off-by: Emil Velikov 
> ---
>  src/gallium/drivers/swr/Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/swr/Makefile.am 
> b/src/gallium/drivers/swr/Makefile.am
> index bc7abad06af..05fc3b3595b 100644
> --- a/src/gallium/drivers/swr/Makefile.am
> +++ b/src/gallium/drivers/swr/Makefile.am
> @@ -238,7 +238,7 @@ COMMON_LDFLAGS = \
>   -module \
>   -no-undefined \
>   $(GC_SECTIONS) \
> - $(NO_UNDEFINED)
> + $(LD_NO_UNDEFINED)
>  
>  lib_LTLIBRARIES =
>  
-- 
Br,

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


[Mesa-dev] [Bug 102241] gallium/wgl: SwapBuffers freezing regularly with swap interval enabled

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102241

Brian Paul  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Brian Paul  ---
Patches pushed as d90e05ad487e9fe7e17c293814ac8549d9d686d8 and
7fb7287ce72066db7dffd918226bf15c3131a871.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102148] Crash when running qopenglwidget example on mesa llvmpipe win32

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102148

Brian Paul  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Brian Paul  ---
Patch pushed as commit 496a691e3544d082670ac1f33059692510a2a86d

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] gallium/os: fix os_time_get_nano() to roll over less

2017-08-16 Thread Brian Paul

On 08/16/2017 04:42 PM, Jose Fonseca wrote:

On 16/08/17 23:37, Jose Fonseca wrote:

On 16/08/17 14:22, Brian Paul wrote:

From: Frank Richter 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102241
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Brian Paul 
---
  src/gallium/auxiliary/os/os_time.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/os/os_time.c
b/src/gallium/auxiliary/os/os_time.c
index e169139..e4a1cae 100644
--- a/src/gallium/auxiliary/os/os_time.c
+++ b/src/gallium/auxiliary/os/os_time.c
@@ -69,10 +69,17 @@ os_time_get_nano(void)
 static LARGE_INTEGER frequency;
 LARGE_INTEGER counter;
+   int64_t secs, nanosecs;
 if(!frequency.QuadPart)
QueryPerformanceFrequency();
 QueryPerformanceCounter();
-   return counter.QuadPart*INT64_C(10)/frequency.QuadPart;
+   /* Compute seconds and nanoseconds parts separately to
+* reduce severity of precision loss.
+*/
+   secs = counter.QuadPart / frequency.QuadPart;
+   nanosecs = (counter.QuadPart % frequency.QuadPart) *
INT64_C(10)
+  / frequency.QuadPart;
+   return secs*INT64_C(10) + nanosecs;
  #else



Series looks great.

Thanks!

Reviewed-by: Jose Fonseca 


BTW, I wonder if we would win by using lldiv().  Because this is often
use for performance measurements, so these extra division might add some
impact.


Frank, do you want to look into that?  In the mean time, I'll push the 
patches as-is.


-Brian


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


[Mesa-dev] [Bug 102123] [llvmpipe] piglit gl-3.2-layered-rendering-framebuffertexture regression

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102123

Brian Paul  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Brian Paul  ---
Commit 9fbb0bf7e60a36113d96ac8a9622ba348def535e checks if MSAA is really
supported before testing the multisample texture targets.

Closing this bug.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/4] ac/nir: fix 64-bit shifts

2017-08-16 Thread Andres Gomez
Connor, it looks like we could want this patch in 17.1 (?)

On Fri, 2017-06-30 at 19:56 -0700, Connor Abbott wrote:
> From: Connor Abbott 
> 
> NIR always makes the shift amount 32 bits, but LLVM asserts if the two
> sources aren't the same type. Zero-extend the shift amount to make LLVM
> happy.
> 
> Signed-off-by: Connor Abbott 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 88f3f44..e72747a 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1621,13 +1621,22 @@ static void visit_alu(struct nir_to_llvm_context 
> *ctx, const nir_alu_instr *inst
>   result = LLVMBuildXor(ctx->builder, src[0], src[1], "");
>   break;
>   case nir_op_ishl:
> - result = LLVMBuildShl(ctx->builder, src[0], src[1], "");
> + result = LLVMBuildShl(ctx->builder, src[0],
> +   LLVMBuildZExt(ctx->builder, src[1],
> + LLVMTypeOf(src[0]), ""),
> +   "");
>   break;
>   case nir_op_ishr:
> - result = LLVMBuildAShr(ctx->builder, src[0], src[1], "");
> + result = LLVMBuildAShr(ctx->builder, src[0],
> +LLVMBuildZExt(ctx->builder, src[1],
> +  LLVMTypeOf(src[0]), ""),
> +"");
>   break;
>   case nir_op_ushr:
> - result = LLVMBuildLShr(ctx->builder, src[0], src[1], "");
> + result = LLVMBuildLShr(ctx->builder, src[0],
> +LLVMBuildZExt(ctx->builder, src[1],
> +  LLVMTypeOf(src[0]), ""),
> +"");
>   break;
>   case nir_op_ilt:
>   result = emit_int_cmp(>ac, LLVMIntSLT, src[0], src[1]);
-- 
Br,

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


[Mesa-dev] [Bug 100438] glsl/ir.cpp:1376: ir_dereference_variable::ir_dereference_variable(ir_variable*): Assertion `var != NULL' failed.

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100438

Timothy Arceri  changed:

   What|Removed |Added

 CC||pmenzel+bugs.freedesktop@mo
   ||lgen.mpg.de

--- Comment #4 from Timothy Arceri  ---
*** Bug 102265 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102265] Segfault in `ir_dereference_variable::ir_dereference_variable` dereferencing NULL variable

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102265

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Timothy Arceri  ---
The assert from 100438 still happens, I susspect you forgot to add
--enable-debug when building.

*** This bug has been marked as a duplicate of bug 100438 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] radv: disable texture gather workaround on gfx9.

2017-08-16 Thread Bas Nieuwenhuizen
Yay, less workarounds.

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Aug 17, 2017, at 01:19, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Not required anymore.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index bc325e6..cc42877 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2185,7 +2185,7 @@ static LLVMValueRef build_tex_intrinsic(struct
> ac_nir_context *ctx,
>   break;
>   }
>  
> -   if (instr->op == nir_texop_tg4) {
> +   if (instr->op == nir_texop_tg4 && ctx->abi->chip_class <= VI) {
>   enum glsl_base_type stype = 
> glsl_get_sampler_result_type(instr->texture->var->type);
>   if (stype == GLSL_TYPE_UINT || stype == GLSL_TYPE_INT) {
>   return radv_lower_gather4_integer(>ac, args, 
> instr);
> -- 
> 2.9.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radv: disable texture gather workaround on gfx9.

2017-08-16 Thread Dave Airlie
From: Dave Airlie 

Not required anymore.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index bc325e6..cc42877 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2185,7 +2185,7 @@ static LLVMValueRef build_tex_intrinsic(struct 
ac_nir_context *ctx,
break;
}
 
-   if (instr->op == nir_texop_tg4) {
+   if (instr->op == nir_texop_tg4 && ctx->abi->chip_class <= VI) {
enum glsl_base_type stype = 
glsl_get_sampler_result_type(instr->texture->var->type);
if (stype == GLSL_TYPE_UINT || stype == GLSL_TYPE_INT) {
return radv_lower_gather4_integer(>ac, args, 
instr);
-- 
2.9.4

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


Re: [Mesa-dev] [PATCH 2/2] gallium/os: fix os_time_get_nano() to roll over less

2017-08-16 Thread Jose Fonseca

On 16/08/17 14:22, Brian Paul wrote:

From: Frank Richter 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102241
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Brian Paul 
---
  src/gallium/auxiliary/os/os_time.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/os/os_time.c 
b/src/gallium/auxiliary/os/os_time.c
index e169139..e4a1cae 100644
--- a/src/gallium/auxiliary/os/os_time.c
+++ b/src/gallium/auxiliary/os/os_time.c
@@ -69,10 +69,17 @@ os_time_get_nano(void)
  
 static LARGE_INTEGER frequency;

 LARGE_INTEGER counter;
+   int64_t secs, nanosecs;
 if(!frequency.QuadPart)
QueryPerformanceFrequency();
 QueryPerformanceCounter();
-   return counter.QuadPart*INT64_C(10)/frequency.QuadPart;
+   /* Compute seconds and nanoseconds parts separately to
+* reduce severity of precision loss.
+*/
+   secs = counter.QuadPart / frequency.QuadPart;
+   nanosecs = (counter.QuadPart % frequency.QuadPart) * INT64_C(10)
+  / frequency.QuadPart;
+   return secs*INT64_C(10) + nanosecs;
  
  #else
  



Series looks great.

Thanks!

Reviewed-by: Jose Fonseca 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102268] anv_batch_chain.c:1475: undefined reference to `anv_gem_sync_file_merge'

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102268

Bug ID: 102268
   Summary: anv_batch_chain.c:1475: undefined reference to
`anv_gem_sync_file_merge'
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: ja...@jlekstrand.net

mesa: 49eda75df6aafdf5d2ffe5d9247b516ac7d14691 (master 17.3.0-devel)

$ make check
[...]
  CCLD vulkan/tests/block_pool_no_free
vulkan/.libs/libvulkan-test.a(vulkan_libvulkan_common_la-anv_batch_chain.o): In
function `anv_cmd_buffer_execbuf':
mesa/src/intel/vulkan/anv_batch_chain.c:1475: undefined reference to
`anv_gem_sync_file_merge'
collect2: error: ld returned 1 exit status

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] st/omx_tizonia: add --enable-omx-tizonia flag and build files

2017-08-16 Thread Andy Furniss

Thanks, I'll try something similar.

One more question - WRT gst-omx, what target should I build -
generic or is something else/patch needed? I don't see tizonia with
current git.

Gurkirpal Singh wrote:

Hi,

It is a known issue that the player is hard to build. Juan suggested to
remove it from the build files
https://github.com/tizonia/tizonia-openmax-il/issues/248#issuecomment-232406388

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


Re: [Mesa-dev] [PATCH 2/2] gallium/os: fix os_time_get_nano() to roll over less

2017-08-16 Thread Jose Fonseca

On 16/08/17 23:37, Jose Fonseca wrote:

On 16/08/17 14:22, Brian Paul wrote:

From: Frank Richter 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102241
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Brian Paul 
---
  src/gallium/auxiliary/os/os_time.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/os/os_time.c 
b/src/gallium/auxiliary/os/os_time.c

index e169139..e4a1cae 100644
--- a/src/gallium/auxiliary/os/os_time.c
+++ b/src/gallium/auxiliary/os/os_time.c
@@ -69,10 +69,17 @@ os_time_get_nano(void)
 static LARGE_INTEGER frequency;
 LARGE_INTEGER counter;
+   int64_t secs, nanosecs;
 if(!frequency.QuadPart)
QueryPerformanceFrequency();
 QueryPerformanceCounter();
-   return counter.QuadPart*INT64_C(10)/frequency.QuadPart;
+   /* Compute seconds and nanoseconds parts separately to
+* reduce severity of precision loss.
+*/
+   secs = counter.QuadPart / frequency.QuadPart;
+   nanosecs = (counter.QuadPart % frequency.QuadPart) * 
INT64_C(10)

+  / frequency.QuadPart;
+   return secs*INT64_C(10) + nanosecs;
  #else



Series looks great.

Thanks!

Reviewed-by: Jose Fonseca 


BTW, I wonder if we would win by using lldiv().  Because this is often 
use for performance measurements, so these extra division might add some 
impact.


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


[Mesa-dev] [PATCH] radeonsi/gfx9: add shader binary overallocation back

2017-08-16 Thread Marek Olšák
From: Marek Olšák 

Cc: 17.2 
---
 src/gallium/drivers/radeonsi/si_shader.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 3f4d847..6976537 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4913,20 +4913,30 @@ int si_shader_binary_upload(struct si_screen *sscreen, 
struct si_shader *shader)
   (!epilog ? mainb->rodata_size : 0);
unsigned char *ptr;
 
assert(!prolog || !prolog->rodata_size);
assert(!previous_stage || !previous_stage->rodata_size);
assert(!prolog2 || !prolog2->rodata_size);
assert((!prolog && !previous_stage && !prolog2 && !epilog) ||
   !mainb->rodata_size);
assert(!epilog || !epilog->rodata_size);
 
+   /* GFX9 can fetch two cache lines after the end of the shader.
+* Prevent VM faults by overallocating the shader binary.
+*/
+   if (sscreen->b.chip_class >= GFX9) {
+   const unsigned icache_line_size = 64;
+
+   bo_size = align(bo_size, icache_line_size) +
+ icache_line_size * 2;
+   }
+
r600_resource_reference(>bo, NULL);
shader->bo = (struct r600_resource*)
 pipe_buffer_create(>b.b, 0,
PIPE_USAGE_IMMUTABLE,
align(bo_size, SI_CPDMA_ALIGNMENT));
if (!shader->bo)
return -ENOMEM;
 
/* Upload. */
ptr = sscreen->b.ws->buffer_map(shader->bo->buf, NULL,
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH 4/4] radeonsi/gfx9: add performance counters

2017-08-16 Thread Marek Olšák
For the series:

Reviewed-by: Marek Olšák 

Marek

On Wed, Aug 16, 2017 at 1:13 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> ---
>  src/gallium/drivers/radeonsi/si_perfcounter.c | 29 
> ++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c 
> b/src/gallium/drivers/radeonsi/si_perfcounter.c
> index 41dd52edb11..2e3a174e393 100644
> --- a/src/gallium/drivers/radeonsi/si_perfcounter.c
> +++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
> @@ -403,6 +403,30 @@ static struct si_pc_block groups_VI[] = {
>
>  };
>
> +static struct si_pc_block groups_gfx9[] = {
> +   { _CB, 438, 4 },
> +   { _CPF, 32 },
> +   { _DB, 328, 4 },
> +   { _GRBM, 38 },
> +   { _GRBMSE, 16 },
> +   { _PA_SU, 292 },
> +   { _PA_SC, 491 },
> +   { _SPI, 196 },
> +   { _SQ, 374 },
> +   { _SX, 208 },
> +   { _TA, 119, 16 },
> +   { _TCA, 35, 2 },
> +   { _TCC, 256, 16 },
> +   { _TD, 57, 16 },
> +   { _TCP, 85, 16 },
> +   { _GDS, 121 },
> +   { _VGT, 148 },
> +   { _IA, 32 },
> +   { _WD, 58 },
> +   { _CPG, 59 },
> +   { _CPC, 35 },
> +};
> +
>  static void si_pc_get_size(struct r600_perfcounter_block *group,
> unsigned count, unsigned *selectors,
> unsigned *num_select_dw, unsigned *num_read_dw)
> @@ -671,8 +695,11 @@ void si_init_perfcounters(struct si_screen *screen)
> blocks = groups_VI;
> num_blocks = ARRAY_SIZE(groups_VI);
> break;
> -   case SI:
> case GFX9:
> +   blocks = groups_gfx9;
> +   num_blocks = ARRAY_SIZE(groups_gfx9);
> +   break;
> +   case SI:
> default:
> return; /* not implemented */
> }
> --
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] st/omx_tizonia: add --enable-omx-tizonia flag and build files

2017-08-16 Thread Gurkirpal Singh
Hi,

It is a known issue that the player is hard to build. Juan suggested to
remove it from the build files
https://github.com/tizonia/tizonia-openmax-il/issues/248#issuecomment-232406388

These are the changes that I make while building tizonia for use with mesa:

diff --git a/Makefile.am b/Makefile.am
index 9499b8b..eef0dcd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,7 +23,7 @@
 # it can be manually configured and built.

 # SUBDIRS = config include libtizplatform rm libtizcore libtizonia plugins
tizonia docs
-SUBDIRS = config include clients libtizplatform rm libtizcore libtizonia
plugins player config
+SUBDIRS = config include clients libtizplatform rm libtizcore libtizonia
plugins config


 # NOTE: A cscope target is included in automake since api 1.12
diff --git a/configure.ac b/configure.ac
index f453f0e..3df710e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,6 +41,5 @@ AC_CONFIG_SUBDIRS([include
libtizcore
libtizonia
plugins
-   player
config])
 AC_OUTPUT
diff --git a/plugins/Makefile.am b/plugins/Makefile.am
index 95458a6..db4f05e 100644
--- a/plugins/Makefile.am
+++ b/plugins/Makefile.am
@@ -17,12 +17,6 @@


 SUBDIRS = \
-   aac_decoder \
-   file_reader \
-   file_writer \
-   flac_decoder \
-   http_renderer \
-   http_source \
mp3_decoder \
mp3_encoder \
mp3_metadata \
@@ -34,7 +28,6 @@ SUBDIRS = \
pcm_decoder \
pcm_renderer_alsa \
pcm_renderer_pa \
-   spotify_source \
vorbis_decoder \
vp8_decoder \
webm_demuxer \
diff --git a/plugins/configure.ac b/plugins/configure.ac
index 7dc191b..7d89f75 100644
--- a/plugins/configure.ac
+++ b/plugins/configure.ac
@@ -49,13 +49,7 @@ PKG_CHECK_MODULES([CHECK], [check >= 0.9.4])

 AC_CONFIG_FILES([Makefile])

-AC_CONFIG_SUBDIRS([aac_decoder
-   file_reader
-   file_writer
-   flac_decoder
-   http_renderer
-   http_source
-   mp3_decoder
+AC_CONFIG_SUBDIRS([mp3_decoder
mp3_encoder
mp3_metadata
mpeg_audio_decoder
@@ -66,7 +60,6 @@ AC_CONFIG_SUBDIRS([aac_decoder
pcm_decoder
pcm_renderer_alsa
pcm_renderer_pa
-   spotify_source
vorbis_decoder
vp8_decoder
webm_demuxer

Cheers,
Gurkirpal

On Thu, Aug 17, 2017 at 2:25 AM, Andy Furniss  wrote:

> Christian König wrote:
>
>> Am 11.08.2017 um 14:32 schrieb Emil Velikov:
>>
>>> Hi Gurkirpal,
>>>
>>> Thanks for working on this. I believe Christian has some good points.
>>> There's only one small question + suggestion from me.
>>>
>>> On 11 August 2017 at 05:31, Gurkirpal Singh 
>>> wrote:
>>>
>>> +PKG_CHECK_MODULES([OMX_TIZONIA], [libtizonia >=
 $LIBOMXIL_TIZONIA_REQUIRED])
 +PKG_CHECK_MODULES([OMX_TIZILHEADERS], [tizilheaders >=
 $LIBOMXIL_TIZONIA_REQUIRED])
 +PKG_CHECK_MODULES([OMX_TIZPLATFORM], [libtizplatform >=
 $LIBOMXIL_TIZONIA_REQUIRED])

>>> I cannot find any tizonia packages for Debian, Fedora or Arch - are
>>> there any?
>>>
>>
>> Well Ubuntu/Debian can be found here https://github.com/tizonia/tiz
>> onia-openmax-il
>>
>
> Is there a way/place to build/get just what is needed for mesa?
>
> That seems to be a player - I gave up trying to build once it got to
> requiring pulseaudio.
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 4/5] intel/screen: Report the correct number of image planes

2017-08-16 Thread Jason Ekstrand

On August 16, 2017 1:28:52 PM Ben Widawsky  wrote:


On 17-08-16 13:26:00, Jason Ekstrand wrote:

For non-CCS images, we were reporting just one plane even though they
may have multiple in the case of YUV.

Cc: 


This has been wrong since it's initial implementation in 2014, ie. not stable
material IMO..


I think that's just proof that no one cares about the query below which is 
really weird to me.  Still seems like a bug though.  Is like to hear from 
Kristian our Daniel to know if they know if there are any users and if this 
patch will break them.



Reviewed-by: Ben Widawsky 


---
src/mesa/drivers/dri/i965/intel_screen.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c

index 9e65273..d454eeb 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -799,7 +799,14 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)

   case __DRI_IMAGE_ATTRIB_FOURCC:
  return intel_lookup_fourcc(image->dri_format, value);
   case __DRI_IMAGE_ATTRIB_NUM_PLANES:
-  *value = isl_drm_modifier_has_aux(image->modifier) ? 2 : 1;
+  if (isl_drm_modifier_has_aux(image->modifier)) {
+ assert(!image->planar_format || image->planar_format->nplanes == 1);
+ *value = 2;
+  } else if (image->planar_format) {
+ *value = image->planar_format->nplanes;
+  } else {
+ *value = 1;
+  }
  return true;
   case __DRI_IMAGE_ATTRIB_OFFSET:
  *value = image->offset;
--
2.5.0.400.gff86faf

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



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


Re: [Mesa-dev] [PATCH v2 4/5] intel/screen: Report the correct number of image planes

2017-08-16 Thread Ben Widawsky

On 17-08-16 13:26:00, Jason Ekstrand wrote:

For non-CCS images, we were reporting just one plane even though they
may have multiple in the case of YUV.

Cc: 


This has been wrong since it's initial implementation in 2014, ie. not stable
material IMO..

Reviewed-by: Ben Widawsky 


---
src/mesa/drivers/dri/i965/intel_screen.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 9e65273..d454eeb 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -799,7 +799,14 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)
   case __DRI_IMAGE_ATTRIB_FOURCC:
  return intel_lookup_fourcc(image->dri_format, value);
   case __DRI_IMAGE_ATTRIB_NUM_PLANES:
-  *value = isl_drm_modifier_has_aux(image->modifier) ? 2 : 1;
+  if (isl_drm_modifier_has_aux(image->modifier)) {
+ assert(!image->planar_format || image->planar_format->nplanes == 1);
+ *value = 2;
+  } else if (image->planar_format) {
+ *value = image->planar_format->nplanes;
+  } else {
+ *value = 1;
+  }
  return true;
   case __DRI_IMAGE_ATTRIB_OFFSET:
  *value = image->offset;
--
2.5.0.400.gff86faf

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

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


[Mesa-dev] [Bug 102218] Nier:Automata (through wine) - Bloom too bright

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102218

--- Comment #3 from Philip Rebohle  ---
I've tried to create a sample program that reproduces the issue, but so far,
the shader that breaks the game actually works correctly in an isolated
environment.



Anyway, in the apitrace, the following sequence of dispatch/draw calls is
involved:

glDispatchCompute(13,7,1):
This invokes the misbehaving compute shader.

glDispatchCompute(1,1,1):
Processes the output of that compute shader, computes the actual average
brightness of the image and mixes it with the average brightness of the
previous frame.

glDrawArrays(GL_TRIANGLE_STRIP, 0, 4):
Uses the output of the previous compute shader to render the (more or less)
final image.



My system specs:
- Arch Linux 64-bit
- AMD RX 480
- Linux 4.12.6
- Mesa 17.1.6 (tested with mesa-git as well, same issue)
- LLVM 4.0.1

I haven't succeeded in building mesa-git against LLVM 5.0rc2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Mark all EGLimages as non-coherent.

2017-08-16 Thread Jason Ekstrand
Reviewed-by: Jason Ekstrand 

On Wed, Aug 16, 2017 at 12:30 PM, Kenneth Graunke 
wrote:

> EGLimages are shared with external users, and we don't know what they're
> going to do with them.  They might scan them out.  They might access
> them in a way that doesn't work with our explicit clflushing.
>
> It's safest to simply mark them non-coherent.
>
> Chris Wilson caught this problem and wrote a similar (though less
> aggressive) patch to solve it; the miptree code has since undergone
> a lot of refactoring so I had to rewrite it.
>
> Cc: Chris Wilson 
> Cc: Jason Ekstrand 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 237ab182712..dab60c4b045 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -1061,12 +1061,10 @@ intel_miptree_create_for_dri_image(struct
> brw_context *brw,
>}
> }
>
> -   /* If this is a window-system image, then we can no longer assume it's
> -* cache-coherent because it may suddenly get scanned out which
> destroys
> -* coherency.
> +   /* Don't assume coherency for imported EGLimages.  We don't know what
> +* external clients are going to do with it.  They may scan it out.
>  */
> -   if (is_winsys_image)
> -  image->bo->cache_coherent = false;
> +   image->bo->cache_coherent = false;
>
> return mt;
>  }
> --
> 2.14.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/5] dri/image: Add a format modifier attributes query

2017-08-16 Thread Jason Ekstrand
---
 include/GL/internal/dri_interface.h | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 2cbd738..a841872 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1178,7 +1178,7 @@ struct __DRIdri2ExtensionRec {
  * extensions.
  */
 #define __DRI_IMAGE "DRI_IMAGE"
-#define __DRI_IMAGE_VERSION 15
+#define __DRI_IMAGE_VERSION 16
 
 /**
  * These formats correspond to the similarly named MESA_FORMAT_*
@@ -1358,6 +1358,13 @@ enum __DRIChromaSiting {
 #define __BLIT_FLAG_FLUSH  0x0001
 #define __BLIT_FLAG_FINISH 0x0002
 
+/**
+ * queryDmaBufFormatModifierAttribs attributes
+ */
+
+/* Available in version 16 */
+#define __DRI_IMAGE_FORMAT_MODIFIER_ATTRIB_PLANE_COUNT   0x0001
+
 typedef struct __DRIimageRec  __DRIimage;
 typedef struct __DRIimageExtensionRec __DRIimageExtension;
 struct __DRIimageExtensionRec {
@@ -1598,6 +1605,24 @@ struct __DRIimageExtensionRec {
  int max, uint64_t *modifiers,
  unsigned int *external_only,
  int *count);
+
+   /**
+* dmabuf format modifier attribute query for a given format and modifier.
+*
+* \param fourccThe format to query. If this format is not supported by
+*  the driver, return false.
+* \param modifier  The modifier to query. If this format+modifier is not
+*  supported by the driver, return false.
+* \param attribThe __DRI_IMAGE_FORMAT_MODIFIER_ATTRIB to query.
+* \param value A pointer to where to store the result of the query.
+*
+* Returns true upon success.
+*
+* \since 16
+*/
+   GLboolean (*queryDmaBufFormatModifierAttribs)(__DRIscreen *screen,
+ int fourcc, uint64_t modifier,
+ int attrib, uint64_t *value);
 };
 
 
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 3/5] i965/screen: Make a parameter const

2017-08-16 Thread Jason Ekstrand
This gets rid of some compiler warnings.
---
 src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index e97e196..9e65273 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -299,7 +299,7 @@ static const struct {
 
 static bool
 modifier_is_supported(const struct gen_device_info *devinfo,
-  struct intel_image_format *fmt, int dri_format,
+  const struct intel_image_format *fmt, int dri_format,
   uint64_t modifier)
 {
const struct isl_drm_modifier_info *modinfo =
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 4/5] intel/screen: Report the correct number of image planes

2017-08-16 Thread Jason Ekstrand
For non-CCS images, we were reporting just one plane even though they
may have multiple in the case of YUV.

Cc: 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 9e65273..39b4ef6 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -799,7 +799,12 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)
case __DRI_IMAGE_ATTRIB_FOURCC:
   return intel_lookup_fourcc(image->dri_format, value);
case __DRI_IMAGE_ATTRIB_NUM_PLANES:
-  *value = isl_drm_modifier_has_aux(image->modifier) ? 2 : 1;
+  if (isl_drm_modifier_has_aux(image->modifier))
+ *value = 2;
+  else if (image->planar_format)
+ *value = image->planar_format->nplanes;
+  else
+ *value = 1;
   return true;
case __DRI_IMAGE_ATTRIB_OFFSET:
   *value = image->offset;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 0/5] gbm: Add a modifier_plane_count query

2017-08-16 Thread Jason Ekstrand
We ran into a little problem with trying to use modifiers with X11.
Specifically, if you do front-buffer rendering with CCS and have any
tearing, then the end results are not at all what you want.  Instead of the
race between render and scanout resulting in a nice clean horizontal or
vertical line like you would get with X or Y-tiling, you get a wide bar of
garbage.  The theory is that his is because the scanout may read old main
surface and new CCS contents or vice versa.  There may also be some issues
with how CCS data gets flushed out of the render cache.

After some discussion on IRC, the solution was proposed by Daniel Vetter of
just not doing front-buffer rendering to multi-planar images.  The chances
of getting anything close to nice results when racing scanout on a multi-
planar image are slim anyway and this nicely rules out the CCS case.  In
order to do this, however, the X server needs to know how many planes a
given modifier will consume.  It could just have a retry loop and keep
deleting modifiers from the list until it GBM creates a single-plane
surface.  This little series adds a GBM query to ask how many planes are in
a given format+modifier combination.

This has been compile-tested only.  I'm hoping Daniel will rework his X11
patches and test it out for me.

Cc: Daniel Stone 

Jason Ekstrand (5):
  dri/image: Add a format modifier attributes query
  gbm: Add a gbm_device_get_format_modifier_plane_count function
  i965/screen: Make a parameter const
  intel/screen: Report the correct number of image planes
  i965/screen: Implement queryDmaBufFormatModifierAttirbs

 include/GL/internal/dri_interface.h  | 27 +-
 src/gbm/backends/dri/gbm_dri.c   | 26 +
 src/gbm/main/gbm.c   | 14 ++
 src/gbm/main/gbm.h   |  5 +
 src/gbm/main/gbmint.h|  3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 33 +---
 6 files changed, 104 insertions(+), 4 deletions(-)

-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [RFC PATCH 1/2] util/f32_to_uf11: make use of optional value range

2017-08-16 Thread Karol Herbst
In the CTS test 'KHR-GL45.copy_image.functional' we ended up doing a sw format
conversion from R11F_G11F_B10F_EXT to RGBA back to R11F_G11F_B10F_EXT within
glGetTexImage calls.

By total misfortune we also got f11 values of 0x4, which got converted to a
0x3680 f32 value in uf11_to_f32. But the result of f32_to_uf11(0x3680)
was 0x0 which led to the above mentioned test to fail due to invalid data read
by glGetTexImage.

Adjusting f32_to_uf11 to make use of the optional value range for
E == 0 and M != 0
so that we have more 'x' for which is the following is true
f32_to_uf11(uf11_to_f32(x)) == x

Fixes a few subtests for KHR-GL45.copy_image.functional on Nouveau and i965.

Signed-off-by: Karol Herbst 
---
 src/util/format_r11g11b10f.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/util/format_r11g11b10f.h b/src/util/format_r11g11b10f.h
index ec5abf9611..5493c10403 100644
--- a/src/util/format_r11g11b10f.h
+++ b/src/util/format_r11g11b10f.h
@@ -93,6 +93,16 @@ static inline uint32_t f32_to_uf11(float val)
   exponent += UF11_EXPONENT_BIAS;
   mantissa >>= UF11_MANTISSA_SHIFT;
   uf11 = exponent << UF11_EXPONENT_SHIFT | mantissa;
+   } else if (exponent > -21) {
+  /* for exponents (-21, -15] we can be a bit smarter than returning 0
+   *
+   * From the GL_EXT_packed_float spec:
+   *  "2^-14 * (M / 64), if E == 0 and M != 0,"
+   *
+   * based on the exponent and mantissa we can calculate M for E == 0 for
+   * the given value.
+   */
+  uf11 = (1 << (exponent + 20)) + (mantissa >> (3 - exponent));
}
 
return uf11;
-- 
2.14.1

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


[Mesa-dev] [PATCH 19/20] st/va: reallocate surface with YUYV stream

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/picture.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 1e1212dd7a..116f9fb517 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -592,6 +592,8 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
void *feedback;
struct pipe_screen *screen;
bool interlaced;
+   enum pipe_video_format format;
+   bool realloc = false;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -627,7 +629,24 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
   surf->templat.interlaced = screen->get_video_param(screen, 
context->decoder->profile,
  
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
  
PIPE_VIDEO_CAP_PREFERS_INTERLACED);
+  realloc = true;
+   }
+
+   format = u_reduce_video_profile(context->templat.profile);
+
+   if (format == PIPE_VIDEO_FORMAT_JPEG && surf->buffer->buffer_format == 
PIPE_FORMAT_NV12) {
+  if (context->mjpeg.sampling_factor == 0x21 ||
+  context->mjpeg.sampling_factor == 0x221212) {
+ surf->templat.buffer_format = PIPE_FORMAT_YUYV;
+ realloc = true;
+  } else if (context->mjpeg.sampling_factor != 0x22) {
+ /* Not NV12 either */
+ mtx_unlock(>mutex);
+ return VA_STATUS_ERROR_INVALID_SURFACE;
+  }
+   }
 
+   if (realloc) {
   surf->buffer->destroy(surf->buffer);
 
   if (vlVaHandleSurfaceAllocate(ctx, surf, >templat) != 
VA_STATUS_SUCCESS) {
-- 
2.11.0

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


[Mesa-dev] [PATCH 06/20] st/va: add MJPEG picture to context

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/va_private.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index dee0c2b4c4..2c01bd3b2e 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -264,6 +264,7 @@ typedef struct {
   struct pipe_vc1_picture_desc vc1;
   struct pipe_h264_picture_desc h264;
   struct pipe_h265_picture_desc h265;
+  struct pipe_mjpeg_picture_desc mjpeg;
   struct pipe_h264_enc_picture_desc h264enc;
} desc;
 
-- 
2.11.0

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


[Mesa-dev] [PATCH 11/20] st/va: add huffman table handling for MJPEG

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/picture_mjpeg.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mjpeg.c 
b/src/gallium/state_trackers/va/picture_mjpeg.c
index 09b2efc21b..17f077962e 100644
--- a/src/gallium/state_trackers/va/picture_mjpeg.c
+++ b/src/gallium/state_trackers/va/picture_mjpeg.c
@@ -63,7 +63,24 @@ void vlVaHandleIQMatrixBufferMJPEG(vlVaContext *context, 
vlVaBuffer *buf)
 
 void vlVaHandleHuffmanTableBufferType(vlVaContext *context, vlVaBuffer *buf)
 {
-   /* TODO */
+   VAHuffmanTableBufferJPEGBaseline *mjpeg = buf->data;
+   int i;
+
+   assert(buf->size >= sizeof(VASliceParameterBufferJPEGBaseline) && 
buf->num_elements == 1);
+
+   for (i = 0; i < 2; ++i) {
+  context->desc.mjpeg.huffman_table.load_huffman_table[i] = 
mjpeg->load_huffman_table[i];
+
+  memcpy(>desc.mjpeg.huffman_table.table[i].num_dc_codes,
+ mjpeg->huffman_table[i].num_dc_codes, 16);
+  memcpy(>desc.mjpeg.huffman_table.table[i].dc_values,
+ mjpeg->huffman_table[i].dc_values, 12);
+  memcpy(>desc.mjpeg.huffman_table.table[i].num_ac_codes,
+ mjpeg->huffman_table[i].num_ac_codes, 16);
+  memcpy(>desc.mjpeg.huffman_table.table[i].ac_values,
+ mjpeg->huffman_table[i].ac_values, 162);
+  memcpy(>desc.mjpeg.huffman_table.table[i].pad, 
mjpeg->huffman_table[i].pad, 2);
+   }
 }
 
 void vlVaHandleSliceParameterBufferMJPEG(vlVaContext *context, vlVaBuffer *buf)
-- 
2.11.0

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


[Mesa-dev] [PATCH 14/20] st/va: make surface allocate functions more usefully

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/surface.c| 8 
 src/gallium/state_trackers/va/va_private.h | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index f968e9ede1..b116fc3f27 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -558,9 +558,9 @@ suface_from_external_memory(VADriverContextP ctx, 
vlVaSurface *surface,
return VA_STATUS_SUCCESS;
 }
 
-static VAStatus
-surface_allocate(VADriverContextP ctx, vlVaSurface *surface,
-struct pipe_video_buffer *templat)
+VAStatus
+vlVaHandleSurfaceAllocate(VADriverContextP ctx, vlVaSurface *surface,
+  struct pipe_video_buffer *templat)
 {
vlVaDriver *drv;
struct pipe_surface **surfaces;
@@ -734,7 +734,7 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int 
format,
  !(memory_attibute->flags & VA_SURFACE_EXTBUF_DESC_ENABLE_TILING))
 templat.bind = PIPE_BIND_LINEAR | PIPE_BIND_SHARED;
 
-vaStatus = surface_allocate(ctx, surf, );
+vaStatus = vlVaHandleSurfaceAllocate(ctx, surf, );
  if (vaStatus != VA_STATUS_SUCCESS)
 goto free_surf;
  break;
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 24b74509c8..a437a5b90f 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -396,6 +396,7 @@ VAStatus vlVaQueryVideoProcPipelineCaps(VADriverContextP 
ctx, VAContextID contex
 
 // internal functions
 VAStatus vlVaHandleVAProcPipelineParameterBufferType(vlVaDriver *drv, 
vlVaContext *context, vlVaBuffer *buf);
+VAStatus vlVaHandleSurfaceAllocate(VADriverContextP ctx, vlVaSurface *surface, 
struct pipe_video_buffer *templat);
 void vlVaGetReferenceFrame(vlVaDriver *drv, VASurfaceID surface_id, struct 
pipe_video_buffer **ref_frame);
 void vlVaHandlePictureParameterBufferMPEG12(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf);
 void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, vlVaBuffer *buf);
-- 
2.11.0

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


[Mesa-dev] [PATCH 13/20] radeon/uvd: reconstruct MJPEG bitstream

2017-08-16 Thread Leo Liu
The current tier 1 mjpeg firmware only supports at the bitstream
level, the later tier 2 support will be at the buffers level with
newer hardware.

Signed-off-by: Leo Liu 
Acked-by: Christian König 
---
 src/gallium/drivers/radeon/radeon_uvd.c | 136 
 1 file changed, 136 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index b140f4ca79..b6106c6e1f 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -947,6 +947,128 @@ static struct ruvd_mpeg4 get_mpeg4_msg(struct 
ruvd_decoder *dec,
return result;
 }
 
+static void get_mjpeg_slice_header(struct ruvd_decoder *dec, struct 
pipe_mjpeg_picture_desc *pic)
+{
+   int size = 0, saved_size, len_pos, i;
+   uint16_t *bs;
+   uint8_t *buf = dec->bs_ptr;
+
+   /* SOI */
+   buf[size++] = 0xff;
+   buf[size++] = 0xd8;
+
+   /* DQT */
+   buf[size++] = 0xff;
+   buf[size++] = 0xdb;
+
+   len_pos = size++;
+   size++;
+
+   for (i = 0; i < 4; ++i) {
+   if (pic->quantization_table.load_quantiser_table[i] == 0)
+   continue;
+
+   buf[size++] = i;
+   memcpy((buf + size), >quantization_table.quantiser_table, 
64);
+   size += 64;
+   }
+
+   bs = (uint16_t*)[len_pos];
+   *bs = util_bswap16(size - 4);
+
+   saved_size = size;
+
+   /* DHT */
+   buf[size++] = 0xff;
+   buf[size++] = 0xc4;
+
+   len_pos = size++;
+   size++;
+
+   for (i = 0; i < 2; ++i) {
+   if (pic->huffman_table.load_huffman_table[i] == 0)
+   continue;
+
+   buf[size++] = 0x00 | i;
+   memcpy((buf + size), >huffman_table.table[i].num_dc_codes, 
16);
+   size += 16;
+   memcpy((buf + size), >huffman_table.table[i].dc_values, 
12);
+   size += 12;
+   }
+
+   for (i = 0; i < 2; ++i) {
+   if (pic->huffman_table.load_huffman_table[i] == 0)
+   continue;
+
+   buf[size++] = 0x10 | i;
+   memcpy((buf + size), >huffman_table.table[i].num_ac_codes, 
16);
+   size += 16;
+   memcpy((buf + size), >huffman_table.table[i].ac_values, 
162);
+   size += 162;
+   }
+
+   bs = (uint16_t*)[len_pos];
+   *bs = util_bswap16(size - saved_size - 2);
+
+   saved_size = size;
+
+   /* SOF */
+   buf[size++] = 0xff;
+   buf[size++] = 0xc0;
+
+   len_pos = size++;
+   size++;
+
+   buf[size++] = 0x08;
+
+   bs = (uint16_t*)[size++];
+   *bs = util_bswap16(pic->picture_parameter.picture_height);
+   size++;
+
+   bs = (uint16_t*)[size++];
+   *bs = util_bswap16(pic->picture_parameter.picture_width);
+   size++;
+
+   buf[size++] = pic->picture_parameter.num_components;
+
+   for (i = 0; i < pic->picture_parameter.num_components; ++i) {
+   buf[size++] = pic->picture_parameter.components[i].component_id;
+   buf[size++] = 
pic->picture_parameter.components[i].h_sampling_factor << 4 |
+   pic->picture_parameter.components[i].v_sampling_factor;
+   buf[size++] = 
pic->picture_parameter.components[i].quantiser_table_selector;
+   }
+
+   bs = (uint16_t*)[len_pos];
+   *bs = util_bswap16(size - saved_size - 2);
+
+   saved_size = size;
+
+   /* SOS */
+   buf[size++] = 0xff;
+   buf[size++] = 0xda;
+
+   len_pos = size++;
+   size++;
+
+   buf[size++] = pic->slice_parameter.num_components;
+
+   for (i = 0; i < pic->slice_parameter.num_components; ++i) {
+   buf[size++] = 
pic->slice_parameter.components[i].component_selector;
+   buf[size++] = 
pic->slice_parameter.components[i].dc_table_selector << 4 |
+   pic->slice_parameter.components[i].ac_table_selector;
+   }
+
+   buf[size++] = 0x00;
+   buf[size++] = 0x3f;
+   buf[size++] = 0x00;
+
+   bs = (uint16_t*)[len_pos];
+   *bs = util_bswap16(size - saved_size - 2);
+
+   dec->bs_ptr += size;
+   dec->bs_size += size;
+}
+
 /**
  * destroy this video decoder
  */
@@ -1025,6 +1147,7 @@ static void ruvd_decode_bitstream(struct pipe_video_codec 
*decoder,
  const unsigned *sizes)
 {
struct ruvd_decoder *dec = (struct ruvd_decoder*)decoder;
+   enum pipe_video_format format = 
u_reduce_video_profile(picture->profile);
unsigned i;
 
assert(decoder);
@@ -1032,10 +1155,16 @@ static void ruvd_decode_bitstream(struct 
pipe_video_codec *decoder,
if (!dec->bs_ptr)
return;
 
+   if (format == PIPE_VIDEO_FORMAT_JPEG)
+   get_mjpeg_slice_header(dec, (struct 
pipe_mjpeg_picture_desc*)picture);
+
for (i = 0; i < 

[Mesa-dev] [PATCH 09/20] st/va: add picture parameter handling for MJPEG

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/picture_mjpeg.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mjpeg.c 
b/src/gallium/state_trackers/va/picture_mjpeg.c
index b0276e80dc..50f339eebf 100644
--- a/src/gallium/state_trackers/va/picture_mjpeg.c
+++ b/src/gallium/state_trackers/va/picture_mjpeg.c
@@ -29,7 +29,26 @@
 
 void vlVaHandlePictureParameterBufferMJPEG(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
 {
-   /* TODO */
+   VAPictureParameterBufferJPEGBaseline *mjpeg = buf->data;
+   int i;
+
+   assert(buf->size >= sizeof(VAPictureParameterBufferJPEGBaseline) && 
buf->num_elements == 1);
+
+   context->desc.mjpeg.picture_parameter.picture_width = mjpeg->picture_width;
+   context->desc.mjpeg.picture_parameter.picture_height = 
mjpeg->picture_height;
+
+   for (i = 0; i < mjpeg->num_components; ++i) {
+  context->desc.mjpeg.picture_parameter.components[i].component_id =
+ mjpeg->components[i].component_id;
+  context->desc.mjpeg.picture_parameter.components[i].h_sampling_factor =
+ mjpeg->components[i].h_sampling_factor;
+  context->desc.mjpeg.picture_parameter.components[i].v_sampling_factor =
+ mjpeg->components[i].v_sampling_factor;
+  
context->desc.mjpeg.picture_parameter.components[i].quantiser_table_selector =
+ mjpeg->components[i].quantiser_table_selector;
+   }
+
+   context->desc.mjpeg.picture_parameter.num_components = 
mjpeg->num_components;
 }
 
 void vlVaHandleIQMatrixBufferMJPEG(vlVaContext *context, vlVaBuffer *buf)
-- 
2.11.0

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


[Mesa-dev] [PATCH 16/20] st/va: reallocate surface when interlaced

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/picture.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 62a30782aa..732079139e 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -589,6 +589,8 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
vlVaBuffer *coded_buf;
vlVaSurface *surf;
void *feedback;
+   struct pipe_screen *screen;
+   bool interlaced;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -615,6 +617,26 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
surf = handle_table_get(drv->htab, context->target_id);
context->mpeg4.frame_num++;
 
+   screen = context->decoder->context->screen;
+   interlaced = screen->get_video_param(screen, context->decoder->profile,
+PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
+
+   if (surf->buffer->interlaced != interlaced) {
+  surf->templat.interlaced = screen->get_video_param(screen, 
context->decoder->profile,
+ 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+ 
PIPE_VIDEO_CAP_PREFERS_INTERLACED);
+
+  surf->buffer->destroy(surf->buffer);
+
+  if (vlVaHandleSurfaceAllocate(ctx, surf, >templat) != 
VA_STATUS_SUCCESS) {
+ mtx_unlock(>mutex);
+ return VA_STATUS_ERROR_ALLOCATION_FAILED;
+  }
+
+  context->target = surf->buffer;
+   }
+
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
   coded_buf = context->coded_buf;
   getEncParamPreset(context);
-- 
2.11.0

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


[Mesa-dev] [PATCH 18/20] st/va: detect MJPEG format from bitstream

2017-08-16 Thread Leo Liu
To find if the format is supported YUYV by sampling factor which
is embedded from bitstream. So we could use this info for buffer
relocation on the correct format.

Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/picture.c   | 1 +
 src/gallium/state_trackers/va/picture_mjpeg.c | 5 +
 src/gallium/state_trackers/va/va_private.h| 4 
 3 files changed, 10 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 732079139e..1e1212dd7a 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -65,6 +65,7 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID 
context_id, VASurfaceID rende
context->target_id = render_target;
surf->ctx = context_id;
context->target = surf->buffer;
+   context->mjpeg.sampling_factor = 0;
 
if (!context->decoder) {
 
diff --git a/src/gallium/state_trackers/va/picture_mjpeg.c 
b/src/gallium/state_trackers/va/picture_mjpeg.c
index 326c890c88..396b743442 100644
--- a/src/gallium/state_trackers/va/picture_mjpeg.c
+++ b/src/gallium/state_trackers/va/picture_mjpeg.c
@@ -30,6 +30,7 @@
 void vlVaHandlePictureParameterBufferMJPEG(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
 {
VAPictureParameterBufferJPEGBaseline *mjpeg = buf->data;
+   unsigned sf;
int i;
 
assert(buf->size >= sizeof(VAPictureParameterBufferJPEGBaseline) && 
buf->num_elements == 1);
@@ -46,6 +47,10 @@ void vlVaHandlePictureParameterBufferMJPEG(vlVaDriver *drv, 
vlVaContext *context
  mjpeg->components[i].v_sampling_factor;
   
context->desc.mjpeg.picture_parameter.components[i].quantiser_table_selector =
  mjpeg->components[i].quantiser_table_selector;
+
+  sf = mjpeg->components[i].h_sampling_factor << 4 | 
mjpeg->components[i].v_sampling_factor;
+  context->mjpeg.sampling_factor <<= 8;
+  context->mjpeg.sampling_factor |= sf;
}
 
context->desc.mjpeg.picture_parameter.num_components = 
mjpeg->num_components;
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index a437a5b90f..9c09318127 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -277,6 +277,10 @@ typedef struct {
   uint8_t start_code[32];
} mpeg4;
 
+   struct {
+  unsigned sampling_factor;
+   } mjpeg;
+
struct vl_deint_filter *deint;
vlVaBuffer *coded_buf;
int target_id;
-- 
2.11.0

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


[Mesa-dev] [PATCH 15/20] radeon/video: MJPEG not support stacked video buffers

2017-08-16 Thread Leo Liu
So we have to detect it for relocation of de-interlaced buffers

Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/drivers/radeon/radeon_video.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index 21c57d2c0f..bec74715aa 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -313,8 +313,12 @@ int rvid_get_video_param(struct pipe_screen *screen,
return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
   rscreen->family > CHIP_RV770;
} else {
-   if (u_reduce_video_profile(profile) == 
PIPE_VIDEO_FORMAT_HEVC)
+   enum pipe_video_format format = 
u_reduce_video_profile(profile);
+
+   if (format == PIPE_VIDEO_FORMAT_HEVC)
return false; //The firmware doesn't support 
interlaced HEVC.
+   else if (format == PIPE_VIDEO_FORMAT_JPEG)
+   return false;
return true;
}
case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE:
-- 
2.11.0

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


[Mesa-dev] [PATCH 08/20] st/va: add handles for MJPEG Buffers

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/Makefile.sources |  1 +
 src/gallium/state_trackers/va/picture.c| 19 ++
 src/gallium/state_trackers/va/picture_mjpeg.c  | 48 ++
 src/gallium/state_trackers/va/va_private.h |  4 +++
 4 files changed, 72 insertions(+)
 create mode 100644 src/gallium/state_trackers/va/picture_mjpeg.c

diff --git a/src/gallium/state_trackers/va/Makefile.sources 
b/src/gallium/state_trackers/va/Makefile.sources
index daebf0120f..2d6546b4b6 100644
--- a/src/gallium/state_trackers/va/Makefile.sources
+++ b/src/gallium/state_trackers/va/Makefile.sources
@@ -10,6 +10,7 @@ C_SOURCES := \
picture_h264.c \
picture_hevc.c \
picture_vc1.c \
+   picture_mjpeg.c \
postproc.c \
subpicture.c \
surface.c \
diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 30617e8cfe..62a30782aa 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -164,6 +164,10 @@ handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *
   vlVaHandlePictureParameterBufferHEVC(drv, context, buf);
   break;
 
+  case PIPE_VIDEO_FORMAT_JPEG:
+  vlVaHandlePictureParameterBufferMJPEG(drv, context, buf);
+  break;
+
default:
   break;
}
@@ -216,6 +220,10 @@ handleIQMatrixBuffer(vlVaContext *context, vlVaBuffer *buf)
   vlVaHandleIQMatrixBufferHEVC(context, buf);
   break;
 
+   case PIPE_VIDEO_FORMAT_JPEG:
+  vlVaHandleIQMatrixBufferMJPEG(context, buf);
+  break;
+
default:
   break;
}
@@ -245,6 +253,10 @@ handleSliceParameterBuffer(vlVaContext *context, 
vlVaBuffer *buf)
   vlVaHandleSliceParameterBufferHEVC(context, buf);
   break;
 
+   case PIPE_VIDEO_FORMAT_JPEG:
+  vlVaHandleSliceParameterBufferMJPEG(context, buf);
+  break;
+
default:
   break;
}
@@ -313,6 +325,9 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
   vlVaDecoderFixMPEG4Startcode(context);
   buffers[num_buffers] = (void *)context->mpeg4.start_code;
   sizes[num_buffers++] = context->mpeg4.start_code_size;
+   case PIPE_VIDEO_FORMAT_JPEG:
+  /* TODO */
+  break;
default:
   break;
}
@@ -553,6 +568,10 @@ vlVaRenderPicture(VADriverContextP ctx, VAContextID 
context_id, VABufferID *buff
  vaStatus = handleVAEncSliceParameterBufferType(drv, context, buf);
  break;
 
+  case VAHuffmanTableBufferType:
+ vlVaHandleHuffmanTableBufferType(context, buf);
+ break;
+
   default:
  break;
   }
diff --git a/src/gallium/state_trackers/va/picture_mjpeg.c 
b/src/gallium/state_trackers/va/picture_mjpeg.c
new file mode 100644
index 00..b0276e80dc
--- /dev/null
+++ b/src/gallium/state_trackers/va/picture_mjpeg.c
@@ -0,0 +1,48 @@
+/**
+ *
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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 "va_private.h"
+
+void vlVaHandlePictureParameterBufferMJPEG(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
+{
+   /* TODO */
+}
+
+void vlVaHandleIQMatrixBufferMJPEG(vlVaContext *context, vlVaBuffer *buf)
+{
+   /* TODO */
+}
+
+void vlVaHandleHuffmanTableBufferType(vlVaContext *context, vlVaBuffer *buf)
+{
+   /* TODO */
+}
+
+void vlVaHandleSliceParameterBufferMJPEG(vlVaContext *context, vlVaBuffer *buf)
+{
+   /* TODO */
+}
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 2c01bd3b2e..24b74509c8 100644
--- 

[Mesa-dev] [PATCH 10/20] st/va: add iq matrix handling for MJPEG

2017-08-16 Thread Leo Liu
Signed-off-by: Leo Liu 
Reviewed-by: Christian König 
---
 src/gallium/state_trackers/va/picture_mjpeg.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mjpeg.c 
b/src/gallium/state_trackers/va/picture_mjpeg.c
index 50f339eebf..09b2efc21b 100644
--- a/src/gallium/state_trackers/va/picture_mjpeg.c
+++ b/src/gallium/state_trackers/va/picture_mjpeg.c
@@ -53,7 +53,12 @@ void vlVaHandlePictureParameterBufferMJPEG(vlVaDriver *drv, 
vlVaContext *context
 
 void vlVaHandleIQMatrixBufferMJPEG(vlVaContext *context, vlVaBuffer *buf)
 {
-   /* TODO */
+   VAIQMatrixBufferJPEGBaseline *mjpeg = buf->data;
+
+   assert(buf->size >= sizeof(VAIQMatrixBufferJPEGBaseline) && 
buf->num_elements == 1);
+
+   memcpy(>desc.mjpeg.quantization_table.load_quantiser_table, 
mjpeg->load_quantiser_table, 4);
+   memcpy(>desc.mjpeg.quantization_table.quantiser_table, 
mjpeg->quantiser_table, 4 * 64);
 }
 
 void vlVaHandleHuffmanTableBufferType(vlVaContext *context, vlVaBuffer *buf)
-- 
2.11.0

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


[Mesa-dev] [PATCH 07/20] st/va: create decoder for MJPEG format

2017-08-16 Thread Leo Liu
Mjpeg doesn't need reference

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 338e0902d6..30617e8cfe 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -170,14 +170,17 @@ handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *
 
/* Create the decoder once max_references is known. */
if (!context->decoder) {
+  enum pipe_video_format format =
+ u_reduce_video_profile(context->templat.profile);
+
   if (!context->target)
  return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-  if (context->templat.max_references == 0)
+  if (context->templat.max_references == 0 &&
+ format != PIPE_VIDEO_FORMAT_JPEG)
  return VA_STATUS_ERROR_INVALID_BUFFER;
 
-  if (u_reduce_video_profile(context->templat.profile) ==
-  PIPE_VIDEO_FORMAT_MPEG4_AVC)
+  if (format == PIPE_VIDEO_FORMAT_MPEG4_AVC)
  context->templat.level = u_get_h264_level(context->templat.width,
 context->templat.height, >templat.max_references);
 
-- 
2.11.0

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


Re: [Mesa-dev] [PATCH 00/20] MJPEG decode support through VA-API

2017-08-16 Thread Leo Liu



On 08/16/2017 01:40 PM, Leo Liu wrote:



On 08/16/2017 03:22 AM, Christian König wrote:

Hi Leo,

Patches #2, #4, #6, #8 - #12, #14, #18-#20 are Reviewed-by: Christian 
König 


Patch #1:

When you add new formats it would be nice to have 
u_reduce_video_profile() in src/gallium/auxiliary/util/u_video.h 
updated as well.


Yes. I have "u_reduce_video_profile()"  updated in patch 3.

The patch1 and patch2 are for vl headers, but I will move 
u_reduce_video_profile() to patch 1 in v2




Additional to that I think the codec name is JPEG, not MJPEG. MJPEG 
is just the file/stream format with multiple JPEGs.


Okay.



Patch #3:


+case PIPE_VIDEO_FORMAT_MJPEG:
+return true;
Please reorder the patch to be the last of the radeon/* patches, so 
that the driver only starts to claim JPEG support when everything 
else is implemented.


Sure in v2 patch 5, also add check for kernel version and ASICs.



Apart from that the patch is Reviewed-by: Christian König 



Patch #5:

+if (dec->stream_type != RUVD_CODEC_MJPEG) {
+dpb_size = calc_dpb_size(dec);
+if (!rvid_create_buffer(dec->screen, >dpb, dpb_size, 
PIPE_USAGE_DEFAULT)) {

+RVID_ERR("Can't allocated dpb.\n");
+goto error;
+}
+rvid_clear_buffer(context, >dpb);
I think it would be cleaner if calc_dpb_size() just return zero for 
RUVD_CODEC_MJPEG and then the calling code skipping buffer allocation 
when it sees a zero sized dpb.


Sure in v2 patch3.


Sorry in v2 patch 4, because the small reorder here.

Leo






Patch #7:

+  enum pipe_video_format format =
+ u_reduce_video_profile(context->templat.profile);
+
Here you use u_reduce_video_profile, but I can't see where you update 
u_reduce_video_profile() for JPEG support?


It's at original patch 3.




Patch #13:

Mhm, I'm not sure if it is a good idea to add this to the driver 
backend, but the patch is Acked-by: Christian König 
 anyway.


Patch #15, #16 and #17 are somehow missing and didn't made it to the 
mailing list.
>The subject line should probably read "reallocate" instead of 
"relocate".


>Additional to that the term "stacked field" isn't really used outside 
AMD, better use interlaced layout.


I will fix commit message.


>  case RUVD_SURFACE_TYPE_LEGACY:
> msg->body.decode.dt_pitch = luma->u.legacy.level[0].nblk_x;
>+if (!chroma)
>+msg->body.decode.dt_pitch *= 2;

>Patch looks good to me, except for this hunk.

>Can we get the pitch somehow else instead of making it depending if 
chroma is present or not?


>Cause that is clearly not correct in all cases.

I will add stream type check in v2.


Thanks for the review.

Leo




Regards,
Christian.

Am 15.08.2017 um 22:08 schrieb Leo Liu:
The series is able to enable mjpeg decode support through vaapi, and 
that

includes for the formats of 420(NV12) and 422(YUYV).

Leo Liu (20):
   vl: add mjpeg profile and format
   vl: add mjpeg picture description
   radeon/video: add mjpeg support
   radeon/uvd: add mjpeg stream type
   radeon/uvd: add mjpeg support
   st/va: add mjpeg picture to context
   st/va: create decoder for mjpeg format
   st/va: add handles for mjpeg Buffers
   st/va: add picture parameter handling for mjpeg
   st/va: add iq matrix handling for mjpeg
   st/va: add huffman table handling for mjpeg
   st/va: add slice parameter handling for mjpeg
   radeon/uvd: reconstruct mjpeg bitstream
   st/va: make surface allocate functions more usefully
   radeon/video: mjpeg not support stacked video buffers
   st/va: relocate surface when stack field false
   radeon/uvd: add yuyv format support for target buffer
   st/va: detect mjpeg format from bitstream
   st/va: relocate surface with yuyv stream
   st/va: add mjpeg for config

  src/gallium/auxiliary/util/u_video.h   |   3 +
  src/gallium/drivers/radeon/radeon_uvd.c| 175 
+++--

  src/gallium/drivers/radeon/radeon_uvd.h|   1 +
  src/gallium/drivers/radeon/radeon_video.c  |   8 +-
  src/gallium/drivers/radeonsi/si_uvd.c  |   2 +-
  src/gallium/include/pipe/p_video_enums.h   |   6 +-
  src/gallium/include/pipe/p_video_state.h   |  59 +
  src/gallium/state_trackers/va/Makefile.sources |   1 +
  src/gallium/state_trackers/va/config.c |   2 +-
  src/gallium/state_trackers/va/picture.c|  70 +-
  src/gallium/state_trackers/va/picture_mjpeg.c  | 116 
  src/gallium/state_trackers/va/surface.c|   8 +-
  src/gallium/state_trackers/va/va_private.h |  14 ++
  13 files changed, 440 insertions(+), 25 deletions(-)
  create mode 100644 src/gallium/state_trackers/va/picture_mjpeg.c





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



Re: [Mesa-dev] [PATCH 00/20] MJPEG decode support through VA-API

2017-08-16 Thread Leo Liu



On 08/16/2017 03:22 AM, Christian König wrote:

Hi Leo,

Patches #2, #4, #6, #8 - #12, #14, #18-#20 are Reviewed-by: Christian 
König 


Patch #1:

When you add new formats it would be nice to have 
u_reduce_video_profile() in src/gallium/auxiliary/util/u_video.h 
updated as well.


Yes. I have "u_reduce_video_profile()"  updated in patch 3.

The patch1 and patch2 are for vl headers, but I will move 
u_reduce_video_profile() to patch 1 in v2




Additional to that I think the codec name is JPEG, not MJPEG. MJPEG is 
just the file/stream format with multiple JPEGs.


Okay.



Patch #3:


+case PIPE_VIDEO_FORMAT_MJPEG:
+return true;
Please reorder the patch to be the last of the radeon/* patches, so 
that the driver only starts to claim JPEG support when everything else 
is implemented.


Sure in v2 patch 5, also add check for kernel version and ASICs.



Apart from that the patch is Reviewed-by: Christian König 



Patch #5:

+if (dec->stream_type != RUVD_CODEC_MJPEG) {
+dpb_size = calc_dpb_size(dec);
+if (!rvid_create_buffer(dec->screen, >dpb, dpb_size, 
PIPE_USAGE_DEFAULT)) {

+RVID_ERR("Can't allocated dpb.\n");
+goto error;
+}
+rvid_clear_buffer(context, >dpb);
I think it would be cleaner if calc_dpb_size() just return zero for 
RUVD_CODEC_MJPEG and then the calling code skipping buffer allocation 
when it sees a zero sized dpb.


Sure in v2 patch3.



Patch #7:

+  enum pipe_video_format format =
+ u_reduce_video_profile(context->templat.profile);
+
Here you use u_reduce_video_profile, but I can't see where you update 
u_reduce_video_profile() for JPEG support?


It's at original patch 3.




Patch #13:

Mhm, I'm not sure if it is a good idea to add this to the driver 
backend, but the patch is Acked-by: Christian König 
 anyway.


Patch #15, #16 and #17 are somehow missing and didn't made it to the 
mailing list.

>The subject line should probably read "reallocate" instead of "relocate".

>Additional to that the term "stacked field" isn't really used outside 
AMD, better use interlaced layout.


I will fix commit message.


>  case RUVD_SURFACE_TYPE_LEGACY:
> msg->body.decode.dt_pitch = luma->u.legacy.level[0].nblk_x;
>+if (!chroma)
>+msg->body.decode.dt_pitch *= 2;

>Patch looks good to me, except for this hunk.

>Can we get the pitch somehow else instead of making it depending if 
chroma is present or not?


>Cause that is clearly not correct in all cases.

I will add stream type check in v2.


Thanks for the review.

Leo




Regards,
Christian.

Am 15.08.2017 um 22:08 schrieb Leo Liu:
The series is able to enable mjpeg decode support through vaapi, and 
that

includes for the formats of 420(NV12) and 422(YUYV).

Leo Liu (20):
   vl: add mjpeg profile and format
   vl: add mjpeg picture description
   radeon/video: add mjpeg support
   radeon/uvd: add mjpeg stream type
   radeon/uvd: add mjpeg support
   st/va: add mjpeg picture to context
   st/va: create decoder for mjpeg format
   st/va: add handles for mjpeg Buffers
   st/va: add picture parameter handling for mjpeg
   st/va: add iq matrix handling for mjpeg
   st/va: add huffman table handling for mjpeg
   st/va: add slice parameter handling for mjpeg
   radeon/uvd: reconstruct mjpeg bitstream
   st/va: make surface allocate functions more usefully
   radeon/video: mjpeg not support stacked video buffers
   st/va: relocate surface when stack field false
   radeon/uvd: add yuyv format support for target buffer
   st/va: detect mjpeg format from bitstream
   st/va: relocate surface with yuyv stream
   st/va: add mjpeg for config

  src/gallium/auxiliary/util/u_video.h   |   3 +
  src/gallium/drivers/radeon/radeon_uvd.c| 175 
+++--

  src/gallium/drivers/radeon/radeon_uvd.h|   1 +
  src/gallium/drivers/radeon/radeon_video.c  |   8 +-
  src/gallium/drivers/radeonsi/si_uvd.c  |   2 +-
  src/gallium/include/pipe/p_video_enums.h   |   6 +-
  src/gallium/include/pipe/p_video_state.h   |  59 +
  src/gallium/state_trackers/va/Makefile.sources |   1 +
  src/gallium/state_trackers/va/config.c |   2 +-
  src/gallium/state_trackers/va/picture.c|  70 +-
  src/gallium/state_trackers/va/picture_mjpeg.c  | 116 
  src/gallium/state_trackers/va/surface.c|   8 +-
  src/gallium/state_trackers/va/va_private.h |  14 ++
  13 files changed, 440 insertions(+), 25 deletions(-)
  create mode 100644 src/gallium/state_trackers/va/picture_mjpeg.c





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


[Mesa-dev] [Bug 100438] glsl/ir.cpp:1376: ir_dereference_variable::ir_dereference_variable(ir_variable*): Assertion `var != NULL' failed.

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100438

--- Comment #3 from Paul Menzel  ---
This seems to be fixed?

The test reveals a regression(?) too, cf bug 102265 [1]. So thank you for
adding the test.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=102265

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102265] Segfault in `ir_dereference_variable::ir_dereference_variable` dereferencing NULL variable

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102265

Bug ID: 102265
   Summary: Segfault in
`ir_dereference_variable::ir_dereference_variable`
dereferencing NULL variable
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: pmenzel+bugs.freedesk...@molgen.mpg.de
QA Contact: intel-3d-b...@lists.freedesktop.org

Created attachment 133555
  --> https://bugs.freedesktop.org/attachment.cgi?id=133555=edit
Stack trace captured with GDB

The test added in bug 100438 crashes in radeonsi_dri.so (Linux 4.9.43, Mesa
17.1.6, libdrm 2.4.82).


```
glslparsertest[28096]: segfault at 20 ip 7f52efb31088 sp 7ffcac4e67e0
error 4 in radeonsi_dri.so[7f52ef82e000+964000]
```

Here is the backtrace.

```
ir_dereference_variable::ir_dereference_variable (var=0x0, this=0x776400) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ir.cpp:1391
1391   
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ir.cpp: No
such file or directory.
#0  ir_dereference_variable::ir_dereference_variable (var=0x0, this=0x776400)
at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ir.cpp:1391
#1  ir_dereference_array::ir_dereference_array (this=0x776390, var=0x0,
array_index=0x775120) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ir.cpp:1411
#2  0x71f17f9b in generate_array_index (mem_ctx=mem_ctx@entry=0x7627c0,
instructions=instructions@entry=0x775090, state=state@entry=0x7627c0, loc=...,
array=, idx=,
function_name=function_name@entry=0x7fffe480,
actual_parameters=0x7fffe4b0) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ast_function.cpp:668
#3  0x71f1af98 in ast_function_expression::hir (this=0x763b00,
instructions=0x775090, state=0x7627c0) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ast_function.cpp:2191
#4  0x71f225d3 in ast_expression_statement::hir (this=,
instructions=, state=) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ast_to_hir.cpp:2201
#5  0x71f2262f in ast_compound_statement::hir (this=0x763c70,
instructions=0x775090, state=0x7627c0) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ast_to_hir.cpp:2217
#6  0x71f2872a in ast_function_definition::hir (this=0x763cd0,
instructions=, state=0x7627c0) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ast_to_hir.cpp:5853
#7  0x71f1f5f8 in _mesa_ast_to_hir (instructions=0x765020,
state=state@entry=0x7627c0) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/ast_to_hir.cpp:155
#8  0x71f80b6a in _mesa_glsl_compile_shader (ctx=ctx@entry=0x71c1f0,
shader=shader@entry=0x762650, dump_ast=dump_ast@entry=false,
dump_hir=dump_hir@entry=false, force_recompile=force_recompile@entry=false) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/compiler/glsl/glsl_parser_extras.cpp:2071
#9  0x71e1f4b4 in _mesa_compile_shader (ctx=0x71c1f0, sh=0x762650) at
/dev/shm/bee-root/mesalib/mesalib-17.1.6-0/source/src/mesa/main/shaderapi.c:1044
#10 0x77a9b1f6 in stub_glCompileShader (shader=1) at
/dev/shm/piglit/tests/util/piglit-dispatch-gen.c:7084
#11 0x00401f7f in test () at
/dev/shm/piglit/tests/glslparsertest/glslparsertest.c:303
#12 0x0040271d in piglit_init (argc=4, argv=0x7fffe998) at
/dev/shm/piglit/tests/glslparsertest/glslparsertest.c:543
#13 0x77b3737b in run_test (gl_fw=0x615c20, argc=4,
argv=0x7fffe998) at
/dev/shm/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:73
#14 0x77b1bb5d in piglit_gl_test_run (argc=4, argv=0x7fffe998,
config=0x7fffe850) at /dev/shm/piglit/tests/util/piglit-framework-gl.c:223
#15 0x0040199e in main (argc=4, argv=0x7fffe998) at
/dev/shm/piglit/tests/glslparsertest/glslparsertest.c:90
```

The full stack trace is attached.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=100438

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] llvmpipe: enable PIPE_CAP_QUERY_SO_OVERFLOW

2017-08-16 Thread Jose Fonseca

On 15/08/17 17:23, srol...@vmware.com wrote:

From: Roland Scheidegger 

The driver supported this since way before the GL spec for it existed.
Just need to support both the per-stream and for all streams variants
(which are identical due to only supporting 1 stream).
Passes piglit arb_transform_feedback_overflow_query-basic.
---
  docs/features.txt| 2 +-
  src/gallium/drivers/llvmpipe/lp_query.c  | 3 +++
  src/gallium/drivers/llvmpipe/lp_screen.c | 2 +-
  3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ace4669..6f57ec2 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -232,7 +232,7 @@ GL 4.6, GLSL 4.60
GL_ARB_shader_group_vote  DONE (i965, nvc0, 
radeonsi)
GL_ARB_spirv_extensions   in progress (Nicolai 
Hähnle, Ian Romanick)
GL_ARB_texture_filter_anisotropic not started
-  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
radeonsi, softpipe)
+  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
radeonsi, llvmpipe, softpipe)
GL_KHR_no_error   started (Timothy 
Arceri)
  
  These are the extensions cherry-picked to make GLES 3.1

diff --git a/src/gallium/drivers/llvmpipe/lp_query.c 
b/src/gallium/drivers/llvmpipe/lp_query.c
index d5ed656..6f8ce94 100644
--- a/src/gallium/drivers/llvmpipe/lp_query.c
+++ b/src/gallium/drivers/llvmpipe/lp_query.c
@@ -155,6 +155,7 @@ llvmpipe_get_query_result(struct pipe_context *pipe,
*result = pq->num_primitives_written;
break;
 case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
vresult->b = pq->num_primitives_generated > pq->num_primitives_written;
break;
 case PIPE_QUERY_SO_STATISTICS: {
@@ -215,6 +216,7 @@ llvmpipe_begin_query(struct pipe_context *pipe, struct 
pipe_query *q)
pq->num_primitives_generated = 
llvmpipe->so_stats.primitives_storage_needed;
break;
 case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
pq->num_primitives_written = llvmpipe->so_stats.num_primitives_written;
pq->num_primitives_generated = 
llvmpipe->so_stats.primitives_storage_needed;
break;
@@ -264,6 +266,7 @@ llvmpipe_end_query(struct pipe_context *pipe, struct 
pipe_query *q)
   llvmpipe->so_stats.primitives_storage_needed - 
pq->num_primitives_generated;
break;
 case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
pq->num_primitives_written =
   llvmpipe->so_stats.num_primitives_written - 
pq->num_primitives_written;
pq->num_primitives_generated =
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 6c64133..32a4050 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -270,6 +270,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_DOUBLES:
 case PIPE_CAP_INT64:
 case PIPE_CAP_INT64_DIVMOD:
+   case PIPE_CAP_QUERY_SO_OVERFLOW:
return 1;
  
 case PIPE_CAP_VENDOR_ID:

@@ -357,7 +358,6 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_POST_DEPTH_COVERAGE:
 case PIPE_CAP_BINDLESS_TEXTURE:
 case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
-   case PIPE_CAP_QUERY_SO_OVERFLOW:
 case PIPE_CAP_MEMOBJ:
return 0;
 }



Series is

Reviewed-by: Jose Fonseca 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] gallium/os: fix os_time_get_nano() to roll over less

2017-08-16 Thread Brian Paul
From: Frank Richter 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102241
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Brian Paul 
---
 src/gallium/auxiliary/os/os_time.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/os/os_time.c 
b/src/gallium/auxiliary/os/os_time.c
index e169139..e4a1cae 100644
--- a/src/gallium/auxiliary/os/os_time.c
+++ b/src/gallium/auxiliary/os/os_time.c
@@ -69,10 +69,17 @@ os_time_get_nano(void)
 
static LARGE_INTEGER frequency;
LARGE_INTEGER counter;
+   int64_t secs, nanosecs;
if(!frequency.QuadPart)
   QueryPerformanceFrequency();
QueryPerformanceCounter();
-   return counter.QuadPart*INT64_C(10)/frequency.QuadPart;
+   /* Compute seconds and nanoseconds parts separately to
+* reduce severity of precision loss.
+*/
+   secs = counter.QuadPart / frequency.QuadPart;
+   nanosecs = (counter.QuadPart % frequency.QuadPart) * INT64_C(10)
+  / frequency.QuadPart;
+   return secs*INT64_C(10) + nanosecs;
 
 #else
 
-- 
1.9.1

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


[Mesa-dev] [PATCH 1/2] st/wgl: check for negative delta in wait_swap_interval()

2017-08-16 Thread Brian Paul
From: Frank Richter 

This can happen because of rollover.  See bug report for details.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102241
Cc: mesa-sta...@lists.freedesktop.org
Reviewed-by: Brian Paul 
---
 src/gallium/state_trackers/wgl/stw_framebuffer.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/wgl/stw_framebuffer.c 
b/src/gallium/state_trackers/wgl/stw_framebuffer.c
index 321fbb6..06b5c8d 100644
--- a/src/gallium/state_trackers/wgl/stw_framebuffer.c
+++ b/src/gallium/state_trackers/wgl/stw_framebuffer.c
@@ -601,8 +601,11 @@ wait_swap_interval(struct stw_framebuffer *fb)
   int64_t min_swap_period =
  1.0e6 / stw_dev->refresh_rate * stw_dev->swap_interval;
 
-  /* if time since last swap is less than wait period, wait */
-  if (delta < min_swap_period) {
+  /* If time since last swap is less than wait period, wait.
+   * Note that it's possible for the delta to be negative because of
+   * rollover.  See https://bugs.freedesktop.org/show_bug.cgi?id=102241
+   */
+  if ((delta >= 0) && (delta < min_swap_period)) {
  float fudge = 1.75f;  /* emperical fudge factor */
  int64_t wait = (min_swap_period - delta) * fudge;
  os_time_sleep(wait);
-- 
1.9.1

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


[Mesa-dev] [Bug 102241] gallium/wgl: SwapBuffers freezing regularly with swap interval enabled

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102241

--- Comment #2 from Brian Paul  ---
Thanks for the patches.  I'll do a little clean-up then post them for review on
mesa-dev in case anyone else has comments.  I'll push to master in a day or so
if there's no additional feedback.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102148] Crash when running qopenglwidget example on mesa llvmpipe win32

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102148

--- Comment #3 from Brian Paul  ---
Thanks for the patch.  Looks good to me.  I'll just clean up the commit message
before pushing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] squash! radeonsi: print saved CS to the log context

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

I noticed these after rebasing on current master, where the CE
is disabled by default.

v2: fix some crashes when not using CE
---
 src/gallium/drivers/radeonsi/si_debug.c  | 5 -
 src/gallium/drivers/radeonsi/si_hw_context.c | 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_debug.c 
b/src/gallium/drivers/radeonsi/si_debug.c
index 7ad28a23dfc..e53ea3bf88d 100644
--- a/src/gallium/drivers/radeonsi/si_debug.c
+++ b/src/gallium/drivers/radeonsi/si_debug.c
@@ -405,7 +405,10 @@ static void si_log_cs(struct si_context *ctx, struct 
u_log_context *log,
 
struct si_saved_cs *scs = ctx->current_saved_cs;
unsigned gfx_cur = ctx->b.gfx.cs->prev_dw + ctx->b.gfx.cs->current.cdw;
-   unsigned ce_cur = ctx->ce_ib->prev_dw + ctx->ce_ib->current.cdw;
+   unsigned ce_cur = 0;
+
+   if (ctx->ce_ib)
+   ce_cur = ctx->ce_ib->prev_dw + ctx->ce_ib->current.cdw;
 
if (!dump_bo_list &&
gfx_cur == scs->gfx_last_dw &&
diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c 
b/src/gallium/drivers/radeonsi/si_hw_context.c
index 73aea70434e..288a81e68b8 100644
--- a/src/gallium/drivers/radeonsi/si_hw_context.c
+++ b/src/gallium/drivers/radeonsi/si_hw_context.c
@@ -153,7 +153,8 @@ void si_context_gfx_flush(void *context, unsigned flags,
 
/* Save the IB for debug contexts. */
radeon_save_cs(ws, cs, >current_saved_cs->gfx, true);
-   radeon_save_cs(ws, ctx->ce_ib, >current_saved_cs->ce, 
false);
+   if (ctx->ce_ib)
+   radeon_save_cs(ws, ctx->ce_ib, 
>current_saved_cs->ce, false);
ctx->current_saved_cs->flushed = true;
}
 
-- 
2.11.0

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


[Mesa-dev] [Bug 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101832

--- Comment #9 from Bernhard Rosenkraenzer  ---
Created attachment 133549
  --> https://bugs.freedesktop.org/attachment.cgi?id=133549=edit
Workaround

This "fixes" it (forward-port of reverting the commit causing the problem,
applies cleanly on 17.2.0-rc4) -- but obviously it isn't a perfect fix because
it brings back the problems the original commit was meant to solve.

Certainly better than X crashing on startup though ;)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 101851] [regression] libEGL_common.a undefined reference to '__gxx_personality_v0'

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101851

James Harvey  changed:

   What|Removed |Added

 CC||lothmor...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 3/4] radeonsi: remove INCREMENT_DE_COUNTER

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

We don't actually ever use the DE counter for synchronization.
---
 src/gallium/drivers/radeonsi/si_compute.c|  2 --
 src/gallium/drivers/radeonsi/si_state.h  |  1 -
 src/gallium/drivers/radeonsi/si_state_draw.c | 10 --
 3 files changed, 13 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index d0e481a3f15..3d1161b6e1f 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -848,8 +848,6 @@ static void si_launch_grid(
 
si_emit_dispatch_packets(sctx, info);
 
-   si_ce_post_draw_synchronization(sctx);
-
if (unlikely(sctx->current_saved_cs))
si_trace_emit(sctx);
 
diff --git a/src/gallium/drivers/radeonsi/si_state.h 
b/src/gallium/drivers/radeonsi/si_state.h
index bce40663085..57d074c1a7f 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -402,7 +402,6 @@ void si_get_active_slot_masks(const struct tgsi_shader_info 
*info,
 void si_init_ia_multi_vgt_param_table(struct si_context *sctx);
 void si_emit_cache_flush(struct si_context *sctx);
 void si_ce_pre_draw_synchronization(struct si_context *sctx);
-void si_ce_post_draw_synchronization(struct si_context *sctx);
 void si_draw_vbo(struct pipe_context *ctx, const struct pipe_draw_info *dinfo);
 void si_trace_emit(struct si_context *sctx);
 
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index b0d2c127fa1..ce92fce0725 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -1150,14 +1150,6 @@ void si_ce_pre_draw_synchronization(struct si_context 
*sctx)
 
radeon_emit(sctx->b.gfx.cs, PKT3(PKT3_WAIT_ON_CE_COUNTER, 0, 
0));
radeon_emit(sctx->b.gfx.cs, 0); /* 0 = don't flush sL1 
conditionally */
-   }
-}
-
-void si_ce_post_draw_synchronization(struct si_context *sctx)
-{
-   if (sctx->ce_need_synchronization) {
-   radeon_emit(sctx->b.gfx.cs, PKT3(PKT3_INCREMENT_DE_COUNTER, 0, 
0));
-   radeon_emit(sctx->b.gfx.cs, 0); /* unused */
 
sctx->ce_need_synchronization = false;
}
@@ -1437,8 +1429,6 @@ void si_draw_vbo(struct pipe_context *ctx, const struct 
pipe_draw_info *info)
si_emit_draw_packets(sctx, info, indexbuf, index_size, 
index_offset);
}
 
-   si_ce_post_draw_synchronization(sctx);
-
if (unlikely(sctx->current_saved_cs))
si_trace_emit(sctx);
 
-- 
2.11.0

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


[Mesa-dev] [PATCH 1/4] radeonsi: extract common code of si_upload_{graphics, compute}_shader_descriptors

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_descriptors.c | 27 ---
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 1e0c422fb4b..9372d1b6a00 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -2903,9 +2903,8 @@ void si_init_all_descriptors(struct si_context *sctx)
si_set_user_data_base(sctx, PIPE_SHADER_FRAGMENT, 
R_00B030_SPI_SHADER_USER_DATA_PS_0);
 }
 
-bool si_upload_graphics_shader_descriptors(struct si_context *sctx)
+static bool si_upload_shader_descriptors(struct si_context *sctx, unsigned 
mask)
 {
-   const unsigned mask = u_bit_consecutive(0, SI_DESCS_FIRST_COMPUTE);
unsigned dirty = sctx->descriptors_dirty & mask;
 
/* Assume nothing will go wrong: */
@@ -2926,6 +2925,12 @@ bool si_upload_graphics_shader_descriptors(struct 
si_context *sctx)
return true;
 }
 
+bool si_upload_graphics_shader_descriptors(struct si_context *sctx)
+{
+   const unsigned mask = u_bit_consecutive(0, SI_DESCS_FIRST_COMPUTE);
+   return si_upload_shader_descriptors(sctx, mask);
+}
+
 bool si_upload_compute_shader_descriptors(struct si_context *sctx)
 {
/* Does not update rw_buffers as that is not needed for compute shaders
@@ -2933,23 +2938,7 @@ bool si_upload_compute_shader_descriptors(struct 
si_context *sctx)
 */
const unsigned mask = u_bit_consecutive(SI_DESCS_FIRST_COMPUTE,
SI_NUM_DESCS - 
SI_DESCS_FIRST_COMPUTE);
-   unsigned dirty = sctx->descriptors_dirty & mask;
-
-   /* Assume nothing will go wrong: */
-   sctx->shader_pointers_dirty |= dirty;
-
-   while (dirty) {
-   unsigned i = u_bit_scan();
-
-   if (!si_upload_descriptors(sctx, >descriptors[i], NULL))
-   return false;
-   }
-
-   sctx->descriptors_dirty &= ~mask;
-
-   si_upload_bindless_descriptors(sctx);
-
-   return true;
+   return si_upload_shader_descriptors(sctx, mask);
 }
 
 void si_release_all_descriptors(struct si_context *sctx)
-- 
2.11.0

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


[Mesa-dev] [PATCH 4/4] radeonsi/gfx9: add performance counters

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_perfcounter.c | 29 ++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c 
b/src/gallium/drivers/radeonsi/si_perfcounter.c
index 41dd52edb11..2e3a174e393 100644
--- a/src/gallium/drivers/radeonsi/si_perfcounter.c
+++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
@@ -403,6 +403,30 @@ static struct si_pc_block groups_VI[] = {
 
 };
 
+static struct si_pc_block groups_gfx9[] = {
+   { _CB, 438, 4 },
+   { _CPF, 32 },
+   { _DB, 328, 4 },
+   { _GRBM, 38 },
+   { _GRBMSE, 16 },
+   { _PA_SU, 292 },
+   { _PA_SC, 491 },
+   { _SPI, 196 },
+   { _SQ, 374 },
+   { _SX, 208 },
+   { _TA, 119, 16 },
+   { _TCA, 35, 2 },
+   { _TCC, 256, 16 },
+   { _TD, 57, 16 },
+   { _TCP, 85, 16 },
+   { _GDS, 121 },
+   { _VGT, 148 },
+   { _IA, 32 },
+   { _WD, 58 },
+   { _CPG, 59 },
+   { _CPC, 35 },
+};
+
 static void si_pc_get_size(struct r600_perfcounter_block *group,
unsigned count, unsigned *selectors,
unsigned *num_select_dw, unsigned *num_read_dw)
@@ -671,8 +695,11 @@ void si_init_perfcounters(struct si_screen *screen)
blocks = groups_VI;
num_blocks = ARRAY_SIZE(groups_VI);
break;
-   case SI:
case GFX9:
+   blocks = groups_gfx9;
+   num_blocks = ARRAY_SIZE(groups_gfx9);
+   break;
+   case SI:
default:
return; /* not implemented */
}
-- 
2.11.0

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


[Mesa-dev] [PATCH 0/4] radeonsi: CE odds and ends + gfx9 perf counters

2017-08-16 Thread Nicolai Hähnle
Hi all,

the first 3 are a bunch of CE-related changes that I still had flying
around from our experiments. Patches 1+3 are clear improvements, 2 is
a wash with how we're currently using the CE. The idea of our internal
experiments was to try to stop the CE from running so far ahead of the
DE by adding a wait packet between the WRITE_CONST_RAM and the
DUMP_CONST_RAM, and so use the CE as a way to prime the L2 cache for
shaders. This didn't really pan out, which is why Marek sent the patch
to disable the CE by default.

Also, the last patch enables performance counters on gfx9. Caveat
emptor: there are of course performance counter changes from VI (as
usual between generations), and it turns out that at least for CPG,
the enums weren't updated properly in line with the hardware changes.
So be sure to double-check/sanity-check whatever you do with performance
counters, but you need to do that anyway. I guess the hardware engineers
just really like keeping us on our toes ;)

Please review!
Cheers,
Nicolai
--
 src/gallium/drivers/radeonsi/si_compute.c|  2 -
 .../drivers/radeonsi/si_descriptors.c| 69 ++
 .../drivers/radeonsi/si_perfcounter.c| 29 +++-
 src/gallium/drivers/radeonsi/si_state.h  |  1 -
 src/gallium/drivers/radeonsi/si_state_draw.c | 10 ---
 5 files changed, 67 insertions(+), 44 deletions(-)

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


[Mesa-dev] [PATCH 16/16] gallium: remove unused PIPE_DUMP_* defines

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/drivers/ddebug/dd_draw.c| 21 -
 src/gallium/drivers/radeonsi/si_debug.c |  8 +++-
 src/gallium/include/pipe/p_defines.h|  3 ---
 3 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/src/gallium/drivers/ddebug/dd_draw.c 
b/src/gallium/drivers/ddebug/dd_draw.c
index aa38c561c57..4bf13bd7e46 100644
--- a/src/gallium/drivers/ddebug/dd_draw.c
+++ b/src/gallium/drivers/ddebug/dd_draw.c
@@ -620,10 +620,7 @@ dd_flush_and_handle_hang(struct dd_context *dctx,
   if (f) {
  fprintf(f, "dd: %s.\n", cause);
  dd_dump_driver_state(dctx, f,
-  PIPE_DUMP_DEVICE_STATUS_REGISTERS |
-  PIPE_DUMP_CURRENT_STATES |
-  PIPE_DUMP_CURRENT_SHADERS |
-  PIPE_DUMP_LAST_COMMAND_BUFFER);
+  PIPE_DUMP_DEVICE_STATUS_REGISTERS);
  dd_dump_dmesg(f);
  dd_close_file_stream(f);
   }
@@ -1118,10 +1115,7 @@ dd_after_draw(struct dd_context *dctx, struct dd_call 
*call)
  if (!dscreen->no_flush &&
 dd_flush_and_check_hang(dctx, NULL, 0)) {
 dd_write_report(dctx, call,
- PIPE_DUMP_DEVICE_STATUS_REGISTERS |
- PIPE_DUMP_CURRENT_STATES |
- PIPE_DUMP_CURRENT_SHADERS |
- PIPE_DUMP_LAST_COMMAND_BUFFER,
+ PIPE_DUMP_DEVICE_STATUS_REGISTERS,
  true);
 
 /* Terminate the process to prevent future hangs. */
@@ -1136,19 +1130,12 @@ dd_after_draw(struct dd_context *dctx, struct dd_call 
*call)
   case DD_DUMP_ALL_CALLS:
  if (!dscreen->no_flush)
 pipe->flush(pipe, NULL, 0);
- dd_write_report(dctx, call,
- PIPE_DUMP_CURRENT_STATES |
- PIPE_DUMP_CURRENT_SHADERS |
- PIPE_DUMP_LAST_COMMAND_BUFFER,
- false);
+ dd_write_report(dctx, call, 0, false);
  break;
   case DD_DUMP_APITRACE_CALL:
  if (dscreen->apitrace_dump_call ==
  dctx->draw_state.apitrace_call_number) {
-dd_write_report(dctx, call,
-PIPE_DUMP_CURRENT_STATES |
-PIPE_DUMP_CURRENT_SHADERS,
-false);
+dd_write_report(dctx, call, 0, false);
 /* No need to continue. */
 exit(0);
  } else {
diff --git a/src/gallium/drivers/radeonsi/si_debug.c 
b/src/gallium/drivers/radeonsi/si_debug.c
index 8dd1e1329c3..7ad28a23dfc 100644
--- a/src/gallium/drivers/radeonsi/si_debug.c
+++ b/src/gallium/drivers/radeonsi/si_debug.c
@@ -1058,11 +1058,9 @@ static void si_dump_debug_state(struct pipe_context 
*ctx, FILE *f,
if (flags & PIPE_DUMP_DEVICE_STATUS_REGISTERS) {
si_dump_debug_registers(sctx, f);
 
-   if (flags & PIPE_DUMP_CURRENT_SHADERS) {
-   si_dump_annotated_shaders(sctx, f);
-   si_dump_command("Active waves (raw data)", "umr -wa | 
column -t", f);
-   si_dump_command("Wave information", "umr -O bits -wa", 
f);
-   }
+   si_dump_annotated_shaders(sctx, f);
+   si_dump_command("Active waves (raw data)", "umr -wa | column 
-t", f);
+   si_dump_command("Wave information", "umr -O bits -wa", f);
}
 }
 
diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 8609aefb986..da7d5da7347 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -358,9 +358,6 @@ enum pipe_flush_flags
  * Flags for pipe_context::dump_debug_state.
  */
 #define PIPE_DUMP_DEVICE_STATUS_REGISTERS(1 << 0)
-#define PIPE_DUMP_CURRENT_STATES (1 << 1)
-#define PIPE_DUMP_CURRENT_SHADERS(1 << 2)
-#define PIPE_DUMP_LAST_COMMAND_BUFFER(1 << 3)
 
 /**
  * Create a compute-only context. Use in pipe_screen::context_create.
-- 
2.11.0

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


[Mesa-dev] [PATCH 15/16] ddebug: remove dd_draw_record::driver_state_log

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

It is no longer used.
---
 src/gallium/drivers/ddebug/dd_draw.c | 57 
 src/gallium/drivers/ddebug/dd_pipe.h |  1 -
 2 files changed, 58 deletions(-)

diff --git a/src/gallium/drivers/ddebug/dd_draw.c 
b/src/gallium/drivers/ddebug/dd_draw.c
index 8a435a37fcb..aa38c561c57 100644
--- a/src/gallium/drivers/ddebug/dd_draw.c
+++ b/src/gallium/drivers/ddebug/dd_draw.c
@@ -945,7 +945,6 @@ dd_free_record(struct dd_draw_record **record)
u_log_page_destroy((*record)->log_page);
dd_unreference_copy_of_call(&(*record)->call);
dd_unreference_copy_of_draw_state(&(*record)->draw_state);
-   FREE((*record)->driver_state_log);
FREE(*record);
*record = next;
 }
@@ -965,7 +964,6 @@ dd_dump_record(struct dd_context *dctx, struct 
dd_draw_record *record,
(now - record->timestamp) / 1000);
 
dd_dump_call(f, >draw_state.base, >call);
-   fprintf(f, "%s\n", record->driver_state_log);
 
fprintf(f,"\n\n**"
  "***\n");
@@ -1035,71 +1033,17 @@ dd_thread_pipelined_hang_detect(void *input)
return 0;
 }
 
-static char *
-dd_get_driver_shader_log(struct dd_context *dctx)
-{
-#if defined(PIPE_OS_LINUX)
-   FILE *f;
-   char *buf;
-   int written_bytes;
-
-   if (!dctx->max_log_buffer_size)
-  dctx->max_log_buffer_size = 16 * 1024;
-
-   /* Keep increasing the buffer size until there is enough space.
-*
-* open_memstream can resize automatically, but it's VERY SLOW.
-* fmemopen is much faster.
-*/
-   while (1) {
-  buf = malloc(dctx->max_log_buffer_size);
-  buf[0] = 0;
-
-  f = fmemopen(buf, dctx->max_log_buffer_size, "a");
-  if (!f) {
- free(buf);
- return NULL;
-  }
-
-  dd_dump_driver_state(dctx, f, PIPE_DUMP_CURRENT_SHADERS);
-  written_bytes = ftell(f);
-  fclose(f);
-
-  /* Return if the backing buffer is large enough. */
-  if (written_bytes < dctx->max_log_buffer_size - 1)
- break;
-
-  /* Try again. */
-  free(buf);
-  dctx->max_log_buffer_size *= 2;
-   }
-
-   return buf;
-#else
-   /* Return an empty string. */
-   return (char*)calloc(1, 4);
-#endif
-}
-
 static void
 dd_pipelined_process_draw(struct dd_context *dctx, struct dd_call *call)
 {
struct pipe_context *pipe = dctx->pipe;
struct dd_draw_record *record;
-   char *log;
 
/* Make a record of the draw call. */
record = MALLOC_STRUCT(dd_draw_record);
if (!record)
   return;
 
-   /* Create the log. */
-   log = dd_get_driver_shader_log(dctx);
-   if (!log) {
-  FREE(record);
-  return;
-   }
-
/* Update the fence with the GPU.
 *
 * radeonsi/clear_buffer waits in the command processor until shaders are
@@ -1112,7 +1056,6 @@ dd_pipelined_process_draw(struct dd_context *dctx, struct 
dd_call *call)
/* Initialize the record. */
record->timestamp = os_time_get();
record->sequence_no = dctx->sequence_no;
-   record->driver_state_log = log;
record->log_page = u_log_new_page(>log);
 
memset(>call, 0, sizeof(record->call));
diff --git a/src/gallium/drivers/ddebug/dd_pipe.h 
b/src/gallium/drivers/ddebug/dd_pipe.h
index f89f3820b43..70b9ae8ae82 100644
--- a/src/gallium/drivers/ddebug/dd_pipe.h
+++ b/src/gallium/drivers/ddebug/dd_pipe.h
@@ -226,7 +226,6 @@ struct dd_draw_record {
struct dd_call call;
struct dd_draw_state_copy draw_state;
struct u_log_page *log_page;
-   char *driver_state_log;
 };
 
 struct dd_context
-- 
2.11.0

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


[Mesa-dev] [PATCH 11/16] radeonsi: print saved CS to the log context

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

Use the auto logger facility, so that CS chunks will be interleaved
with other log info.
---
 src/gallium/drivers/radeonsi/si_debug.c  | 215 +--
 src/gallium/drivers/radeonsi/si_hw_context.c |  64 +---
 src/gallium/drivers/radeonsi/si_pipe.c   |   7 +-
 src/gallium/drivers/radeonsi/si_pipe.h   |  31 +++-
 src/gallium/drivers/radeonsi/si_state_draw.c |  28 ++--
 5 files changed, 257 insertions(+), 88 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_debug.c 
b/src/gallium/drivers/radeonsi/si_debug.c
index e797f10f7f0..9a7b0908199 100644
--- a/src/gallium/drivers/radeonsi/si_debug.c
+++ b/src/gallium/drivers/radeonsi/si_debug.c
@@ -34,6 +34,9 @@
 #include "util/u_memory.h"
 #include "ac_debug.h"
 
+static void si_dump_bo_list(struct si_context *sctx,
+   const struct radeon_saved_cs *saved, FILE *f);
+
 DEBUG_GET_ONCE_OPTION(replace_shaders, "RADEON_REPLACE_SHADERS", NULL)
 
 static void si_dump_shader(struct si_screen *sscreen,
@@ -266,51 +269,180 @@ static void si_dump_debug_registers(struct si_context 
*sctx, FILE *f)
fprintf(f, "\n");
 }
 
-static void si_dump_last_ib(struct si_context *sctx, FILE *f)
+struct si_log_chunk_cs {
+   struct si_context *ctx;
+   struct si_saved_cs *cs;
+   bool dump_bo_list;
+   unsigned gfx_begin, gfx_end;
+   unsigned ce_begin, ce_end;
+};
+
+static void si_log_chunk_type_cs_destroy(void *data)
+{
+   struct si_log_chunk_cs *chunk = data;
+   si_saved_cs_reference(>cs, NULL);
+   free(chunk);
+}
+
+static void si_parse_current_ib(FILE *f, struct radeon_winsys_cs *cs,
+   unsigned begin, unsigned end,
+   unsigned last_trace_id, const char *name,
+   enum chip_class chip_class)
 {
+   unsigned orig_end = end;
+
+   assert(begin <= end);
+
+   fprintf(f, "-- %s begin (dw = %u) --\n",
+   name, begin);
+
+   for (unsigned prev_idx = 0; prev_idx < cs->num_prev; ++prev_idx) {
+   struct radeon_winsys_cs_chunk *chunk = >prev[prev_idx];
+
+   if (begin < chunk->cdw) {
+   ac_parse_ib_chunk(f, chunk->buf + begin,
+ MIN2(end, chunk->cdw) - begin,
+ last_trace_id, chip_class, NULL, 
NULL);
+   }
+
+   if (end <= chunk->cdw)
+   return;
+
+   if (begin < chunk->cdw)
+   fprintf(f, "\n-- Next %s Chunk --\n\n",
+   name);
+
+   begin -= MAX2(begin, chunk->cdw) - chunk->cdw;
+   end -= chunk->cdw;
+   }
+
+   assert(end <= cs->current.cdw);
+
+   ac_parse_ib_chunk(f, cs->current.buf + begin, end - begin, 
last_trace_id,
+ chip_class, NULL, NULL);
+
+   fprintf(f, "--- %s end (dw = %u) 
---\n\n",
+   name, orig_end);
+}
+
+static void si_log_chunk_type_cs_print(void *data, FILE *f)
+{
+   struct si_log_chunk_cs *chunk = data;
+   struct si_context *ctx = chunk->ctx;
+   struct si_saved_cs *scs = chunk->cs;
int last_trace_id = -1;
int last_ce_trace_id = -1;
 
-   if (!sctx->last_gfx.ib)
-   return;
+   /* We are expecting that the ddebug pipe has already
+* waited for the context, so this buffer should be idle.
+* If the GPU is hung, there is no point in waiting for it.
+*/
+   uint32_t *map = ctx->b.ws->buffer_map(scs->trace_buf->buf,
+ NULL,
+ PIPE_TRANSFER_UNSYNCHRONIZED |
+ PIPE_TRANSFER_READ);
+   if (map) {
+   last_trace_id = map[0];
+   last_ce_trace_id = map[1];
+   }
 
-   if (sctx->last_trace_buf) {
-   /* We are expecting that the ddebug pipe has already
-* waited for the context, so this buffer should be idle.
-* If the GPU is hung, there is no point in waiting for it.
-*/
-   uint32_t *map = 
sctx->b.ws->buffer_map(sctx->last_trace_buf->buf,
-  NULL,
-  
PIPE_TRANSFER_UNSYNCHRONIZED |
-  PIPE_TRANSFER_READ);
-   if (map) {
-   last_trace_id = map[0];
-   last_ce_trace_id = map[1];
+   if (chunk->gfx_end != chunk->gfx_begin) {
+   if (chunk->gfx_begin == 0) {
+   if (ctx->init_config)
+   ac_parse_ib(f, ctx->init_config->pm4, 
ctx->init_config->ndw,
+   

[Mesa-dev] [PATCH 07/16] radeonsi: add reference count to si_compute

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

To allow keep-alive for deferred logging.
---
 src/gallium/drivers/radeonsi/si_compute.c | 24 ++--
 src/gallium/drivers/radeonsi/si_compute.h | 14 ++
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 5efdd3919d2..8c016ba65ab 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -151,6 +151,7 @@ static void *si_create_compute_state(
struct si_screen *sscreen = (struct si_screen *)ctx->screen;
struct si_compute *program = CALLOC_STRUCT(si_compute);
 
+   pipe_reference_init(>reference, 1);
program->screen = (struct si_screen *)ctx->screen;
program->ir_type = cso->ir_type;
program->local_size = cso->req_local_mem;
@@ -855,20 +856,24 @@ static void si_launch_grid(
sctx->b.flags |= SI_CONTEXT_CS_PARTIAL_FLUSH;
 }
 
+void si_destroy_compute(struct si_compute *program)
+{
+   if (program->ir_type == PIPE_SHADER_IR_TGSI) {
+   util_queue_drop_job(>screen->shader_compiler_queue,
+   >ready);
+   util_queue_fence_destroy(>ready);
+   }
+
+   si_shader_destroy(>shader);
+   FREE(program);
+}
 
 static void si_delete_compute_state(struct pipe_context *ctx, void* state){
struct si_compute *program = (struct si_compute *)state;
struct si_context *sctx = (struct si_context*)ctx;
 
-   if (!state) {
+   if (!state)
return;
-   }
-
-   if (program->ir_type == PIPE_SHADER_IR_TGSI) {
-   util_queue_drop_job(>screen->shader_compiler_queue,
-   >ready);
-   util_queue_fence_destroy(>ready);
-   }
 
if (program == sctx->cs_shader_state.program)
sctx->cs_shader_state.program = NULL;
@@ -876,8 +881,7 @@ static void si_delete_compute_state(struct pipe_context 
*ctx, void* state){
if (program == sctx->cs_shader_state.emitted_program)
sctx->cs_shader_state.emitted_program = NULL;
 
-   si_shader_destroy(>shader);
-   FREE(program);
+   si_compute_reference(, NULL);
 }
 
 static void si_set_compute_resources(struct pipe_context * ctx_,
diff --git a/src/gallium/drivers/radeonsi/si_compute.h 
b/src/gallium/drivers/radeonsi/si_compute.h
index 268817b23a6..c19b701fc71 100644
--- a/src/gallium/drivers/radeonsi/si_compute.h
+++ b/src/gallium/drivers/radeonsi/si_compute.h
@@ -24,11 +24,14 @@
 #ifndef SI_COMPUTE_H
 #define SI_COMPUTE_H
 
+#include "util/u_inlines.h"
+
 #include "si_shader.h"
 
 #define MAX_GLOBAL_BUFFERS 22
 
 struct si_compute {
+   struct pipe_reference reference;
struct si_screen *screen;
struct tgsi_token *tokens;
struct util_queue_fence ready;
@@ -53,4 +56,15 @@ struct si_compute {
unsigned uses_bindless_images:1;
 };
 
+void si_destroy_compute(struct si_compute *program);
+
+static inline void
+si_compute_reference(struct si_compute **dst, struct si_compute *src)
+{
+   if (pipe_reference(&(*dst)->reference, >reference))
+   si_destroy_compute(*dst);
+
+   *dst = src;
+}
+
 #endif /* SI_COMPUTE_H */
-- 
2.11.0

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


[Mesa-dev] [PATCH 09/16] radeonsi: re-order debug state dumping

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

Keep together the parts that won't use the deferred logging mechanism.
---
 src/gallium/drivers/radeonsi/si_debug.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_debug.c 
b/src/gallium/drivers/radeonsi/si_debug.c
index 5a6d39102eb..3cc34b64bb8 100644
--- a/src/gallium/drivers/radeonsi/si_debug.c
+++ b/src/gallium/drivers/radeonsi/si_debug.c
@@ -815,9 +815,16 @@ static void si_dump_debug_state(struct pipe_context *ctx, 
FILE *f,
 {
struct si_context *sctx = (struct si_context*)ctx;
 
-   if (flags & PIPE_DUMP_DEVICE_STATUS_REGISTERS)
+   if (flags & PIPE_DUMP_DEVICE_STATUS_REGISTERS) {
si_dump_debug_registers(sctx, f);
 
+   if (flags & PIPE_DUMP_CURRENT_SHADERS) {
+   si_dump_annotated_shaders(sctx, f);
+   si_dump_command("Active waves (raw data)", "umr -wa | 
column -t", f);
+   si_dump_command("Wave information", "umr -O bits -wa", 
f);
+   }
+   }
+
if (flags & PIPE_DUMP_CURRENT_STATES)
si_dump_framebuffer(sctx, f);
 
@@ -829,12 +836,6 @@ static void si_dump_debug_state(struct pipe_context *ctx, 
FILE *f,
si_dump_gfx_shader(sctx->screen, >ps_shader, f);
si_dump_compute_shader(sctx->screen, >cs_shader_state, f);
 
-   if (flags & PIPE_DUMP_DEVICE_STATUS_REGISTERS) {
-   si_dump_annotated_shaders(sctx, f);
-   si_dump_command("Active waves (raw data)", "umr -wa | 
column -t", f);
-   si_dump_command("Wave information", "umr -O bits -wa", 
f);
-   }
-
si_dump_descriptor_list(>descriptors[SI_DESCS_RW_BUFFERS],
"", "RW buffers", 4, SI_NUM_RW_BUFFERS,
si_identity, f);
-- 
2.11.0

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


[Mesa-dev] [PATCH 10/16] radeonsi: start using u_log_context for debugging

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/drivers/radeon/r600_pipe_common.h |   2 +-
 src/gallium/drivers/radeon/r600_texture.c |  41 +++--
 src/gallium/drivers/radeonsi/si_debug.c   | 239 +++---
 3 files changed, 199 insertions(+), 83 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h 
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 01e097a4595..22b5a2d9338 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -832,7 +832,7 @@ bool r600_init_flushed_depth_texture(struct pipe_context 
*ctx,
 struct pipe_resource *texture,
 struct r600_texture **staging);
 void r600_print_texture_info(struct r600_common_screen *rscreen,
-struct r600_texture *rtex, FILE *f);
+struct r600_texture *rtex, struct u_log_context 
*log);
 struct pipe_resource *r600_texture_create(struct pipe_screen *screen,
const struct pipe_resource *templ);
 bool vi_dcc_formats_compatible(enum pipe_format format1,
diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index deedfaff366..22850e0c87d 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -28,6 +28,7 @@
 #include "r600_cs.h"
 #include "r600_query.h"
 #include "util/u_format.h"
+#include "util/u_log.h"
 #include "util/u_memory.h"
 #include "util/u_pack_color.h"
 #include "util/u_surface.h"
@@ -1039,12 +1040,12 @@ static void r600_texture_allocate_htile(struct 
r600_common_screen *rscreen,
 }
 
 void r600_print_texture_info(struct r600_common_screen *rscreen,
-struct r600_texture *rtex, FILE *f)
+struct r600_texture *rtex, struct u_log_context 
*log)
 {
int i;
 
/* Common parameters. */
-   fprintf(f, "  Info: npix_x=%u, npix_y=%u, npix_z=%u, blk_w=%u, "
+   u_log_printf(log, "  Info: npix_x=%u, npix_y=%u, npix_z=%u, blk_w=%u, "
"blk_h=%u, array_size=%u, last_level=%u, "
"bpe=%u, nsamples=%u, flags=0x%x, %s\n",
rtex->resource.b.b.width0, rtex->resource.b.b.height0,
@@ -1055,7 +1056,7 @@ void r600_print_texture_info(struct r600_common_screen 
*rscreen,
rtex->surface.flags, 
util_format_short_name(rtex->resource.b.b.format));
 
if (rscreen->chip_class >= GFX9) {
-   fprintf(f, "  Surf: size=%"PRIu64", slice_size=%"PRIu64", "
+   u_log_printf(log, "  Surf: size=%"PRIu64", 
slice_size=%"PRIu64", "
"alignment=%u, swmode=%u, epitch=%u, pitch=%u\n",
rtex->surface.surf_size,
rtex->surface.u.gfx9.surf_slice_size,
@@ -1065,7 +1066,7 @@ void r600_print_texture_info(struct r600_common_screen 
*rscreen,
rtex->surface.u.gfx9.surf_pitch);
 
if (rtex->fmask.size) {
-   fprintf(f, "  FMASK: offset=%"PRIu64", size=%"PRIu64", "
+   u_log_printf(log, "  FMASK: offset=%"PRIu64", 
size=%"PRIu64", "
"alignment=%u, swmode=%u, epitch=%u\n",
rtex->fmask.offset,
rtex->surface.u.gfx9.fmask_size,
@@ -1075,7 +1076,7 @@ void r600_print_texture_info(struct r600_common_screen 
*rscreen,
}
 
if (rtex->cmask.size) {
-   fprintf(f, "  CMask: offset=%"PRIu64", size=%"PRIu64", "
+   u_log_printf(log, "  CMask: offset=%"PRIu64", 
size=%"PRIu64", "
"alignment=%u, rb_aligned=%u, 
pipe_aligned=%u\n",
rtex->cmask.offset,
rtex->surface.u.gfx9.cmask_size,
@@ -1085,7 +1086,7 @@ void r600_print_texture_info(struct r600_common_screen 
*rscreen,
}
 
if (rtex->htile_offset) {
-   fprintf(f, "  HTile: offset=%"PRIu64", size=%"PRIu64", 
alignment=%u, "
+   u_log_printf(log, "  HTile: offset=%"PRIu64", 
size=%"PRIu64", alignment=%u, "
"rb_aligned=%u, pipe_aligned=%u\n",
rtex->htile_offset,
rtex->surface.htile_size,
@@ -1095,7 +1096,7 @@ void r600_print_texture_info(struct r600_common_screen 
*rscreen,
}
 
if (rtex->dcc_offset) {
-   fprintf(f, "  DCC: offset=%"PRIu64", size=%"PRIu64", "
+   u_log_printf(log, "  DCC: offset=%"PRIu64", 
size=%"PRIu64", "
"alignment=%u, pitch_max=%u, 
num_dcc_levels=%u\n",
rtex->dcc_offset, rtex->surface.dcc_size,
  

[Mesa-dev] [PATCH 02/16] util/log: add auto logger facility

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/auxiliary/util/u_log.c | 60 --
 src/gallium/auxiliary/util/u_log.h | 17 +++
 2 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_log.c 
b/src/gallium/auxiliary/util/u_log.c
index 6d826f0adda..359b3e10a2e 100644
--- a/src/gallium/auxiliary/util/u_log.c
+++ b/src/gallium/auxiliary/util/u_log.c
@@ -36,13 +36,18 @@ struct u_log_page {
unsigned max_entries;
 };
 
+struct u_log_auto_logger {
+   u_auto_log_fn *callback;
+   void *data;
+};
+
 /**
  * Initialize the given logging context.
  */
 void
 u_log_context_init(struct u_log_context *ctx)
 {
-   ctx->cur = NULL;
+   memset(ctx, 0, sizeof(*ctx));
 }
 
 /**
@@ -55,7 +60,56 @@ void
 u_log_context_destroy(struct u_log_context *ctx)
 {
u_log_page_destroy(ctx->cur);
-   ctx->cur = NULL;
+   FREE(ctx->auto_loggers);
+   memset(ctx, 0, sizeof(*ctx));
+}
+
+/**
+ * Add an auto logger.
+ *
+ * Auto loggers are called each time a chunk is added to the log.
+ */
+void
+u_log_add_auto_logger(struct u_log_context *ctx, u_auto_log_fn *callback,
+  void *data)
+{
+   struct u_log_auto_logger *new_auto_loggers =
+  REALLOC(ctx->auto_loggers,
+  sizeof(*new_auto_loggers) * ctx->num_auto_loggers,
+  sizeof(*new_auto_loggers) * (ctx->num_auto_loggers + 1));
+   if (!new_auto_loggers) {
+  fprintf(stderr, "Gallium u_log: out of memory\n");
+  return;
+   }
+
+   unsigned idx = ctx->num_auto_loggers++;
+   ctx->auto_loggers = new_auto_loggers;
+   ctx->auto_loggers[idx].callback = callback;
+   ctx->auto_loggers[idx].data = data;
+}
+
+/**
+ * Make sure that auto loggers have run.
+ */
+void
+u_log_flush(struct u_log_context *ctx)
+{
+   if (!ctx->num_auto_loggers)
+  return;
+
+   struct u_log_auto_logger *auto_loggers = ctx->auto_loggers;
+   unsigned num_auto_loggers = ctx->num_auto_loggers;
+
+   /* Prevent recursion. */
+   ctx->num_auto_loggers = 0;
+   ctx->auto_loggers = NULL;
+
+   for (unsigned i = 0; i < num_auto_loggers; ++i)
+  auto_loggers[i].callback(auto_loggers[i].data, ctx);
+
+   assert(!ctx->num_auto_loggers);
+   ctx->num_auto_loggers = num_auto_loggers;
+   ctx->auto_loggers = auto_loggers;
 }
 
 static void str_print(void *data, FILE *stream)
@@ -96,6 +150,8 @@ u_log_chunk(struct u_log_context *ctx, const struct 
u_log_chunk_type *type,
 {
struct u_log_page *page = ctx->cur;
 
+   u_log_flush(ctx);
+
if (!page) {
   ctx->cur = CALLOC_STRUCT(u_log_page);
   page = ctx->cur;
diff --git a/src/gallium/auxiliary/util/u_log.h 
b/src/gallium/auxiliary/util/u_log.h
index d4e6018c9f7..09c47caee55 100644
--- a/src/gallium/auxiliary/util/u_log.h
+++ b/src/gallium/auxiliary/util/u_log.h
@@ -35,6 +35,11 @@
  *
  * Chunks are accumulated into "pages". The manager of the log can periodically
  * take out the current page using \ref u_log_new_page and dump it to a file.
+ *
+ * Furthermore, "auto loggers" can be added to a context, which are callbacks
+ * that are given the opportunity to add their own logging each time a chunk is
+ * added. Drivers can use this to lazily log chunks of their command stream.
+ * Lazy loggers don't need to be re-entrant.
  */
 
 #ifndef U_LOG_H
@@ -45,6 +50,7 @@
 #include "u_debug.h"
 
 struct u_log_page;
+struct u_log_auto_logger;
 
 struct u_log_chunk_type {
void (*destroy)(void *data);
@@ -53,8 +59,12 @@ struct u_log_chunk_type {
 
 struct u_log_context {
struct u_log_page *cur;
+   struct u_log_auto_logger *auto_loggers;
+   unsigned num_auto_loggers;
 };
 
+typedef void (u_auto_log_fn)(void *data, struct u_log_context *ctx);
+
 void
 u_log_context_init(struct u_log_context *ctx);
 
@@ -62,6 +72,13 @@ void
 u_log_context_destroy(struct u_log_context *ctx);
 
 void
+u_log_add_auto_logger(struct u_log_context *ctx, u_auto_log_fn *callback,
+  void *data);
+
+void
+u_log_flush(struct u_log_context *ctx);
+
+void
 u_log_printf(struct u_log_context *ctx, const char *fmt, ...) 
_util_printf_format(2,3);
 
 void
-- 
2.11.0

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


[Mesa-dev] [PATCH 03/16] gallium: add pipe_context::set_log_context

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/include/pipe/p_context.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/gallium/include/pipe/p_context.h 
b/src/gallium/include/pipe/p_context.h
index c2b1ad217c8..4609d4dbf23 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -75,6 +75,7 @@ struct pipe_viewport_state;
 struct pipe_compute_state;
 union pipe_color_union;
 union pipe_query_result;
+struct u_log_context;
 struct u_upload_mgr;
 
 /**
@@ -749,6 +750,19 @@ struct pipe_context {
 unsigned flags);
 
/**
+* Set the log context to which the driver should write internal debug logs
+* (internal states, command streams).
+*
+* The caller must ensure that the log context is destroyed and reset to
+* NULL before the pipe context is destroyed, and that log context functions
+* are only called from the driver thread.
+*
+* \param ctx pipe context
+* \param log logging context
+*/
+   void (*set_log_context)(struct pipe_context *ctx, struct u_log_context 
*log);
+
+   /**
 * Emit string marker in cmdstream
 */
void (*emit_string_marker)(struct pipe_context *ctx,
-- 
2.11.0

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


[Mesa-dev] [PATCH 00/16] gallium, ddebug, radeonsi: cleaner logging of IBs and other info

2017-08-16 Thread Nicolai Hähnle
Hi all,

GALLIUM_DDEBUG is a useful facility for understanding what the driver
actually does, but it can occasionally be hard to follow the IB dumps,
especially when you want to understand a sequence of draws that are
all placed in the same IB, without submits in between.

The goal of this series is to properly interleave the IB chunks that
are emitted for each draw with the corresponding state. On top, this
should be done in a way that doesn't slow down pipelined hang detection
too much.

This series refactors the logging done by ddebug, somewhat putting it
on its head. Rather than asking the driver to provide information at
specific times, the ddebug module passes a u_log_context to the driver.
The driver then appends opaque "chunks" to the log as it does its thing.
The ddebug module will cut of "pages" of chunks associated with Gallium
level draw calls, and request actual formatting (printing) of those
pages only when needed.

There are probably still some aspects to be tweaked over time, but
I found this mode quite useful for GALLIUM_DDEBUG="always noflush"
of some smaller tests, and I can see it being quite useful for pipelined
hang detection as well -- although that needs some separate fixes and
improvements, e.g. because those fence writes that ddebug does actually
end up as SDMA writes (aka useless) nowadays! Anyway, I feel the
current state is already an improvement.

Please review!
Thanks,
Nicolai
--
 src/amd/common/ac_debug.c|  37 +-
 src/amd/common/ac_debug.h|   3 +
 src/gallium/auxiliary/Makefile.sources   |   2 +
 src/gallium/auxiliary/util/u_log.c   | 234 
 src/gallium/auxiliary/util/u_log.h   | 100 
 src/gallium/drivers/ddebug/dd_context.c  |   9 +
 src/gallium/drivers/ddebug/dd_draw.c |  95 +---
 src/gallium/drivers/ddebug/dd_pipe.h |   5 +-
 .../drivers/radeon/r600_pipe_common.h|   5 +-
 src/gallium/drivers/radeon/r600_texture.c|  41 +-
 src/gallium/drivers/radeonsi/si_blit.c   |  13 +
 src/gallium/drivers/radeonsi/si_compute.c|  30 +-
 src/gallium/drivers/radeonsi/si_compute.h|  14 +
 src/gallium/drivers/radeonsi/si_debug.c  | 493 -
 src/gallium/drivers/radeonsi/si_hw_context.c |  64 ++-
 src/gallium/drivers/radeonsi/si_pipe.c   |  19 +-
 src/gallium/drivers/radeonsi/si_pipe.h   |  33 +-
 src/gallium/drivers/radeonsi/si_shader.h |  14 +
 src/gallium/drivers/radeonsi/si_state_draw.c |  31 +-
 .../drivers/radeonsi/si_state_shaders.c  |  17 +-
 src/gallium/include/pipe/p_context.h |  14 +
 src/gallium/include/pipe/p_defines.h |   3 -
 22 files changed, 978 insertions(+), 298 deletions(-)

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


[Mesa-dev] [PATCH 08/16] radeonsi: make si_shader_selector_reference globally visible

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_shader.h| 14 ++
 src/gallium/drivers/radeonsi/si_state_shaders.c | 17 ++---
 2 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index e44d71c2614..c41b10714e5 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -663,4 +663,18 @@ si_shader_uses_bindless_images(struct si_shader_selector 
*selector)
return selector ? selector->info.uses_bindless_images : false;
 }
 
+void si_destroy_shader_selector(struct si_context *sctx,
+   struct si_shader_selector *sel);
+
+static inline void
+si_shader_selector_reference(struct si_context *sctx,
+struct si_shader_selector **dst,
+struct si_shader_selector *src)
+{
+   if (pipe_reference(&(*dst)->reference, >reference))
+   si_destroy_shader_selector(sctx, *dst);
+
+   *dst = src;
+}
+
 #endif
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index de5260ccd8f..968e231b8b8 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1534,19 +1534,6 @@ static bool si_check_missing_main_part(struct si_screen 
*sscreen,
return true;
 }
 
-static void si_destroy_shader_selector(struct si_context *sctx,
-  struct si_shader_selector *sel);
-
-static void si_shader_selector_reference(struct si_context *sctx,
-struct si_shader_selector **dst,
-struct si_shader_selector *src)
-{
-   if (pipe_reference(&(*dst)->reference, >reference))
-   si_destroy_shader_selector(sctx, *dst);
-
-   *dst = src;
-}
-
 /* Select the hw shader variant depending on the current state. */
 static int si_shader_select_with_key(struct si_screen *sscreen,
 struct si_shader_ctx_state *state,
@@ -2447,8 +2434,8 @@ static void si_delete_shader(struct si_context *sctx, 
struct si_shader *shader)
free(shader);
 }
 
-static void si_destroy_shader_selector(struct si_context *sctx,
-  struct si_shader_selector *sel)
+void si_destroy_shader_selector(struct si_context *sctx,
+   struct si_shader_selector *sel)
 {
struct si_shader *p = sel->first_variant, *c;
struct si_shader_ctx_state *current_shader[SI_NUM_SHADERS] = {
-- 
2.11.0

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


[Mesa-dev] [PATCH 04/16] ddebug: add driver log to record dumps

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/drivers/ddebug/dd_context.c |  9 +
 src/gallium/drivers/ddebug/dd_draw.c| 17 +
 src/gallium/drivers/ddebug/dd_pipe.h|  4 
 3 files changed, 30 insertions(+)

diff --git a/src/gallium/drivers/ddebug/dd_context.c 
b/src/gallium/drivers/ddebug/dd_context.c
index 5b0b27e006a..fc44a4bd1b9 100644
--- a/src/gallium/drivers/ddebug/dd_context.c
+++ b/src/gallium/drivers/ddebug/dd_context.c
@@ -583,6 +583,11 @@ dd_context_destroy(struct pipe_context *_pipe)
   pipe->transfer_unmap(pipe, dctx->fence_transfer);
   pipe_resource_reference(>fence, NULL);
}
+
+   if (pipe->set_log_context)
+  pipe->set_log_context(pipe, NULL);
+   u_log_context_destroy(>log);
+
pipe->destroy(pipe);
FREE(dctx);
 }
@@ -899,6 +904,10 @@ dd_context_create(struct dd_screen *dscreen, struct 
pipe_context *pipe)
 
dd_init_draw_functions(dctx);
 
+   u_log_context_init(>log);
+   if (pipe->set_log_context)
+  pipe->set_log_context(pipe, >log);
+
dctx->draw_state.sample_mask = ~0;
 
if (dscreen->mode == DD_DETECT_HANGS_PIPELINED) {
diff --git a/src/gallium/drivers/ddebug/dd_draw.c 
b/src/gallium/drivers/ddebug/dd_draw.c
index ae8f99bf2b4..8a435a37fcb 100644
--- a/src/gallium/drivers/ddebug/dd_draw.c
+++ b/src/gallium/drivers/ddebug/dd_draw.c
@@ -561,6 +561,12 @@ dd_write_report(struct dd_context *dctx, struct dd_call 
*call, unsigned flags,
 
dd_dump_call(f, >draw_state, call);
dd_dump_driver_state(dctx, f, flags);
+
+   fprintf(f,"\n\n**"
+ "***\n");
+   fprintf(f, "Context Log:\n\n");
+   u_log_new_page_print(>log, f);
+
if (dump_dmesg)
   dd_dump_dmesg(f);
dd_close_file_stream(f);
@@ -936,6 +942,7 @@ dd_free_record(struct dd_draw_record **record)
 {
struct dd_draw_record *next = (*record)->next;
 
+   u_log_page_destroy((*record)->log_page);
dd_unreference_copy_of_call(&(*record)->call);
dd_unreference_copy_of_draw_state(&(*record)->draw_state);
FREE((*record)->driver_state_log);
@@ -960,6 +967,11 @@ dd_dump_record(struct dd_context *dctx, struct 
dd_draw_record *record,
dd_dump_call(f, >draw_state.base, >call);
fprintf(f, "%s\n", record->driver_state_log);
 
+   fprintf(f,"\n\n**"
+ "***\n");
+   fprintf(f, "Context Log:\n\n");
+   u_log_page_print(record->log_page, f);
+
dctx->pipe->dump_debug_state(dctx->pipe, f,
 PIPE_DUMP_DEVICE_STATUS_REGISTERS);
dd_dump_dmesg(f);
@@ -1101,6 +1113,7 @@ dd_pipelined_process_draw(struct dd_context *dctx, struct 
dd_call *call)
record->timestamp = os_time_get();
record->sequence_no = dctx->sequence_no;
record->driver_state_log = log;
+   record->log_page = u_log_new_page(>log);
 
memset(>call, 0, sizeof(record->call));
dd_copy_call(>call, call);
@@ -1170,6 +1183,8 @@ dd_after_draw(struct dd_context *dctx, struct dd_call 
*call)
 
 /* Terminate the process to prevent future hangs. */
 dd_kill_process();
+ } else {
+u_log_page_destroy(u_log_new_page(>log));
  }
  break;
   case DD_DETECT_HANGS_PIPELINED:
@@ -1193,6 +1208,8 @@ dd_after_draw(struct dd_context *dctx, struct dd_call 
*call)
 false);
 /* No need to continue. */
 exit(0);
+ } else {
+u_log_page_destroy(u_log_new_page(>log));
  }
  break;
   default:
diff --git a/src/gallium/drivers/ddebug/dd_pipe.h 
b/src/gallium/drivers/ddebug/dd_pipe.h
index e21b5fee086..f89f3820b43 100644
--- a/src/gallium/drivers/ddebug/dd_pipe.h
+++ b/src/gallium/drivers/ddebug/dd_pipe.h
@@ -33,6 +33,7 @@
 #include "pipe/p_screen.h"
 #include "dd_util.h"
 #include "os/os_thread.h"
+#include "util/u_log.h"
 
 enum dd_mode {
DD_DETECT_HANGS,
@@ -224,6 +225,7 @@ struct dd_draw_record {
 
struct dd_call call;
struct dd_draw_state_copy draw_state;
+   struct u_log_page *log_page;
char *driver_state_log;
 };
 
@@ -235,6 +237,8 @@ struct dd_context
struct dd_draw_state draw_state;
unsigned num_draw_calls;
 
+   struct u_log_context log;
+
/* Pipelined hang detection.
 *
 * This is without unnecessary flushes and waits. There is a memory-based
-- 
2.11.0

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


[Mesa-dev] [PATCH 01/16] util: add chunk logging module

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/auxiliary/Makefile.sources |   2 +
 src/gallium/auxiliary/util/u_log.c | 178 +
 src/gallium/auxiliary/util/u_log.h |  83 +++
 3 files changed, 263 insertions(+)
 create mode 100644 src/gallium/auxiliary/util/u_log.c
 create mode 100644 src/gallium/auxiliary/util/u_log.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 9ae8e6c8ca5..2adc60ca657 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -260,6 +260,8 @@ C_SOURCES := \
util/u_keymap.h \
util/u_linear.c \
util/u_linear.h \
+   util/u_log.c \
+   util/u_log.h \
util/u_math.c \
util/u_math.h \
util/u_memory.h \
diff --git a/src/gallium/auxiliary/util/u_log.c 
b/src/gallium/auxiliary/util/u_log.c
new file mode 100644
index 000..6d826f0adda
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_log.c
@@ -0,0 +1,178 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * 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 "u_log.h"
+
+#include "u_memory.h"
+
+struct page_entry {
+   const struct u_log_chunk_type *type;
+   void *data;
+};
+
+struct u_log_page {
+   struct page_entry *entries;
+   unsigned num_entries;
+   unsigned max_entries;
+};
+
+/**
+ * Initialize the given logging context.
+ */
+void
+u_log_context_init(struct u_log_context *ctx)
+{
+   ctx->cur = NULL;
+}
+
+/**
+ * Free all resources associated with the given logging context.
+ *
+ * Pages taken from the context via \ref u_log_new_page must be destroyed
+ * separately.
+ */
+void
+u_log_context_destroy(struct u_log_context *ctx)
+{
+   u_log_page_destroy(ctx->cur);
+   ctx->cur = NULL;
+}
+
+static void str_print(void *data, FILE *stream)
+{
+   fputs((char *)data, stream);
+}
+
+static const struct u_log_chunk_type str_chunk_type = {
+   .destroy = free,
+   .print = str_print,
+};
+
+void
+u_log_printf(struct u_log_context *ctx, const char *fmt, ...)
+{
+   va_list va;
+   char *str = NULL;
+
+   va_start(va, fmt);
+   int ret = vasprintf(, fmt, va);
+   va_end(va);
+
+   if (ret >= 0) {
+  u_log_chunk(ctx, _chunk_type, str);
+   } else {
+  fprintf(stderr, "Gallium u_log_printf: out of memory\n");
+   }
+}
+
+/**
+ * Add a custom chunk to the log.
+ *
+ * type->destroy will be called as soon as \p data is no longer needed.
+ */
+void
+u_log_chunk(struct u_log_context *ctx, const struct u_log_chunk_type *type,
+void *data)
+{
+   struct u_log_page *page = ctx->cur;
+
+   if (!page) {
+  ctx->cur = CALLOC_STRUCT(u_log_page);
+  page = ctx->cur;
+  if (!page)
+ goto out_of_memory;
+   }
+
+   if (page->num_entries >= page->max_entries) {
+  unsigned new_max_entries = MAX2(16, page->num_entries * 2);
+  struct page_entry *new_entries = REALLOC(page->entries,
+   page->max_entries * 
sizeof(*page->entries),
+   new_max_entries * 
sizeof(*page->entries));
+  if (!new_entries)
+ goto out_of_memory;
+
+  page->entries = new_entries;
+  page->max_entries = new_max_entries;
+   }
+
+   page->entries[page->num_entries].type = type;
+   page->entries[page->num_entries].data = data;
+   page->num_entries++;
+   return;
+
+out_of_memory:
+   fprintf(stderr, "Gallium: u_log: out of memory\n");
+}
+
+/**
+ * Convenience helper that starts a new page and prints the previous one.
+ */
+void
+u_log_new_page_print(struct u_log_context *ctx, FILE *stream)
+{
+   if (ctx->cur) {
+  u_log_page_print(ctx->cur, stream);
+  u_log_page_destroy(ctx->cur);
+  ctx->cur = NULL;
+   }
+}
+
+/**
+ * Return the current page from the logging context and start a new one.
+ *
+ * The caller is 

[Mesa-dev] [PATCH 14/16] radeonsi: emit string markers to log context

2017-08-16 Thread Nicolai Hähnle
From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_pipe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 2b8f7f4f5c2..e2a121a82ab 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -134,6 +134,9 @@ static void si_emit_string_marker(struct pipe_context *ctx,
struct si_context *sctx = (struct si_context *)ctx;
 
dd_parse_apitrace_marker(string, len, >apitrace_call_number);
+
+   if (sctx->b.log)
+   u_log_printf(sctx->b.log, "\nString marker: %*s\n", len, 
string);
 }
 
 static LLVMTargetMachineRef
-- 
2.11.0

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


[Mesa-dev] [Bug 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101832

Bernhard Rosenkraenzer  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Drivers/Gallium/swr
 CC||b...@lindev.ch

--- Comment #8 from Bernhard Rosenkraenzer  ---
This is unrelated to the radeonsi driver -- the exact same commit causes a
similar crash here on a laptop with an Intel and Nouveau GPU.

(EE) Backtrace:
(EE) 0: /usr/libexec/Xorg (xorg_backtrace+0x33) [0x56095d]
(EE) 1: /usr/libexec/Xorg (0x40+0x164414) [0x564414]
(EE) 2: /lib64/libpthread.so.0 (0x3547e0+0xfb70) [0x3547e0fb70]
(EE) 3: /lib64/libc.so.6 (0x3547a0+0x113131) [0x3547b13131]
(EE) 4: /usr/lib64/dri/nouveau_dri.so (0x7f8127608000+0xa74c4e)
[0x7f812807cc4e]
(EE) 5: /usr/lib64/dri/nouveau_dri.so (0x7f8127608000+0xa752e1)
[0x7f812807d2e1]
(EE) 6: /usr/lib64/dri/nouveau_dri.so (0x7f8127608000+0x77ff0) [0x7f812767fff0]
(EE) 7: /lib64/ld-linux-x86-64.so.2 (0x354760+0xc0c9) [0x354760c0c9]
(EE) 8: /lib64/ld-linux-x86-64.so.2 (0x354760+0xc1d0) [0x354760c1d0]
(EE) 9: /lib64/ld-linux-x86-64.so.2 (0x354760+0xf6dc) [0x354760f6dc]
(EE) 10: /lib64/libc.so.6 (_dl_catch_error+0x72) [0x3547aee17b]
(EE) 11: /lib64/ld-linux-x86-64.so.2 (0x354760+0xedc1) [0x354760edc1]
(EE) 12: /lib64/libdl.so.2 (0x354820+0x1006) [0x3548201006]
(EE) 13: /lib64/libc.so.6 (_dl_catch_error+0x72) [0x3547aee17b]
(EE) 14: /lib64/libdl.so.2 (0x354820+0x1505) [0x3548201505]
(EE) 15: /lib64/libdl.so.2 (dlopen+0x35) [0x3548201043]
(EE) 16: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x4ab4) [0x7f81285b3ab4]
(EE) 17: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x4bf4) [0x7f81285b3bf4]
(EE) 18: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x52a8) [0x7f81285b42a8]
(EE) 19: /usr/lib64/libgbm.so.1 (0x7f81285af000+0x2e1b) [0x7f81285b1e1b]
(EE) 20: /usr/lib64/libgbm.so.1 (gbm_create_device+0x39) [0x7f81285b1e89]
(EE) 21: /usr/lib64/xorg/modules/libglamoregl.so (glamor_egl_init+0x80)
[0x7f8128630ca0]
(EE) 22: /usr/lib64/xorg/modules/drivers/modesetting_drv.so
(0x7f812a2ca000+0x7d72) [0x7f812a2d1d72]
(EE) 23: /usr/libexec/Xorg (InitOutput+0x1660) [0x46be93]
(EE) 24: /usr/libexec/Xorg (0x40+0x20de1) [0x420de1]
(EE) 25: /lib64/libc.so.6 (__libc_start_main+0x15a) [0x3547a21de3]
(EE) 26: /usr/libexec/Xorg (_start+0x2a) [0x420aba]
(EE)
(EE) Segmentation fault at address 0x0

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] nouveau hardware decoding and vaDeriveImage

2017-08-16 Thread Julien Isorce
Hi,

This issue is tracked here https://bugs.freedesktop.org/s
how_bug.cgi?id=98285
This is due to a limitation in libva API which only supports 1 FD per
VaSurface.
It is enough for intel-driver because NV12 is only 1 bo. But in nouveau
driver, NV12 is 2 separates bo (omitting the interlaced pb).

Note that this libva API limitation is also a problem for AMD hardware
because NV12 is also 2 non-contiguous bo (see function
'si_video_buffer_create' and 'nouveau_vp3_video_buffer_create' mesa
source). I do not know if this is HW requirement, or if using one
contiguous bo with offset handling would work. So currently there is 2
independent calls to pipe->screen->resource_create. But maybe it would also
work if the second resource would somehow has the same underlying memory
but with an offset.

The workaround for now is to convert it to RGB: (the following pipeline
works on both nvidia and amd hardware)

GST_GL_PLATFORM=egl GST_GL_API=gles2 gst-launch-1.0 filesrc
location=test.mp4 ! qtdemux ! h264parse ! vaapih264dec ! vaapipostproc !
"video/x-raw(memory:DMABuf), format=*RGBA*" ! glimagesink

In the pipeline above, vaapipostproc will receive a NV12 vaSurface as input
and will convert it to a RGBA vaSurface. And export it as 1 dmabuf FD.
Which will be imported by glimagesink by using eglCreateImage. This is not
a full zero-copy, but at least this is zero-cpu-copy, the conversion being
done on the gpu.

Cheers
Julien


On 16 August 2017 at 03:06, Ilia Mirkin  wrote:

> [adding Julien, who did the nouveau va-api integration.]
>
> On Tue, Aug 15, 2017 at 9:59 AM, Philipp Kerling 
> wrote:
> > Hi,
> >
> > I recently noticed that hardware video decoding with the nouveau driver
> > and libva does not play nicely with Wayland and decided to dig a bit.
> >
> > To use libva in conjunction with Wayland in EGL applications, you
> > usually export the surface dmabuf via vaDeriveImage &
> > vaAcquireBufferHandle and then import it in EGL via eglCreateImageKHR &
> > EGL_LINUX_DMA_BUF_EXT.
> > However, this does not work with nouveau.
> >
> > The first problem I could identify is that nouveau uses NV12 as buffer
> > format and mesa vaDeriveImage cannot handle that (see FourCCs handled
> > in vlVaDeriveImage). It seems to be easy to add though (just have to
> > set num_planes/offset etc. correctly), and I did so locally. Also,
> > nouveau always sets the interlaced flag on the buffer, which
> > vlVaDeriveImage also errors out on. Not sure why it does that and what
> > to do with that currently, I just removed the check locally.
>
> The hw decoder produces an interlaced NV12 image -- i.e. the Y plane
> is 2 images and the UV plane is 2 images, below one another. This is
> in firmware written in falcon (VP3+) or xtensa (VP2) microcode by
> NVIDIA. There is no open-source implementation, and thus would be
> tricky to change. It's possible that this firmware supports other
> output formats as well ... but we're not presently aware of it.
> Presumably the 10-bit decoding is done *somehow*.
>
> >
> > Then I hit another problem, which is that NV12 uses two planes and thus
> > has an offset into the buffer for the second plane, but nouveau cannot
> > handle offsets in eglCreateImageKHR (see nouveau_screen_bo_from_handle
> > which has a check for this).
>
> The VP2-era hardware decoder (G84..G200, minus G98) wants a single
> output buffer - you enter it in as a single base address and then an
> offset to the UV plane. It's a 32-bit offset but a 40-bit VA space.
> Later decoder generations (VP3+) have a separate address for both Y
> and UV planes. Actually looking over the VP2 logic (which I'm sad to
> say I wrote many years ago), it *might* be possible to have separate
> buffers for the final output image (in the second VP step).
>
> > Is there an easy/obvious way to add handling for the offset parameter
> > in nouveau_screen.c? This might be all that is currently breaking hwdec
> > on nouveau+Wayland, but I couldn't test it of course, so there might
> > still be other problems lurking.
>
> Well, strictly speaking this should be easy - while nouveau_bo has no
> offset, nv04_resource does - specifically things tend to use
> nv04_resource->address. I believe this offset stuff was added
> recently, and I don't know much about EGL or Wayland or ... well a lot
> of the new hotness. So e.g. in nv50_miptree_from_handle you could set
> the mt->base.address = bo->offset + whandle->offset; I wonder if the
> tiling stuff will be an issue -- the decoder can get *very* picking
> about tiling -- somehow you'll have to ensure that the images are
> allocated with proper tiling flags set -- see how nvc0_miptree_create
> calls nvc0_miptree_init_layout_video, which sets tile_mode to 0x10.
> That's not by coincidence.
>
> BTW, note that you can't use a decoder in one thread and GL commands
> in another thread. This will cause death in nouveau. Also note that
> there are known (but unfixed) artifacts when decoding 

[Mesa-dev] [Bug 102241] gallium/wgl: SwapBuffers freezing regularly with swap interval enabled

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102241

--- Comment #1 from frank.rich...@gmail.com ---
Created attachment 133537
  --> https://bugs.freedesktop.org/attachment.cgi?id=133537=edit
Improve conversion to nanoseconds in Windows os_time_get_nano()

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102148] Crash when running qopenglwidget example on mesa llvmpipe win32

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102148

--- Comment #2 from Andreas Roth  ---
(In reply to frank.richter from comment #1)
> Created attachment 133534 [details] [review]
> Fixes the win32 llvmpipe crash
> 
> Fixes the crash with llvmpipe on Win32 by adding another null check (*fence
> is expected to be non-null).

I tried your fix and it works. Thank you very much!

Hope this fix will land in the official mesa source tree soon.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 102148] Crash when running qopenglwidget example on mesa llvmpipe win32

2017-08-16 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102148

--- Comment #1 from frank.rich...@gmail.com ---
Created attachment 133534
  --> https://bugs.freedesktop.org/attachment.cgi?id=133534=edit
Fixes the win32 llvmpipe crash

Fixes the crash with llvmpipe on Win32 by adding another null check (*fence is
expected to be non-null).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 9/9] loader_dri3: Make sure we have an updated back v3

2017-08-16 Thread Thomas Hellstrom
With GLX_SWAP_COPY_OML and GLX_SWAP_EXCHANGE_OML it may happen in situations
when glXSwapBuffers() is immediately followed by for example another
glXSwapBuffers() or glXCopyBuffers() or back buffer age querying, that we
haven't yet allocated and initialized a new back buffer because there was
no GL rendering in between.

Make sure that we have a back buffer in those situations.

v2: Eliminate the drawable have_back_format member.
v3: Make sure we re-initialize the back even if it exists.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Michel Dänzer 
---
 src/loader/loader_dri3_helper.c | 59 ++---
 src/loader/loader_dri3_helper.h |  1 +
 2 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 55e1471..e7d4715 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -59,6 +59,9 @@ static struct loader_dri3_blit_context blit_context = {
 static void
 dri3_flush_present_events(struct loader_dri3_drawable *draw);
 
+static struct loader_dri3_buffer *
+dri3_find_back_alloc(struct loader_dri3_drawable *draw);
+
 /**
  * Do we have blit functionality in the image blit extension?
  *
@@ -269,6 +272,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->first_init = true;
 
draw->cur_blit_source = -1;
+   draw->back_format = __DRI_IMAGE_FORMAT_NONE;
 
if (draw->ext->config)
   draw->ext->config->configQueryi(draw->dri_screen,
@@ -616,7 +620,10 @@ loader_dri3_copy_sub_buffer(struct loader_dri3_drawable 
*draw,
   flags |= __DRI2_FLUSH_CONTEXT;
loader_dri3_flush(draw, flags, __DRI2_THROTTLE_SWAPBUFFER);
 
-   back = dri3_back_buffer(draw);
+   back = dri3_find_back_alloc(draw);
+   if (!back)
+  return;
+
y = draw->height - y - height;
 
if (draw->is_different_gpu) {
@@ -641,7 +648,7 @@ loader_dri3_copy_sub_buffer(struct loader_dri3_drawable 
*draw,
loader_dri3_swapbuffer_barrier(draw);
dri3_fence_reset(draw->conn, back);
dri3_copy_area(draw->conn,
-  dri3_back_buffer(draw)->pixmap,
+  back->pixmap,
   draw->drawable,
   dri3_drawable_gc(draw),
   x, y, x, y, width, height);
@@ -652,7 +659,7 @@ loader_dri3_copy_sub_buffer(struct loader_dri3_drawable 
*draw,
if (draw->have_fake_front && !draw->is_different_gpu) {
   dri3_fence_reset(draw->conn, dri3_fake_front_buffer(draw));
   dri3_copy_area(draw->conn,
- dri3_back_buffer(draw)->pixmap,
+ back->pixmap,
  dri3_fake_front_buffer(draw)->pixmap,
  dri3_drawable_gc(draw),
  x, y, x, y, width, height);
@@ -763,7 +770,8 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
 
draw->vtable->flush_drawable(draw, flush_flags);
 
-   back = draw->buffers[dri3_find_back(draw)];
+   back = dri3_find_back_alloc(draw);
+
if (draw->is_different_gpu && back) {
   /* Update the linear buffer before presenting the pixmap */
   (void) loader_dri3_blit_image(draw,
@@ -892,15 +900,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
 int
 loader_dri3_query_buffer_age(struct loader_dri3_drawable *draw)
 {
-   int back_id = LOADER_DRI3_BACK_ID(dri3_find_back(draw));
+   struct loader_dri3_buffer *back = dri3_find_back_alloc(draw);
 
-   if (back_id < 0 || !draw->buffers[back_id])
+   if (!back || back->last_swap == 0)
   return 0;
 
-   if (draw->buffers[back_id]->last_swap != 0)
-  return draw->send_sbc - draw->buffers[back_id]->last_swap + 1;
-   else
-  return 0;
+   return draw->send_sbc - back->last_swap + 1;
 }
 
 /** loader_dri3_open
@@ -1334,6 +1339,8 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
int buf_id;
 
if (buffer_type == loader_dri3_buffer_back) {
+  draw->back_format = format;
+
   buf_id = dri3_find_back(draw);
 
   if (buf_id < 0)
@@ -1620,3 +1627,35 @@ loader_dri3_close_screen(__DRIscreen *dri_screen)
}
mtx_unlock(_context.mtx);
 }
+
+/**
+ * Find a backbuffer slot - potentially allocating a back buffer
+ *
+ * \param draw[in,out]  Pointer to the drawable for which to find back.
+ * \return Pointer to a new back buffer or NULL if allocation failed or was
+ * not mandated.
+ *
+ * Find a potentially new back buffer, and if it's not been allocated yet and
+ * in addition needs initializing, then try to allocate and initialize it.
+ */
+static struct loader_dri3_buffer *
+dri3_find_back_alloc(struct loader_dri3_drawable *draw)
+{
+   struct loader_dri3_buffer *back;
+   int id;
+
+   id = dri3_find_back(draw);
+   back = (id >= 0) ? draw->buffers[id] : NULL;
+
+   if (back || (id >= 0 && draw->back_format != __DRI_IMAGE_FORMAT_NONE)) {
+  if (dri3_update_drawable(draw->dri_drawable, draw)) {
+ (void) dri3_get_buffer(draw->dri_drawable,
+  

Re: [Mesa-dev] [PATCH 17/20] radeon/uvd: add yuyv format support for target buffer

2017-08-16 Thread Christian König

Am 15.08.2017 um 22:08 schrieb Leo Liu:

YUYV is a packed YUV format, and there is no chorma plane

Signed-off-by: Leo Liu 
---
  src/gallium/drivers/radeon/radeon_uvd.c | 8 ++--
  src/gallium/drivers/radeonsi/si_uvd.c   | 2 +-
  2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index 59d1f199e9..5e5638d565 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -1543,6 +1543,8 @@ void ruvd_set_dt_surfaces(struct ruvd_msg *msg, struct 
radeon_surf *luma,
default:
case RUVD_SURFACE_TYPE_LEGACY:
msg->body.decode.dt_pitch = luma->u.legacy.level[0].nblk_x;
+   if (!chroma)
+   msg->body.decode.dt_pitch *= 2;


Patch looks good to me, except for this hunk.

Can we get the pitch somehow else instead of making it depending if 
chroma is present or not?


Cause that is clearly not correct in all cases.

Christian.


switch (luma->u.legacy.level[0].mode) {
case RADEON_SURF_MODE_LINEAR_ALIGNED:
msg->body.decode.dt_tiling_mode = RUVD_TILE_LINEAR;
@@ -1562,10 +1564,12 @@ void ruvd_set_dt_surfaces(struct ruvd_msg *msg, struct 
radeon_surf *luma,
}
  
  		msg->body.decode.dt_luma_top_offset = texture_offset(luma, 0, type);

-   msg->body.decode.dt_chroma_top_offset = texture_offset(chroma, 
0, type);
+   if (chroma)
+   msg->body.decode.dt_chroma_top_offset = 
texture_offset(chroma, 0, type);
if (msg->body.decode.dt_field_mode) {
msg->body.decode.dt_luma_bottom_offset = 
texture_offset(luma, 1, type);
-   msg->body.decode.dt_chroma_bottom_offset = 
texture_offset(chroma, 1, type);
+   if (chroma)
+   msg->body.decode.dt_chroma_bottom_offset = 
texture_offset(chroma, 1, type);
} else {
msg->body.decode.dt_luma_bottom_offset = 
msg->body.decode.dt_luma_top_offset;
msg->body.decode.dt_chroma_bottom_offset = 
msg->body.decode.dt_chroma_top_offset;
diff --git a/src/gallium/drivers/radeonsi/si_uvd.c 
b/src/gallium/drivers/radeonsi/si_uvd.c
index d17a6656a4..2441ad248c 100644
--- a/src/gallium/drivers/radeonsi/si_uvd.c
+++ b/src/gallium/drivers/radeonsi/si_uvd.c
@@ -131,7 +131,7 @@ static struct pb_buffer* si_uvd_set_dtb(struct ruvd_msg 
*msg, struct vl_video_bu
  
  	msg->body.decode.dt_field_mode = buf->base.interlaced;
  
-	ruvd_set_dt_surfaces(msg, >surface, >surface, type);

+   ruvd_set_dt_surfaces(msg, >surface, (chroma) ? >surface : 
NULL, type);
  
  	return luma->resource.buf;

  }



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


Re: [Mesa-dev] [PATCH 16/20] st/va: relocate surface when stack field false

2017-08-16 Thread Christian König

Am 15.08.2017 um 22:08 schrieb Leo Liu:

Signed-off-by: Leo Liu 


The subject line should probably read "reallocate" instead of "relocate".

Additional to that the term "stacked field" isn't really used outside 
AMD, better use interlaced layout.


Apart from that the patch looks good to me as well.

Christian.


---
  src/gallium/state_trackers/va/picture.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 59594829dd..3af387ea5b 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -589,6 +589,8 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
 vlVaBuffer *coded_buf;
 vlVaSurface *surf;
 void *feedback;
+   struct pipe_screen *screen;
+   bool interlaced;
  
 if (!ctx)

return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -615,6 +617,26 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID 
context_id)
 surf = handle_table_get(drv->htab, context->target_id);
 context->mpeg4.frame_num++;
  
+   screen = context->decoder->context->screen;

+   interlaced = screen->get_video_param(screen, context->decoder->profile,
+PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
+
+   if (surf->buffer->interlaced != interlaced) {
+  surf->templat.interlaced = screen->get_video_param(screen, 
context->decoder->profile,
+ 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+ 
PIPE_VIDEO_CAP_PREFERS_INTERLACED);
+
+  surf->buffer->destroy(surf->buffer);
+
+  if (vlVaHandleSurfaceAllocate(ctx, surf, >templat) != 
VA_STATUS_SUCCESS) {
+ mtx_unlock(>mutex);
+ return VA_STATUS_ERROR_ALLOCATION_FAILED;
+  }
+
+  context->target = surf->buffer;
+   }
+
 if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
coded_buf = context->coded_buf;
getEncParamPreset(context);



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


Re: [Mesa-dev] [PATCH 15/20] radeon/video: mjpeg not support stacked video buffers

2017-08-16 Thread Christian König

Am 15.08.2017 um 22:08 schrieb Leo Liu:

So we have to detect it for relocation of de-interlaced buffers

Signed-off-by: Leo Liu 


Ah, here are the missing patches. This one is Reviewed-by: Christian 
König .



---
  src/gallium/drivers/radeon/radeon_video.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index 0cff2a0df9..6196724104 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -305,8 +305,12 @@ int rvid_get_video_param(struct pipe_screen *screen,
return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
   rscreen->family > CHIP_RV770;
} else {
-   if (u_reduce_video_profile(profile) == 
PIPE_VIDEO_FORMAT_HEVC)
+   enum pipe_video_format format = 
u_reduce_video_profile(profile);
+
+   if (format == PIPE_VIDEO_FORMAT_HEVC)
return false; //The firmware doesn't support 
interlaced HEVC.
+   else if (format == PIPE_VIDEO_FORMAT_MJPEG)
+   return false;
return true;
}
case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE:



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


Re: [Mesa-dev] [PATCH 00/20] MJPEG decode support through VA-API

2017-08-16 Thread Christian König

Hi Leo,

Patches #2, #4, #6, #8 - #12, #14, #18-#20 are Reviewed-by: Christian 
König 


Patch #1:

When you add new formats it would be nice to have 
u_reduce_video_profile() in src/gallium/auxiliary/util/u_video.h updated 
as well.


Additional to that I think the codec name is JPEG, not MJPEG. MJPEG is 
just the file/stream format with multiple JPEGs.


Patch #3:


+   case PIPE_VIDEO_FORMAT_MJPEG:
+   return true;
Please reorder the patch to be the last of the radeon/* patches, so that 
the driver only starts to claim JPEG support when everything else is 
implemented.


Apart from that the patch is Reviewed-by: Christian König 



Patch #5:

+   if (dec->stream_type != RUVD_CODEC_MJPEG) {
+   dpb_size = calc_dpb_size(dec);
+   if (!rvid_create_buffer(dec->screen, >dpb, dpb_size, 
PIPE_USAGE_DEFAULT)) {
+   RVID_ERR("Can't allocated dpb.\n");
+   goto error;
+   }
+   rvid_clear_buffer(context, >dpb);
I think it would be cleaner if calc_dpb_size() just return zero for 
RUVD_CODEC_MJPEG and then the calling code skipping buffer allocation 
when it sees a zero sized dpb.


Patch #7:

+  enum pipe_video_format format =
+ u_reduce_video_profile(context->templat.profile);
+
Here you use u_reduce_video_profile, but I can't see where you update 
u_reduce_video_profile() for JPEG support?


Patch #13:

Mhm, I'm not sure if it is a good idea to add this to the driver 
backend, but the patch is Acked-by: Christian König 
 anyway.


Patch #15, #16 and #17 are somehow missing and didn't made it to the 
mailing list.


Regards,
Christian.

Am 15.08.2017 um 22:08 schrieb Leo Liu:

The series is able to enable mjpeg decode support through vaapi, and that
includes for the formats of 420(NV12) and 422(YUYV).

Leo Liu (20):
   vl: add mjpeg profile and format
   vl: add mjpeg picture description
   radeon/video: add mjpeg support
   radeon/uvd: add mjpeg stream type
   radeon/uvd: add mjpeg support
   st/va: add mjpeg picture to context
   st/va: create decoder for mjpeg format
   st/va: add handles for mjpeg Buffers
   st/va: add picture parameter handling for mjpeg
   st/va: add iq matrix handling for mjpeg
   st/va: add huffman table handling for mjpeg
   st/va: add slice parameter handling for mjpeg
   radeon/uvd: reconstruct mjpeg bitstream
   st/va: make surface allocate functions more usefully
   radeon/video: mjpeg not support stacked video buffers
   st/va: relocate surface when stack field false
   radeon/uvd: add yuyv format support for target buffer
   st/va: detect mjpeg format from bitstream
   st/va: relocate surface with yuyv stream
   st/va: add mjpeg for config

  src/gallium/auxiliary/util/u_video.h   |   3 +
  src/gallium/drivers/radeon/radeon_uvd.c| 175 +++--
  src/gallium/drivers/radeon/radeon_uvd.h|   1 +
  src/gallium/drivers/radeon/radeon_video.c  |   8 +-
  src/gallium/drivers/radeonsi/si_uvd.c  |   2 +-
  src/gallium/include/pipe/p_video_enums.h   |   6 +-
  src/gallium/include/pipe/p_video_state.h   |  59 +
  src/gallium/state_trackers/va/Makefile.sources |   1 +
  src/gallium/state_trackers/va/config.c |   2 +-
  src/gallium/state_trackers/va/picture.c|  70 +-
  src/gallium/state_trackers/va/picture_mjpeg.c  | 116 
  src/gallium/state_trackers/va/surface.c|   8 +-
  src/gallium/state_trackers/va/va_private.h |  14 ++
  13 files changed, 440 insertions(+), 25 deletions(-)
  create mode 100644 src/gallium/state_trackers/va/picture_mjpeg.c



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


  1   2   >