Re: [Mesa-dev] [PATCH] i965: Enable ES 3.2 on Skylake.

[Matt Turner]

On Wed, Sep 21, 2016 at 7:35 AM, Kenneth Graunke  wrote:
> It's already advertised because the version.c extension checks are
> fulfilled, but we didn't actually claim support, so trying to create
> a ES 3.2 context would fail.
>
> It's all done, and the CTS results look good, so let's turn it on.
>
> Signed-off-by: Kenneth Graunke 

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

[Mesa-dev] [PATCH] i965: Enable ES 3.2 on Skylake.

[Kenneth Graunke]

It's already advertised because the version.c extension checks are
fulfilled, but we didn't actually claim support, so trying to create
a ES 3.2 context would fail.

It's all done, and the CTS results look good, so let's turn it on.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 5b21df6..8e5fdb2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1426,6 +1426,7 @@ static void
 set_max_gl_versions(struct intel_screen *screen)
 {
__DRIscreen *dri_screen = screen->driScrnPriv;
+   const bool has_astc = screen->devinfo->gen >= 9;
 
switch (screen->devinfo->gen) {
case 9:
@@ -1433,7 +1434,7 @@ set_max_gl_versions(struct intel_screen *screen)
   dri_screen->max_gl_core_version = 44;
   dri_screen->max_gl_compat_version = 30;
   dri_screen->max_gl_es1_version = 11;
-  dri_screen->max_gl_es2_version = 31;
+  dri_screen->max_gl_es2_version = has_astc ? 32 : 31;
   break;
case 7:
   dri_screen->max_gl_core_version = 33;
-- 
2.10.0

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

[Mesa-dev] [Bug 97260] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

--- Comment #56 from Michel Dänzer  ---
Created attachment 126687
  --> https://bugs.freedesktop.org/attachment.cgi?id=126687&action=edit
Use 4 buffers for flipping

(In reply to Xavier Sellier from comment #52)
> We are experiencing the very same issue.

And you ignored my explicit request to file your own report because... ?

Anyway, there are only two things which can move this issue forward: bisecting
the kernel, or trying if this Mesa patch helps.

-- 
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 97260] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

--- Comment #55 from Xavier Sellier  ---
Created attachment 126686
  --> https://bugs.freedesktop.org/attachment.cgi?id=126686&action=edit
Unigine valley benchmark (Kernel 4.8.0-rc5)

-- 
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 97260] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

Xavier Sellier  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|REOPENED|RESOLVED

--- Comment #54 from Xavier Sellier  ---
I'll upload my next benchmark, and it seems I have the very same result between
kernel 4.6 and kernel 4.8.0-rc5

-- 
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 97260] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

--- Comment #53 from Xavier Sellier  ---
Created attachment 126685
  --> https://bugs.freedesktop.org/attachment.cgi?id=126685&action=edit
Unigine valley benchmark (Kernel 4.6.0-1)

-- 
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 97260] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

Xavier Sellier  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|REOPENED

--- Comment #52 from Xavier Sellier  ---
Hey,

I have 2 computers with the very same hardware (AMD FX 6300 with a AMD R9 290).
We are experiencing the very same issue.

We're both running Debian sid.

uname -a
Linux binogure 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64
GNU/Linux

glxinfo | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD HAWAII (DRM 2.43.0 / 4.6.0-1-amd64,
LLVM 3.8.1)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 12.0.3
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 12.0.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 12.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

lspci | grep -i vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Hawaii PRO [Radeon R9 290]

Up to this kernel (4.6.1), everything runs fine (around 100 fps on most of
games). Each time I upgrade the kernel to 4.7.0-1 or 4.8.0-rc5, fps are
dropping to 25~30.
To compare fps, I use unigine valley benchmark, I will attach result to 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

[Mesa-dev] [Bug 97260] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

Michel Dänzer  changed:

   What|Removed |Added

Summary|[bisected] R9 290 low   |R9 290 low performance in
   |performance in Linux 4.7|Linux 4.7
 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #51 from Michel Dänzer  ---
Per comment 50, we won't be able to do anything more about Clésio's problem.

Anyone else still seeing similar symptoms, please file your own report and try
narrowing down which change of which component introduced it.

-- 
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 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97879

Michel Dänzer  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|glsl-compiler
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org
 CC||dri-devel@lists.freedesktop
   ||.org

--- Comment #1 from Michel Dänzer  ---
Looks like most of the cycles at the start of the apitrace are spent in the
GLSL compiler frontend, in particular in do_common_optimization.

-- 
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 1/3] anv: device: calculate compute thread numbers using subslices numbers

[Lionel Landwerlin]

On Tue, 2016-09-20 at 16:48 -0700, Kenneth Graunke wrote:
> On Friday, September 9, 2016 11:45:07 AM PDT Lionel Landwerlin wrote:
> [snip]
> > 
> > diff --git a/src/intel/vulkan/anv_private.h
> > b/src/intel/vulkan/anv_private.h
> > index 99b3acf..aa9be69 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -569,6 +569,20 @@ struct anv_physical_device {
> >  struct isl_device   isl_dev;
> >  int cmd_parser_version
> > ;
> >  
> > +uint32_teu_total;
> > +uint32_tsubslice_total;
> > +
> > +/**
> > + * Platform specific constants containing the maximum number
> > of threads
> > + * for each pipeline stage.
> > + */
> > +uint32_tmax_vs_threads;
> > +uint32_tmax_hs_threads;
> > +uint32_tmax_ds_threads;
> > +uint32_tmax_gs_threads;
> > +uint32_tmax_wm_threads;
> > +uint32_tmax_cs_threads;
> > +
> 
> One idea we've had for a while is to make a gen_device_info struct
> which is mutable, and initialize it from the static const ones we
> currently have.  But, then mutate the max_*_threads and other fields.

Thanks. Thought the same, but figured there was a reason for not doing
that.
I'll give it a try.

> 
> In GL, we've got a couple bugs on Cherryview currently because we
> have two copies of it, and some places use brw->* (the updated copy)
> and others use devinfo->* (the static const copy)...and they're not
> the same.  Just mutating gen_device_info would fix this, by having
> only one copy for everybody.
> 
> Anyway, I think we could do that as a later cleanup if you like.
> 
> Thanks for fixing this!  As is, these three are:
> Reviewed-by: Kenneth Graunke 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] *** Decode fields spanning across two DWords correctly ***

[Gandikota, Sirisha]

>-Original Message-
>From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of
>Kenneth Graunke
>Sent: Tuesday, September 20, 2016 4:28 PM
>To: mesa-dev@lists.freedesktop.org
>Subject: Re: [Mesa-dev] [PATCH v3] *** Decode fields spanning across two
>DWords correctly ***
>
>On Tuesday, September 20, 2016 3:59:27 PM PDT Sirisha Gandikota wrote:
>> From: Sirisha Gandikota 
>>
>> The first version of aubinator did not take into account the fields
>> spanning across 2 DWords. Hence fields like 64bit address/offset and
>> int were not decoded correctly. This patch should fix that issue.
>>
>> v2: Aptly renamed dw to qw in the method gen_field_iterator_next() and
>> removed extra white space in the same method (Anuj)
>>
>> v3: Change all instances of dw to qw (Anuj)
>>
>> Tested on HSW, BDW, SKL aub files
>>
>>
>> Sirisha Gandikota (1):
>>   aubinator: Fix the decoding of values that span two Dwords
>>
>>  src/intel/tools/decoder.c | 50
>> +++
>>  1 file changed, 37 insertions(+), 13 deletions(-)
>
>Hi Sirisha,
>
>You don't need to send a cover letter (--compose) for single patches.
>We generally only do that for patch series.
>
[SG] Thanks Ken... point noted! :)
>--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] anv: device: calculate compute thread numbers using subslices numbers

[Kenneth Graunke]

On Friday, September 9, 2016 11:45:07 AM PDT Lionel Landwerlin wrote:
[snip]
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index 99b3acf..aa9be69 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -569,6 +569,20 @@ struct anv_physical_device {
>  struct isl_device   isl_dev;
>  int cmd_parser_version;
>  
> +uint32_teu_total;
> +uint32_tsubslice_total;
> +
> +/**
> + * Platform specific constants containing the maximum number of threads
> + * for each pipeline stage.
> + */
> +uint32_tmax_vs_threads;
> +uint32_tmax_hs_threads;
> +uint32_tmax_ds_threads;
> +uint32_tmax_gs_threads;
> +uint32_tmax_wm_threads;
> +uint32_tmax_cs_threads;
> +

One idea we've had for a while is to make a gen_device_info struct
which is mutable, and initialize it from the static const ones we
currently have.  But, then mutate the max_*_threads and other fields.

In GL, we've got a couple bugs on Cherryview currently because we
have two copies of it, and some places use brw->* (the updated copy)
and others use devinfo->* (the static const copy)...and they're not
the same.  Just mutating gen_device_info would fix this, by having
only one copy for everybody.

Anyway, I think we could do that as a later cleanup if you like.

Thanks for fixing this!  As is, these three are:
Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [PATCH 07/12] anv/image: Memset hiz surfaces to 0 when binding memory

[Nanley Chery]

On Fri, Sep 02, 2016 at 12:46:30PM -0700, Chad Versace wrote:
> On Thu 01 Sep 2016, Jason Ekstrand wrote:
> > 
> > 
> > On Wed, Aug 31, 2016 at 8:29 PM, Nanley Chery  wrote:
> > 
> > From: Jason Ekstrand 
> > 
> > Nanley Chery (amend):
> >  - Change memset value from 0xff to 0 (a defined value for HiZ).
> 
> Yep. 0xff may hang the GPU, but 0x0 is safe.
> 
> > 
> > Signed-off-by: Nanley Chery 
> > ---
> >  src/intel/vulkan/anv_image.c | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> > index 5112c5d..9fbebd0 100644
> > --- a/src/intel/vulkan/anv_image.c
> > +++ b/src/intel/vulkan/anv_image.c
> > @@ -311,11 +311,12 @@ anv_DestroyImage(VkDevice _device, VkImage _image,
> >  }
> > 
> >  VkResult anv_BindImageMemory(
> > -    VkDevice                                    device,
> > +    VkDevice                                    _device,
> >      VkImage                                     _image,
> >      VkDeviceMemory                              _memory,
> >      VkDeviceSize                                memoryOffset)
> >  {
> > +   ANV_FROM_HANDLE(anv_device, device, _device);
> >     ANV_FROM_HANDLE(anv_device_memory, mem, _memory);
> >     ANV_FROM_HANDLE(anv_image, image, _image);
> > 
> > @@ -327,6 +328,21 @@ VkResult anv_BindImageMemory(
> >        image->offset = 0;
> >     }
> > 
> > +   if (anv_image_has_hiz(image)) {
> > +      /* HiZ surfaces need to have their memory cleared to 0 before 
> > they
> > +       * can be used.  If we let it have garbage data, it can cause GPU
> > +       * hangs on some hardware.
> > +       */
> > +      void *map = anv_gem_mmap(device, image->bo->gem_handle,
> > +                               image->offset + 
> > image->hiz_surface.offset,
> > +                               image->hiz_surface.isl.size,
> > +                               device->info.has_llc ? 0 : 
> > I915_MMAP_WC);
> 
> IIUC, because the mapping is write-combined on non-LLC chipets, and thus
> coherent, we don't need to follow anv_gem_munmap() with
> __builtin_ia32_mfence(). Looks good to me.
> 
> As an aside, I found some weirdness elsewhere in the driver regarding
> I915_MMAP_WC. I filed a bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=97579
> 
> > We should assert that offset and size are both divisible by 4096.  
> > Otherwise,
> > the kernel will return a NULL map and we'll segfault.  It should always be 
> > true
> > because the surface is tiled, but we should assert none the less.
> 
> Also, I'm bothered that the code assumes anv_gem_mmap() always succeeds.
> But that assumption seems prevalent throughout the driver. Is there any
> situation where, given valid input, it could still fail? After all,
> vkMapMemory's return type is VkResult, not void.
> 

As I understand it, yes, anv_gem_mmap() can fail if we run out of
host CPU PTEs to perform the mapping. My V2 will address this.

Nanley

> >  
> > 
> > +
> > +      memset(map, 0, image->hiz_surface.isl.size);
> > +
> > +      anv_gem_munmap(map, image->hiz_surface.isl.size);
> > +   }
> > +
> >     return VK_SUCCESS;
> >  }
> >
> > --
> > 2.9.3
> 
> Your git is newer than mine!
> /me pulls git master and rebuilds
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97879

Kenneth Graunke  changed:

   What|Removed |Added

 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|Other   |Drivers/Gallium/radeonsi
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

-- 
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 v3] *** Decode fields spanning across two DWords correctly ***

[Kenneth Graunke]

On Tuesday, September 20, 2016 3:59:27 PM PDT Sirisha Gandikota wrote:
> From: Sirisha Gandikota 
> 
> The first version of aubinator did not take into account the fields
> spanning across 2 DWords. Hence fields like 64bit address/offset and
> int were not decoded correctly. This patch should fix that issue.
> 
> v2: Aptly renamed dw to qw in the method gen_field_iterator_next()
> and removed extra white space in the same method (Anuj)
> 
> v3: Change all instances of dw to qw (Anuj)
> 
> Tested on HSW, BDW, SKL aub files
> 
> 
> Sirisha Gandikota (1):
>   aubinator: Fix the decoding of values that span two Dwords
> 
>  src/intel/tools/decoder.c | 50 
> +++
>  1 file changed, 37 insertions(+), 13 deletions(-)

Hi Sirisha,

You don't need to send a cover letter (--compose) for single patches.
We generally only do that for patch series.

--Ken


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

Re: [Mesa-dev] [PATCH v2] mesa: Implement ARB_shader_viewport_layer_array for i965

[Kenneth Graunke]

On Monday, September 19, 2016 3:36:09 PM PDT Dylan Baker wrote:
> This extension is a combination of AMD_vertex_shader_viewport_index and
> AMD_vertex_shader_layer, making it rather trivial to implement.
> 
> For gallium I *think* this needs a new cap because of the addition of
> support in tessellation evaluation shaders, and since I don't have any
> hardware to test it on, I've left that for someone else to wire up.
> 
> Signed-off-by: Dylan Baker 
> Reviewed-by: Ilia Mirkin 
> Reviewed-by: Kenneth Graunke 
> ---
> 
> v2: - changed messages to gen6+ instead of gen8+.
> - remove GLL from EXT list.

Pushed, thanks!

To ssh://git.freedesktop.org/git/mesa/mesa
   956f3e3..d4bf9ba  master -> master


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 V6] nir: Add a loop analysis pass

[Timothy Arceri]

From: Thomas Helland 

This pass detects induction variables and calculates the
trip count of loops to be used for loop unrolling.

I've removed support for float induction values for now, for the
simple reason that they don't appear in my shader-db collection,
and so I don't see it as common enough that we want to pollute the
pass with this in the initial version.

V2: Rebase, adapt to removal of function overloads

V3: (Timothy Arceri)
 - don't try to find trip count if loop terminator conditional is a phi
 - fix trip count for do-while loops
 - replace conditional type != alu assert with return
 - disable unrolling of loops with continues
 - multiple fixes to memory allocation, stop leaking and don't destroy
   structs we want to use for unrolling.
 - fix iteration count bugs when induction var not on RHS of condition
 - add FIXME for && conditions
 - calculate trip count for unsigned induction/limit vars

V4:
- count instructions in a loop
- set the limiting_terminator even if we can't find the trip count for
 all terminators. This is needed for complex unrolling where we handle
 2 terminators and the trip count is unknown for one of them.
- restruct structs so we don't keep information not required after
 analysis and remove dead fields.
- force unrolling in some cases as per the rules in the GLSL IR pass

V5:
- fix metadata mask value 0x10 vs 0x16

V6:
- merge loop_variable and nir_loop_variable structs and lists suggested by Jason
- remove induction var hash table and store pointer to induction information in
  the loop_variable suggested by Jason.
- use lowercase list_addtail() suggested by Jason.
- tidy up init_loop_block() as per Jasons suggestions.
- replace switch with nir_op_infos[alu->op].num_inputs == 2 in
  is_var_basic_induction_var() as suggested by Jason.
- use nir_block_last_instr() in and rename foreach_cf_node_ex_loop() as 
suggested
  by Jason.
- fix else check for is_trivial_loop_terminator() as per Connors suggetions.
- simplify offset for induction valiables incremented before the exit 
conditions is
  checked.
- replace nir_op_isub check with assert() as it should have been lowered away.
---
 src/compiler/Makefile.sources   |   2 +
 src/compiler/nir/nir.h  |  36 +-
 src/compiler/nir/nir_loop_analyze.c | 956 
 src/compiler/nir/nir_metadata.c |   8 +-
 4 files changed, 1000 insertions(+), 2 deletions(-)
 create mode 100644 src/compiler/nir/nir_loop_analyze.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index f5b4f9c..7ed26a9 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -190,6 +190,8 @@ NIR_FILES = \
nir/nir_intrinsics.c \
nir/nir_intrinsics.h \
nir/nir_liveness.c \
+   nir/nir_loop_analyze.c \
+   nir/nir_loop_analyze.h \
nir/nir_lower_alu_to_scalar.c \
nir/nir_lower_atomics.c \
nir/nir_lower_bitmap.c \
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index aac247c..4272051 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -1552,9 +1552,36 @@ nir_if_last_else_node(nir_if *if_stmt)
 }
 
 typedef struct {
+   nir_if *nif;
+
+   nir_instr *conditional_instr;
+
+   struct list_head loop_terminator_link;
+} nir_loop_terminator;
+
+typedef struct {
+   /* Number of instructions in the loop */
+   unsigned num_instructions;
+
+   /* How many times the loop is run (if known) */
+   unsigned trip_count;
+   bool is_trip_count_known;
+
+   /* Unroll the loop regardless of its size */
+   bool force_unroll;
+
+   nir_loop_terminator *limiting_terminator;
+
+   /* A list of loop_terminators terminating this loop. */
+   struct list_head loop_terminator_list;
+} nir_loop_info;
+
+typedef struct {
nir_cf_node cf_node;
 
struct exec_list body; /** < list of nir_cf_node */
+
+   nir_loop_info *info;
 } nir_loop;
 
 static inline nir_cf_node *
@@ -1579,6 +1606,7 @@ typedef enum {
nir_metadata_dominance = 0x2,
nir_metadata_live_ssa_defs = 0x4,
nir_metadata_not_properly_reset = 0x8,
+   nir_metadata_loop_analysis = 0x10,
 } nir_metadata;
 
 typedef struct {
@@ -1761,6 +1789,8 @@ typedef struct nir_shader_compiler_options {
 * information must be inferred from the list of input nir_variables.
 */
bool use_interpolated_input_intrinsics;
+
+   unsigned max_unroll_iterations;
 } nir_shader_compiler_options;
 
 typedef struct nir_shader_info {
@@ -1965,7 +1995,7 @@ nir_loop *nir_loop_create(nir_shader *shader);
 nir_function_impl *nir_cf_node_get_function(nir_cf_node *node);
 
 /** requests that the given pieces of metadata be generated */
-void nir_metadata_require(nir_function_impl *impl, nir_metadata required);
+void nir_metadata_require(nir_function_impl *impl, nir_metadata required, ...);
 /** dirties all but the preserved metadata */
 void nir_metadata_preserve(nir_function_impl *impl, nir_metadata preserved);
 
@@ -2570,6 +2600,10 @@ void nir_lower_double_pack(

Re: [Mesa-dev] [PATCH v3] aubinator: Fix the decoding of values that span two Dwords

[Anuj Phogat]

On Tue, Sep 20, 2016 at 3:59 PM, Sirisha Gandikota
 wrote:
> From: Sirisha Gandikota 
>
> Fixed the way the values that span two Dwords are decoded.
> Based on the start and end indices of the field, the Dwords
> are fetched and decoded accordingly.
>
> v2: rename dw to qw in gen_field_iterator_next
> and remove extra white space (Anuj)
>
> v3: change all instances of dw to qw (Anuj)
>
> Earlier, 64-bit fields (such as most pointers on Gen8+)
> weren't decoded correctly.  gen_field_iterator_next seemed
> to walk one DWord at a time, sets v.dw, and then passes it
> to field(). So, even though field() takes a uint64_t, we're
> passing it a uint32_t (which gets promoted, so the top 32
> bits will always be zero). This seems pretty bogus... (Ken)
>
> Signed-off-by: Sirisha Gandikota 
> ---
>  src/intel/tools/decoder.c | 50 
> +++
>  1 file changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
> index b5f557c..be3558b 100644
> --- a/src/intel/tools/decoder.c
> +++ b/src/intel/tools/decoder.c
> @@ -191,6 +191,26 @@ get_register_offset(const char **atts, uint32_t *offset)
> return;
>  }
>
> +static void
> +get_start_end_pos(int *start, int *end)
> +{
> +   /* start value has to be mod with 32 as we need the relative
> +* start position in the first DWord. For the end position, add
> +* the length of the field to the start position to get the
> +* relative postion in the 64 bit address.
> +*/
> +   if (*end - *start > 32) {
> +  int len = *end - *start;
> +  *start = *start % 32;
> +  *end = *start + len;
> +   } else {
> +  *start = *start % 32;
> +  *end = *end % 32;
> +   }
> +
> +   return;
> +}
> +
>  static inline uint64_t
>  mask(int start, int end)
>  {
> @@ -204,18 +224,16 @@ mask(int start, int end)
>  static inline uint64_t
>  field(uint64_t value, int start, int end)
>  {
> -   /* The field values are obtained from the DWord,
> -* Hence, get the relative start and end positions
> -* by doing a %32 on the start and end positions
> -*/
> -   return (value & mask(start % 32, end % 32)) >> (start % 32);
> +   get_start_end_pos(&start, &end);
> +   return (value & mask(start, end)) >> (start);
>  }
>
>  static inline uint64_t
>  field_address(uint64_t value, int start, int end)
>  {
> /* no need to right shift for address/offset */
> -   return (value & mask(start % 32, end % 32));
> +   get_start_end_pos(&start, &end);
> +   return (value & mask(start, end));
>  }
>
>  static struct gen_type
> @@ -491,7 +509,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
>  {
> struct gen_field *f;
> union {
> -  uint32_t dw;
> +  uint64_t qw;
>float f;
> } v;
>
> @@ -500,20 +518,26 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
>
> f = iter->group->fields[iter->i++];
> iter->name = f->name;
> -   v.dw = iter->p[f->start / 32];
> +   int index = f->start / 32;
> +
> +   if ((f->end - f->start) > 32)
> +  v.qw = ((uint64_t) iter->p[index+1] << 32) | iter->p[index];
> +   else
> +  v.qw = iter->p[index];
> +
> switch (f->type.kind) {
> case GEN_TYPE_UNKNOWN:
> case GEN_TYPE_INT:
>snprintf(iter->value, sizeof(iter->value),
> -   "%ld", field(v.dw, f->start, f->end));
> +   "%ld", field(v.qw, f->start, f->end));
>break;
> case GEN_TYPE_UINT:
>snprintf(iter->value, sizeof(iter->value),
> -   "%lu", field(v.dw, f->start, f->end));
> +   "%lu", field(v.qw, f->start, f->end));
>break;
> case GEN_TYPE_BOOL:
>snprintf(iter->value, sizeof(iter->value),
> -   "%s", field(v.dw, f->start, f->end) ? "true" : "false");
> +   "%s", field(v.qw, f->start, f->end) ? "true" : "false");
>break;
> case GEN_TYPE_FLOAT:
>snprintf(iter->value, sizeof(iter->value), "%f", v.f);
> @@ -521,7 +545,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
> case GEN_TYPE_ADDRESS:
> case GEN_TYPE_OFFSET:
>snprintf(iter->value, sizeof(iter->value),
> -   "0x%08lx", field_address(v.dw, f->start, f->end));
> +   "0x%08lx", field_address(v.qw, f->start, f->end));
>break;
> case GEN_TYPE_STRUCT:
>snprintf(iter->value, sizeof(iter->value),
> @@ -529,7 +553,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
>break;
> case GEN_TYPE_UFIXED:
>snprintf(iter->value, sizeof(iter->value),
> -   "%f", (float) field(v.dw, f->start, f->end) / (1 << 
> f->type.f));
> +   "%f", (float) field(v.qw, f->start, f->end) / (1 << 
> f->type.f));
>break;
> case GEN_TYPE_SFIXED:
>/* FIXME: Sign extend extracted field. */
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.o

[Mesa-dev] [PATCH v3] aubinator: Fix the decoding of values that span two Dwords

[Sirisha Gandikota]

From: Sirisha Gandikota 

Fixed the way the values that span two Dwords are decoded.
Based on the start and end indices of the field, the Dwords
are fetched and decoded accordingly.

v2: rename dw to qw in gen_field_iterator_next
and remove extra white space (Anuj)

v3: change all instances of dw to qw (Anuj)

Earlier, 64-bit fields (such as most pointers on Gen8+)
weren't decoded correctly.  gen_field_iterator_next seemed
to walk one DWord at a time, sets v.dw, and then passes it
to field(). So, even though field() takes a uint64_t, we're
passing it a uint32_t (which gets promoted, so the top 32
bits will always be zero). This seems pretty bogus... (Ken)

Signed-off-by: Sirisha Gandikota 
---
 src/intel/tools/decoder.c | 50 +++
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
index b5f557c..be3558b 100644
--- a/src/intel/tools/decoder.c
+++ b/src/intel/tools/decoder.c
@@ -191,6 +191,26 @@ get_register_offset(const char **atts, uint32_t *offset)
return;
 }
 
+static void
+get_start_end_pos(int *start, int *end)
+{
+   /* start value has to be mod with 32 as we need the relative
+* start position in the first DWord. For the end position, add
+* the length of the field to the start position to get the
+* relative postion in the 64 bit address.
+*/
+   if (*end - *start > 32) {
+  int len = *end - *start;
+  *start = *start % 32;
+  *end = *start + len;
+   } else {
+  *start = *start % 32;
+  *end = *end % 32;
+   }
+
+   return;
+}
+
 static inline uint64_t
 mask(int start, int end)
 {
@@ -204,18 +224,16 @@ mask(int start, int end)
 static inline uint64_t
 field(uint64_t value, int start, int end)
 {
-   /* The field values are obtained from the DWord,
-* Hence, get the relative start and end positions
-* by doing a %32 on the start and end positions
-*/
-   return (value & mask(start % 32, end % 32)) >> (start % 32);
+   get_start_end_pos(&start, &end);
+   return (value & mask(start, end)) >> (start);
 }
 
 static inline uint64_t
 field_address(uint64_t value, int start, int end)
 {
/* no need to right shift for address/offset */
-   return (value & mask(start % 32, end % 32));
+   get_start_end_pos(&start, &end);
+   return (value & mask(start, end));
 }
 
 static struct gen_type
@@ -491,7 +509,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 {
struct gen_field *f;
union {
-  uint32_t dw;
+  uint64_t qw;
   float f;
} v;
 
@@ -500,20 +518,26 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 
f = iter->group->fields[iter->i++];
iter->name = f->name;
-   v.dw = iter->p[f->start / 32];
+   int index = f->start / 32;
+
+   if ((f->end - f->start) > 32)
+  v.qw = ((uint64_t) iter->p[index+1] << 32) | iter->p[index];
+   else
+  v.qw = iter->p[index];
+
switch (f->type.kind) {
case GEN_TYPE_UNKNOWN:
case GEN_TYPE_INT:
   snprintf(iter->value, sizeof(iter->value),
-   "%ld", field(v.dw, f->start, f->end));
+   "%ld", field(v.qw, f->start, f->end));
   break;
case GEN_TYPE_UINT:
   snprintf(iter->value, sizeof(iter->value),
-   "%lu", field(v.dw, f->start, f->end));
+   "%lu", field(v.qw, f->start, f->end));
   break;
case GEN_TYPE_BOOL:
   snprintf(iter->value, sizeof(iter->value),
-   "%s", field(v.dw, f->start, f->end) ? "true" : "false");
+   "%s", field(v.qw, f->start, f->end) ? "true" : "false");
   break;
case GEN_TYPE_FLOAT:
   snprintf(iter->value, sizeof(iter->value), "%f", v.f);
@@ -521,7 +545,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
case GEN_TYPE_ADDRESS:
case GEN_TYPE_OFFSET:
   snprintf(iter->value, sizeof(iter->value),
-   "0x%08lx", field_address(v.dw, f->start, f->end));
+   "0x%08lx", field_address(v.qw, f->start, f->end));
   break;
case GEN_TYPE_STRUCT:
   snprintf(iter->value, sizeof(iter->value),
@@ -529,7 +553,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
   break;
case GEN_TYPE_UFIXED:
   snprintf(iter->value, sizeof(iter->value),
-   "%f", (float) field(v.dw, f->start, f->end) / (1 << f->type.f));
+   "%f", (float) field(v.qw, f->start, f->end) / (1 << f->type.f));
   break;
case GEN_TYPE_SFIXED:
   /* FIXME: Sign extend extracted field. */
-- 
2.7.4

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

[Mesa-dev] [PATCH v3] *** Decode fields spanning across two DWords correctly ***

[Sirisha Gandikota]

From: Sirisha Gandikota 

The first version of aubinator did not take into account the fields
spanning across 2 DWords. Hence fields like 64bit address/offset and
int were not decoded correctly. This patch should fix that issue.

v2: Aptly renamed dw to qw in the method gen_field_iterator_next()
and removed extra white space in the same method (Anuj)

v3: Change all instances of dw to qw (Anuj)

Tested on HSW, BDW, SKL aub files


Sirisha Gandikota (1):
  aubinator: Fix the decoding of values that span two Dwords

 src/intel/tools/decoder.c | 50 +++
 1 file changed, 37 insertions(+), 13 deletions(-)

-- 
2.7.4

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

Re: [Mesa-dev] [PATCH v2] aubinator: Fix the decoding of values that span two Dwords

[Anuj Phogat]

On Tue, Sep 20, 2016 at 3:31 PM, Sirisha Gandikota
 wrote:
> From: Sirisha Gandikota 
>
> Fixed the way the values that span two Dwords are decoded.
> Based on the start and end indices of the field, the Dwords
> are fetched and decoded accordingly.
>
> v2: rename dw to qw in gen_field_iterator_next()
> and remove extra white space in the same method (Anuj)
>
> Earlier, 64-bit fields (such as most pointers on Gen8+)
> weren't decoded correctly.  gen_field_iterator_next seemed
> to walk one DWord at a time, sets v.dw, and then passes it
> to field(). So, even though field() takes a uint64_t, we're
> passing it a uint32_t (which gets promoted, so the top 32
> bits will always be zero). This seems pretty bogus... (Ken)
>
> Signed-off-by: Sirisha Gandikota 
> ---
>  src/intel/tools/decoder.c | 40 
>  1 file changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
> index b5f557c..1610457 100644
> --- a/src/intel/tools/decoder.c
> +++ b/src/intel/tools/decoder.c
> @@ -191,6 +191,26 @@ get_register_offset(const char **atts, uint32_t *offset)
> return;
>  }
>
> +static void
> +get_start_end_pos(int *start, int *end)
> +{
> +   /* start value has to be mod with 32 as we need the relative
> +* start position in the first DWord. For the end position, add
> +* the length of the field to the start position to get the
> +* relative postion in the 64 bit address.
> +*/
> +   if (*end - *start > 32) {
> +  int len = *end - *start;
> +  *start = *start % 32;
> +  *end = *start + len;
> +   } else {
> +  *start = *start % 32;
> +  *end = *end % 32;
> +   }
> +
> +   return;
> +}
> +
>  static inline uint64_t
>  mask(int start, int end)
>  {
> @@ -204,18 +224,16 @@ mask(int start, int end)
>  static inline uint64_t
>  field(uint64_t value, int start, int end)
>  {
> -   /* The field values are obtained from the DWord,
> -* Hence, get the relative start and end positions
> -* by doing a %32 on the start and end positions
> -*/
> -   return (value & mask(start % 32, end % 32)) >> (start % 32);
> +   get_start_end_pos(&start, &end);
> +   return (value & mask(start, end)) >> (start);
>  }
>
>  static inline uint64_t
>  field_address(uint64_t value, int start, int end)
>  {
> /* no need to right shift for address/offset */
> -   return (value & mask(start % 32, end % 32));
> +   get_start_end_pos(&start, &end);
> +   return (value & mask(start, end));
>  }
>
>  static struct gen_type
> @@ -491,7 +509,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
>  {
> struct gen_field *f;
> union {
> -  uint32_t dw;
> +  uint64_t qw;
>float f;
> } v;
>
> @@ -500,7 +518,13 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
>
> f = iter->group->fields[iter->i++];
> iter->name = f->name;
> -   v.dw = iter->p[f->start / 32];
> +   int index = f->start / 32;
> +
> +   if ((f->end - f->start) > 32)
> +  v.dw = ((uint64_t) iter->p[index+1] << 32) | iter->p[index];
All occurances of v.dw in this function should be changed to v.qw
> +   else
> +  v.dw = iter->p[index];
> +
> switch (f->type.kind) {
> case GEN_TYPE_UNKNOWN:
> case GEN_TYPE_INT:
> --
> 2.7.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 v2] *** Decode fields spanning to two DWords correctly ***

[Sirisha Gandikota]

From: Sirisha Gandikota 

The first version of aubinator did not take into account the fields
spanning to 2 DWords. Hence fields like 64bit address/offset and
int were not decoded correctly. This patch should fix that issue.

v2: Aptly renamed dw to qw in the method gen_field_iterator_next()
and removed extra white space in the same method

Sirisha Gandikota (1):
  aubinator: Fix the decoding of values that span two Dwords

 src/intel/tools/decoder.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH v2] aubinator: Fix the decoding of values that span two Dwords

[Sirisha Gandikota]

From: Sirisha Gandikota 

Fixed the way the values that span two Dwords are decoded.
Based on the start and end indices of the field, the Dwords
are fetched and decoded accordingly.

v2: rename dw to qw in gen_field_iterator_next()
and remove extra white space in the same method (Anuj)

Earlier, 64-bit fields (such as most pointers on Gen8+)
weren't decoded correctly.  gen_field_iterator_next seemed
to walk one DWord at a time, sets v.dw, and then passes it
to field(). So, even though field() takes a uint64_t, we're
passing it a uint32_t (which gets promoted, so the top 32
bits will always be zero). This seems pretty bogus... (Ken)

Signed-off-by: Sirisha Gandikota 
---
 src/intel/tools/decoder.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
index b5f557c..1610457 100644
--- a/src/intel/tools/decoder.c
+++ b/src/intel/tools/decoder.c
@@ -191,6 +191,26 @@ get_register_offset(const char **atts, uint32_t *offset)
return;
 }
 
+static void
+get_start_end_pos(int *start, int *end)
+{
+   /* start value has to be mod with 32 as we need the relative
+* start position in the first DWord. For the end position, add
+* the length of the field to the start position to get the
+* relative postion in the 64 bit address.
+*/
+   if (*end - *start > 32) {
+  int len = *end - *start;
+  *start = *start % 32;
+  *end = *start + len;
+   } else {
+  *start = *start % 32;
+  *end = *end % 32;
+   }
+
+   return;
+}
+
 static inline uint64_t
 mask(int start, int end)
 {
@@ -204,18 +224,16 @@ mask(int start, int end)
 static inline uint64_t
 field(uint64_t value, int start, int end)
 {
-   /* The field values are obtained from the DWord,
-* Hence, get the relative start and end positions
-* by doing a %32 on the start and end positions
-*/
-   return (value & mask(start % 32, end % 32)) >> (start % 32);
+   get_start_end_pos(&start, &end);
+   return (value & mask(start, end)) >> (start);
 }
 
 static inline uint64_t
 field_address(uint64_t value, int start, int end)
 {
/* no need to right shift for address/offset */
-   return (value & mask(start % 32, end % 32));
+   get_start_end_pos(&start, &end);
+   return (value & mask(start, end));
 }
 
 static struct gen_type
@@ -491,7 +509,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 {
struct gen_field *f;
union {
-  uint32_t dw;
+  uint64_t qw;
   float f;
} v;
 
@@ -500,7 +518,13 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 
f = iter->group->fields[iter->i++];
iter->name = f->name;
-   v.dw = iter->p[f->start / 32];
+   int index = f->start / 32;
+
+   if ((f->end - f->start) > 32)
+  v.dw = ((uint64_t) iter->p[index+1] << 32) | iter->p[index];
+   else
+  v.dw = iter->p[index];
+
switch (f->type.kind) {
case GEN_TYPE_UNKNOWN:
case GEN_TYPE_INT:
-- 
2.7.4

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

[Mesa-dev] [Bug 97260] [bisected] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

--- Comment #50 from Clésio Luiz  ---
I opened the bug, but a couple weeks ago my card died, so I cannot provide info
anymore.

-- 
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] aubinator: Fix the decoding of values that span two Dwords

[Anuj Phogat]

On Tue, Sep 20, 2016 at 12:35 PM, Sirisha Gandikota
 wrote:
> From: Sirisha Gandikota 
>
> Fixed the way the values that span two Dwords are decoded.
> Based on the start and end indices of the field, the Dwords
> are fetched and decoded accordingly.
>
> Earlier, 64-bit fields (such as most pointers on Gen8+)
> weren't decoded correctly.  gen_field_iterator_next seemed
> to walk one DWord at a time, sets v.dw, and then passes it
> to field(). So, even though field() takes a uint64_t, we're
> passing it a uint32_t (which gets promoted, so the top 32
> bits will always be zero). This seems pretty bogus... (Ken)
>
> Signed-off-by: Sirisha Gandikota 
> ---
>  src/intel/tools/decoder.c | 40 
>  1 file changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
> index b5f557c..bea9f22 100644
> --- a/src/intel/tools/decoder.c
> +++ b/src/intel/tools/decoder.c
> @@ -191,6 +191,26 @@ get_register_offset(const char **atts, uint32_t *offset)
> return;
>  }
>
> +static void
> +get_start_end_pos(int *start, int *end)
> +{
> +   /* start value has to be mod with 32 as we need the relative
> +* start position in the first DWord. For the end position, add
> +* the length of the field to the start position to get the
> +* relative postion in the 64 bit address.
> +*/
> +   if (*end - *start > 32) {
> +  int len = *end - *start;
> +  *start = *start % 32;
> +  *end = *start + len;
> +   } else {
> +  *start = *start % 32;
> +  *end = *end % 32;
> +   }
> +
> +   return;
> +}
> +
>  static inline uint64_t
>  mask(int start, int end)
>  {
> @@ -204,18 +224,16 @@ mask(int start, int end)
>  static inline uint64_t
>  field(uint64_t value, int start, int end)
>  {
> -   /* The field values are obtained from the DWord,
> -* Hence, get the relative start and end positions
> -* by doing a %32 on the start and end positions
> -*/
> -   return (value & mask(start % 32, end % 32)) >> (start % 32);
> +   get_start_end_pos(&start, &end);
> +   return (value & mask(start, end)) >> (start);
>  }
>
>  static inline uint64_t
>  field_address(uint64_t value, int start, int end)
>  {
> /* no need to right shift for address/offset */
> -   return (value & mask(start % 32, end % 32));
> +   get_start_end_pos(&start, &end);
> +   return (value & mask(start, end));
>  }
>
>  static struct gen_type
> @@ -491,7 +509,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
>  {
> struct gen_field *f;
> union {
> -  uint32_t dw;
> +  uint64_t dw;
uint64_t qw?
>float f;
> } v;
>
> @@ -500,7 +518,13 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
>
> f = iter->group->fields[iter->i++];
> iter->name = f->name;
> -   v.dw = iter->p[f->start / 32];
> +   int index = f->start / 32;
> +
> +   if ((f->end - f->start) > 32)
> +  v.dw = ((uint64_t) iter->p[index+1] << 32 ) | iter->p[index];
Omit the white space after 32.
> +   else
> +  v.dw = iter->p[index];
> +
> switch (f->type.kind) {
> case GEN_TYPE_UNKNOWN:
> case GEN_TYPE_INT:
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

With above comments fixed:
Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: Rename __DRIScreen pointers to "dri_screen".

[Anuj Phogat]

On Tue, Sep 20, 2016 at 12:15 PM, Kenneth Graunke  wrote:
> I want to use "screen" as the variable name for a struct intel_screen
> pointer.  This means that we can't use it for __DRIscreen pointers.
>
> Sometimes we called it "screen", sometimes "sPriv", sometimes
> "driScrnPriv", and sometimes "psp" (Pointer to Screen Private?).
> The last one is particularly confusing because we use "psp" to refer to
> the Gen4 PIPELINED_STATE_POINTERS packet as well.
>
> Let's be consistent.  "dri_screen" is clear, and it's not used often
> enough that I'm worried about the verbosity.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_context.c   |  42 +-
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c |   4 +-
>  src/mesa/drivers/dri/i965/intel_fbo.c |   7 +-
>  src/mesa/drivers/dri/i965/intel_screen.c  | 106 
> +-
>  src/mesa/drivers/dri/i965/intel_syncobj.c |   2 +-
>  src/mesa/drivers/dri/i965/intel_tex_image.c   |   7 +-
>  6 files changed, 85 insertions(+), 83 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 3af4555..27e7d59 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -366,10 +366,10 @@ intel_flush_front(struct gl_context *ctx)
> struct brw_context *brw = brw_context(ctx);
> __DRIcontext *driContext = brw->driContext;
> __DRIdrawable *driDrawable = driContext->driDrawablePriv;
> -   __DRIscreen *const screen = brw->intelScreen->driScrnPriv;
> +   __DRIscreen *const dri_screen = brw->intelScreen->driScrnPriv;
>
> if (brw->front_buffer_dirty && _mesa_is_winsys_fbo(ctx->DrawBuffer)) {
> -  if (flushFront(screen) && driDrawable &&
> +  if (flushFront(dri_screen) && driDrawable &&
>driDrawable->loaderPrivate) {
>
>   /* Resolve before flushing FAKE_FRONT_LEFT to FRONT_LEFT.
> @@ -382,7 +382,7 @@ intel_flush_front(struct gl_context *ctx)
>   intel_resolve_for_dri2_flush(brw, driDrawable);
>   intel_batchbuffer_flush(brw);
>
> - flushFront(screen)(driDrawable, driDrawable->loaderPrivate);
> + flushFront(dri_screen)(driDrawable, driDrawable->loaderPrivate);
>
>   /* We set the dirty bit in intel_prepare_render() if we're
>* front buffer rendering once we get there.
> @@ -917,9 +917,8 @@ brwCreateContext(gl_api api,
>   unsigned *dri_ctx_error,
>  void *sharedContextPrivate)
>  {
> -   __DRIscreen *sPriv = driContextPriv->driScreenPriv;
> struct gl_context *shareCtx = (struct gl_context *) sharedContextPrivate;
> -   struct intel_screen *screen = sPriv->driverPrivate;
> +   struct intel_screen *screen = 
> driContextPriv->driScreenPriv->driverPrivate;
> const struct gen_device_info *devinfo = screen->devinfo;
> struct dd_function_table functions;
>
> @@ -1443,7 +1442,7 @@ void
>  intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
>  {
> struct brw_context *brw = context->driverPrivate;
> -   __DRIscreen *screen = brw->intelScreen->driScrnPriv;
> +   __DRIscreen *dri_screen = brw->intelScreen->driScrnPriv;
>
> /* Set this up front, so that in case our buffers get invalidated
>  * while we're getting new buffers, we don't clobber the stamp and
> @@ -1453,7 +1452,7 @@ intel_update_renderbuffers(__DRIcontext *context, 
> __DRIdrawable *drawable)
> if (unlikely(INTEL_DEBUG & DEBUG_DRI))
>fprintf(stderr, "enter %s, drawable %p\n", __func__, drawable);
>
> -   if (screen->image.loader)
> +   if (dri_screen->image.loader)
>intel_update_image_buffers(brw, drawable);
> else
>intel_update_dri2_buffers(brw, drawable);
> @@ -1517,7 +1516,7 @@ intel_query_dri2_buffers(struct brw_context *brw,
>   __DRIbuffer **buffers,
>   int *buffer_count)
>  {
> -   __DRIscreen *screen = brw->intelScreen->driScrnPriv;
> +   __DRIscreen *dri_screen = brw->intelScreen->driScrnPriv;
> struct gl_framebuffer *fb = drawable->driverPrivate;
> int i = 0;
> unsigned attachments[8];
> @@ -1561,12 +1560,13 @@ intel_query_dri2_buffers(struct brw_context *brw,
>
> assert(i <= ARRAY_SIZE(attachments));
>
> -   *buffers = screen->dri2.loader->getBuffersWithFormat(drawable,
> -&drawable->w,
> -&drawable->h,
> -attachments, i / 2,
> -buffer_count,
> -
> drawable->loaderPrivate);
> +   *buffers =
> +  dri_screen->dri2.loader->getBuffersWithFormat(drawable,
> +&drawable->w,
> +&drawable->h,
> +

[Mesa-dev] [Bug 97260] [bisected] R9 290 low performance in Linux 4.7

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97260

Xavier Sellier  changed:

   What|Removed |Added

 CC||xsell...@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] [Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97879

Bug ID: 97879
   Summary: [amdgpu] Rocket League: long hangs (several seconds)
when loading assets (models/textures/shaders?)
   Product: Mesa
   Version: 12.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: s.je...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

The game Rocket League has recently be ported to Linux (still in Beta at the
moment). Running the game works fine but at each match start, the video output
just freezes for several seconds. After these 5-10 second pauses the game
resumes (though at a much later point in time since the other players in this
multiplayer game kept playing during the time the output froze on my end).

After the first few of those freezes, they don't happen anymore for that one
match (presumably because the textures/shaders have been loaded already?). As
soon as players join or leave those freezes come back though (because more
loading of assets is required?).

Setting the "Texture Detail" option to "Quality" instead of "High Quality"
reduces the freezes to around 1 second max which makes the game much more
playable.

Hardware:
i7 3.4GH, 8GB RAM
RX 480 Sapphire Nitro 8GB

Software:
Linux 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64
GNU/Linux
mesa 12.0.3-1
llvm 3.8.1-1

I tried to get an apitrace of a match vs CPUs. You can find it here:

https://sillymon.ch/data/RocketLeague.trace.xz

-- 
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] [PATCH 1/3] st/va: Return more useful config attributes

[Mark Thompson]

---
On 20/09/16 10:55, Christian König wrote:
>> +if (profile == VAProfileHEVCMain10)
>> +   value = VA_RT_FORMAT_YUV420_10BPP;
> We actually don't support that yet. Main10 profiles dither down the 10bit 
> output to 8bits before writing it to the VA-API surface at the moment.
> 
> Apart from that the set looks good to me,
> Christian.

Sure - it can easily be added later anyway.  1/3 v2 enclosing.

Thanks,

- Mark


 src/gallium/state_trackers/va/config.c | 47 +++---
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 4052316..72f68ba 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -115,16 +115,45 @@ vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile 
profile, VAEntrypoint en

for (i = 0; i < num_attribs; ++i) {
   unsigned int value;
-  switch (attrib_list[i].type) {
-  case VAConfigAttribRTFormat:
- value = VA_RT_FORMAT_YUV420;
- break;
-  case VAConfigAttribRateControl:
- value = VA_RC_CQP | VA_RC_CBR | VA_RC_VBR;
- break;
-  default:
+  if (entrypoint == VAEntrypointVLD) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+value = VA_RT_FORMAT_YUV420;
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else if (entrypoint == VAEntrypointEncSlice) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+value = VA_RT_FORMAT_YUV420;
+break;
+ case VAConfigAttribRateControl:
+value = VA_RC_CQP | VA_RC_CBR | VA_RC_VBR;
+break;
+ case VAConfigAttribEncPackedHeaders:
+value = 0;
+break;
+ case VAConfigAttribEncMaxRefFrames:
+value = 1;
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else if (entrypoint == VAEntrypointVideoProc) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+value = (VA_RT_FORMAT_YUV420 |
+ VA_RT_FORMAT_RGB32);
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else {
  value = VA_ATTRIB_NOT_SUPPORTED;
- break;
   }
   attrib_list[i].value = value;
}
-- 
2.9.3

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

[Mesa-dev] [PATCH] *** Decode fields spanning to two DWords correctly ***

[Sirisha Gandikota]

From: Sirisha Gandikota 

The first version of aubinator did not take into account the fields
spanning to 2 DWords. Hence fields like 64bit address/offset and int
were not decoded correctly. This patch should fix that issue.

Sirisha Gandikota (1):
  aubinator: Fix the decoding of values that span two Dwords

 src/intel/tools/decoder.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH] aubinator: Fix the decoding of values that span two Dwords

[Sirisha Gandikota]

From: Sirisha Gandikota 

Fixed the way the values that span two Dwords are decoded.
Based on the start and end indices of the field, the Dwords
are fetched and decoded accordingly.

Earlier, 64-bit fields (such as most pointers on Gen8+)
weren't decoded correctly.  gen_field_iterator_next seemed
to walk one DWord at a time, sets v.dw, and then passes it
to field(). So, even though field() takes a uint64_t, we're
passing it a uint32_t (which gets promoted, so the top 32
bits will always be zero). This seems pretty bogus... (Ken)

Signed-off-by: Sirisha Gandikota 
---
 src/intel/tools/decoder.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
index b5f557c..bea9f22 100644
--- a/src/intel/tools/decoder.c
+++ b/src/intel/tools/decoder.c
@@ -191,6 +191,26 @@ get_register_offset(const char **atts, uint32_t *offset)
return;
 }
 
+static void
+get_start_end_pos(int *start, int *end)
+{
+   /* start value has to be mod with 32 as we need the relative
+* start position in the first DWord. For the end position, add
+* the length of the field to the start position to get the
+* relative postion in the 64 bit address.
+*/
+   if (*end - *start > 32) {
+  int len = *end - *start;
+  *start = *start % 32;
+  *end = *start + len;
+   } else {
+  *start = *start % 32;
+  *end = *end % 32;
+   }
+
+   return;
+}
+
 static inline uint64_t
 mask(int start, int end)
 {
@@ -204,18 +224,16 @@ mask(int start, int end)
 static inline uint64_t
 field(uint64_t value, int start, int end)
 {
-   /* The field values are obtained from the DWord,
-* Hence, get the relative start and end positions
-* by doing a %32 on the start and end positions
-*/
-   return (value & mask(start % 32, end % 32)) >> (start % 32);
+   get_start_end_pos(&start, &end);
+   return (value & mask(start, end)) >> (start);
 }
 
 static inline uint64_t
 field_address(uint64_t value, int start, int end)
 {
/* no need to right shift for address/offset */
-   return (value & mask(start % 32, end % 32));
+   get_start_end_pos(&start, &end);
+   return (value & mask(start, end));
 }
 
 static struct gen_type
@@ -491,7 +509,7 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 {
struct gen_field *f;
union {
-  uint32_t dw;
+  uint64_t dw;
   float f;
} v;
 
@@ -500,7 +518,13 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 
f = iter->group->fields[iter->i++];
iter->name = f->name;
-   v.dw = iter->p[f->start / 32];
+   int index = f->start / 32;
+
+   if ((f->end - f->start) > 32)
+  v.dw = ((uint64_t) iter->p[index+1] << 32 ) | iter->p[index];
+   else
+  v.dw = iter->p[index];
+
switch (f->type.kind) {
case GEN_TYPE_UNKNOWN:
case GEN_TYPE_INT:
-- 
2.7.4

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

[Mesa-dev] [PATCH] swr: replace mesa->swr format enum conversion

[Tim Rowley]

Replace old string comparison with a mapping table.
---
 src/gallium/drivers/swr/swr_screen.cpp | 344 -
 1 file changed, 293 insertions(+), 51 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index 2ffb3a7..90fc77e 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -45,6 +45,7 @@ extern "C" {
 #include "jit_api.h"
 
 #include 
+#include 
 
 /* MSVC case instensitive compare */
 #if defined(PIPE_CC_MSVC)
@@ -415,60 +416,301 @@ swr_get_paramf(struct pipe_screen *screen, enum 
pipe_capf param)
 SWR_FORMAT
 mesa_to_swr_format(enum pipe_format format)
 {
-   const struct util_format_description *format_desc =
-  util_format_description(format);
-   if (!format_desc)
-  return (SWR_FORMAT)-1;
-
-   // more robust check would be comparing all attributes of the formats
-   // luckily format names are mostly standardized
-   for (int i = 0; i < NUM_SWR_FORMATS; i++) {
-  const SWR_FORMAT_INFO &swr_desc = GetFormatInfo((SWR_FORMAT)i);
-
-  if (!strcasecmp(format_desc->short_name, swr_desc.name))
- return (SWR_FORMAT)i;
+   static const std::map mesa2swr = {
+  {PIPE_FORMAT_NONE,   (SWR_FORMAT)-1},
+  {PIPE_FORMAT_B8G8R8A8_UNORM, B8G8R8A8_UNORM},
+  {PIPE_FORMAT_B8G8R8X8_UNORM, B8G8R8X8_UNORM},
+  {PIPE_FORMAT_A8R8G8B8_UNORM, (SWR_FORMAT)-1},
+  {PIPE_FORMAT_X8R8G8B8_UNORM, (SWR_FORMAT)-1},
+  {PIPE_FORMAT_B5G5R5A1_UNORM, B5G5R5A1_UNORM},
+  {PIPE_FORMAT_B4G4R4A4_UNORM, B4G4R4A4_UNORM},
+  {PIPE_FORMAT_B5G6R5_UNORM,   B5G6R5_UNORM},
+  {PIPE_FORMAT_R10G10B10A2_UNORM,  R10G10B10A2_UNORM},
+  {PIPE_FORMAT_L8_UNORM,   L8_UNORM},
+  {PIPE_FORMAT_A8_UNORM,   A8_UNORM},
+  {PIPE_FORMAT_I8_UNORM,   I8_UNORM},
+  {PIPE_FORMAT_L8A8_UNORM, L8A8_UNORM},
+  {PIPE_FORMAT_L16_UNORM,  L16_UNORM},
+  {PIPE_FORMAT_UYVY,   YCRCB_SWAPUVY},
+  {PIPE_FORMAT_YUYV,   (SWR_FORMAT)-1},
+  {PIPE_FORMAT_Z16_UNORM,  R16_UNORM}, // z
+  {PIPE_FORMAT_Z32_UNORM,  (SWR_FORMAT)-1},
+  {PIPE_FORMAT_Z32_FLOAT,  R32_FLOAT}, // z
+  {PIPE_FORMAT_Z24_UNORM_S8_UINT,  R24_UNORM_X8_TYPELESS}, // z
+  {PIPE_FORMAT_S8_UINT_Z24_UNORM,  (SWR_FORMAT)-1},
+  {PIPE_FORMAT_Z24X8_UNORM,R24_UNORM_X8_TYPELESS}, // z
+  {PIPE_FORMAT_X8Z24_UNORM,(SWR_FORMAT)-1},
+  {PIPE_FORMAT_S8_UINT,(SWR_FORMAT)-1},
+  {PIPE_FORMAT_R64_FLOAT,  (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R64G64_FLOAT,   (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R64G64B64_FLOAT,(SWR_FORMAT)-1},
+  {PIPE_FORMAT_R64G64B64A64_FLOAT, (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32_FLOAT,  R32_FLOAT},
+  {PIPE_FORMAT_R32G32_FLOAT,   R32G32_FLOAT},
+  {PIPE_FORMAT_R32G32B32_FLOAT,R32G32B32_FLOAT},
+  {PIPE_FORMAT_R32G32B32A32_FLOAT, R32G32B32A32_FLOAT},
+  {PIPE_FORMAT_R32_UNORM,  (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32G32_UNORM,   (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32G32B32_UNORM,(SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32G32B32A32_UNORM, (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32_USCALED,R32_USCALED},
+  {PIPE_FORMAT_R32G32_USCALED, R32G32_USCALED},
+  {PIPE_FORMAT_R32G32B32_USCALED,  R32G32B32_USCALED},
+  {PIPE_FORMAT_R32G32B32A32_USCALED,   R32G32B32A32_USCALED},
+  {PIPE_FORMAT_R32_SNORM,  (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32G32_SNORM,   (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32G32B32_SNORM,(SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32G32B32A32_SNORM, (SWR_FORMAT)-1},
+  {PIPE_FORMAT_R32_SSCALED,R32_SSCALED},
+  {PIPE_FORMAT_R32G32_SSCALED, R32G32_SSCALED},
+  {PIPE_FORMAT_R32G32B32_SSCALED,  R32G32B32_SSCALED},
+  {PIPE_FORMAT_R32G32B32A32_SSCALED,   R32G32B32A32_SSCALED},
+  {PIPE_FORMAT_R16_UNORM,  R16_UNORM},
+  {PIPE_FORMAT_R16G16_UNORM,   R16G16_UNORM},
+  {PIPE_FORMAT_R16G16B16_UNORM,R16G16B16_UNORM},
+  {PIPE_FORMAT_R16G16B16A16_UNORM, R16G16B16A16_UNORM},
+  {PIPE_FORMAT_R16_USCALED,R16_USCALED},
+  {PIPE_FORMAT_R16G16_USCALED, R16G16_USCALED},
+  {PIPE_FORMAT_R16G16B16_USCALED,  R16G16B16_USCALED},
+  {PIPE_FORMAT_R16G16B16A16_USCALED,   R16G16B16A16_USCALED},
+  {PIPE_FORMAT_R16_SNORM,  R16_SNORM},
+  {PIPE_FORMAT_R16G16_SNORM,   R16G16_SNORM},
+  {PIPE_FORMAT_R16G16B16_SNORM,R16G16B16_SNORM},
+  {PIPE_FORMAT_R16G16B16A16_SNORM, R16G16B16A16_SNORM},
+  {PIPE_FORMAT_R16_SSCALED,R16_SSCALED},
+  {PIPE_FORMAT_R16G16_SSCALED, 

[Mesa-dev] [PATCH 1/2] i965: Rename __DRIScreen pointers to "dri_screen".

[Kenneth Graunke]

I want to use "screen" as the variable name for a struct intel_screen
pointer.  This means that we can't use it for __DRIscreen pointers.

Sometimes we called it "screen", sometimes "sPriv", sometimes
"driScrnPriv", and sometimes "psp" (Pointer to Screen Private?).
The last one is particularly confusing because we use "psp" to refer to
the Gen4 PIPELINED_STATE_POINTERS packet as well.

Let's be consistent.  "dri_screen" is clear, and it's not used often
enough that I'm worried about the verbosity.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.c   |  42 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c |   4 +-
 src/mesa/drivers/dri/i965/intel_fbo.c |   7 +-
 src/mesa/drivers/dri/i965/intel_screen.c  | 106 +-
 src/mesa/drivers/dri/i965/intel_syncobj.c |   2 +-
 src/mesa/drivers/dri/i965/intel_tex_image.c   |   7 +-
 6 files changed, 85 insertions(+), 83 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 3af4555..27e7d59 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -366,10 +366,10 @@ intel_flush_front(struct gl_context *ctx)
struct brw_context *brw = brw_context(ctx);
__DRIcontext *driContext = brw->driContext;
__DRIdrawable *driDrawable = driContext->driDrawablePriv;
-   __DRIscreen *const screen = brw->intelScreen->driScrnPriv;
+   __DRIscreen *const dri_screen = brw->intelScreen->driScrnPriv;
 
if (brw->front_buffer_dirty && _mesa_is_winsys_fbo(ctx->DrawBuffer)) {
-  if (flushFront(screen) && driDrawable &&
+  if (flushFront(dri_screen) && driDrawable &&
   driDrawable->loaderPrivate) {
 
  /* Resolve before flushing FAKE_FRONT_LEFT to FRONT_LEFT.
@@ -382,7 +382,7 @@ intel_flush_front(struct gl_context *ctx)
  intel_resolve_for_dri2_flush(brw, driDrawable);
  intel_batchbuffer_flush(brw);
 
- flushFront(screen)(driDrawable, driDrawable->loaderPrivate);
+ flushFront(dri_screen)(driDrawable, driDrawable->loaderPrivate);
 
  /* We set the dirty bit in intel_prepare_render() if we're
   * front buffer rendering once we get there.
@@ -917,9 +917,8 @@ brwCreateContext(gl_api api,
  unsigned *dri_ctx_error,
 void *sharedContextPrivate)
 {
-   __DRIscreen *sPriv = driContextPriv->driScreenPriv;
struct gl_context *shareCtx = (struct gl_context *) sharedContextPrivate;
-   struct intel_screen *screen = sPriv->driverPrivate;
+   struct intel_screen *screen = driContextPriv->driScreenPriv->driverPrivate;
const struct gen_device_info *devinfo = screen->devinfo;
struct dd_function_table functions;
 
@@ -1443,7 +1442,7 @@ void
 intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
 {
struct brw_context *brw = context->driverPrivate;
-   __DRIscreen *screen = brw->intelScreen->driScrnPriv;
+   __DRIscreen *dri_screen = brw->intelScreen->driScrnPriv;
 
/* Set this up front, so that in case our buffers get invalidated
 * while we're getting new buffers, we don't clobber the stamp and
@@ -1453,7 +1452,7 @@ intel_update_renderbuffers(__DRIcontext *context, 
__DRIdrawable *drawable)
if (unlikely(INTEL_DEBUG & DEBUG_DRI))
   fprintf(stderr, "enter %s, drawable %p\n", __func__, drawable);
 
-   if (screen->image.loader)
+   if (dri_screen->image.loader)
   intel_update_image_buffers(brw, drawable);
else
   intel_update_dri2_buffers(brw, drawable);
@@ -1517,7 +1516,7 @@ intel_query_dri2_buffers(struct brw_context *brw,
  __DRIbuffer **buffers,
  int *buffer_count)
 {
-   __DRIscreen *screen = brw->intelScreen->driScrnPriv;
+   __DRIscreen *dri_screen = brw->intelScreen->driScrnPriv;
struct gl_framebuffer *fb = drawable->driverPrivate;
int i = 0;
unsigned attachments[8];
@@ -1561,12 +1560,13 @@ intel_query_dri2_buffers(struct brw_context *brw,
 
assert(i <= ARRAY_SIZE(attachments));
 
-   *buffers = screen->dri2.loader->getBuffersWithFormat(drawable,
-&drawable->w,
-&drawable->h,
-attachments, i / 2,
-buffer_count,
-
drawable->loaderPrivate);
+   *buffers =
+  dri_screen->dri2.loader->getBuffersWithFormat(drawable,
+&drawable->w,
+&drawable->h,
+attachments, i / 2,
+buffer_count,
+drawable->loaderPrivate);
 }
 
 /**
@@ -1713,7 +1713,7 @@ static void
 i

[Mesa-dev] [PATCH 2/2] i965: Rename intelScreen to screen.

[Kenneth Graunke]

"intelScreen" is wordy and also doesn't fit our style guidelines.
"screen" is shorter, which is nice, because we use it fairly often.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_blorp.c|   2 +-
 src/mesa/drivers/dri/i965/brw_clip.c |   4 +-
 src/mesa/drivers/dri/i965/brw_context.c  |  44 +++---
 src/mesa/drivers/dri/i965/brw_context.h  |   4 +-
 src/mesa/drivers/dri/i965/brw_cs.c   |   6 +-
 src/mesa/drivers/dri/i965/brw_ff_gs.c|   4 +-
 src/mesa/drivers/dri/i965/brw_gs.c   |   8 +-
 src/mesa/drivers/dri/i965/brw_link.cpp   |   4 +-
 src/mesa/drivers/dri/i965/brw_program.c  |  20 +--
 src/mesa/drivers/dri/i965/brw_queryobj.c |   2 +-
 src/mesa/drivers/dri/i965/brw_sf.c   |   4 +-
 src/mesa/drivers/dri/i965/brw_state_dump.c   |   2 +-
 src/mesa/drivers/dri/i965/brw_surface_formats.c  |   2 +-
 src/mesa/drivers/dri/i965/brw_tcs.c  |   2 +-
 src/mesa/drivers/dri/i965/brw_tes.c  |   4 +-
 src/mesa/drivers/dri/i965/brw_vs.c   |   6 +-
 src/mesa/drivers/dri/i965/brw_wm.c   |   4 +-
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |   8 +-
 src/mesa/drivers/dri/i965/gen7_cs_state.c|   4 +-
 src/mesa/drivers/dri/i965/gen7_l3_state.c|  10 +-
 src/mesa/drivers/dri/i965/gen7_urb.c |   2 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c|   6 +-
 src/mesa/drivers/dri/i965/intel_extensions.c |   8 +-
 src/mesa/drivers/dri/i965/intel_fbo.c|   4 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c|   4 +-
 src/mesa/drivers/dri/i965/intel_screen.c | 166 +++
 src/mesa/drivers/dri/i965/intel_tex.c|   4 +-
 src/mesa/drivers/dri/i965/intel_tex_image.c  |   2 +-
 28 files changed, 170 insertions(+), 170 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index e1ea208..23fe3aa 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -66,7 +66,7 @@ brw_blorp_init(struct brw_context *brw)
 {
blorp_init(&brw->blorp, brw, &brw->isl_dev);
 
-   brw->blorp.compiler = brw->intelScreen->compiler;
+   brw->blorp.compiler = brw->screen->compiler;
 
switch (brw->gen) {
case 6:
diff --git a/src/mesa/drivers/dri/i965/brw_clip.c 
b/src/mesa/drivers/dri/i965/brw_clip.c
index 4c9d5c5..1d2070b 100644
--- a/src/mesa/drivers/dri/i965/brw_clip.c
+++ b/src/mesa/drivers/dri/i965/brw_clip.c
@@ -61,7 +61,7 @@ static void compile_clip_prog( struct brw_context *brw,
 
/* Begin the compilation:
 */
-   brw_init_codegen(brw->intelScreen->devinfo, &c.func, mem_ctx);
+   brw_init_codegen(brw->screen->devinfo, &c.func, mem_ctx);
 
c.func.single_program_flow = 1;
 
@@ -116,7 +116,7 @@ static void compile_clip_prog( struct brw_context *brw,
 
if (unlikely(INTEL_DEBUG & DEBUG_CLIP)) {
   fprintf(stderr, "clip:\n");
-  brw_disassemble(brw->intelScreen->devinfo, c.func.store,
+  brw_disassemble(brw->screen->devinfo, c.func.store,
   0, program_size, stderr);
   fprintf(stderr, "\n");
}
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 27e7d59..908eb6d 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -80,9 +80,9 @@
 const char *const brw_vendor_string = "Intel Open Source Technology Center";
 
 static const char *
-get_bsw_model(const struct intel_screen *intelScreen)
+get_bsw_model(const struct intel_screen *screen)
 {
-   switch (intelScreen->eu_total) {
+   switch (screen->eu_total) {
case 16:
   return "405";
case 12:
@@ -93,13 +93,13 @@ get_bsw_model(const struct intel_screen *intelScreen)
 }
 
 const char *
-brw_get_renderer_string(const struct intel_screen *intelScreen)
+brw_get_renderer_string(const struct intel_screen *screen)
 {
const char *chipset;
static char buffer[128];
char *bsw = NULL;
 
-   switch (intelScreen->deviceID) {
+   switch (screen->deviceID) {
 #undef CHIPSET
 #define CHIPSET(id, symbol, str) case id: chipset = str; break;
 #include "pci_ids/i965_pci_ids.h"
@@ -109,11 +109,11 @@ brw_get_renderer_string(const struct intel_screen 
*intelScreen)
}
 
/* Braswell branding is funny, so we have to fix it up here */
-   if (intelScreen->deviceID == 0x22B1) {
+   if (screen->deviceID == 0x22B1) {
   bsw = strdup(chipset);
   char *needle = strstr(bsw, "XXX");
   if (needle) {
- memcpy(needle, get_bsw_model(intelScreen), 3);
+ memcpy(needle, get_bsw_model(screen), 3);
  chipset = bsw;
   }
}
@@ -134,7 +134,7 @@ intel_get_string(struct gl_context * ctx, GLenum name)
 
case GL_RENDERER:
   return
- (GLubyte *) brw_get_renderer_string(brw->intelScreen);
+ (GLubyte *) brw_get_renderer_string(brw->screen);
 
d

Re: [Mesa-dev] [PATCH] i965/ir: Test thread dispatch packing assumptions.

[Jason Ekstrand]

On Sep 20, 2016 12:49 AM, "Francisco Jerez"  wrote:
>
> Not intended for upstream.

If we're going to upstream this, we should remove the content saying we
won't.

Otherwise r-b

> Should cause a GPU hang if some thread is
> executed with a non-contiguous dispatch mask breaking assumptions of
> brw_stage_has_packed_dispatch().  Doesn't cause any CTS, DEQP or
> Piglit regressions, while replacing brw_stage_has_packed_dispatch()
> with a dummy implementation that unconditionally returns true on top
> of this patch causes multiple GPU hangs.
>
> v2: Drop VEC4 test and clean up slightly for upstream (Jason).
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 03d4f5f..c5fa3f7 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -6832,3 +6832,33 @@ brw_compile_cs(const struct brw_compiler
*compiler, void *log_data,
>
> return g.get_assembly(final_assembly_size);
>  }
> +
> +/**
> + * Test the dispatch mask packing assumptions of
> + * brw_stage_has_packed_dispatch().  Call this from e.g. the top of
> + * fs_visitor::emit_nir_code() to cause a GPU hang if any shader
invocation is
> + * executed with an unexpected dispatch mask.
> + */
> +static UNUSED void
> +brw_fs_test_dispatch_packing(const fs_builder &bld)
> +{
> +   const gl_shader_stage stage = bld.shader->stage;
> +
> +   if (brw_stage_has_packed_dispatch(bld.shader->devinfo, stage,
> + bld.shader->stage_prog_data)) {
> +  const fs_builder ubld = bld.exec_all().group(1, 0);
> +  const fs_reg tmp = component(bld.vgrf(BRW_REGISTER_TYPE_UD), 0);
> +  const fs_reg mask = (stage == MESA_SHADER_FRAGMENT ?
brw_vmask_reg() :
> +   brw_dmask_reg());
> +
> +  ubld.ADD(tmp, mask, brw_imm_ud(1));
> +  ubld.AND(tmp, mask, tmp);
> +
> +  /* This will loop forever if the dispatch mask doesn't have the
expected
> +   * form '2^n-1', in which case tmp will be non-zero.
> +   */
> +  bld.emit(BRW_OPCODE_DO);
> +  bld.CMP(bld.null_reg_ud(), tmp, brw_imm_ud(0), BRW_CONDITIONAL_NZ);
> +  set_predicate(BRW_PREDICATE_NORMAL, bld.emit(BRW_OPCODE_WHILE));
> +   }
> +}
> --
> 2.9.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: Check for VK_WHOLE_SIZE in anv_CmdFillBuffer

[Jason Ekstrand]

Seems reasonable

Reviewed-by: Jason Ekstrand 

This reminds me that we really need to convert CmdFillBuffer over to using
blorp...

On Sep 20, 2016 6:37 PM, "Nicolas Koch"  wrote:

> Vulkan spec:
> Size is the number of bytes to fill, and must be either a multiple of 4,
> or VK_WHOLE_SIZE to fill the range from offset to the end of the buffer.
> If VK_WHOLE_SIZE is used and the remaining size of the buffer is not a
> multiple of 4, then the nearest smaller multiple is used.
> ---
>  src/intel/vulkan/anv_meta_clear.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_meta_clear.c
> b/src/intel/vulkan/anv_meta_clear.c
> index ed4d1db..fd0797f 100644
> --- a/src/intel/vulkan/anv_meta_clear.c
> +++ b/src/intel/vulkan/anv_meta_clear.c
> @@ -1012,6 +1012,12 @@ void anv_CmdFillBuffer(
>
> meta_clear_begin(&saved_state, cmd_buffer);
>
> +   if (fillSize == VK_WHOLE_SIZE) {
> +  fillSize = dst_buffer->size - dstOffset;
> +  /* Make sure fillSize is a multiple of 4 */
> +  fillSize -= fillSize & 3;
> +   }
> +
> VkFormat format;
> int bs;
> if ((fillSize & 15) == 0 && (dstOffset & 15) == 0) {
> --
> 2.10.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

[Mesa-dev] [PATCH] anv: Check for VK_WHOLE_SIZE in anv_CmdFillBuffer

[Nicolas Koch]

Vulkan spec:
Size is the number of bytes to fill, and must be either a multiple of 4,
or VK_WHOLE_SIZE to fill the range from offset to the end of the buffer.
If VK_WHOLE_SIZE is used and the remaining size of the buffer is not a
multiple of 4, then the nearest smaller multiple is used.
---
 src/intel/vulkan/anv_meta_clear.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/intel/vulkan/anv_meta_clear.c 
b/src/intel/vulkan/anv_meta_clear.c
index ed4d1db..fd0797f 100644
--- a/src/intel/vulkan/anv_meta_clear.c
+++ b/src/intel/vulkan/anv_meta_clear.c
@@ -1012,6 +1012,12 @@ void anv_CmdFillBuffer(
 
meta_clear_begin(&saved_state, cmd_buffer);
 
+   if (fillSize == VK_WHOLE_SIZE) {
+  fillSize = dst_buffer->size - dstOffset;
+  /* Make sure fillSize is a multiple of 4 */
+  fillSize -= fillSize & 3;
+   }
+
VkFormat format;
int bs;
if ((fillSize & 15) == 0 && (dstOffset & 15) == 0) {
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH] st/va: Make VAAPI_DISABLE_INTERLACE default true

[Andy Furniss]

Andy Furniss wrote:



Hi @Andy, could you update your patch to move that debug env flag to
radeon ?  Thx


I don't know mesa code that well so maybe I misunderstand, but, if I
default to true and test in there it will affect vdpau decode as well
which I guess will disable de-interlace and maybe worse (IIRC messing
with progressive vs interlaced broke something vdpau last time I tried).


On the last bit, I can confirm that forcing false for
PIPE_VIDEO_CAP_SUPPORTS_INTERLACED
is far worse than just loosing de-interlacer.

With s/w decode and mplayer/mpv -vo vdpau I get corruption, 000s of
vmfaults plus a segfault.

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

Re: [Mesa-dev] [PATCH] radeon/vce: add firmware support for version 52.8.3

[Christian König]

Am 20.09.2016 um 16:11 schrieb Leo Liu:

Signed-off-by: Leo Liu 


Reviewed-by: Christian König 


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

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 92cb8ce..8504d93 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -51,6 +51,7 @@
  #define FW_50_17_3 ((50 << 24) | (17 << 16) | (3 << 8))
  #define FW_52_0_3 ((52 << 24) | (0 << 16) | (3 << 8))
  #define FW_52_4_3 ((52 << 24) | (4 << 16) | (3 << 8))
+#define FW_52_8_3 ((52 << 24) | (8 << 16) | (3 << 8))
  
  /**

   * flush commands to the hardware
@@ -488,6 +489,7 @@ struct pipe_video_codec *rvce_create_encoder(struct 
pipe_context *context,
  
  	case FW_52_0_3:

case FW_52_4_3:
+   case FW_52_8_3:
radeon_vce_52_init(enc);
get_pic_param = radeon_vce_52_get_param;
break;
@@ -522,6 +524,7 @@ bool rvce_is_fw_version_supported(struct r600_common_screen 
*rscreen)
case FW_50_17_3:
case FW_52_0_3:
case FW_52_4_3:
+   case FW_52_8_3:
return true;
default:
return false;



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

[Mesa-dev] [PATCH] radeon/vce: add firmware support for version 52.8.3

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_vce.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 92cb8ce..8504d93 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -51,6 +51,7 @@
 #define FW_50_17_3 ((50 << 24) | (17 << 16) | (3 << 8))
 #define FW_52_0_3 ((52 << 24) | (0 << 16) | (3 << 8))
 #define FW_52_4_3 ((52 << 24) | (4 << 16) | (3 << 8))
+#define FW_52_8_3 ((52 << 24) | (8 << 16) | (3 << 8))
 
 /**
  * flush commands to the hardware
@@ -488,6 +489,7 @@ struct pipe_video_codec *rvce_create_encoder(struct 
pipe_context *context,
 
case FW_52_0_3:
case FW_52_4_3:
+   case FW_52_8_3:
radeon_vce_52_init(enc);
get_pic_param = radeon_vce_52_get_param;
break;
@@ -522,6 +524,7 @@ bool rvce_is_fw_version_supported(struct r600_common_screen 
*rscreen)
case FW_50_17_3:
case FW_52_0_3:
case FW_52_4_3:
+   case FW_52_8_3:
return true;
default:
return false;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] st/va: Make VAAPI_DISABLE_INTERLACE default true

[Andy Furniss]

Julien Isorce wrote:

On 16 September 2016 at 08:43, Christian König
 wrote:


Am 15.09.2016 um 23:07 schrieb Julien Isorce:



On 15 September 2016 at 16:02, Leo Liu  wrote:




On 09/15/2016 10:43 AM, Andy Furniss wrote:


Since bf901a2 st/va: also honors interlaced preference when
providing a video format existing scripts and most use cases
will need true.

Signed-off-by: Andy Furniss  ---
src/gallium/state_trackers/va/surface.c | 2 +- 1 file changed,
1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c index
00df69d..e73e17e 100644 ---
a/src/gallium/state_trackers/va/surface.c +++
b/src/gallium/state_trackers/va/surface.c @@ -43,7 +43,7 @@

#include "va_private.h"

-DEBUG_GET_ONCE_BOOL_OPTION(nointerlace,
"VAAPI_DISABLE_INTERLACE", FALSE);
+DEBUG_GET_ONCE_BOOL_OPTION(nointerlace,
"VAAPI_DISABLE_INTERLACE", TRUE);



Like being mentioned,  It'll still override the preferred
interlaced format when this env is not explicitly used.

Not sure this will be okay with other case. @Julien?



Hi,

So the problem is that with radeon,
PIPE_VIDEO_CAP_SUPPORTS_INTERLACED always returns false for
encoding but can return true for decoding (depending on the chipset
and the codec). Then when doing transcoding you need all to be non
interlaced to avoid extra copy/conversion and even a clash. Is it
correct ?


Yes correct. The decoder supports both interlaced as well as
progressive memory layout, but the encoder can only handle
progressive input.

Interlaced memory layout is needed for things like adaptive
deinterlacing as well as VDPAU OpenGL interop.




Should debug_get_option_nointerlace() be moved to
radeon_video.c::rvid_get_video_param ?


For the short term that sounds like a good idea to me.




Hi @Andy, could you update your patch to move that debug env flag to
radeon ?  Thx


I don't know mesa code that well so maybe I misunderstand, but, if I
default to true and test in there it will affect vdpau decode as well
which I guess will disable de-interlace and maybe worse (IIRC messing
with progressive vs interlaced broke something vdpau last time I tried).

So I don't know how to make the flag only affect vaapi usage from there.


In the mid term we need to better handle this case. E.g. allocate
the video buffer with the layout the driver reports as preferred,
if that doesn't match the use case (transcoding, deinterlacing or
interop) convert as needed.



yes, also if the conversion is done in HW that should still
acceptable. But also it should be a way to configure that from
gstreamer-vaapi/libva using VA_SURFACE_ATTRIB_USAGE_HINT_ENCODER /
VA_SURFACE_ATTRIB_USAGE_HINT_VPP_READ maybe ... and catch this flag
in vlVaCreateSurfaces2.





Other question:

case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED: if (rscreen->family <
CHIP_PALM) { /* MPEG2 only with shaders and no support for
interlacing on R6xx style UVD */ return codec !=
PIPE_VIDEO_FORMAT_MPEG12 && rscreen->family > CHIP_RV770; } else {
if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
return false; //The firmware doesn't support interlaced HEVC.
return true; } So if instead it would always return false then it
will really work on hardware for which above code says true ?


It would work, but the deinterlacing and interop use case I noted
above would break.





Because my understanding is that for nvidia hardware this is not a
preference but rather a requirement but I might be wrong.


Yes, as far as I know that is correct. AMD hardware can handle both
for most hardware/profile combinations, even the HEVC limit only
applies to a certain firmware version IIRC.


In any case, with current upstream code and
VAAPI_DISABLE_INTERLACE=1 it hits "assert(templat->interlaced);" in
nouveau_vp3_video_buffer_create. If I remove the asset it crashes
and can even stall the driver (just wanted to check ).


Crap, feel free to revert the patch setting it to true by default.



It has not been pushed:
https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/state_trackers/va



so still time for @Andy to update his patch.



Cheers Julien



Regards, Christian.

Cheers Julien



Regards, Leo



#include 







___ mesa-dev mailing
listmesa-dev@lists.freedesktop.orghttps://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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

[Mike Lothian]

I'm running libva-1.7.2 but I notice this commit in git
https://cgit.freedesktop.org/vaapi/libva/commit/?id=a55ea7cb3143d57c8dba1b76ccea3511ea69adf2
but
that looks like it might only work with wayland

On Tue, 20 Sep 2016 at 14:40 Christian König 
wrote:

> Sounds like your version of libva ignores the DRI_PRIME environment
> parameter.
>
> Not sure what to do with this, but clearly a loader and not a driver
> problem.
>
> Regards,
> Christian.
>
>
> Am 20.09.2016 um 15:36 schrieb Mike Lothian:
>
> Here's what I currently have:
>
> fireburn@axion ~ $ DRI_PRIME=1 vainfo
> libva info: VA-API version 0.39.3
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
> libva info: Found init function __vaDriverInit_0_39
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 0.39 (libva 1.7.2)
> vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.2
> vainfo: Supported profile and entrypoints
>   VAProfileMPEG2Simple: VAEntrypointVLD
>   VAProfileMPEG2Simple: VAEntrypointEncSlice
>   VAProfileMPEG2Main  : VAEntrypointVLD
>   VAProfileMPEG2Main  : VAEntrypointEncSlice
>   VAProfileH264ConstrainedBaseline: VAEntrypointVLD
>   VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
>   VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
>   VAProfileH264Main   : VAEntrypointVLD
>   VAProfileH264Main   : VAEntrypointEncSlice
>   VAProfileH264Main   : VAEntrypointEncSliceLP
>   VAProfileH264High   : VAEntrypointVLD
>   VAProfileH264High   : VAEntrypointEncSlice
>   VAProfileH264High   : VAEntrypointEncSliceLP
>   VAProfileH264MultiviewHigh  : VAEntrypointVLD
>   VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
>   VAProfileH264StereoHigh : VAEntrypointVLD
>   VAProfileH264StereoHigh : VAEntrypointEncSlice
>   VAProfileVC1Simple  : VAEntrypointVLD
>   VAProfileVC1Main: VAEntrypointVLD
>   VAProfileVC1Advanced: VAEntrypointVLD
>   VAProfileNone   : VAEntrypointVideoProc
>   VAProfileJPEGBaseline   : VAEntrypointVLD
>   VAProfileJPEGBaseline   : VAEntrypointEncPicture
>   VAProfileVP8Version0_3  : VAEntrypointVLD
>   VAProfileVP8Version0_3  : VAEntrypointEncSlice
>   VAProfileHEVCMain   : VAEntrypointVLD
>   VAProfileHEVCMain   : VAEntrypointEncSlice
>
>
> which picks up the i965 driver despite the DRI_PRIME=1 paramerter being
> fed in - I have to manually specify LIBVA_DRIVER_NAME=radeonsi in order to
> get it to get the details out of vainfo - the same goes for vdpauinfo
>
> fireburn@axion ~ $ LIBVA_DRIVER_NAME=radeonsi DRI_PRIME=1 vainfo
> libva info: VA-API version 0.39.3
> libva info: va_getDriverName() returns 0
> libva info: User requested driver 'radeonsi'
> libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
> libva info: Found init function __vaDriverInit_0_39
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 0.39 (libva 1.7.2)
> vainfo: Driver version: mesa gallium vaapi
> vainfo: Supported profile and entrypoints
>   VAProfileMPEG2Simple: VAEntrypointVLD
>   VAProfileMPEG2Main  : VAEntrypointVLD
>   VAProfileVC1Simple  : VAEntrypointVLD
>   VAProfileVC1Main: VAEntrypointVLD
>   VAProfileVC1Advanced: VAEntrypointVLD
>   VAProfileH264Baseline   : VAEntrypointVLD
>   VAProfileH264Baseline   : VAEntrypointEncSlice
>   VAProfileH264Main   : VAEntrypointVLD
>   VAProfileH264Main   : VAEntrypointEncSlice
>   VAProfileH264High   : VAEntrypointVLD
>   VAProfileH264High   : VAEntrypointEncSlice
>   VAProfileNone   : VAEntrypointVideoProc
>
>
> On Tue, 20 Sep 2016 at 14:13 Nayan Deshmukh 
> wrote:
>
>> Hi Mike,
>>
>>
>> On Tue, Sep 20, 2016 at 5:45 PM, Mike Lothian 
>> wrote:
>>
>>> Hi
>>>
>>> I've just confirmed this works for getting details from vainfo and
>>> vdpauinfo using DRI_PRIME=1 without needing to set up offloading with xrandr
>>>
>>> I do however need to specify the driver still, is that something being
>>> worked on? It would be great if it autoselected based on the card running
>>> at DRI_PRIME=1 (or x if there's more than one card)
>>>
>>> I have a prime system and I don't need to specify any drivers in my
>> system.
>> Though I am not the right person to answer this question.
>> Maybe Michel can answer this.
>>
>> Cheers,
>> Nayan
>>
>>> Cheers
>>>
>>> Mike
>>>
>>> On Tue, 20 Sep 2016 at 05:52 Nayan Deshmukh 
>>> wrote:
>>>
 In case of prime when rendering is done on GPU other then the
 server GPU, use a seprate linear buffer for 

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

[Christian König]

Sounds like your version of libva ignores the DRI_PRIME environment 
parameter.


Not sure what to do with this, but clearly a loader and not a driver 
problem.


Regards,
Christian.

Am 20.09.2016 um 15:36 schrieb Mike Lothian:

Here's what I currently have:

fireburn@axion ~ $ DRI_PRIME=1 vainfo
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.2
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointEncSliceLP
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointEncSliceLP
  VAProfileH264MultiviewHigh  : VAEntrypointVLD
  VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
  VAProfileH264StereoHigh : VAEntrypointVLD
  VAProfileH264StereoHigh : VAEntrypointEncSlice
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointEncPicture
  VAProfileVP8Version0_3  : VAEntrypointVLD
  VAProfileVP8Version0_3  : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice


which picks up the i965 driver despite the DRI_PRIME=1 paramerter 
being fed in - I have to manually specify LIBVA_DRIVER_NAME=radeonsi 
in order to get it to get the details out of vainfo - the same goes 
for vdpauinfo


fireburn@axion ~ $ LIBVA_DRIVER_NAME=radeonsi DRI_PRIME=1 vainfo
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileNone   : VAEntrypointVideoProc


On Tue, 20 Sep 2016 at 14:13 Nayan Deshmukh > wrote:


Hi Mike,


On Tue, Sep 20, 2016 at 5:45 PM, Mike Lothian mailto:m...@fireburn.co.uk>> wrote:

Hi

I've just confirmed this works for getting details from vainfo
and vdpauinfo using DRI_PRIME=1 without needing to set up
offloading with xrandr

I do however need to specify the driver still, is that
something being worked on? It would be great if it
autoselected based on the card running at DRI_PRIME=1 (or x if
there's more than one card)

I have a prime system and I don't need to specify any drivers in
my system.
Though I am not the right person to answer this question.
Maybe Michel can answer this.

Cheers,
Nayan

Cheers

Mike

On Tue, 20 Sep 2016 at 05:52 Nayan Deshmukh
mailto:nayan26deshm...@gmail.com>>
wrote:

In case of prime when rendering is done on GPU other then the
server GPU, use a seprate linear buffer for each back buffer
which will be displayed using present extension.

v2: Use a seprate linear buffer for each back buffer (Michel)
v3: Change variable names and fix coding style (Leo and Emil)
v4: Use PIPE

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

[Mike Lothian]

Here's what I currently have:

fireburn@axion ~ $ DRI_PRIME=1 vainfo
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.2
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointEncSliceLP
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointEncSliceLP
  VAProfileH264MultiviewHigh  : VAEntrypointVLD
  VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
  VAProfileH264StereoHigh : VAEntrypointVLD
  VAProfileH264StereoHigh : VAEntrypointEncSlice
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointEncPicture
  VAProfileVP8Version0_3  : VAEntrypointVLD
  VAProfileVP8Version0_3  : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice


which picks up the i965 driver despite the DRI_PRIME=1 paramerter being fed
in - I have to manually specify LIBVA_DRIVER_NAME=radeonsi in order to get
it to get the details out of vainfo - the same goes for vdpauinfo

fireburn@axion ~ $ LIBVA_DRIVER_NAME=radeonsi DRI_PRIME=1 vainfo
libva info: VA-API version 0.39.3
libva info: va_getDriverName() returns 0
libva info: User requested driver 'radeonsi'
libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.2)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileNone   : VAEntrypointVideoProc


On Tue, 20 Sep 2016 at 14:13 Nayan Deshmukh 
wrote:

> Hi Mike,
>
>
> On Tue, Sep 20, 2016 at 5:45 PM, Mike Lothian  wrote:
>
>> Hi
>>
>> I've just confirmed this works for getting details from vainfo and
>> vdpauinfo using DRI_PRIME=1 without needing to set up offloading with xrandr
>>
>> I do however need to specify the driver still, is that something being
>> worked on? It would be great if it autoselected based on the card running
>> at DRI_PRIME=1 (or x if there's more than one card)
>>
>> I have a prime system and I don't need to specify any drivers in my
> system.
> Though I am not the right person to answer this question.
> Maybe Michel can answer this.
>
> Cheers,
> Nayan
>
>> Cheers
>>
>> Mike
>>
>> On Tue, 20 Sep 2016 at 05:52 Nayan Deshmukh 
>> wrote:
>>
>>> In case of prime when rendering is done on GPU other then the
>>> server GPU, use a seprate linear buffer for each back buffer
>>> which will be displayed using present extension.
>>>
>>> v2: Use a seprate linear buffer for each back buffer (Michel)
>>> v3: Change variable names and fix coding style (Leo and Emil)
>>> v4: Use PIPE_BIND_SAMPLER_VIEW for back buffer in case when
>>> a seprate linear buffer is used (Michel)
>>> v4.1: remove empty line
>>> v4.2: destroy the context and handle the case when
>>>   create_context fails (Emil)
>>>
>>> Signed-off-by: Nayan Deshmukh 
>>> Reviewed-by: Leo Liu 
>>> Acked-by: Michel Dänzer 
>>> ---
>>>  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 66
>>> +--
>>>  1 file changed, 53 insertions(+), 13

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

[Nayan Deshmukh]

Hi Mike,


On Tue, Sep 20, 2016 at 5:45 PM, Mike Lothian  wrote:

> Hi
>
> I've just confirmed this works for getting details from vainfo and
> vdpauinfo using DRI_PRIME=1 without needing to set up offloading with xrandr
>
> I do however need to specify the driver still, is that something being
> worked on? It would be great if it autoselected based on the card running
> at DRI_PRIME=1 (or x if there's more than one card)
>
> I have a prime system and I don't need to specify any drivers in my
system.
Though I am not the right person to answer this question.
Maybe Michel can answer this.

Cheers,
Nayan

> Cheers
>
> Mike
>
> On Tue, 20 Sep 2016 at 05:52 Nayan Deshmukh 
> wrote:
>
>> In case of prime when rendering is done on GPU other then the
>> server GPU, use a seprate linear buffer for each back buffer
>> which will be displayed using present extension.
>>
>> v2: Use a seprate linear buffer for each back buffer (Michel)
>> v3: Change variable names and fix coding style (Leo and Emil)
>> v4: Use PIPE_BIND_SAMPLER_VIEW for back buffer in case when
>> a seprate linear buffer is used (Michel)
>> v4.1: remove empty line
>> v4.2: destroy the context and handle the case when
>>   create_context fails (Emil)
>>
>> Signed-off-by: Nayan Deshmukh 
>> Reviewed-by: Leo Liu 
>> Acked-by: Michel Dänzer 
>> ---
>>  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 66
>> +--
>>  1 file changed, 53 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> index 3d596a6..191a64b 100644
>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> @@ -49,6 +49,7 @@
>>  struct vl_dri3_buffer
>>  {
>> struct pipe_resource *texture;
>> +   struct pipe_resource *linear_texture;
>>
>> uint32_t pixmap;
>> uint32_t sync_fence;
>> @@ -69,6 +70,8 @@ struct vl_dri3_screen
>> xcb_present_event_t eid;
>> xcb_special_event_t *special_event;
>>
>> +   struct pipe_context *pipe;
>> +
>> struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
>> int cur_back;
>>
>> @@ -82,6 +85,7 @@ struct vl_dri3_screen
>> int64_t last_ust, ns_frame, last_msc, next_msc;
>>
>> bool flushed;
>> +   bool is_different_gpu;
>>  };
>>
>>  static void
>> @@ -102,6 +106,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
>> xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
>> xshmfence_unmap_shm(buffer->shm_fence);
>> pipe_resource_reference(&buffer->texture, NULL);
>> +   if (buffer->linear_texture)
>> +   pipe_resource_reference(&buffer->linear_texture, NULL);
>> FREE(buffer);
>>  }
>>
>> @@ -209,7 +215,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>> xcb_sync_fence_t sync_fence;
>> struct xshmfence *shm_fence;
>> int buffer_fd, fence_fd;
>> -   struct pipe_resource templ;
>> +   struct pipe_resource templ, *pixmap_buffer_texture;
>> struct winsys_handle whandle;
>> unsigned usage;
>>
>> @@ -226,8 +232,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>>goto close_fd;
>>
>> memset(&templ, 0, sizeof(templ));
>> -   templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW |
>> -PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
>> +   templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
>> templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
>> templ.target = PIPE_TEXTURE_2D;
>> templ.last_level = 0;
>> @@ -235,16 +240,34 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>> templ.height0 = scrn->height;
>> templ.depth0 = 1;
>> templ.array_size = 1;
>> -   buffer->texture = scrn->base.pscreen->resource_
>> create(scrn->base.pscreen,
>> - &templ);
>> -   if (!buffer->texture)
>> -  goto unmap_shm;
>>
>> +   if (scrn->is_different_gpu) {
>> +  buffer->texture = scrn->base.pscreen->resource_
>> create(scrn->base.pscreen,
>> +&templ);
>> +  if (!buffer->texture)
>> + goto unmap_shm;
>> +
>> +  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED |
>> +PIPE_BIND_LINEAR;
>> +  buffer->linear_texture = scrn->base.pscreen->resource_
>> create(scrn->base.pscreen,
>> +
>> &templ);
>> +  pixmap_buffer_texture = buffer->linear_texture;
>> +
>> +  if (!buffer->linear_texture)
>> + goto no_linear_texture;
>> +   } else {
>> +  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
>> +  buffer->texture = scrn->base.pscreen->resource_
>> create(scrn->base.pscreen,
>> +&templ);
>> +  if (!buffer->texture)
>> + goto unmap_shm;
>> +  pixmap_buffer_texture = buffer->texture;
>> +   }
>> memset(&whandle, 0, sizeof(whandle));
>> whandle.type= DRM_API_HANDLE_TYPE_FD;
>> usage = PIPE_HANDLE_USAGE_EXPLICIT_FLUSH | PIPE

Re: [Mesa-dev] [PATCH 1/3] vl/dri3: handle the case of different GPU(v4.2)

[Mike Lothian]

Hi

I've just confirmed this works for getting details from vainfo and
vdpauinfo using DRI_PRIME=1 without needing to set up offloading with xrandr

I do however need to specify the driver still, is that something being
worked on? It would be great if it autoselected based on the card running
at DRI_PRIME=1 (or x if there's more than one card)

Cheers

Mike

On Tue, 20 Sep 2016 at 05:52 Nayan Deshmukh 
wrote:

> In case of prime when rendering is done on GPU other then the
> server GPU, use a seprate linear buffer for each back buffer
> which will be displayed using present extension.
>
> v2: Use a seprate linear buffer for each back buffer (Michel)
> v3: Change variable names and fix coding style (Leo and Emil)
> v4: Use PIPE_BIND_SAMPLER_VIEW for back buffer in case when
> a seprate linear buffer is used (Michel)
> v4.1: remove empty line
> v4.2: destroy the context and handle the case when
>   create_context fails (Emil)
>
> Signed-off-by: Nayan Deshmukh 
> Reviewed-by: Leo Liu 
> Acked-by: Michel Dänzer 
> ---
>  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 66
> +--
>  1 file changed, 53 insertions(+), 13 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 3d596a6..191a64b 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -49,6 +49,7 @@
>  struct vl_dri3_buffer
>  {
> struct pipe_resource *texture;
> +   struct pipe_resource *linear_texture;
>
> uint32_t pixmap;
> uint32_t sync_fence;
> @@ -69,6 +70,8 @@ struct vl_dri3_screen
> xcb_present_event_t eid;
> xcb_special_event_t *special_event;
>
> +   struct pipe_context *pipe;
> +
> struct vl_dri3_buffer *back_buffers[BACK_BUFFER_NUM];
> int cur_back;
>
> @@ -82,6 +85,7 @@ struct vl_dri3_screen
> int64_t last_ust, ns_frame, last_msc, next_msc;
>
> bool flushed;
> +   bool is_different_gpu;
>  };
>
>  static void
> @@ -102,6 +106,8 @@ dri3_free_back_buffer(struct vl_dri3_screen *scrn,
> xcb_sync_destroy_fence(scrn->conn, buffer->sync_fence);
> xshmfence_unmap_shm(buffer->shm_fence);
> pipe_resource_reference(&buffer->texture, NULL);
> +   if (buffer->linear_texture)
> +   pipe_resource_reference(&buffer->linear_texture, NULL);
> FREE(buffer);
>  }
>
> @@ -209,7 +215,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> xcb_sync_fence_t sync_fence;
> struct xshmfence *shm_fence;
> int buffer_fd, fence_fd;
> -   struct pipe_resource templ;
> +   struct pipe_resource templ, *pixmap_buffer_texture;
> struct winsys_handle whandle;
> unsigned usage;
>
> @@ -226,8 +232,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>goto close_fd;
>
> memset(&templ, 0, sizeof(templ));
> -   templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW |
> -PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> +   templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> templ.target = PIPE_TEXTURE_2D;
> templ.last_level = 0;
> @@ -235,16 +240,34 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
> templ.height0 = scrn->height;
> templ.depth0 = 1;
> templ.array_size = 1;
> -   buffer->texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> - &templ);
> -   if (!buffer->texture)
> -  goto unmap_shm;
>
> +   if (scrn->is_different_gpu) {
> +  buffer->texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> +&templ);
> +  if (!buffer->texture)
> + goto unmap_shm;
> +
> +  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED |
> +PIPE_BIND_LINEAR;
> +  buffer->linear_texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> +  &templ);
> +  pixmap_buffer_texture = buffer->linear_texture;
> +
> +  if (!buffer->linear_texture)
> + goto no_linear_texture;
> +   } else {
> +  templ.bind |= PIPE_BIND_SCANOUT | PIPE_BIND_SHARED;
> +  buffer->texture =
> scrn->base.pscreen->resource_create(scrn->base.pscreen,
> +&templ);
> +  if (!buffer->texture)
> + goto unmap_shm;
> +  pixmap_buffer_texture = buffer->texture;
> +   }
> memset(&whandle, 0, sizeof(whandle));
> whandle.type= DRM_API_HANDLE_TYPE_FD;
> usage = PIPE_HANDLE_USAGE_EXPLICIT_FLUSH | PIPE_HANDLE_USAGE_READ;
> scrn->base.pscreen->resource_get_handle(scrn->base.pscreen, NULL,
> -   buffer->texture, &whandle,
> +   pixmap_buffer_texture,
> &whandle,
> usage);
> buffer_fd = whandle.handle

[Mesa-dev] st/omx/dec/h265: Correct the timestamping (derived from commit 3b6bda665a5a890f2c98e19d2939d7de92b8cb4c)

[Das, Indrajit-kumar]

From: Indrajit Das 



Reviewed-by: Christian König 

Reviewed-by: Nishanth Peethambaran 
Signed-off-by: Indrajit Das 
---
src/gallium/state_trackers/omx/vid_dec_h265.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/omx/vid_dec_h265.c 
b/src/gallium/state_trackers/omx/vid_dec_h265.c
index 7c0f75d..db20292 100644
--- a/src/gallium/state_trackers/omx/vid_dec_h265.c
+++ b/src/gallium/state_trackers/omx/vid_dec_h265.c
@@ -60,6 +60,7 @@ enum {
struct dpb_list {
struct list_head list;
struct pipe_video_buffer *buffer;
+   OMX_TICKS timestamp;
unsigned poc;
};

@@ -518,6 +519,9 @@ static void vid_dec_h265_BeginFrame(vid_dec_PrivateType 
*priv)
   return;

vid_dec_NeedTarget(priv);
+   if (priv->first_buf_in_frame)
+priv->timestamp = priv->timestamps[0];
+   priv->first_buf_in_frame = false;

if (!priv->codec) {
   struct pipe_video_codec templat = {};
@@ -558,6 +562,8 @@ static struct pipe_video_buffer 
*vid_dec_h265_Flush(vid_dec_PrivateType *priv,
   return NULL;

buf = result->buffer;
+   if (timestamp)
+*timestamp = result->timestamp;

--priv->codec_data.h265.dpb_num;
LIST_DEL(&result->list);
@@ -572,6 +578,7 @@ static void vid_dec_h265_EndFrame(vid_dec_PrivateType *priv)
struct pipe_video_buffer *tmp;
struct ref_pic_set *rps;
int i;
+   OMX_TICKS timestamp;

if (!priv->frame_started)
   return;
@@ -621,7 +628,9 @@ static void vid_dec_h265_EndFrame(vid_dec_PrivateType *priv)
if (!entry)
   return;

+   priv->first_buf_in_frame = true;
entry->buffer = priv->target;
+   entry->timestamp = priv->timestamp;
entry->poc = get_poc(priv);

LIST_ADDTAIL(&entry->list, &priv->codec_data.h265.dpb_list);
@@ -632,7 +641,8 @@ static void vid_dec_h265_EndFrame(vid_dec_PrivateType *priv)
   return;

tmp = priv->in_buffers[0]->pInputPortPrivate;
-   priv->in_buffers[0]->pInputPortPrivate = vid_dec_h265_Flush(priv, NULL);
+   priv->in_buffers[0]->pInputPortPrivate = vid_dec_h265_Flush(priv, 
×tamp);
+   priv->in_buffers[0]->nTimeStamp = timestamp;
priv->target = tmp;
priv->frame_finished = priv->in_buffers[0]->pInputPortPrivate != NULL;
if (priv->frame_finished &&
@@ -894,4 +904,5 @@ void vid_dec_h265_Init(vid_dec_PrivateType *priv)
priv->Decode = vid_dec_h265_Decode;
priv->EndFrame = vid_dec_h265_EndFrame;
priv->Flush = vid_dec_h265_Flush;
+   priv->first_buf_in_frame = true;
}
--
2.7.4

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

Re: [Mesa-dev] [PATCH 3/3] st/va: flush the context before calling flush_frontbuffer(v2)

[Nayan Deshmukh]

Thanks for the push Christian.

Cheers,
Nayan.

On Tue, Sep 20, 2016 at 2:49 PM, Christian König 
wrote:

> I've just pushed this version of the patchset.
>
> Thanks for the help,
> Christian.
>
>
> Am 20.09.2016 um 06:52 schrieb Nayan Deshmukh:
>
>> so that the texture is rendered to back buffer before calling
>> flush_frontbuffer and can be copied to a different buffer in
>> the function
>>
>> v2: change comment style
>>
>> Signed-off-by: Nayan Deshmukh 
>> Reviewed-by: Michel Dänzer 
>> ---
>>   src/gallium/state_trackers/va/surface.c | 6 +-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/state_trackers/va/surface.c
>> b/src/gallium/state_trackers/va/surface.c
>> index 00df69d..115db43 100644
>> --- a/src/gallium/state_trackers/va/surface.c
>> +++ b/src/gallium/state_trackers/va/surface.c
>> @@ -321,10 +321,14 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID
>> surface_id, void* draw, short s
>> return status;
>>  }
>>   +   /* flush before calling flush_frontbuffer so that rendering is
>> flushed
>> +* to back buffer so the texture can be copied in flush_frontbuffer
>> +*/
>> +   drv->pipe->flush(drv->pipe, NULL, 0);
>> +
>>  screen->flush_frontbuffer(screen, tex, 0, 0,
>>vscreen->get_private(vscreen), NULL);
>>   -   drv->pipe->flush(drv->pipe, NULL, 0);
>>pipe_resource_reference(&tex, NULL);
>>  pipe_surface_reference(&surf_draw, NULL);
>>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/va: Make VAAPI_DISABLE_INTERLACE default true

[Julien Isorce]

On 16 September 2016 at 08:43, Christian König 
wrote:

> Am 15.09.2016 um 23:07 schrieb Julien Isorce:
>
>
>
> On 15 September 2016 at 16:02, Leo Liu  wrote:
>
>>
>>
>> On 09/15/2016 10:43 AM, Andy Furniss wrote:
>>
>>> Since bf901a2
>>> st/va: also honors interlaced preference when providing a video format
>>> existing scripts and most use cases will need true.
>>>
>>> Signed-off-by: Andy Furniss 
>>> ---
>>>  src/gallium/state_trackers/va/surface.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/state_trackers/va/surface.c
>>> b/src/gallium/state_trackers/va/surface.c
>>> index 00df69d..e73e17e 100644
>>> --- a/src/gallium/state_trackers/va/surface.c
>>> +++ b/src/gallium/state_trackers/va/surface.c
>>> @@ -43,7 +43,7 @@
>>>
>>>  #include "va_private.h"
>>>
>>> -DEBUG_GET_ONCE_BOOL_OPTION(nointerlace, "VAAPI_DISABLE_INTERLACE",
>>> FALSE);
>>> +DEBUG_GET_ONCE_BOOL_OPTION(nointerlace, "VAAPI_DISABLE_INTERLACE",
>>> TRUE);
>>>
>>
>> Like being mentioned,  It'll still override the preferred interlaced
>> format when this env is not explicitly used.
>>
>> Not sure this will be okay with other case. @Julien?
>>
>
> Hi,
>
> So the problem is that with radeon, PIPE_VIDEO_CAP_SUPPORTS_INTERLACED
> always returns false for encoding
> but can return true for decoding (depending on the chipset and the codec).
> Then when doing transcoding you need all to be non interlaced to avoid
> extra copy/conversion and even a clash. Is it correct ?
>
>
> Yes correct. The decoder supports both interlaced as well as progressive
> memory layout, but the encoder can only handle progressive input.
>
> Interlaced memory layout is needed for things like adaptive deinterlacing
> as well as VDPAU OpenGL interop.
>

> Should debug_get_option_nointerlace() be moved to 
> radeon_video.c::rvid_get_video_param
> ?
>
>
> For the short term that sounds like a good idea to me.
>


Hi @Andy, could you update your patch to move that debug env flag to radeon
?  Thx



> In the mid term we need to better handle this case. E.g. allocate the
> video buffer with the layout the driver reports as preferred, if that
> doesn't match the use case (transcoding, deinterlacing or interop) convert
> as needed.
>

yes, also if the conversion is done in HW that should still acceptable.
But also it should be a way to configure that from gstreamer-vaapi/libva
using VA_SURFACE_ATTRIB_USAGE_HINT_ENCODER /
VA_SURFACE_ATTRIB_USAGE_HINT_VPP_READ maybe ... and catch this flag in
vlVaCreateSurfaces2.


>
>
> Other question:
>
> case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED:
> if (rscreen->family < CHIP_PALM) {
> /* MPEG2 only with shaders and no support for
>interlacing on R6xx style UVD */
> return codec != PIPE_VIDEO_FORMAT_MPEG12 &&
>rscreen->family > CHIP_RV770;
> } else {
> if (u_reduce_video_profile(profile) == PIPE_VIDEO_FORMAT_HEVC)
> return false; //The firmware doesn't support interlaced
> HEVC.
> return true;
> }
> So if instead it would always return false then it will really work on
> hardware for which above code says true ?
>
>
> It would work, but the deinterlacing and interop use case I noted above
> would break.
>
>

> Because my understanding is that for nvidia hardware this is not a
> preference but rather a requirement but I might be wrong.
>
>
> Yes, as far as I know that is correct. AMD hardware can handle both for
> most hardware/profile combinations, even the HEVC limit only applies to a
> certain firmware version IIRC.
>
>
> In any case, with current upstream code and VAAPI_DISABLE_INTERLACE=1 it
> hits "assert(templat->interlaced);" in nouveau_vp3_video_buffer_create.
> If I remove the asset it crashes and can even stall the driver (just wanted
> to check ).
>
>
> Crap, feel free to revert the patch setting it to true by default.
>

It has not been pushed:
https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/state_trackers/va
so still time for @Andy to update his patch.


Cheers
Julien


> Regards,
> Christian.
>
> Cheers
> Julien
>
>
>> Regards,
>> Leo
>>
>>
>>>  #include 
>>>
>>>
>>
>
>
> ___
> mesa-dev mailing 
> listmesa-dev@lists.freedesktop.orghttps://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/3] st/va: Return more useful config attributes

[Christian König]

+if (profile == VAProfileHEVCMain10)
+   value = VA_RT_FORMAT_YUV420_10BPP;
We actually don't support that yet. Main10 profiles dither down the 
10bit output to 8bits before writing it to the VA-API surface at the moment.


Apart from that the set looks good to me,
Christian.

Am 19.09.2016 um 01:09 schrieb Mark Thompson:

---
More chroma formats might be supportable, I've kept this to YUV420 + RGB for 
now.

Also, B-frames might be supported in some configurations?  That could be 
conditional on the GPU being used somehow if necessary.


  src/gallium/state_trackers/va/config.c | 53 --
  1 file changed, 44 insertions(+), 9 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 4052316..c6c5bb1 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -115,16 +115,51 @@ vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile 
profile, VAEntrypoint en

 for (i = 0; i < num_attribs; ++i) {
unsigned int value;
-  switch (attrib_list[i].type) {
-  case VAConfigAttribRTFormat:
- value = VA_RT_FORMAT_YUV420;
- break;
-  case VAConfigAttribRateControl:
- value = VA_RC_CQP | VA_RC_CBR | VA_RC_VBR;
- break;
-  default:
+  if (entrypoint == VAEntrypointVLD) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+if (profile == VAProfileHEVCMain10)
+   value = VA_RT_FORMAT_YUV420_10BPP;
+else
+   value = VA_RT_FORMAT_YUV420;
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else if (entrypoint == VAEntrypointEncSlice) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+if (profile == VAProfileHEVCMain10)
+   value = VA_RT_FORMAT_YUV420_10BPP;
+else
+   value = VA_RT_FORMAT_YUV420;
+break;
+ case VAConfigAttribRateControl:
+value = VA_RC_CQP | VA_RC_CBR | VA_RC_VBR;
+break;
+ case VAConfigAttribEncPackedHeaders:
+value = 0;
+break;
+ case VAConfigAttribEncMaxRefFrames:
+value = 1;
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else if (entrypoint == VAEntrypointVideoProc) {
+ switch (attrib_list[i].type) {
+ case VAConfigAttribRTFormat:
+value = (VA_RT_FORMAT_YUV420 |
+ VA_RT_FORMAT_RGB32);
+break;
+ default:
+value = VA_ATTRIB_NOT_SUPPORTED;
+break;
+ }
+  } else {
   value = VA_ATTRIB_NOT_SUPPORTED;
- break;
}
attrib_list[i].value = value;
 }



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

[Mesa-dev] [Bug 97863] [BXT] Webglc is failing a lot of tests related to extensions, textures, uniforms and more

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97863

--- Comment #3 from Alejandro Piñeiro (freenode IRC: apinheiro) 
 ---
(In reply to Elio from comment #2)
> Forgot to include the website:
> 
> www.khronos.org/registry/webgl/conformance-suites/1.0.3/webgl-conformance-
> tests.html

Some time ago we had a similar bug, but for 1.0.2 conformance test. At that
time only two were failing, and after triaging them, the problem were related
to Chromium exposing shaders with version #130 instead of #100 (the one used in
opengl ES 1.0, that is the one used on WebGL 1.0).

More details here:
https://bugs.freedesktop.org/show_bug.cgi?id=62510#c8

Probably it would be worth to check if Chromium keeps doing that version error.

-- 
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/3] st/va: flush the context before calling flush_frontbuffer(v2)

[Christian König]

I've just pushed this version of the patchset.

Thanks for the help,
Christian.

Am 20.09.2016 um 06:52 schrieb Nayan Deshmukh:

so that the texture is rendered to back buffer before calling
flush_frontbuffer and can be copied to a different buffer in
the function

v2: change comment style

Signed-off-by: Nayan Deshmukh 
Reviewed-by: Michel Dänzer 
---
  src/gallium/state_trackers/va/surface.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 00df69d..115db43 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -321,10 +321,14 @@ vlVaPutSurface(VADriverContextP ctx, VASurfaceID 
surface_id, void* draw, short s
return status;
 }
  
+   /* flush before calling flush_frontbuffer so that rendering is flushed

+* to back buffer so the texture can be copied in flush_frontbuffer
+*/
+   drv->pipe->flush(drv->pipe, NULL, 0);
+
 screen->flush_frontbuffer(screen, tex, 0, 0,
   vscreen->get_private(vscreen), NULL);
  
-   drv->pipe->flush(drv->pipe, NULL, 0);
  
 pipe_resource_reference(&tex, NULL);

 pipe_surface_reference(&surf_draw, NULL);



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

Re: [Mesa-dev] [PATCH v2] st/vdpau: fix argument type to vlVdpOutputSurfaceDMABuf

[Christian König]

Done.

Christian.

Am 20.09.2016 um 08:49 schrieb Nayan Deshmukh:

It hasn't been committed yet.
Ilia, Christian can someone push this.

Regards,
Nayan.

On Thu, Sep 15, 2016 at 12:55 PM, Christian König 
mailto:deathsim...@vodafone.de>> wrote:


Am 15.09.2016 um 01:16 schrieb Ilia Mirkin:

Signed-off-by: Ilia Mirkin mailto:imir...@alum.mit.edu>>


Reviewed-by: Christian König mailto:christian.koe...@amd.com>>.


---

v1 -> v2: adjust typedef in vdpau_dmabuf.h, per Nayan

  src/gallium/include/state_tracker/vdpau_dmabuf.h | 2 +-
  src/gallium/state_trackers/vdpau/output.c   | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/state_tracker/vdpau_dmabuf.h
b/src/gallium/include/state_tracker/vdpau_dmabuf.h
index 886c344..f838c92 100644
--- a/src/gallium/include/state_tracker/vdpau_dmabuf.h
+++ b/src/gallium/include/state_tracker/vdpau_dmabuf.h
@@ -87,7 +87,7 @@ typedef VdpStatus VdpVideoSurfaceDMABuf(
  );
typedef VdpStatus VdpOutputSurfaceDMABuf(
-   VdpVideoSurface   surface,
+   VdpOutputSurface  surface,
 struct VdpSurfaceDMABufDesc * result
  );
  diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index 85751ea..f4d62a3 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -773,7 +773,7 @@ struct pipe_resource
*vlVdpOutputSurfaceGallium(VdpOutputSurface surface)
 return vlsurface->surface->texture;
  }
  -VdpStatus vlVdpOutputSurfaceDMABuf(VdpVideoSurface surface,
+VdpStatus vlVdpOutputSurfaceDMABuf(VdpOutputSurface surface,
 struct
VdpSurfaceDMABufDesc *result)
  {
 vlVdpOutputSurface *vlsurface;






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

Re: [Mesa-dev] [PATCH v3 0/3] Make eglExportDMABUFImageMESA return corresponding offset.

[Weng, Chuanbo]

Hi Emil,
What you mentioned about style issue in last round is:
Please move the variable declaration in local scope and add 
space between ){
I think I have fixed these issue in this version. Maybe I have 
misunderstood your meaning. Do you expect
the style like this:

struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_image *dri2_img = dri2_egl_image(img);
EGLint img_offset = 0;

(void) drv;

Or this style (put the variable declaration at the beginning of local 
scope):

if (offsets) {
EGLint img_offset = 0;
offsets[0] = 0;


Thanks,
Chuanbo Weng


-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com] 
Sent: Tuesday, September 20, 2016 5:13 AM
To: Jason Ekstrand 
Cc: Weng, Chuanbo ; Nicolai Hähnle 
; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH v3 0/3] Make eglExportDMABUFImageMESA return 
corresponding offset.

On 19 September 2016 at 16:38, Jason Ekstrand  wrote:
> It all looks fine to me.  Feel free to add a
>
> Reviewed-by: Jason Ekstrand 
>
> That said, my knowledge of the details of the DRI vfuncs is very 
> limited so I'd like to see Emil or Axel sign off on it too, especially 
> since they were the ones who had all the comments.
>
Thanks for double-checking Jason.

Afaics patches have a few outstanding style issues (mentioned last round), but 
I'll squash those just before committing tomorrow morning.

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