Re: [Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

2017-08-12 Thread Leo Liu

Where is the patch 1?


On 08/12/2017 12:07 PM, Gurkirpal Singh wrote:

Coexist with --enable-omx so they can be built independently
Detect tizonia package config file
Generate libomxtiz_mesa.so and install it to libtizcore.pc::pluginsdir
Only compile empty source (target.c) for now.

v2: Show error message when --enable-omx is used (Christian)
 Use single PKG_CHECK_MODULES for omx_tizonia checks (Emil)
 Use spaces instead of tabs
 Add checks around omx-tizonia

GSoC Project link: 
https://summerofcode.withgoogle.com/projects/#4737166321123328

Signed-off-by: Gurkirpal Singh 
Reviewed-and-Tested-by: Julien Isorce 
---
  configure.ac| 40 ++-
  src/gallium/Makefile.am |  4 ++
  src/gallium/targets/omx-tizonia/Makefile.am | 77 +
  src/gallium/targets/omx-tizonia/omx.sym | 11 +
  src/gallium/targets/omx-tizonia/target.c|  2 +
  5 files changed, 132 insertions(+), 2 deletions(-)
  create mode 100644 src/gallium/targets/omx-tizonia/Makefile.am
  create mode 100644 src/gallium/targets/omx-tizonia/omx.sym
  create mode 100644 src/gallium/targets/omx-tizonia/target.c

diff --git a/configure.ac b/configure.ac
index 38af96a..5669695 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,6 +85,7 @@ dnl Versions for external dependencies
  DRI2PROTO_REQUIRED=2.8
  GLPROTO_REQUIRED=1.4.14
  LIBOMXIL_BELLAGIO_REQUIRED=0.0
+LIBOMXIL_TIZONIA_REQUIRED=0.9.0
  LIBVA_REQUIRED=0.38.0
  VDPAU_REQUIRED=1.1
  WAYLAND_REQUIRED=1.11
@@ -1216,14 +1217,19 @@ AC_ARG_ENABLE([vdpau],
 [enable_vdpau=auto])
  AC_ARG_ENABLE([omx],
 [AS_HELP_STRING([--enable-omx],
- [DEPRECATED: Use --enable-omx-bellagio instead 
@<:@default=auto@:>@])],
-   [AC_MSG_ERROR([--enable-omx is deprecated. Use --enable-omx-bellagio 
instead.])],


Is this in patch 1?


+ [DEPRECATED: Use --enable-omx-bellagio or --enable-omx-tizonia instead 
@<:@default=auto@:>@])],
+   [AC_MSG_ERROR([--enable-omx is deprecated. Use --enable-omx-bellagio or 
--enable-omx-tizonia instead.])],
 [])
  AC_ARG_ENABLE([omx-bellagio],
 [AS_HELP_STRING([--enable-omx-bellagio],
   [enable OpenMAX Bellagio library @<:@default=disabled@:>@])],
 [enable_omx_bellagio="$enableval"],
 [enable_omx_bellagio=no])
+AC_ARG_ENABLE([omx-tizonia],
+   [AS_HELP_STRING([--enable-omx-tizonia],
+ [enable OpenMAX Tizonia library @<:@default=disabled@:>@])],
+   [enable_omx_tizonia="$enableval"],
+   [enable_omx_tizonia=no])
  AC_ARG_ENABLE([va],
 [AS_HELP_STRING([--enable-va],
   [enable va library @<:@default=auto@:>@])],
@@ -1275,6 +1281,7 @@ if test "x$enable_opengl" = xno -a \
  "x$enable_xvmc" = xno -a \
  "x$enable_vdpau" = xno -a \
  "x$enable_omx_bellagio" = xno -a \
+"x$enable_omx_tizonia" = xno -a \
  "x$enable_va" = xno -a \
  "x$enable_opencl" = xno; then
  AC_MSG_ERROR([at least one API should be enabled])
@@ -2121,6 +2128,10 @@ if test -n "$with_gallium_drivers" -a 
"x$with_gallium_drivers" != xswrast; then
  PKG_CHECK_EXISTS([libomxil-bellagio >= $LIBOMXIL_BELLAGIO_REQUIRED], 
[enable_omx_bellagio=yes], [enable_omx_bellagio=no])
  fi
  
+if test "x$enable_omx_tizonia" = xauto -a "x$have_omx_platform" = xyes; then

+   PKG_CHECK_EXISTS([libtizonia >= $LIBOMXIL_TIZONIA_REQUIRED], 
[enable_omx_tizonia=yes], [enable_omx_tizonia=no])
+fi
+
  if test "x$enable_va" = xauto -a "x$have_va_platform" = xyes; then
  PKG_CHECK_EXISTS([libva >= $LIBVA_REQUIRED], [enable_va=yes], 
[enable_va=no])
  fi
@@ -2130,6 +2141,7 @@ if test "x$enable_dri" = xyes -o \
  "x$enable_xvmc" = xyes -o \
  "x$enable_vdpau" = xyes -o \
  "x$enable_omx_bellagio" = xyes -o \
+"x$enable_omx_tizonia" = xyes -o \
  "x$enable_va" = xyes; then
  need_gallium_vl=yes
  fi
@@ -2138,6 +2150,7 @@ AM_CONDITIONAL(NEED_GALLIUM_VL, test "x$need_gallium_vl" 
= xyes)
  if test "x$enable_xvmc" = xyes -o \
  "x$enable_vdpau" = xyes -o \
  "x$enable_omx_bellagio" = xyes -o \
+"x$enable_omx_tizonia" = xyes -o \
  "x$enable_va" = xyes; then
  PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
  need_gallium_vl_winsys=yes
@@ -2172,6 +2185,18 @@ if test "x$enable_omx_bellagio" = xyes; then
  fi
  AM_CONDITIONAL(HAVE_ST_OMX_BELLAGIO, test "x$enable_omx_bellagio" = xyes)
  
+if test "x$enable_omx_tizonia" = xyes; then

+if test "x$have_omx_platform" != xyes; then
+AC_MSG_ERROR([OMX requires at least one of the x11 or drm platforms])
+fi
+PKG_CHECK_MODULES([OMX_TIZONIA],
+  [libtizonia >= $LIBOMXIL_TIZONIA_REQUIRED
+   tizilheaders >= $LIBOMXIL_TIZONIA_REQUIRED
+   libtizplatform >= $LIBOMXIL_TIZONIA_REQUIRED])
+gallium_st="$gallium_st omx_tizonia"
+fi

Re: [Mesa-dev] [PATCH v2 1/1] clover: Wait for requested operation if blocking flag is set

2017-08-12 Thread Francisco Jerez
Jan Vesely  writes:

> On Sat, 2017-08-05 at 12:34 -0700, Francisco Jerez wrote:
>> Francisco Jerez  writes:
>> 
>> > Jan Vesely  writes:
>> > 
>> > > Hi,
>> > > 
>> > > thanks for detailed explanation. I indeed missed the writeBuffer part
>> > > in specs.
>> > > 
>> > > On Wed, 2017-08-02 at 15:05 -0700, Francisco Jerez wrote:
>> > > > These changes are somewhat redundant and potentially
>> > > > performance-impacting, the reason is that in the OpenCL API,
>> > > > clEnqueueWrite* commands are specified to block until the memory
>> > > > provided by the application as origin can be reused safely (i.e. until
>> > > > soft_copy_op()() runs), not necessarily until the transfer to graphics
>> > > > memory has completed (which is what hard_event::wait() will wait for).
>> > > > OTOH reads and maps as implemented by soft_copy_op and friends are
>> > > > essentially blocking so the wait() call is redundant in most cases.
>> > > 
>> > > That explains a noticeable slowdown running piglit with these changes.
>> > > I'm not sure about the read part though. I expected it to be basically
>> > > a noop, but it changes behaviour.
>> > 
>> > I think this change would have slowed you down the most whenever the
>> > mapping operation performed by soft_copy_op() is able to proceed
>> > immediately, either because the buffer is idle (so the driver doesn't
>> > stall on transfer_map()) *or* because the driver is trying to be smart
>> > and creates a bounce buffer where data can be copied into immediately
>> > without stalling, then inserts a pipelined GPU copy from the bounce
>> > buffer into the real buffer.  With this patch you will stall on the GPU
>> > copy regardless (and whatever other work was already on the command
>> > stream which might be substantial), even though it wouldn't have been
>> > necessary in any of these cases.
>> > 
>> > > Adding clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS) after a
>> > > blocking read in one of the piglit tests surprisingly returns
>> > > CL_QUEUED.
>> > > 
>> > 
>> > Hmm, yeah, that seems kind of debatable behaviour, although it's
>> > definitely legit for writes, not quite sure for reads...  I believe the
>> > reason why that happens is because the CPU copy proceeds very quickly
>> > (due to the reasons mentioned in the last paragraph), but the hard_event
>> > is still associated with a pipe_fence synchronous with the GPU's command
>> > stream, so it won't get signalled until the GPU catches up.
>
> Hi,
> sorry for the delay, last week was submission week...
>

No worries.

> The part that I'm still missing is what kind of GPU work needs to be
> done after clEnqueueRead*(). I assume all necessary work is completed
> before I can access the data.
> Also CL_QUEUED status was surprising. since we performed at least some
> of the work (we got the data), I'd expect CL_RUNNING or CL_SUBMITTED at
> least.
>

The lag is not due to GPU work that needs to be performed after the
clEnqueueRead call, but due to GPU work that may precede it in the
command stream: Because clover doesn't know when the last time was that
the buffer was referenced by GPU work, the event is associated with a
fence synchronous with the current batch (which obviously won't signal
before any of the GPU work that actually referenced the buffer
completes).  However the pipe driver has a more accurate idea of when
the buffer was used last, so the transfer_map() operation is likely to
complete more quickly than the CL event status changes to CL_COMPLETE.
The reason you're seeing CL_QUEUED rather than CL_SUBMITTED is because
the read operation didn't even need to flush the current batch, so
there's no fence associated with the CL event object yet.

>> > 
>> > > The specs don't mention use of events with blocking read, but it does
>> > > say that "When the read command has completed, the contents of the
>> > > buffer that ptr points to can be used by the application." in the non-
>> > > blocking section. I'd say that the expectation is for the event to be
>> > > CL_COMPLETE after blocking read (at least beignet/pocl/intel-cpu-sdk
>> > > follow this).
>> > > 
>> > > > 
>> > > > The only reason why it might be useful to behave differently on 
>> > > > blocking
>> > > > transfers is that the application may have specified a user event in 
>> > > > the
>> > > > event dependency list, which may cause the soft_copy_op() call to be
>> > > > delayed until the application signals the user event.  In order to fix
>> > > > that it should really only be necessary to wait for the event action to
>> > > > be executed, not necessarily its associated GPU work.
>> > > 
>> > > I think that another use is that non-blocking writes do not create an
>> > > extra copy of the buffer. Thus
>> > > clEnqueueWriteBuffer(...,cl_false, ev, ...)
>> > > clWaitForEvents(ev)
>> > > is more memory efficient.
>> > > 
>> > > > 
>> > > > Last time this issue came up (yeah it's not the 

Re: [Mesa-dev] [PATCH v2 1/1] clover: Wait for requested operation if blocking flag is set

2017-08-12 Thread Jan Vesely
On Sat, 2017-08-05 at 12:34 -0700, Francisco Jerez wrote:
> Francisco Jerez  writes:
> 
> > Jan Vesely  writes:
> > 
> > > Hi,
> > > 
> > > thanks for detailed explanation. I indeed missed the writeBuffer part
> > > in specs.
> > > 
> > > On Wed, 2017-08-02 at 15:05 -0700, Francisco Jerez wrote:
> > > > These changes are somewhat redundant and potentially
> > > > performance-impacting, the reason is that in the OpenCL API,
> > > > clEnqueueWrite* commands are specified to block until the memory
> > > > provided by the application as origin can be reused safely (i.e. until
> > > > soft_copy_op()() runs), not necessarily until the transfer to graphics
> > > > memory has completed (which is what hard_event::wait() will wait for).
> > > > OTOH reads and maps as implemented by soft_copy_op and friends are
> > > > essentially blocking so the wait() call is redundant in most cases.
> > > 
> > > That explains a noticeable slowdown running piglit with these changes.
> > > I'm not sure about the read part though. I expected it to be basically
> > > a noop, but it changes behaviour.
> > 
> > I think this change would have slowed you down the most whenever the
> > mapping operation performed by soft_copy_op() is able to proceed
> > immediately, either because the buffer is idle (so the driver doesn't
> > stall on transfer_map()) *or* because the driver is trying to be smart
> > and creates a bounce buffer where data can be copied into immediately
> > without stalling, then inserts a pipelined GPU copy from the bounce
> > buffer into the real buffer.  With this patch you will stall on the GPU
> > copy regardless (and whatever other work was already on the command
> > stream which might be substantial), even though it wouldn't have been
> > necessary in any of these cases.
> > 
> > > Adding clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS) after a
> > > blocking read in one of the piglit tests surprisingly returns
> > > CL_QUEUED.
> > > 
> > 
> > Hmm, yeah, that seems kind of debatable behaviour, although it's
> > definitely legit for writes, not quite sure for reads...  I believe the
> > reason why that happens is because the CPU copy proceeds very quickly
> > (due to the reasons mentioned in the last paragraph), but the hard_event
> > is still associated with a pipe_fence synchronous with the GPU's command
> > stream, so it won't get signalled until the GPU catches up.

Hi,
sorry for the delay, last week was submission week...

The part that I'm still missing is what kind of GPU work needs to be
done after clEnqueueRead*(). I assume all necessary work is completed
before I can access the data.
Also CL_QUEUED status was surprising. since we performed at least some
of the work (we got the data), I'd expect CL_RUNNING or CL_SUBMITTED at
least.

> > 
> > > The specs don't mention use of events with blocking read, but it does
> > > say that "When the read command has completed, the contents of the
> > > buffer that ptr points to can be used by the application." in the non-
> > > blocking section. I'd say that the expectation is for the event to be
> > > CL_COMPLETE after blocking read (at least beignet/pocl/intel-cpu-sdk
> > > follow this).
> > > 
> > > > 
> > > > The only reason why it might be useful to behave differently on blocking
> > > > transfers is that the application may have specified a user event in the
> > > > event dependency list, which may cause the soft_copy_op() call to be
> > > > delayed until the application signals the user event.  In order to fix
> > > > that it should really only be necessary to wait for the event action to
> > > > be executed, not necessarily its associated GPU work.
> > > 
> > > I think that another use is that non-blocking writes do not create an
> > > extra copy of the buffer. Thus
> > > clEnqueueWriteBuffer(...,cl_false, ev, ...)
> > > clWaitForEvents(ev)
> > > is more memory efficient.
> > > 
> > > > 
> > > > Last time this issue came up (yeah it's not the first time) I proposed
> > > > the patches below to add a mechanism to wait for the event action only,
> > > > feel free to include it as PATCH 0.1 and 0.2 of this series (it's been a
> > > > while so they may no longer apply cleanly).
> > > 
> > > I think we can just add comments explaining why the blocking argument
> > > is ignored, until someone chooses to fix this problem
> > 
> > I think the problem is definitely worth fixing, and it shouldn't really
> > take more effort than adding comments explaining the current behaviour
> > ;), basically just add a bunch of 'if (blocking)
> > hev().wait_signalled();' where the spec requires it, roughly as you had
> > been doing in this patch, but wait_signalled() should only stall on the
> > CPU work associated with the event, which should give you the same
> > performance as the current approach.

I can send a patch that replaces wait() -> wait_signalled()

> > 
> > > and/or to
> > > implement proper non-blocking variants (would 

Re: [Mesa-dev] [Nouveau] [PATCH] nvc0/ir: propagate immediates to CALL input MOVs

2017-08-12 Thread Ilia Mirkin
On Sat, Aug 12, 2017 at 3:33 PM, Tobias Klausmann
 wrote:
> On using builtin functions we have to move the input to registers $0 and $1, 
> if
> one of the input value is an immediate, we fail to propagate the immediate:
>
> ...
> mov u32 $r477 0x0003 (0)
> ...
> mov u32 $r0 %r473 (0)
> mov u32 $r1 $r477 (0)
> call abs BUILTIN:0 (0)
> mov u32 %r495 $r1 (0)
> ...
>
> With this patch the immediate is propagated, potentially causing the first MOV
> to be superfluous, which we'd remove in that case:
>
> ...
>
> mov u32 $r0 %r473 (0)
> mov u32 $r1 0x0003 (0)
> call abs BUILTIN:0 (0)
> mov u32 %r495 $r1 (0)
> ...
>
> Shaderdb stats:
> total instructions in shared programs : 4893460 -> 4893324 (-0.00%)
> total gprs used in shared programs: 582972 -> 582881 (-0.02%)
> total local used in shared programs   : 17960 -> 17960 (0.00%)
>
> localgpr   inst  bytes
> helped   0  91 112 112
>   hurt   0   0   0   0
>
> Signed-off-by: Tobias Klausmann 
> ---
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp   | 21 
> +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index c8f0701572..861d08af24 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -47,8 +47,25 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
> int builtin;
>
> bld.setPosition(i, false);
> -   bld.mkMovToReg(0, i->getSrc(0));
> -   bld.mkMovToReg(1, i->getSrc(1));
> +
> +   // Generate movs to the input regs for the call we want to generate
> +   for (int s = 0; i->srcExists(s); ++s) {
> +  Instruction *ld = i->getSrc(s)->getInsn();
> +  ImmediateValue imm;
> +  // check if we are moving an immediate, propagate it in that case
> +  if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
> +!ld->src(0).getImmediate(imm))

At this point you don't even have to use getImmediate - you can just
look at ld->src(0).getFile() == FILE_IMMEDIATE.

Normally you'd just do i->src(s).getImmediate(imm) and moved on with
life. But you kinda need the ld here, which is annoying. Perhaps you
can just drop the manual deletion of the op here... which would let
you do the much simpler thing. Can you see if there's any effect from
that?

> + bld.mkMovToReg(s, i->getSrc(s));
> +  else {
> + bld.mkMovToReg(s, ld->getSrc(0));
> + // Clear the src, to make code elimination possible here before we
> + // delete the instruction i later
> + i->setSrc(s, NULL);

i gets deleted later on. move the deletion of ld after that happens?

> + if (ld->getDef(0)->refCount() == 0)

ld->isDead()

> +delete_Instruction(prog, ld);
> +  }
> +   }
> +
> switch (i->dType) {
> case TYPE_U32: builtin = NVC0_BUILTIN_DIV_U32; break;
> case TYPE_S32: builtin = NVC0_BUILTIN_DIV_S32; break;
> --
> 2.14.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] nvc0/ir: propagate immediates to CALL input MOVs

2017-08-12 Thread Tobias Klausmann
On using builtin functions we have to move the input to registers $0 and $1, if
one of the input value is an immediate, we fail to propagate the immediate:

...
mov u32 $r477 0x0003 (0)
...
mov u32 $r0 %r473 (0)
mov u32 $r1 $r477 (0)
call abs BUILTIN:0 (0)
mov u32 %r495 $r1 (0)
...

With this patch the immediate is propagated, potentially causing the first MOV
to be superfluous, which we'd remove in that case:

...

mov u32 $r0 %r473 (0)
mov u32 $r1 0x0003 (0)
call abs BUILTIN:0 (0)
mov u32 %r495 $r1 (0)
...

Shaderdb stats:
total instructions in shared programs : 4893460 -> 4893324 (-0.00%)
total gprs used in shared programs: 582972 -> 582881 (-0.02%)
total local used in shared programs   : 17960 -> 17960 (0.00%)

localgpr   inst  bytes
helped   0  91 112 112
  hurt   0   0   0   0

Signed-off-by: Tobias Klausmann 
---
 .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp   | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index c8f0701572..861d08af24 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -47,8 +47,25 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
int builtin;
 
bld.setPosition(i, false);
-   bld.mkMovToReg(0, i->getSrc(0));
-   bld.mkMovToReg(1, i->getSrc(1));
+
+   // Generate movs to the input regs for the call we want to generate
+   for (int s = 0; i->srcExists(s); ++s) {
+  Instruction *ld = i->getSrc(s)->getInsn();
+  ImmediateValue imm;
+  // check if we are moving an immediate, propagate it in that case
+  if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
+!ld->src(0).getImmediate(imm))
+ bld.mkMovToReg(s, i->getSrc(s));
+  else {
+ bld.mkMovToReg(s, ld->getSrc(0));
+ // Clear the src, to make code elimination possible here before we
+ // delete the instruction i later
+ i->setSrc(s, NULL);
+ if (ld->getDef(0)->refCount() == 0)
+delete_Instruction(prog, ld);
+  }
+   }
+
switch (i->dType) {
case TYPE_U32: builtin = NVC0_BUILTIN_DIV_U32; break;
case TYPE_S32: builtin = NVC0_BUILTIN_DIV_S32; break;
-- 
2.14.0

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


[Mesa-dev] [PATCH v2] nv50/ir: clean up saturated values immediately

2017-08-12 Thread Ilia Mirkin
Since we don't iterate to a fixed point, we can end up in situations
where we have a SAT instruction + a long immediate. This is not legal.
However since it's immediately computable, just run unary straight away
to handle the situation.

Fixes: 24a799ad35a82 ("nv50/ir: fix ConstantFolding with saturation")
Reported-by: Tobias Klausmann 
Signed-off-by: Ilia Mirkin 
---

v1 -> v2:
  use the more complete getImmediate() when we don't know for sure that
  the argument is an actual ImmediateValue, to pick up potential additional
  cases.

 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index cfc0dfc53cf..7e4e193e3d2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -727,7 +727,9 @@ ConstantFolding::expr(Instruction *i,
   // Leave PFETCH alone... we just folded its 2 args into 1.
   break;
default:
-  i->op = i->saturate ? OP_SAT : OP_MOV; /* SAT handled by unary() */
+  i->op = i->saturate ? OP_SAT : OP_MOV;
+  if (i->saturate)
+ unary(i, *i->getSrc(0)->asImm());
   break;
}
i->subOp = 0;
@@ -1513,8 +1515,11 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
, int s)
// This can get left behind some of the optimizations which simplify
// saturatable values.
if (newi->op == OP_MOV && newi->saturate) {
+  ImmediateValue tmp;
   newi->saturate = 0;
   newi->op = OP_SAT;
+  if (newi->src(0).getImmediate(tmp))
+ unary(newi, tmp);
}
 
if (newi->op != op)
-- 
2.13.0

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


[Mesa-dev] [PATCH v2 3/4] st/omx_tizonia: Add entrypoint

2017-08-12 Thread Gurkirpal Singh
Adds common structure for adding components and screen creation

v2: Separate commits for entrypoint and decoder (Christian)
Preserve copyright for copied files (Emil)

Signed-off-by: Gurkirpal Singh 
Reviewed-and-Tested-by: Julien Isorce 
---
 src/gallium/state_trackers/omx_tizonia/Makefile.am |  35 ++
 .../state_trackers/omx_tizonia/Makefile.sources|   3 +
 .../state_trackers/omx_tizonia/entrypoint.c| 120 +
 .../state_trackers/omx_tizonia/entrypoint.h|  38 +++
 4 files changed, 196 insertions(+)
 create mode 100644 src/gallium/state_trackers/omx_tizonia/Makefile.am
 create mode 100644 src/gallium/state_trackers/omx_tizonia/Makefile.sources
 create mode 100644 src/gallium/state_trackers/omx_tizonia/entrypoint.c
 create mode 100644 src/gallium/state_trackers/omx_tizonia/entrypoint.h

diff --git a/src/gallium/state_trackers/omx_tizonia/Makefile.am 
b/src/gallium/state_trackers/omx_tizonia/Makefile.am
new file mode 100644
index 000..932929b
--- /dev/null
+++ b/src/gallium/state_trackers/omx_tizonia/Makefile.am
@@ -0,0 +1,35 @@
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+# NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+include Makefile.sources
+include $(top_srcdir)/src/gallium/Automake.inc
+
+AM_CFLAGS = \
+   $(GALLIUM_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
+   $(VL_CFLAGS) \
+   $(XCB_DRI3_CFLAGS) \
+   $(OMX_TIZONIA_CFLAGS) \
+   $(OMX_TIZILHEADERS_CFLAGS) \
+   $(OMX_TIZPLATFORM_CFLAGS)
+
+noinst_LTLIBRARIES = libomxtiztracker.la
+
+libomxtiztracker_la_SOURCES = $(C_SOURCES)
diff --git a/src/gallium/state_trackers/omx_tizonia/Makefile.sources 
b/src/gallium/state_trackers/omx_tizonia/Makefile.sources
new file mode 100644
index 000..de6fcf9
--- /dev/null
+++ b/src/gallium/state_trackers/omx_tizonia/Makefile.sources
@@ -0,0 +1,3 @@
+C_SOURCES := \
+   entrypoint.c \
+   entrypoint.h
diff --git a/src/gallium/state_trackers/omx_tizonia/entrypoint.c 
b/src/gallium/state_trackers/omx_tizonia/entrypoint.c
new file mode 100644
index 000..8a38707
--- /dev/null
+++ b/src/gallium/state_trackers/omx_tizonia/entrypoint.c
@@ -0,0 +1,120 @@
+/**
+ *
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "os/os_thread.h"
+#include "util/u_memory.h"
+#include "loader/loader.h"
+
+#include "entrypoint.h"
+
+#if defined(HAVE_X11_PLATFORM)
+#include 
+#else
+#define XOpenDisplay(x) NULL
+#define XCloseDisplay(x)
+#define Display void
+#endif
+
+static mtx_t omx_lock = _MTX_INITIALIZER_NP;
+static Display 

[Mesa-dev] [PATCH v2 0/4] gallium/st: Add Tizonia based state tracker

2017-08-12 Thread Gurkirpal Singh
Sending patches in separate thread since I can't see some patches
in reply to the original thread.

Gurkirpal Singh (4):
  st/omx_bellagio: Rename state tracker and option
  st/omx_tizonia: Add --enable-omx-tizonia flag and build files
  st/omx_tizonia: Add entrypoint
  st/omx_tizonia: Add H.264 decoder

 configure.ac   |   85 +-
 src/gallium/Makefile.am|8 +-
 src/gallium/state_trackers/omx/Makefile.am |   35 -
 src/gallium/state_trackers/omx/Makefile.sources|   10 -
 src/gallium/state_trackers/omx/entrypoint.c|  152 --
 src/gallium/state_trackers/omx/entrypoint.h|   48 -
 src/gallium/state_trackers/omx/vid_dec.c   |  665 
 src/gallium/state_trackers/omx/vid_dec.h   |  148 --
 src/gallium/state_trackers/omx/vid_dec_h264.c  | 1032 
 src/gallium/state_trackers/omx/vid_dec_h265.c  | 1013 
 src/gallium/state_trackers/omx/vid_dec_mpeg12.c|  383 -
 src/gallium/state_trackers/omx/vid_enc.c   | 1278 ---
 src/gallium/state_trackers/omx/vid_enc.h   |   96 --
 .../state_trackers/omx_bellagio/Makefile.am|   35 +
 .../state_trackers/omx_bellagio/Makefile.sources   |   10 +
 .../state_trackers/omx_bellagio/entrypoint.c   |  152 ++
 .../state_trackers/omx_bellagio/entrypoint.h   |   48 +
 src/gallium/state_trackers/omx_bellagio/vid_dec.c  |  665 
 src/gallium/state_trackers/omx_bellagio/vid_dec.h  |  148 ++
 .../state_trackers/omx_bellagio/vid_dec_h264.c | 1032 
 .../state_trackers/omx_bellagio/vid_dec_h265.c | 1013 
 .../state_trackers/omx_bellagio/vid_dec_mpeg12.c   |  383 +
 src/gallium/state_trackers/omx_bellagio/vid_enc.c  | 1278 +++
 src/gallium/state_trackers/omx_bellagio/vid_enc.h  |   96 ++
 src/gallium/state_trackers/omx_tizonia/Makefile.am |   35 +
 .../state_trackers/omx_tizonia/Makefile.sources|   12 +
 .../state_trackers/omx_tizonia/entrypoint.c|  162 ++
 .../state_trackers/omx_tizonia/entrypoint.h|   38 +
 src/gallium/state_trackers/omx_tizonia/h264d.c |  173 ++
 src/gallium/state_trackers/omx_tizonia/h264d.h |   57 +
 .../state_trackers/omx_tizonia/h264dinport.c   |  147 ++
 .../state_trackers/omx_tizonia/h264dinport.h   |   31 +
 .../state_trackers/omx_tizonia/h264dinport_decls.h |   48 +
 src/gallium/state_trackers/omx_tizonia/h264dprc.c  | 1711 
 src/gallium/state_trackers/omx_tizonia/h264dprc.h  |   31 +
 .../state_trackers/omx_tizonia/h264dprc_decls.h|  110 ++
 src/gallium/state_trackers/omx_tizonia/names.h |   30 +
 src/gallium/targets/omx-bellagio/Makefile.am   |   75 +
 src/gallium/targets/omx-bellagio/omx.sym   |   11 +
 src/gallium/targets/omx-bellagio/target.c  |2 +
 src/gallium/targets/omx-tizonia/Makefile.am|   77 +
 src/gallium/targets/omx-tizonia/omx.sym|   11 +
 src/gallium/targets/omx-tizonia/target.c   |2 +
 src/gallium/targets/omx/Makefile.am|   75 -
 src/gallium/targets/omx/omx.sym|   11 -
 src/gallium/targets/omx/target.c   |2 -
 46 files changed, 7692 insertions(+), 4972 deletions(-)
 delete mode 100644 src/gallium/state_trackers/omx/Makefile.am
 delete mode 100644 src/gallium/state_trackers/omx/Makefile.sources
 delete mode 100644 src/gallium/state_trackers/omx/entrypoint.c
 delete mode 100644 src/gallium/state_trackers/omx/entrypoint.h
 delete mode 100644 src/gallium/state_trackers/omx/vid_dec.c
 delete mode 100644 src/gallium/state_trackers/omx/vid_dec.h
 delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h264.c
 delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h265.c
 delete mode 100644 src/gallium/state_trackers/omx/vid_dec_mpeg12.c
 delete mode 100644 src/gallium/state_trackers/omx/vid_enc.c
 delete mode 100644 src/gallium/state_trackers/omx/vid_enc.h
 create mode 100644 src/gallium/state_trackers/omx_bellagio/Makefile.am
 create mode 100644 src/gallium/state_trackers/omx_bellagio/Makefile.sources
 create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.c
 create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.h
 create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.c
 create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.h
 create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec_h264.c
 create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec_h265.c
 create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec_mpeg12.c
 create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.c
 create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.h
 create mode 100644 src/gallium/state_trackers/omx_tizonia/Makefile.am
 create mode 100644 src/gallium/state_trackers/omx_tizonia/Makefile.sources
 create mode 100644 

[Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

2017-08-12 Thread Gurkirpal Singh
Coexist with --enable-omx so they can be built independently
Detect tizonia package config file
Generate libomxtiz_mesa.so and install it to libtizcore.pc::pluginsdir
Only compile empty source (target.c) for now.

v2: Show error message when --enable-omx is used (Christian)
Use single PKG_CHECK_MODULES for omx_tizonia checks (Emil)
Use spaces instead of tabs
Add checks around omx-tizonia

GSoC Project link: 
https://summerofcode.withgoogle.com/projects/#4737166321123328

Signed-off-by: Gurkirpal Singh 
Reviewed-and-Tested-by: Julien Isorce 
---
 configure.ac| 40 ++-
 src/gallium/Makefile.am |  4 ++
 src/gallium/targets/omx-tizonia/Makefile.am | 77 +
 src/gallium/targets/omx-tizonia/omx.sym | 11 +
 src/gallium/targets/omx-tizonia/target.c|  2 +
 5 files changed, 132 insertions(+), 2 deletions(-)
 create mode 100644 src/gallium/targets/omx-tizonia/Makefile.am
 create mode 100644 src/gallium/targets/omx-tizonia/omx.sym
 create mode 100644 src/gallium/targets/omx-tizonia/target.c

diff --git a/configure.ac b/configure.ac
index 38af96a..5669695 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,6 +85,7 @@ dnl Versions for external dependencies
 DRI2PROTO_REQUIRED=2.8
 GLPROTO_REQUIRED=1.4.14
 LIBOMXIL_BELLAGIO_REQUIRED=0.0
+LIBOMXIL_TIZONIA_REQUIRED=0.9.0
 LIBVA_REQUIRED=0.38.0
 VDPAU_REQUIRED=1.1
 WAYLAND_REQUIRED=1.11
@@ -1216,14 +1217,19 @@ AC_ARG_ENABLE([vdpau],
[enable_vdpau=auto])
 AC_ARG_ENABLE([omx],
[AS_HELP_STRING([--enable-omx],
- [DEPRECATED: Use --enable-omx-bellagio instead 
@<:@default=auto@:>@])],
-   [AC_MSG_ERROR([--enable-omx is deprecated. Use --enable-omx-bellagio 
instead.])],
+ [DEPRECATED: Use --enable-omx-bellagio or --enable-omx-tizonia 
instead @<:@default=auto@:>@])],
+   [AC_MSG_ERROR([--enable-omx is deprecated. Use --enable-omx-bellagio or 
--enable-omx-tizonia instead.])],
[])
 AC_ARG_ENABLE([omx-bellagio],
[AS_HELP_STRING([--enable-omx-bellagio],
  [enable OpenMAX Bellagio library @<:@default=disabled@:>@])],
[enable_omx_bellagio="$enableval"],
[enable_omx_bellagio=no])
+AC_ARG_ENABLE([omx-tizonia],
+   [AS_HELP_STRING([--enable-omx-tizonia],
+ [enable OpenMAX Tizonia library @<:@default=disabled@:>@])],
+   [enable_omx_tizonia="$enableval"],
+   [enable_omx_tizonia=no])
 AC_ARG_ENABLE([va],
[AS_HELP_STRING([--enable-va],
  [enable va library @<:@default=auto@:>@])],
@@ -1275,6 +1281,7 @@ if test "x$enable_opengl" = xno -a \
 "x$enable_xvmc" = xno -a \
 "x$enable_vdpau" = xno -a \
 "x$enable_omx_bellagio" = xno -a \
+"x$enable_omx_tizonia" = xno -a \
 "x$enable_va" = xno -a \
 "x$enable_opencl" = xno; then
 AC_MSG_ERROR([at least one API should be enabled])
@@ -2121,6 +2128,10 @@ if test -n "$with_gallium_drivers" -a 
"x$with_gallium_drivers" != xswrast; then
 PKG_CHECK_EXISTS([libomxil-bellagio >= $LIBOMXIL_BELLAGIO_REQUIRED], 
[enable_omx_bellagio=yes], [enable_omx_bellagio=no])
 fi
 
+if test "x$enable_omx_tizonia" = xauto -a "x$have_omx_platform" = xyes; 
then
+   PKG_CHECK_EXISTS([libtizonia >= $LIBOMXIL_TIZONIA_REQUIRED], 
[enable_omx_tizonia=yes], [enable_omx_tizonia=no])
+fi
+
 if test "x$enable_va" = xauto -a "x$have_va_platform" = xyes; then
 PKG_CHECK_EXISTS([libva >= $LIBVA_REQUIRED], [enable_va=yes], 
[enable_va=no])
 fi
@@ -2130,6 +2141,7 @@ if test "x$enable_dri" = xyes -o \
 "x$enable_xvmc" = xyes -o \
 "x$enable_vdpau" = xyes -o \
 "x$enable_omx_bellagio" = xyes -o \
+"x$enable_omx_tizonia" = xyes -o \
 "x$enable_va" = xyes; then
 need_gallium_vl=yes
 fi
@@ -2138,6 +2150,7 @@ AM_CONDITIONAL(NEED_GALLIUM_VL, test "x$need_gallium_vl" 
= xyes)
 if test "x$enable_xvmc" = xyes -o \
 "x$enable_vdpau" = xyes -o \
 "x$enable_omx_bellagio" = xyes -o \
+"x$enable_omx_tizonia" = xyes -o \
 "x$enable_va" = xyes; then
 PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
 need_gallium_vl_winsys=yes
@@ -2172,6 +2185,18 @@ if test "x$enable_omx_bellagio" = xyes; then
 fi
 AM_CONDITIONAL(HAVE_ST_OMX_BELLAGIO, test "x$enable_omx_bellagio" = xyes)
 
+if test "x$enable_omx_tizonia" = xyes; then
+if test "x$have_omx_platform" != xyes; then
+AC_MSG_ERROR([OMX requires at least one of the x11 or drm platforms])
+fi
+PKG_CHECK_MODULES([OMX_TIZONIA],
+  [libtizonia >= $LIBOMXIL_TIZONIA_REQUIRED
+   tizilheaders >= $LIBOMXIL_TIZONIA_REQUIRED
+   libtizplatform >= $LIBOMXIL_TIZONIA_REQUIRED])
+gallium_st="$gallium_st omx_tizonia"
+fi
+AM_CONDITIONAL(HAVE_ST_OMX_TIZONIA, test "x$enable_omx_tizonia" = xyes)
+
 if test "x$enable_va" = xyes; then
 if test "x$have_va_platform" != xyes; 

[Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

2017-08-12 Thread Gurkirpal Singh
Coexist with --enable-omx so they can be built independently
Detect tizonia package config file
Generate libomxtiz_mesa.so and install it to libtizcore.pc::pluginsdir
Only compile empty source (target.c) for now.

v2: Show error message when --enable-omx is used (Christian)
Use single PKG_CHECK_MODULES for omx_tizonia checks (Emil)
Use spaces instead of tabs
Add checks around omx-tizonia

GSoC Project link: 
https://summerofcode.withgoogle.com/projects/#4737166321123328

Signed-off-by: Gurkirpal Singh 
Reviewed-and-Tested-by: Julien Isorce 
---
 configure.ac| 40 ++-
 src/gallium/Makefile.am |  4 ++
 src/gallium/targets/omx-tizonia/Makefile.am | 77 +
 src/gallium/targets/omx-tizonia/omx.sym | 11 +
 src/gallium/targets/omx-tizonia/target.c|  2 +
 5 files changed, 132 insertions(+), 2 deletions(-)
 create mode 100644 src/gallium/targets/omx-tizonia/Makefile.am
 create mode 100644 src/gallium/targets/omx-tizonia/omx.sym
 create mode 100644 src/gallium/targets/omx-tizonia/target.c

diff --git a/configure.ac b/configure.ac
index 38af96a..5669695 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,6 +85,7 @@ dnl Versions for external dependencies
 DRI2PROTO_REQUIRED=2.8
 GLPROTO_REQUIRED=1.4.14
 LIBOMXIL_BELLAGIO_REQUIRED=0.0
+LIBOMXIL_TIZONIA_REQUIRED=0.9.0
 LIBVA_REQUIRED=0.38.0
 VDPAU_REQUIRED=1.1
 WAYLAND_REQUIRED=1.11
@@ -1216,14 +1217,19 @@ AC_ARG_ENABLE([vdpau],
[enable_vdpau=auto])
 AC_ARG_ENABLE([omx],
[AS_HELP_STRING([--enable-omx],
- [DEPRECATED: Use --enable-omx-bellagio instead 
@<:@default=auto@:>@])],
-   [AC_MSG_ERROR([--enable-omx is deprecated. Use --enable-omx-bellagio 
instead.])],
+ [DEPRECATED: Use --enable-omx-bellagio or --enable-omx-tizonia 
instead @<:@default=auto@:>@])],
+   [AC_MSG_ERROR([--enable-omx is deprecated. Use --enable-omx-bellagio or 
--enable-omx-tizonia instead.])],
[])
 AC_ARG_ENABLE([omx-bellagio],
[AS_HELP_STRING([--enable-omx-bellagio],
  [enable OpenMAX Bellagio library @<:@default=disabled@:>@])],
[enable_omx_bellagio="$enableval"],
[enable_omx_bellagio=no])
+AC_ARG_ENABLE([omx-tizonia],
+   [AS_HELP_STRING([--enable-omx-tizonia],
+ [enable OpenMAX Tizonia library @<:@default=disabled@:>@])],
+   [enable_omx_tizonia="$enableval"],
+   [enable_omx_tizonia=no])
 AC_ARG_ENABLE([va],
[AS_HELP_STRING([--enable-va],
  [enable va library @<:@default=auto@:>@])],
@@ -1275,6 +1281,7 @@ if test "x$enable_opengl" = xno -a \
 "x$enable_xvmc" = xno -a \
 "x$enable_vdpau" = xno -a \
 "x$enable_omx_bellagio" = xno -a \
+"x$enable_omx_tizonia" = xno -a \
 "x$enable_va" = xno -a \
 "x$enable_opencl" = xno; then
 AC_MSG_ERROR([at least one API should be enabled])
@@ -2121,6 +2128,10 @@ if test -n "$with_gallium_drivers" -a 
"x$with_gallium_drivers" != xswrast; then
 PKG_CHECK_EXISTS([libomxil-bellagio >= $LIBOMXIL_BELLAGIO_REQUIRED], 
[enable_omx_bellagio=yes], [enable_omx_bellagio=no])
 fi
 
+if test "x$enable_omx_tizonia" = xauto -a "x$have_omx_platform" = xyes; 
then
+   PKG_CHECK_EXISTS([libtizonia >= $LIBOMXIL_TIZONIA_REQUIRED], 
[enable_omx_tizonia=yes], [enable_omx_tizonia=no])
+fi
+
 if test "x$enable_va" = xauto -a "x$have_va_platform" = xyes; then
 PKG_CHECK_EXISTS([libva >= $LIBVA_REQUIRED], [enable_va=yes], 
[enable_va=no])
 fi
@@ -2130,6 +2141,7 @@ if test "x$enable_dri" = xyes -o \
 "x$enable_xvmc" = xyes -o \
 "x$enable_vdpau" = xyes -o \
 "x$enable_omx_bellagio" = xyes -o \
+"x$enable_omx_tizonia" = xyes -o \
 "x$enable_va" = xyes; then
 need_gallium_vl=yes
 fi
@@ -2138,6 +2150,7 @@ AM_CONDITIONAL(NEED_GALLIUM_VL, test "x$need_gallium_vl" 
= xyes)
 if test "x$enable_xvmc" = xyes -o \
 "x$enable_vdpau" = xyes -o \
 "x$enable_omx_bellagio" = xyes -o \
+"x$enable_omx_tizonia" = xyes -o \
 "x$enable_va" = xyes; then
 PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
 need_gallium_vl_winsys=yes
@@ -2172,6 +2185,18 @@ if test "x$enable_omx_bellagio" = xyes; then
 fi
 AM_CONDITIONAL(HAVE_ST_OMX_BELLAGIO, test "x$enable_omx_bellagio" = xyes)
 
+if test "x$enable_omx_tizonia" = xyes; then
+if test "x$have_omx_platform" != xyes; then
+AC_MSG_ERROR([OMX requires at least one of the x11 or drm platforms])
+fi
+PKG_CHECK_MODULES([OMX_TIZONIA],
+  [libtizonia >= $LIBOMXIL_TIZONIA_REQUIRED
+   tizilheaders >= $LIBOMXIL_TIZONIA_REQUIRED
+   libtizplatform >= $LIBOMXIL_TIZONIA_REQUIRED])
+gallium_st="$gallium_st omx_tizonia"
+fi
+AM_CONDITIONAL(HAVE_ST_OMX_TIZONIA, test "x$enable_omx_tizonia" = xyes)
+
 if test "x$enable_va" = xyes; then
 if test "x$have_va_platform" != xyes; 

[Mesa-dev] [PATCH v2 3/4] st/omx_tizonia: Add entrypoint

2017-08-12 Thread Gurkirpal Singh
Adds common structure for adding components and screen creation

v2: Separate commits for entrypoint and decoder (Christian)
Preserve copyright for copied files (Emil)

Signed-off-by: Gurkirpal Singh 
Reviewed-and-Tested-by: Julien Isorce 
---
 src/gallium/state_trackers/omx_tizonia/Makefile.am |  35 ++
 .../state_trackers/omx_tizonia/Makefile.sources|   3 +
 .../state_trackers/omx_tizonia/entrypoint.c| 120 +
 .../state_trackers/omx_tizonia/entrypoint.h|  38 +++
 4 files changed, 196 insertions(+)
 create mode 100644 src/gallium/state_trackers/omx_tizonia/Makefile.am
 create mode 100644 src/gallium/state_trackers/omx_tizonia/Makefile.sources
 create mode 100644 src/gallium/state_trackers/omx_tizonia/entrypoint.c
 create mode 100644 src/gallium/state_trackers/omx_tizonia/entrypoint.h

diff --git a/src/gallium/state_trackers/omx_tizonia/Makefile.am 
b/src/gallium/state_trackers/omx_tizonia/Makefile.am
new file mode 100644
index 000..932929b
--- /dev/null
+++ b/src/gallium/state_trackers/omx_tizonia/Makefile.am
@@ -0,0 +1,35 @@
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+# NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+include Makefile.sources
+include $(top_srcdir)/src/gallium/Automake.inc
+
+AM_CFLAGS = \
+   $(GALLIUM_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
+   $(VL_CFLAGS) \
+   $(XCB_DRI3_CFLAGS) \
+   $(OMX_TIZONIA_CFLAGS) \
+   $(OMX_TIZILHEADERS_CFLAGS) \
+   $(OMX_TIZPLATFORM_CFLAGS)
+
+noinst_LTLIBRARIES = libomxtiztracker.la
+
+libomxtiztracker_la_SOURCES = $(C_SOURCES)
diff --git a/src/gallium/state_trackers/omx_tizonia/Makefile.sources 
b/src/gallium/state_trackers/omx_tizonia/Makefile.sources
new file mode 100644
index 000..de6fcf9
--- /dev/null
+++ b/src/gallium/state_trackers/omx_tizonia/Makefile.sources
@@ -0,0 +1,3 @@
+C_SOURCES := \
+   entrypoint.c \
+   entrypoint.h
diff --git a/src/gallium/state_trackers/omx_tizonia/entrypoint.c 
b/src/gallium/state_trackers/omx_tizonia/entrypoint.c
new file mode 100644
index 000..8a38707
--- /dev/null
+++ b/src/gallium/state_trackers/omx_tizonia/entrypoint.c
@@ -0,0 +1,120 @@
+/**
+ *
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "os/os_thread.h"
+#include "util/u_memory.h"
+#include "loader/loader.h"
+
+#include "entrypoint.h"
+
+#if defined(HAVE_X11_PLATFORM)
+#include 
+#else
+#define XOpenDisplay(x) NULL
+#define XCloseDisplay(x)
+#define Display void
+#endif
+
+static mtx_t omx_lock = _MTX_INITIALIZER_NP;
+static Display 

Re: [Mesa-dev] [PATCH 2/2] i965: Guard GetBufferSubData's streaming memcpy load with USE_SSE41

2017-08-12 Thread Kenneth Graunke
On Saturday, August 12, 2017 1:25:25 AM PDT Mauro Rossi wrote:
> On Aug 11, 2017 5:14 PM, "Kenneth Graunke"  wrote:
> 
> On Thursday, August 10, 2017 11:50:30 PM PDT Tapani Pälli wrote:
> > I do wonder what the target machine is (I haven't seen one that would
> > not have ARCH_X86_HAVE_SSE4_1 true, both 32bit and 64bit) but falling
> > back to memcpy makes perfect sense without USE_SSE4_1;
> >
> > Reviewed-by: Tapani Pälli 
> 
> I agree - you really want SSE 4.1 support for decent performance on Atoms.
> The MOVNTDQA texture upload path, for example, gave us some really big
> performance gains on some ChromeOS workloads.
> 
> So, while we should patch this, it'd still be worth figuring out if it's
> possible to enable it in Android-x86.
> 
> --Ken
> 
> 
> Hi,
> 
> I checked on nougat-x86 build 32bit and the patches are Ok.
> 
> The users of android-x86 have the option to build with silvermont.mk and
> later
> to have an optimized build, but we currently try to support SSE3 devices.
> GNU/Linux distributions for desktop, like their kernel, may have that goal
> too.
> 
> Thanks
> M.

Well, right...but we do guard these with runtime checks.  So you should
be able to build in optional SSE 4.1 support but still have such a build
work on SSE3-only hardware...

I'm glad to hear it's an option, at least...

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 2/2] i965: Guard GetBufferSubData's streaming memcpy load with USE_SSE41

2017-08-12 Thread Mauro Rossi
On Aug 11, 2017 5:14 PM, "Kenneth Graunke"  wrote:

On Thursday, August 10, 2017 11:50:30 PM PDT Tapani Pälli wrote:
> I do wonder what the target machine is (I haven't seen one that would
> not have ARCH_X86_HAVE_SSE4_1 true, both 32bit and 64bit) but falling
> back to memcpy makes perfect sense without USE_SSE4_1;
>
> Reviewed-by: Tapani Pälli 

I agree - you really want SSE 4.1 support for decent performance on Atoms.
The MOVNTDQA texture upload path, for example, gave us some really big
performance gains on some ChromeOS workloads.

So, while we should patch this, it'd still be worth figuring out if it's
possible to enable it in Android-x86.

--Ken


Hi,

I checked on nougat-x86 build 32bit and the patches are Ok.

The users of android-x86 have the option to build with silvermont.mk and
later
to have an optimized build, but we currently try to support SSE3 devices.
GNU/Linux distributions for desktop, like their kernel, may have that goal
too.

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


Re: [Mesa-dev] [PATCH] android: amd/common: fix sid_tables.h generation rules

2017-08-12 Thread Mauro Rossi
2017-08-11 20:06 GMT+02:00 Mauro Rossi :
> 2017-08-11 17:25 GMT+02:00 Rob Herring :
>> On Fri, Aug 11, 2017 at 10:10 AM, Mauro Rossi  wrote:
>>> 2017-08-11 16:23 GMT+02:00 Rob Herring :
 On Fri, Aug 11, 2017 at 9:02 AM, Mauro Rossi  wrote:
> Current generation rules rely on LOCAL_PATH variable,
> which may be undefined when dependencies are expanded;
> move to using MESA_TOP variable to define sid_tables.py script path

 I count roughly 67 occurrences of pointing to python scripts using
 LOCAL_PATH. Presumably they all need to be fixed or this isn't really
 the problem.

> Fixes the following building error:
>
> external/mesa/src/gallium/drivers/radeonsi/si_debug.c:30:10: fatal error: 
> 'sid_tables.h' file not found
>  ^
> 1 error generated.
>
> Fixes: 730574c58e "android: amd/common: add support for 
> libmesa_amd_common"

 Why do I not see this error?
>>>
>>>
>>> I was also suprised to see the error,
>>> it started to appear persistently when building nougat-x86 from scratch.
>>>
>>> As a similar case I saw this one:
>>> https://cgit.freedesktop.org/mesa/mesa/commit/?id=c1a29e104cc585ad3219b12d09f532a129d68dad
>>>
>>> and in general I empirically saw it is unsafe to use $(LOCAL_PATH) in
>>> generated files dependencies rules.
>>> Chih-Wei may know better the reason.
>>
>> The discussion on this concluded that LOCAL_PATH as a rule dependency
>> is okay. LOCAL_PATH in the recipe for the rule is not.
>

Hi Rob,

It is as you said, the patch is not necessary

Sorry, I suspect I've been affected by a failing hard drive
M.

>
>>
>>>
>>> Added him in Cc:
>>>
>>> Mauro
>>>
>>> PS: If it is a false positive and not needed in 17.2 and mesa-dev
>>> please Rob, Chih-Wei just tell me,
>>> but in any case 17.1 branch requires to add:
>>>
>>> +LOCAL_STATIC_LIBRARIES := libmesa_amd_common
>>>
>>> in 
>>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/Android.mk?h=17.1
>>
>> Not sure, but probably needed as radeonsi was not in good shape in 17.1.
>>
>> Rob

Now I cross-checked and the additional static dependendency is not needed either
Also mesa-stable can be dropped and does not need changes
M.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev