[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96949

Kenneth Graunke  changed:

   What|Removed |Added

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

--- Comment #3 from Kenneth Graunke  ---
Thanks!  That indeed fixes the regressions.  Pushed as:

commit b89d0df5351eea1f26c6890dcdff7c0e38424ee1
Author: Brian Paul 
Date:   Fri Jul 15 21:22:53 2016 -0600

mesa: handle numSamples=0 in _mesa_test_proxy_teximage()

Should fix the regressions reported in bug 96949.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96949
Reviewed-by: Kenneth Graunke 

-- 
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] mesa: handle numSamples=0 in _mesa_test_proxy_teximage()

2016-07-15 Thread Kenneth Graunke
On Friday, July 15, 2016 9:22:53 PM PDT Brian Paul wrote:
> Should fix the regressions reported in bug 96949.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96949
> ---
>  src/mesa/main/teximage.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 10232d6..d74a45f 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1271,8 +1271,6 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, 
> GLenum target,
>  {
> uint64_t bytes, mbytes;
>  
> -   assert(numSamples > 0);
> -
> if (numLevels > 0) {
>/* Compute total memory for a whole mipmap.  This is the path
> * taken for glTexStorage(GL_PROXY_TEXTURE_x).
> @@ -1306,7 +1304,7 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, 
> GLenum target,
> }
>  
> bytes *= _mesa_num_tex_faces(target);
> -   bytes *= numSamples;
> +   bytes *= MAX2(1, numSamples);
>  
> mbytes = bytes / (1024 * 1024); /* convert to MB */

This looks good to me.  Thanks Brian!

Reviewed-by: Kenneth Graunke 

I'm running it through our test lab now - if it works, I'll push it.

Have a great time next week!


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] mesa: handle numSamples=0 in _mesa_test_proxy_teximage()

2016-07-15 Thread Brian Paul
Should fix the regressions reported in bug 96949.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96949
---
 src/mesa/main/teximage.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 10232d6..d74a45f 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1271,8 +1271,6 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum 
target,
 {
uint64_t bytes, mbytes;
 
-   assert(numSamples > 0);
-
if (numLevels > 0) {
   /* Compute total memory for a whole mipmap.  This is the path
* taken for glTexStorage(GL_PROXY_TEXTURE_x).
@@ -1306,7 +1304,7 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, GLenum 
target,
}
 
bytes *= _mesa_num_tex_faces(target);
-   bytes *= numSamples;
+   bytes *= MAX2(1, numSamples);
 
mbytes = bytes / (1024 * 1024); /* convert to MB */
 
-- 
1.9.1

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


[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96949

--- Comment #2 from Brian Paul  ---
OK, I think the fix is simple.  I posted a patch to mesa-dev.  If it checks out
for you, feel free to push it to master.

-- 
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 96953] dri2_wl_swrast crashes on 64 bit, but not on 32 bit

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96953

--- Comment #1 from n3rdopolis  ---
I can add that this is swrast and wayland, as when I try using qtwayland's x11
backend it works, and when I try 64 bit on Intel with qtwayland it works

-- 
You are receiving this mail because:
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 96953] dri2_wl_swrast crashes on 64 bit, but not on 32 bit

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96953

Bug ID: 96953
   Summary: dri2_wl_swrast crashes on 64 bit, but not on 32 bit
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: EGL/Wayland
  Assignee: wayland-b...@lists.freedesktop.org
  Reporter: bluescreen_aven...@verizon.net
QA Contact: mesa-dev@lists.freedesktop.org

I am not sure if this is because of qtwayland or because of mesa, but it seems
I am getting a crash with git master
I have a stack trace, let me know if running it with any variables exported

I am building mesa with
./autogen.sh --prefix=$INSTALLDIR --enable-driglx-direct --enable-dri
--with-dri-drivers=r200,radeon,nouveau,i915,i965,swrast --enable-osmesa
--enable-xa --enable-glx-tls --enable-shared-dricore --enable-gles1
--enable-gles2 
--with-gallium-drivers=nouveau,svga,r300,r600,swrast,radeonsi,virgl 
--with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi
--enable-gallium-egl --with-llvm-prefix=/usr/lib/llvm-3.6/
--with-llvm-shared-libs --libdir=$INSTALLDIR/lib/$(dpkg-architecture
-qDEB_HOST_MULTIARCH) 

0  dri2_wl_swrast_put_image2 (draw=0x300c240, op=,
x=, y=0, w=, h=0, stride=64,
data=0x3012b40 "", loaderPrivate=0x3012240)
at drivers/dri2/platform_wayland.c:1642
dri2_surf = 0x3012240
copy_width = -4
src = 0x36d4000 
dst = 0x7fffcd4f4ffc 
__PRETTY_FUNCTION__ = "dri2_wl_swrast_put_image2"
#1  0x7fffed28ed26 in dri2_wl_swrast_put_image (
draw=, op=, x=,
y=, w=, h=,
data=0x3012b40 "", loaderPrivate=0x3012240)
at drivers/dri2/platform_wayland.c:1658
dri2_surf = 0x3012240
#2  0x7fffea1bbd38 in put_image (height=,
width=, data=,
dPriv=) at drisw.c:71
sPriv = 
loader = 
#3  drisw_put_image (drawable=, data=,
width=, height=) at drisw.c:141
dPriv = 
#4  0x7fffea1bc1dd in drisw_copy_to_front (ptex=0x300c0d0,
dPriv=0x300c240) at drisw.c:181
No locals.
#5  drisw_swap_buffers (dPriv=0x300c240) at drisw.c:208
ctx = 0x2e2ac20
ptex = 0x300c0d0
#6  0x7fffed28d0b9 in dri2_wl_swrast_swap_buffers (
drv=, disp=, draw=)
at drivers/dri2/platform_wayland.c:1729
No locals.
#7  0x7fffed2839e2 in eglSwapBuffers (dpy=0x710400,
surface=surface@entry=0x3012240) at main/eglapi.c:1008
ctx = 0x2e7ef00
disp = 0x710400
surf = 0x3012240
drv = 
ret = 
__func__ = "eglSwapBuffers"
#8  0x77e57b7a in QtWaylandClient::QWaylandGLContext::swapBuffers
(this=0x2e7eb90, surface=0x2dd1a00)
at
../../../hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp:553
window = 0x2dd19f0
eglSurface = 0x3012240
sub = 0x0
#9  0x76854238 in QOpenGLContext::swapBuffers (
this=this@entry=0x2d91790, surface=surface@entry=0x2dd0650)
at /srcbuild/qtbase/src/gui/kernel/qopenglcontext.cpp:1063
__PRETTY_FUNCTION__ = "void QOpenGLContext::swapBuffers(QSurface*)"
surfaceHandle = 0x2dd1a00
#10 0x769a4c8a in QPlatformBackingStore::composeAndFlush (
this=this@entry=0x2dd1550, window=window@entry=0x2dd0640,
region=..., offset=..., textures=,
context=, translucentBackground=false)
at /srcbuild/qtbase/src/gui/painting/qplatformbackingstore.cpp:414
funcs = 0x3012080
deviceWindowRect = {x1 = 0, y1 = 0, x2 = 1009, y2 = 575}
textureId = 
origin = 
#11 0x769a4d8b in QPlatformBackingStore::composeAndFlush (
this=this@entry=0x2dd1550, window=0x2dd0640, region=...,
offset=...,
textures=textures@entry=0x7745cf40 <(anonymous
namespace)::Q_QGS_qt_dummy_platformTextureList::innerFunction()::holder>,
context=context@entry=0x2d91790, translucentBackground=false)
at /srcbuild/qtbase/src/gui/painting/qplatformbackingstore.cpp:317
No locals.
#12 0x77049590 in QWidgetBackingStore::qt_flush (
widget=widget@entry=0x83d880, region=...,
backingStore=, tlw=0x83d880, tlwOffset=...,
widgetTextures=0x7745cf40 <(anonymous
namespace)::Q_QGS_qt_dummy_platformTextureList::innerFunction()::holder>,
widgetBackingStore=0x2dd1b30)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:138
translucentBackground = false
flushUpdate = 0
fpsDebug = false
__PRETTY_FUNCTION__ = "static void
QWidgetBackingStore::qt_flush(QWidget*, const QRegion&, QBackingStore*,
QWidget*, const QPoint&, QPlatformTextureList*, QWidgetBackingStore*)"
offset = {xp = 0, yp = 0}
compositionWasActive = 
#13 0x77049ed3 in QWidgetBackingStore::flush (
this=this@entry=0x2dd1b30, widget=widget@entry=0x0)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:1415
target = 0x83d880
hasDirtyOnScreenWidgets = false

Re: [Mesa-dev] mesa from git fails to compile

2016-07-15 Thread Dylan Baker
Sorry to not respond earlier, I've apparently been having silent
filesystem corruption for over a week now.

Can you use pip --user to install a newer version of mako locally? mako
0.5 was realeased in late 2011, and not having the output_encoding and
future_imports arguments are going to make hybridizing for python3 very
painful. In the short term I can send a patch that makes it work with
0.5.0, but there may not be a good way in the future to keep
compatibility.

Just FYI, mako 0.8 was released in early 2013, which is what piglit
requires as it's minimum.

On Thu, Jul 14, 2016, at 07:48, Pali Rohár wrote:
> On Thursday 14 July 2016 15:41:51 Eric Engestrom wrote:
> > On Thu, Jul 14, 2016 at 12:24:32PM +0200, Pali Rohár wrote:
> > > Any news? Or possible fix?
> > 
> > Have you tried Emil's suggestion, ie. upgrading to at least 0.8.0?
> 
> No, as I wrote that ubuntu precise for that build has only python-mako
> in version 0.5.0 :-( As ubuntu precise does not have newer version I
> cannot update system package...
> 
> > Build system wizards:
> > Any way to check the version and abort the compilation before running
> > into this issue?  If it helps, this prints the version:
> > python <<< 'import mako; print(mako.__version__)'
> 
> -- 
> Pali Rohár
> pali.ro...@gmail.com
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


-- 
  Dylan Baker
  dy...@pnwbakers.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Required Mako version? (WAS: mesa from git fails to compile)

2016-07-15 Thread Jason Ekstrand
Adding Dylan

On Jul 14, 2016 10:24 PM, "Samuel Iglesias Gonsálvez" 
wrote:

>
>
> On 14/07/16 18:34, Eric Engestrom wrote:
> > On Thu, Jul 14, 2016 at 04:01:13PM +0100, Eric Engestrom wrote:
> >> Oh right, there's already check for the Mako version, but the minimum is
> >> currently set to 0.3.4 (configure.ac:92).
> >>
> >> Emil, you were the one to mention 0.8.0; is that the actual minimum, or
> >> just a known working version?
> >
> > OK, so I did a bit of digging, and the version check was introduced by
> > Samuel Iglesias Gonsalvez a couple years ago (2b37bea0) at 0.7.3, and
> > he later lowered it to 0.3.4 (6d43a4c3), but I can't find any discussion
> > regarding this change: it seems there was none on the mailing list [0].
> >
> > Adding Samuel so he can enlighten us :)
> >
> > [0]
> https://lists.freedesktop.org/archives/mesa-dev/2015-January/074366.html
> >
>
> There was a discussion in the mailing list. Just after I pushed this
> patch to master [0] setting it to 0.7.3 (because that was the version I
> had back then), Dave Airlie mentioned that RHEL6 only ships mako 0.3.4
> [1] and asked if we really need a later version or not. We did some
> tests [2][3] and finally this patch [4] was pushed upstream.
>
> I don't know if we need some feature from mako 0.8.0 to generate
> isl_format_layout because this file was added later than my change,
> probably Emil knows it.
>
> Sam
>
> [0]
> https://lists.freedesktop.org/archives/mesa-dev/2015-January/074000.html
> [1]
> https://lists.freedesktop.org/archives/mesa-dev/2015-January/074283.html
> [2]
> https://lists.freedesktop.org/archives/mesa-dev/2015-January/074287.html
> [3]
> https://lists.freedesktop.org/archives/mesa-dev/2015-January/074332.html
> [4]
> https://lists.freedesktop.org/archives/mesa-dev/2015-January/074366.html
>
>
> ___
> 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 3/3] i915: store reference to the context within struct intel_fence

2016-07-15 Thread Mauro Rossi
Hi,

I'm sending the v2 re-spin of patch as per i965, rechecked twice
line-by-line with Tomasz's one.

Building ok, marshmallow-x86 booting ok and here are the results of Android
CTS egl and gles2 x86 target tests

Android CTS 6.0_r7 build:2906653
07-16 00:52:42 I/DeviceManager: Detected new device 192.168.1.7:
cts-tf > list r
Session Pass   Fail Not Executed  Start time   Plan
name  Device serial(s)
0(EGL)  1410   24   0 2016.07.16_00.21.30  NA
  unknown
1(GLES2)  13832 82   0 2016.07.16_00.24.23  NA
unknown
cts-tf >

I get the same results as per i965GM

Mauro


>From d35c093d48facae4ad0d7119a8b6fdc898a6a1e8 Mon Sep 17 00:00:00 2001
From: Mauro Rossi 
Date: Fri, 15 Jul 2016 21:46:09 +0200
Subject: [PATCH] i915: store reference to the context within struct
 intel_fence (v2)

Porting of the corresponding patch for i965.

Here follows the original commit message by Tomasz Figa:

"As the spec allows for {server,client}_wait_sync to be called without
currently bound context, while our implementation requires context
pointer.

v2: Add a mutex and acquire it for the duration of
brw_fence_client_wait() and brw_fence_is_completed() as suggested
by Chad."

NOTE: in i915 all references to 'brw' are replaced by 'intel'
---
 src/mesa/drivers/dri/i915/intel_syncobj.c | 55
---
 1 file changed, 44 insertions(+), 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/intel_syncobj.c
b/src/mesa/drivers/dri/i915/intel_syncobj.c
index 18d1546..5d37204a 100644
--- a/src/mesa/drivers/dri/i915/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i915/intel_syncobj.c
@@ -46,9 +46,11 @@
 #include "intel_reg.h"

 struct intel_fence {
+   struct intel_context *intel;
/** The fence waits for completion of this batch. */
drm_intel_bo *batch_bo;

+   mtx_t mutex;
bool signalled;
 };

@@ -77,7 +79,7 @@ intel_fence_insert(struct intel_context *intel, struct
intel_fence *fence)
 }

 static bool
-intel_fence_has_completed(struct intel_fence *fence)
+intel_fence_has_completed_locked(struct intel_fence *fence)
 {
if (fence->signalled)
   return true;
@@ -92,13 +94,21 @@ intel_fence_has_completed(struct intel_fence *fence)
return false;
 }

-/**
- * Return true if the function successfully signals or has already
signalled.
- * (This matches the behavior expected from __DRI2fence::client_wait_sync).
- */
 static bool
-intel_fence_client_wait(struct intel_context *intel, struct intel_fence
*fence,
-  uint64_t timeout)
+intel_fence_has_completed(struct intel_fence *fence)
+{
+   bool ret;
+
+   mtx_lock(>mutex);
+   ret = intel_fence_has_completed_locked(fence);
+   mtx_unlock(>mutex);
+
+   return ret;
+}
+
+static bool
+intel_fence_client_wait_locked(struct intel_context *intel, struct
intel_fence *fence,
+ uint64_t timeout)
 {
if (fence->signalled)
   return true;
@@ -123,6 +133,23 @@ intel_fence_client_wait(struct intel_context *intel,
struct intel_fence *fence,
return true;
 }

+/**
+ * Return true if the function successfully signals or has already
signalled.
+ * (This matches the behavior expected from __DRI2fence::client_wait_sync).
+ */
+static bool
+intel_fence_client_wait(struct intel_context *intel, struct intel_fence
*fence,
+  uint64_t timeout)
+{
+   bool ret;
+
+   mtx_lock(>mutex);
+   ret = intel_fence_client_wait_locked(intel, fence, timeout);
+   mtx_unlock(>mutex);
+
+   return ret;
+}
+
 static void
 intel_fence_server_wait(struct intel_context *intel, struct intel_fence
*fence)
 {
@@ -215,6 +242,8 @@ intel_dri_create_fence(__DRIcontext *ctx)
if (!fence)
   return NULL;

+   mtx_init(>mutex, mtx_plain);
+   fence->intel = intel;
intel_fence_insert(intel, fence);

return fence;
@@ -233,19 +262,23 @@ static GLboolean
 intel_dri_client_wait_sync(__DRIcontext *ctx, void *driver_fence, unsigned
flags,
uint64_t timeout)
 {
-   struct intel_context *intel = ctx->driverPrivate;
struct intel_fence *fence = driver_fence;

-   return intel_fence_client_wait(intel, fence, timeout);
+   return intel_fence_client_wait(fence->intel, fence, timeout);
 }

 static void
 intel_dri_server_wait_sync(__DRIcontext *ctx, void *driver_fence, unsigned
flags)
 {
-   struct intel_context *intel = ctx->driverPrivate;
struct intel_fence *fence = driver_fence;

-   intel_fence_server_wait(intel, fence);
+   /* We might be called here with a NULL fence as a result of WaitSyncKHR
+* on a EGL_KHR_reusable_sync fence. Nothing to do here in such case.
+*/
+   if (!fence)
+  return;
+
+   intel_fence_server_wait(fence->intel, fence);
 }

 const __DRI2fenceExtension intelFenceExtension = {
-- 
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96949

Nanley Chery  changed:

   What|Removed |Added

 CC||anuj.pho...@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


Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

2016-07-15 Thread Andy Furniss

Zhang, Boyuan wrote:

Hi Andy,

The memory issue is fixed. Please try the new patch set I just submitted. 
Should NOT have hard lock anymore.


Seems good, no leak and no lock :-)

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


[Mesa-dev] [Bug 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96950

--- Comment #2 from Brian Paul  ---
(In reply to Rob Clark from comment #1)
> Do you still see the issue after 64d35f81 "vbo: fix attr reset"?

Yes.

-- 
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 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96950

--- Comment #1 from Rob Clark  ---
Do you still see the issue after 64d35f81 "vbo: fix attr reset"?

-- 
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 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96950

Rob Clark  changed:

   What|Removed |Added

 CC||robcl...@freedesktop.org

-- 
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 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96950

Brian Paul  changed:

   What|Removed |Added

 CC||mathias.froehl...@web.de

-- 
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 96950] Another regression from bc4e0c486: vbo: Use a bitmask to track the active arrays in vbo_exec*.

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96950

Bug ID: 96950
   Summary: Another regression from bc4e0c486: vbo: Use a bitmask
to track the active arrays in vbo_exec*.
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: bri...@vmware.com
QA Contact: mesa-dev@lists.freedesktop.org

I'm seeing a failed assertion at vbo_exec_api.c:183 that started with commit
bc4e0c486.  It occurs with Redway3D's Turbine demo (I think it's Windows only).

I've taken a quick look but haven't found the cause.  I may take a look in a
week when I'm back from vacation.

-- 
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 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96949

--- Comment #1 from Brian Paul  ---
I'd appreciate it if you could debug this a bit further.  I didn't see any of
those regressions here.

I'm on vacation for the next week so I won't be able to do anything.  Feel free
to revert the patch if you can't debug it.  Thanks.

-- 
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 0/4] RadeonSI: Multithreaded shader compilation

2016-07-15 Thread Marek Olšák
On Wed, Jul 13, 2016 at 10:50 AM, Vedran Miletić  wrote:
> On 07/13/2016 05:19 AM, Timothy Arceri wrote:
>>
>> So I finally got around to setting up my new polaris card on fedora. I
>> was curious to see how Talos performed compared to i965 as I was pretty
>> sure the compiling/linking was not just to do with variants and should
>> be noticable regardless of hardware.
>>
>> The results looks the same to me, there is really bad jerkyness for
>> around 5-10 seconds as you walk when the game first loads from a
>> contine point in the big hall area (the place where you often start a
>> continue from as this is where it auto saves). Obviously these get
>> cached in memory but you see them everytime you start the game and they
>> are very noticable on my machine at least.
>>
>> Anyway obviously up to you what you work on but I don't think an on
>> disk shader cache for radeonsi would be a wasted effort.
>>
>> Tim
>>
>
> Can confirm on Tonga. Very visible in first vs second run of a Benchmark in
> the game; in the first run there is a very long stop (approx 1 second) the
> moment the character picks up the green sigil (and a few other points, I
> would have to check exactly), second run is all smooth.

Those stalls are not so visible while you're playing the game. It's
somehow just more visible during the benchmark.

I'd say the games that would benefit from a persistent shader cache
are in this order:
- Borderlands 2
- Bioshock Infinite
- ???

Not so much Talos Principle unless you are focusing on the benchmark only.

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


Re: [Mesa-dev] [PATCH v4 19/34] i965/state: Add a helper for emitting a surface state using isl

2016-07-15 Thread Jason Ekstrand
On Fri, Jul 15, 2016 at 2:30 PM, Chad Versace 
wrote:

> On Thu 14 Jul 2016, Chad Versace wrote:
> > On Wed 13 Jul 2016, Jason Ekstrand wrote:
> > > Reviewed-by: Topi Pohjolainen 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_state.h|  8 +++
> > >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 79
> 
> > >  2 files changed, 87 insertions(+)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_state.h
> b/src/mesa/drivers/dri/i965/brw_state.h
> > > index a16e876..91ebce9 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_state.h
> > > +++ b/src/mesa/drivers/dri/i965/brw_state.h
> > > @@ -274,6 +274,14 @@ GLuint translate_tex_format(struct brw_context
> *brw,
> > >  int brw_get_texture_swizzle(const struct gl_context *ctx,
> > >  const struct gl_texture_object *t);
> > >
> >
> > Move the forward declaration below to the top of the header. As written,
> > it looks like the function's return type.
>

I'll do one better.  Now that we have an isl_device in brw_context, we
isl.h is included basically globally so there's no need for the forward
declaration. :)


> > > +struct isl_view;
> > > +void brw_emit_surface_state(struct brw_context *brw,
> > > +struct intel_mipmap_tree *mt,
> > > +const struct isl_view *view,
> > > +uint32_t mocs, bool for_gather,
> > > +uint32_t *surf_offset, int surf_index,
> > > +unsigned read_domains, unsigned
> write_domains);
>
> Ping! Unresolved issue^^^
>
> Fix that, and this patch is
> Reviewed-by: Chad Versace 
>

Thanks!


>
> But keep reading...
>
>
>
> > > +   if (aux_surf) {
> > > +  /* On gen7 and prior, the bottom 12 bits of the MCS base
> address are
> > > +   * used to store other information.  This should be ok,
> however, because
> > > +   * surface buffer addresses are always 4K page alinged.
> > > +   */
> >
> > Could you please insert the original comment from gen7_wm_surface_state?
> > Because...
> >
> > > +  assert((aux_offset & 0xfff) == 0);
> > > +  drm_intel_bo_emit_reloc(brw->batch.bo,
> > > +  *surf_offset + 4 * ss_info.aux_reloc_dw,
> > > +  mt->mcs_mt->bo,
> dw[ss_info.aux_reloc_dw] & 0xfff,
> >
> 
> >
> > ...that ^^^ bit of code REALLY confused me until I found the original
> > comment. What's happening is obvious in retrospect, yet terribly obscure
> > without a fuller comment.
>
> I prefer you insert the original comment, or at least some more
> explanation. My r-b stands with or without a comment update.
>

I copied the original comment.  The only change I made was to prefix it
with "on gen7 and prior..."

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


[Mesa-dev] [Bug 96949] [regression] Piglit numSamples assertion failures with 9a23a177b90

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96949

Bug ID: 96949
   Summary: [regression] Piglit numSamples assertion failures with
9a23a177b90
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: nanleych...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org
CC: bri...@vmware.com

With commit 9a23a177b90ea60ba45b8b5090b832c87d595346 ,
 mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()

The 26 piglit tests listed below start failing with the error,

  src/mesa/main/teximage.c:1274: _mesa_test_proxy_teximage: Assertion
`numSamples > 0' failed. 

piglit.spec.arb_texture_view.sampling-2d-array-as-cubemap-array
piglit.spec.arb_texture_view.copytexsubimage-layers
piglit.spec.arb_texture_view.texsubimage-levels pbo
piglit.spec.arb_texture_view.targets
piglit.spec.arb_texture_view.rendering-levels
piglit.spec.arb_texture_view.texsubimage-layers pbo
piglit.spec.arb_texture_view.clear-into-view-layered
piglit.spec.arb_copy_image.arb_copy_image-texview
piglit.spec.arb_texture_view.cubemap-view
piglit.spec.arb_texture_view.texsubimage-layers
piglit.spec.arb_texture_view.mipgen
piglit.spec.arb_texture_view.max-level
piglit.spec.arb_texture_view.clear-into-view-2d-array
piglit.spec.arb_texture_view.clear-into-view-2d
piglit.spec.arb_texture_view.rendering-formats
piglit.spec.arb_texture_view.sampling-2d-array-as-2d-layer
piglit.spec.arb_texture_view.sampling-2d-array-as-cubemap
piglit.spec.arb_texture_view.lifetime-format
piglit.spec.arb_texture_view.texsubimage-levels
piglit.spec.arb_texture_view.formats
piglit.spec.arb_texture_view.queries
piglit.spec.arb_clear_texture.arb_clear_texture-texview
piglit.spec.arb_texture_view.rendering-layers
piglit.spec.arb_texture_view.getteximage-srgb
piglit.spec.arb_texture_view.rendering-target
piglit.spec.arb_texture_view.params

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


[Mesa-dev] [PATCH 1/2] nir: Add a nir_deref_foreach_leaf helper

2016-07-15 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Connor Abbott 
---
 src/compiler/nir/nir.c   | 107 +++
 src/compiler/nir/nir.h   |   4 ++
 src/compiler/nir/nir_lower_returns.c |   9 +--
 3 files changed, 116 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 3c8b4e0..a4a28a3 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -659,6 +659,113 @@ nir_copy_deref(void *mem_ctx, nir_deref *deref)
return NULL;
 }
 
+/* This is the second step in the recursion.  We've found the tail and made a
+ * copy.  Now we need to iterate over all possible leaves and call the
+ * callback on each one.
+ */
+static bool
+deref_foreach_leaf_build_recur(nir_deref_var *deref, nir_deref *tail,
+   nir_deref_foreach_leaf_cb cb, void *state)
+{
+   unsigned length;
+   union {
+  nir_deref_array arr;
+  nir_deref_struct str;
+   } tmp;
+
+   assert(tail->child == NULL);
+   switch (glsl_get_base_type(tail->type)) {
+   case GLSL_TYPE_ARRAY:
+  tmp.arr.deref.deref_type = nir_deref_type_array;
+  tmp.arr.deref.child = NULL;
+  tmp.arr.deref.type = glsl_get_array_element(tail->type);
+  tmp.arr.deref_array_type = nir_deref_array_type_direct;
+  tmp.arr.indirect = NIR_SRC_INIT;
+  tail->child = 
+
+  length = glsl_get_length(tail->type);
+  for (unsigned i = 0; i < length; i++) {
+ tmp.arr.base_offset = i;
+ if (!deref_foreach_leaf_build_recur(deref, , cb, state))
+return false;
+  }
+  return true;
+
+   case GLSL_TYPE_STRUCT:
+  tmp.str.deref.deref_type = nir_deref_type_struct;
+  tmp.str.deref.child = NULL;
+  tail->child = 
+
+  length = glsl_get_length(tail->type);
+  for (unsigned i = 0; i < length; i++) {
+ tmp.str.deref.type = glsl_get_struct_field(tail->type, i);
+ tmp.str.index = i;
+ if (!deref_foreach_leaf_build_recur(deref, , cb, state))
+return false;
+  }
+  return true;
+
+   default:
+  return cb(deref, state);
+   }
+}
+
+/* This is the first step of the foreach_leaf recursion.  In this step we are
+ * walking to the end of the deref chain and making a copy in the stack as we
+ * go.  This is because we don't want to mutate the deref chain that was
+ * passed in by the caller.  The downside is that this deref chain is on the
+ * stack and , if the caller wants to do anything with it, they will have to
+ * make their own copy because this one will go away.
+ */
+static bool
+deref_foreach_leaf_copy_recur(nir_deref_var *deref, nir_deref *tail,
+  nir_deref_foreach_leaf_cb cb, void *state)
+{
+   union {
+  nir_deref_array arr;
+  nir_deref_struct str;
+   } c;
+
+   if (tail->child) {
+  switch (tail->child->deref_type) {
+  case nir_deref_type_array:
+ c.arr = *nir_deref_as_array(tail->child);
+ tail->child = 
+ return deref_foreach_leaf_copy_recur(deref, , cb, state);
+
+  case nir_deref_type_struct:
+ c.str = *nir_deref_as_struct(tail->child);
+ tail->child = 
+ return deref_foreach_leaf_copy_recur(deref, , cb, state);
+
+  case nir_deref_type_var:
+  default:
+ unreachable("Invalid deref type for a child");
+  }
+   } else {
+  /* We've gotten to the end of the original deref.  Time to start
+   * building our own derefs.
+   */
+  return deref_foreach_leaf_build_recur(deref, tail, cb, state);
+   }
+}
+
+/**
+ * This function iterates over all of the possible derefs that can be created
+ * with the given deref as the head.  It then calls the provided callback with
+ * a full deref for each one.
+ *
+ * The deref passed to the callback will be allocated on the stack.  You will
+ * need to make a copy if you want it to hang around.
+ */
+bool
+nir_deref_foreach_leaf(nir_deref_var *deref,
+   nir_deref_foreach_leaf_cb cb, void *state)
+{
+   nir_deref_var copy = *deref;
+   return deref_foreach_leaf_copy_recur(, , cb, state);
+}
+
 /* Returns a load_const instruction that represents the constant
  * initializer for the given deref chain.  The caller is responsible for
  * ensuring that there actually is a constant initializer.
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index a7921ee..79716b1 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -1929,6 +1929,10 @@ nir_deref_struct *nir_deref_struct_create(void *mem_ctx, 
unsigned field_index);
 
 nir_deref *nir_copy_deref(void *mem_ctx, nir_deref *deref);
 
+typedef bool (*nir_deref_foreach_leaf_cb)(nir_deref_var *deref, void *state);
+bool nir_deref_foreach_leaf(nir_deref_var *deref,
+nir_deref_foreach_leaf_cb cb, void *state);
+
 nir_load_const_instr *
 

[Mesa-dev] [PATCH 2/2] nir/inline: Constant-initialize local variables in the callee if needed

2016-07-15 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand 
Cc: "12.0" 
Cc: Connor Abbott 
---
 src/compiler/nir/nir_inline_functions.c | 41 +++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_inline_functions.c 
b/src/compiler/nir/nir_inline_functions.c
index c36748d..5e7382a 100644
--- a/src/compiler/nir/nir_inline_functions.c
+++ b/src/compiler/nir/nir_inline_functions.c
@@ -25,6 +25,19 @@
 #include "nir_builder.h"
 #include "nir_control_flow.h"
 
+static bool
+deref_apply_constant_initializer(nir_deref_var *deref, void *state)
+{
+   struct nir_builder *b = state;
+
+   nir_load_const_instr *initializer =
+  nir_deref_get_const_initializer_load(b->shader, deref);
+
+   nir_store_deref_var(b, deref, >def, 0xf);
+
+   return true;
+}
+
 static bool inline_function_impl(nir_function_impl *impl, struct set *inlined);
 
 static void
@@ -174,11 +187,35 @@ inline_functions_block(nir_block *block, nir_builder *b,
   /* Add copies of all in parameters */
   assert(call->num_params == callee_copy->num_params);
 
+  b->cursor = nir_before_instr(>instr);
+
+  /* Before we insert the copy of the function, we need to lower away
+   * constant initializers on local variables.  This is because constant
+   * initializers happen (effectively) at the top of the function and,
+   * since these are about to become locals of the calling function,
+   * initialization will happen at the top of the caller rather than at
+   * the top of the callee.  This isn't usually a problem, but if we are
+   * being inlined inside of a loop, it can result in the variable not
+   * getting re-initizlied properly for all loop iterations.
+   */
+  nir_foreach_variable(local, _copy->locals) {
+ if (!local->constant_initializer)
+continue;
+
+ nir_deref_var deref;
+ deref.deref.deref_type = nir_deref_type_var,
+ deref.deref.child = NULL;
+ deref.deref.type = local->type,
+ deref.var = local;
+
+ nir_deref_foreach_leaf(, deref_apply_constant_initializer, b);
+
+ local->constant_initializer = NULL;
+  }
+
   exec_list_append(>impl->locals, _copy->locals);
   exec_list_append(>impl->registers, _copy->registers);
 
-  b->cursor = nir_before_instr(>instr);
-
   /* We now need to tie the two functions together using the
* parameters.  There are two ways we do this: One is to turn the
* parameter into a local variable and do a shadow-copy.  The other
-- 
2.5.0.400.gff86faf

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


Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

2016-07-15 Thread Zhang, Boyuan
Hi Andy,

The memory issue is fixed. Please try the new patch set I just submitted. 
Should NOT have hard lock anymore.

And thanks for providing the rate control info, I will do some test about it.

Regards,
Boyuan

-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com] 
Sent: July-15-16 1:32 PM
To: Zhang, Boyuan; Christian König; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

Zhang, Boyuan wrote:
> Hi Andy,
>
> Thanks for the testing. I will look into the memory issue. For the cbr 
> test, what was the bitrate you set? And by saying testing high rates, 
> how high was the rate approximately?

Testing more shows that I get the same size file independent of framerate. An 
example inputting rawvideo and asking gstreamer for 30mbit with 500 frames 
2560x1440 for both 25fps and 50fps produces 60M byte files for both.

omx doesn't have this issue, for 30mbit the files produced are 53M and 26M.

Also noted that omx takes 3.8 seconds and vaapi 13.8 for the same input.




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


[Mesa-dev] [PATCH 10/11] st/va: add preset values for VAAPI encode

2016-07-15 Thread Boyuan Zhang
Add some hardcoded values hardware needs mainly for rate control purpose. With 
previously hardcoded values for OMX, the rate control result is not correct. 
This change fixed the rate control result by setting correct values for Vaapi.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/picture.c | 36 +
 1 file changed, 36 insertions(+)

diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index c244619..275250f 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -95,6 +95,41 @@ vlVaGetReferenceFrame(vlVaDriver *drv, VASurfaceID 
surface_id,
   *ref_frame = NULL;
 }
 
+static void
+getEncParamPreset(vlVaContext *context)
+{
+   //motion estimation preset
+   context->desc.h264enc.motion_est.motion_est_quarter_pixel = 0x0001;
+   context->desc.h264enc.motion_est.lsmvert = 0x0002;
+   context->desc.h264enc.motion_est.enc_disable_sub_mode = 0x0078;
+   context->desc.h264enc.motion_est.enc_en_ime_overw_dis_subm = 0x0001;
+   context->desc.h264enc.motion_est.enc_ime_overw_dis_subm_no = 0x0001;
+   context->desc.h264enc.motion_est.enc_ime2_search_range_x = 0x0004;
+   context->desc.h264enc.motion_est.enc_ime2_search_range_y = 0x0004;
+
+   //pic control preset
+   context->desc.h264enc.pic_ctrl.enc_cabac_enable = 0x0001;
+   context->desc.h264enc.pic_ctrl.enc_constraint_set_flags = 0x0040;
+
+   //rate control
+   context->desc.h264enc.rate_ctrl.vbv_buffer_size = 2000;
+   if (context->desc.h264enc.rate_ctrl.frame_rate_num == 0) {
+  context->desc.h264enc.rate_ctrl.frame_rate_num = 30;
+  context->desc.h264enc.rate_ctrl.frame_rate_den = 1;
+   }
+   context->desc.h264enc.rate_ctrl.vbv_buf_lv = 48;
+   context->desc.h264enc.rate_ctrl.fill_data_enable = 1;
+   context->desc.h264enc.rate_ctrl.enforce_hrd = 1;
+   context->desc.h264enc.enable_vui = false;
+   context->desc.h264enc.rate_ctrl.target_bits_picture =
+  context->desc.h264enc.rate_ctrl.target_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_integer =
+  context->desc.h264enc.rate_ctrl.peak_bitrate / 
context->desc.h264enc.rate_ctrl.frame_rate_num;
+   context->desc.h264enc.rate_ctrl.peak_bits_picture_fraction = 0;
+
+   context->desc.h264enc.ref_pic_mode = 0x0201;
+}
+
 static VAStatus
 handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext *context, vlVaBuffer 
*buf)
 {
@@ -514,6 +549,7 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
 
if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
   coded_buf = context->coded_buf;
+  getEncParamPreset(context);
   context->decoder->begin_frame(context->decoder, context->target, 
>desc.base);
   context->decoder->encode_bitstream(context->decoder, context->target,
  coded_buf->derived_surface.resource, 
);
-- 
2.7.4

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


[Mesa-dev] [PATCH 08/11] st/va: get rate control method from configattrib

2016-07-15 Thread Boyuan Zhang
Rate control method is passed from app to driver through config attrib list. 
That is why we need to store this rate control method to config. And later on, 
we will pass this value to context->desc.h264enc.rate_ctrl.rate_ctrl_method.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/config.c | 11 +++
 src/gallium/state_trackers/va/context.c|  3 ++-
 src/gallium/state_trackers/va/va_private.h |  1 +
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 73704a1..ea838c0 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -172,6 +172,17 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
 
config->profile = p;
 
+   for (int i = 0; i rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_CONSTANT;
+ else if (attrib_list[i].value == VA_RC_VBR)
+config->rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_VARIABLE;
+ else
+config->rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE;
+  }
+   }
+
*config_id = handle_table_add(drv->htab, config);
 
return VA_STATUS_SUCCESS;
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index b4334f4..c67ed1f 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -274,7 +274,8 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 
context->desc.base.profile = config->profile;
context->desc.base.entry_point = config->entrypoint;
-
+   if (config->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE)
+  context->desc.h264enc.rate_ctrl.rate_ctrl_method = config->rc;
pipe_mutex_lock(drv->mutex);
*context_id = handle_table_add(drv->htab, context);
pipe_mutex_unlock(drv->mutex);
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 723983d..ad9010a 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -246,6 +246,7 @@ typedef struct {
 typedef struct {
VAEntrypoint entrypoint;
enum pipe_video_profile profile;
+   enum pipe_h264_enc_rate_control_method rc;
 } vlVaConfig;
 
 typedef struct {
-- 
2.7.4

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


[Mesa-dev] [PATCH 11/11] st/va: enable h264 VAAPI encode

2016-07-15 Thread Boyuan Zhang
Enable H.264 VAAPI encoding through config. Currently only H.264 baseline is 
supported.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/config.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index ea838c0..04d214d 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -74,6 +74,7 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile 
profile,
 {
struct pipe_screen *pscreen;
enum pipe_video_profile p;
+   int va_status = VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
@@ -90,12 +91,18 @@ vlVaQueryConfigEntrypoints(VADriverContextP ctx, VAProfile 
profile,
   return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
 
pscreen = VL_VA_PSCREEN(ctx);
-   if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, 
PIPE_VIDEO_CAP_SUPPORTED))
-  return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
-
-   entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD;
+   if (pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, 
PIPE_VIDEO_CAP_SUPPORTED)) {
+  entrypoint_list[(*num_entrypoints)++] = VAEntrypointVLD;
+  va_status = VA_STATUS_SUCCESS;
+   }
+   if (pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_ENCODE, 
PIPE_VIDEO_CAP_SUPPORTED) &&
+   p == PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE) {
+  entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncSlice;
+  entrypoint_list[(*num_entrypoints)++] = VAEntrypointEncPicture;
+  va_status = VA_STATUS_SUCCESS;
+   }
 
-   return VA_STATUS_SUCCESS;
+   return va_status;
 }
 
 VAStatus
@@ -114,7 +121,7 @@ vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile 
profile, VAEntrypoint en
  value = VA_RT_FORMAT_YUV420;
  break;
   case VAConfigAttribRateControl:
- value = VA_RC_NONE;
+ value = VA_RC_CQP | VA_RC_CBR;
  break;
   default:
  value = VA_ATTRIB_NOT_SUPPORTED;
@@ -159,10 +166,15 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
   return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
 
pscreen = VL_VA_PSCREEN(ctx);
-   if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, 
PIPE_VIDEO_CAP_SUPPORTED))
-  return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
-
-   if (entrypoint != VAEntrypointVLD)
+   if (entrypoint == VAEntrypointVLD) {
+  if (!pscreen->get_video_param(pscreen, p, 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_SUPPORTED))
+ return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
+   }
+   else if (entrypoint == VAEntrypointEncSlice) {
+  if (!pscreen->get_video_param(pscreen, p, PIPE_VIDEO_ENTRYPOINT_ENCODE, 
PIPE_VIDEO_CAP_SUPPORTED))
+ return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
+   }
+   else
   return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
 
if (entrypoint == VAEntrypointEncSlice || entrypoint == 
VAEntrypointEncPicture)
-- 
2.7.4

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


[Mesa-dev] [PATCH 09/11] st/va: add functions for VAAPI encode

2016-07-15 Thread Boyuan Zhang
Add necessary functions/changes for VAAPI encoding to buffer and picture. These 
changes will allow driver to handle all Vaapi encode related operations. This 
patch doesn't change the Vaapi decode behaviour.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/buffer.c |   6 ++
 src/gallium/state_trackers/va/picture.c| 162 -
 src/gallium/state_trackers/va/va_private.h |   3 +
 3 files changed, 169 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/va/buffer.c 
b/src/gallium/state_trackers/va/buffer.c
index 7d3167b..dfcebbe 100644
--- a/src/gallium/state_trackers/va/buffer.c
+++ b/src/gallium/state_trackers/va/buffer.c
@@ -133,6 +133,12 @@ vlVaMapBuffer(VADriverContextP ctx, VABufferID buf_id, 
void **pbuff)
   if (!buf->derived_surface.transfer || !*pbuff)
  return VA_STATUS_ERROR_INVALID_BUFFER;
 
+  if (buf->type == VAEncCodedBufferType) {
+ ((VACodedBufferSegment*)buf->data)->buf = *pbuff;
+ ((VACodedBufferSegment*)buf->data)->size = buf->coded_size;
+ ((VACodedBufferSegment*)buf->data)->next = NULL;
+ *pbuff = buf->data;
+  }
} else {
   pipe_mutex_unlock(drv->mutex);
   *pbuff = buf->data;
diff --git a/src/gallium/state_trackers/va/picture.c 
b/src/gallium/state_trackers/va/picture.c
index 89ac024..c244619 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -78,7 +78,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID 
context_id, VASurfaceID rende
   return VA_STATUS_SUCCESS;
}
 
-   context->decoder->begin_frame(context->decoder, context->target, 
>desc.base);
+   if (context->decoder->entrypoint != PIPE_VIDEO_ENTRYPOINT_ENCODE)
+  context->decoder->begin_frame(context->decoder, context->target, 
>desc.base);
 
return VA_STATUS_SUCCESS;
 }
@@ -278,6 +279,132 @@ handleVASliceDataBufferType(vlVaContext *context, 
vlVaBuffer *buf)
   num_buffers, (const void * const*)buffers, sizes);
 }
 
+static VAStatus
+handleVAEncMiscParameterTypeRateControl(vlVaContext *context, 
VAEncMiscParameterBuffer *misc)
+{
+   VAEncMiscParameterRateControl *rc = (VAEncMiscParameterRateControl 
*)misc->data;
+   if (context->desc.h264enc.rate_ctrl.rate_ctrl_method ==
+   PIPE_H264_ENC_RATE_CONTROL_METHOD_CONSTANT)
+  context->desc.h264enc.rate_ctrl.target_bitrate = rc->bits_per_second;
+   else
+  context->desc.h264enc.rate_ctrl.target_bitrate = rc->bits_per_second * 
rc->target_percentage;
+   context->desc.h264enc.rate_ctrl.peak_bitrate = rc->bits_per_second;
+   if (context->desc.h264enc.rate_ctrl.target_bitrate < 200)
+  context->desc.h264enc.rate_ctrl.vbv_buffer_size = 
MIN2((context->desc.h264enc.rate_ctrl.target_bitrate * 2.75), 200);
+   else
+  context->desc.h264enc.rate_ctrl.vbv_buffer_size = 
context->desc.h264enc.rate_ctrl.target_bitrate;
+
+   return VA_STATUS_SUCCESS;
+}
+
+static VAStatus
+handleVAEncSequenceParameterBufferType(vlVaDriver *drv, vlVaContext *context, 
vlVaBuffer *buf)
+{
+   VAEncSequenceParameterBufferH264 *h264 = (VAEncSequenceParameterBufferH264 
*)buf->data;
+   if (!context->decoder) {
+  context->templat.max_references = h264->max_num_ref_frames;
+  context->templat.level = h264->level_idc;
+  context->decoder = drv->pipe->create_video_codec(drv->pipe, 
>templat);
+  if (!context->decoder)
+ return VA_STATUS_ERROR_ALLOCATION_FAILED;
+   }
+   context->desc.h264enc.gop_size = h264->intra_idr_period;
+   return VA_STATUS_SUCCESS;
+}
+
+static VAStatus
+handleVAEncMiscParameterBufferType(vlVaContext *context, vlVaBuffer *buf)
+{
+   VAStatus vaStatus = VA_STATUS_SUCCESS;
+   VAEncMiscParameterBuffer *misc;
+   misc = buf->data;
+
+   switch (misc->type) {
+   case VAEncMiscParameterTypeRateControl:
+  vaStatus = handleVAEncMiscParameterTypeRateControl(context, misc);
+  break;
+
+   default:
+  break;
+   }
+
+   return vaStatus;
+}
+
+static VAStatus
+handleVAEncPictureParameterBufferType(vlVaDriver *drv, vlVaContext *context, 
vlVaBuffer *buf)
+{
+   VAEncPictureParameterBufferH264 *h264;
+   vlVaBuffer *coded_buf;
+
+   h264 = buf->data;
+   context->desc.h264enc.frame_num = h264->frame_num;
+   context->desc.h264enc.not_referenced = false;
+   context->desc.h264enc.is_idr = (h264->pic_fields.bits.idr_pic_flag == 1);
+   context->desc.h264enc.pic_order_cnt = h264->CurrPic.TopFieldOrderCnt / 2;
+   if (context->desc.h264enc.is_idr)
+  context->desc.h264enc.i_remain = 1;
+   else
+  context->desc.h264enc.i_remain = 0;
+
+   context->desc.h264enc.p_remain = context->desc.h264enc.gop_size - 
context->desc.h264enc.gop_cnt - context->desc.h264enc.i_remain;
+
+   coded_buf = handle_table_get(drv->htab, h264->coded_buf);
+   if (!coded_buf->derived_surface.resource)
+  coded_buf->derived_surface.resource = 
pipe_buffer_create(drv->pipe->screen, PIPE_BIND_VERTEX_BUFFER,
+  

[Mesa-dev] [PATCH 06/11] vl/util: add copy func for yv12image to nv12surface

2016-07-15 Thread Boyuan Zhang
Add function to copy from yv12 image to nv12 surface for VAAPI putimage call. 
We need this function in VaPutImage call where copying from yv12 image to nv12 
surface for encoding. Existing function can't be used because it only work for 
copying from yv12 surface to nv12 image in Vaapi.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/auxiliary/util/u_video.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index 9196afc..d147295 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -130,6 +130,29 @@ u_copy_yv12_to_nv12(void *const *destination_data,
 }
 
 static inline void
+u_copy_yv12_img_to_nv12_surf(uint8_t *const *src,
+ uint8_t *dest,
+ int *offset,
+ int field)
+{
+   if (field == 0) {
+  for (int i = 0; i < offset[1] ; i++)
+ dest[i] = src[field][i];
+   } else if (field == 1) {
+  bool odd = false;
+  for (int i = 0; i < (offset[1]/2) ; i++){
+ if (odd == false) {
+dest[i] = src[field][i/2];
+odd = true;
+ } else {
+dest[i] = src[field+1][i/2];
+odd = false;
+ }
+  }
+   }
+}
+
+static inline void
 u_copy_swap422_packed(void *const *destination_data,
uint32_t const *destination_pitches,
int src_plane, int src_field,
-- 
2.7.4

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


[Mesa-dev] [PATCH 05/11] st/va: add encode entrypoint

2016-07-15 Thread Boyuan Zhang
VAAPI passes PIPE_VIDEO_ENTRYPOINT_ENCODE as entry point for encoding case. We 
will save this encode entry point in config. config_id was used as profile 
previously. Now, config has both profile and entrypoint field, and config_id is 
used to get the config object. Later on, we pass this entrypoint to 
context->templat.entrypoint instead of always hardcoded to 
PIPE_VIDEO_ENTRYPOINT_BITSTREAM for decoding case previously.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/config.c | 61 +++---
 src/gallium/state_trackers/va/context.c| 57 
 src/gallium/state_trackers/va/surface.c| 12 --
 src/gallium/state_trackers/va/va_private.h |  5 +++
 4 files changed, 103 insertions(+), 32 deletions(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 9ca0aa8..73704a1 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -34,6 +34,8 @@
 
 #include "va_private.h"
 
+#include "util/u_handle_table.h"
+
 DEBUG_GET_ONCE_BOOL_OPTION(mpeg4, "VAAPI_MPEG4_ENABLED", false)
 
 VAStatus
@@ -128,14 +130,27 @@ VAStatus
 vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint 
entrypoint,
  VAConfigAttrib *attrib_list, int num_attribs, VAConfigID 
*config_id)
 {
+   vlVaDriver *drv;
+   vlVaConfig *config;
struct pipe_screen *pscreen;
enum pipe_video_profile p;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   config = CALLOC(1, sizeof(vlVaConfig));
+   if (!config)
+  return VA_STATUS_ERROR_ALLOCATION_FAILED;
+
if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
-  *config_id = PIPE_VIDEO_PROFILE_UNKNOWN;
+  config->entrypoint = VAEntrypointVideoProc;
+  config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
+  *config_id = handle_table_add(drv->htab, config);
   return VA_STATUS_SUCCESS;
}
 
@@ -150,7 +165,14 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
if (entrypoint != VAEntrypointVLD)
   return VA_STATUS_ERROR_UNSUPPORTED_ENTRYPOINT;
 
-   *config_id = p;
+   if (entrypoint == VAEntrypointEncSlice || entrypoint == 
VAEntrypointEncPicture)
+  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_ENCODE;
+   else
+  config->entrypoint = PIPE_VIDEO_ENTRYPOINT_BITSTREAM;
+
+   config->profile = p;
+
+   *config_id = handle_table_add(drv->htab, config);
 
return VA_STATUS_SUCCESS;
 }
@@ -158,9 +180,25 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, 
VAEntrypoint entrypoin
 VAStatus
 vlVaDestroyConfig(VADriverContextP ctx, VAConfigID config_id)
 {
+   vlVaDriver *drv;
+   vlVaConfig *config;
+
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   config = handle_table_get(drv->htab, config_id);
+
+   if (!config)
+  return VA_STATUS_ERROR_INVALID_CONFIG;
+
+   FREE(config);
+   handle_table_remove(drv->htab, config_id);
+
return VA_STATUS_SUCCESS;
 }
 
@@ -168,18 +206,31 @@ VAStatus
 vlVaQueryConfigAttributes(VADriverContextP ctx, VAConfigID config_id, 
VAProfile *profile,
   VAEntrypoint *entrypoint, VAConfigAttrib 
*attrib_list, int *num_attribs)
 {
+   vlVaDriver *drv;
+   vlVaConfig *config;
+
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   *profile = PipeToProfile(config_id);
+   drv = VL_VA_DRIVER(ctx);
+
+   if (!drv)
+  return VA_STATUS_ERROR_INVALID_CONTEXT;
+
+   config = handle_table_get(drv->htab, config_id);
+
+   if (!config)
+  return VA_STATUS_ERROR_INVALID_CONFIG;
+
+   *profile = PipeToProfile(config->profile);
 
-   if (config_id == PIPE_VIDEO_PROFILE_UNKNOWN) {
+   if (config->profile == PIPE_VIDEO_PROFILE_UNKNOWN) {
   *entrypoint = VAEntrypointVideoProc;
   *num_attribs = 0;
   return VA_STATUS_SUCCESS;
}
 
-   *entrypoint = VAEntrypointVLD;
+   *entrypoint = config->entrypoint;
 
*num_attribs = 1;
attrib_list[0].type = VAConfigAttribRTFormat;
diff --git a/src/gallium/state_trackers/va/context.c 
b/src/gallium/state_trackers/va/context.c
index 402fbb2..b4334f4 100644
--- a/src/gallium/state_trackers/va/context.c
+++ b/src/gallium/state_trackers/va/context.c
@@ -195,18 +195,21 @@ vlVaCreateContext(VADriverContextP ctx, VAConfigID 
config_id, int picture_width,
 {
vlVaDriver *drv;
vlVaContext *context;
+   vlVaConfig *config;
int is_vpp;
 
if (!ctx)
   return VA_STATUS_ERROR_INVALID_CONTEXT;
 
-   is_vpp = config_id == PIPE_VIDEO_PROFILE_UNKNOWN && !picture_width &&
+   drv = VL_VA_DRIVER(ctx);
+   config = handle_table_get(drv->htab, config_id);
+
+   is_vpp = config->profile == PIPE_VIDEO_PROFILE_UNKNOWN && !picture_width &&
 !picture_height && 

[Mesa-dev] [PATCH 07/11] st/va: add conversion for yv12 to nv12in putimage

2016-07-15 Thread Boyuan Zhang
For putimage call, if image format is yv12 (or IYUV with U V field swap) and 
surface format is nv12, then we need to convert yv12 to nv12 and then copy the 
converted data from image to surface. We can't use the existing logic where 
surface is destroyed and re-created with yv12 format.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/state_trackers/va/image.c | 33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/src/gallium/state_trackers/va/image.c 
b/src/gallium/state_trackers/va/image.c
index 1b956e3..47895ee 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -471,7 +471,9 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
   return VA_STATUS_ERROR_OPERATION_FAILED;
}
 
-   if (format != surf->buffer->buffer_format) {
+   if ((format != surf->buffer->buffer_format) &&
+ ((format != PIPE_FORMAT_YV12) || (surf->buffer->buffer_format != 
PIPE_FORMAT_NV12)) &&
+ ((format != PIPE_FORMAT_IYUV) || (surf->buffer->buffer_format != 
PIPE_FORMAT_NV12))) {
   struct pipe_video_buffer *tmp_buf;
   struct pipe_video_buffer templat = surf->templat;
 
@@ -513,12 +515,29 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface, 
VAImageID image,
   unsigned width, height;
   if (!views[i]) continue;
   vlVaVideoSurfaceSize(surf, i, , );
-  for (j = 0; j < views[i]->texture->array_size; ++j) {
- struct pipe_box dst_box = {0, 0, j, width, height, 1};
- drv->pipe->transfer_inline_write(drv->pipe, views[i]->texture, 0,
-PIPE_TRANSFER_WRITE, _box,
-data[i] + pitches[i] * j,
-pitches[i] * views[i]->texture->array_size, 0);
+  if ((format == PIPE_FORMAT_YV12) || (format == PIPE_FORMAT_IYUV) &&
+(surf->buffer->buffer_format == PIPE_FORMAT_NV12)) {
+ struct pipe_transfer *transfer = NULL;
+ uint8_t *map = NULL;
+ struct pipe_box dst_box_1 = {0, 0, 0, width, height, 1};
+ map = drv->pipe->transfer_map(drv->pipe,
+   views[i]->texture,
+   0,
+   PIPE_TRANSFER_DISCARD_RANGE,
+   _box_1, );
+ if (map == NULL)
+return VA_STATUS_ERROR_OPERATION_FAILED;
+
+ u_copy_yv12_img_to_nv12_surf (data, map, vaimage->offsets, i);
+ pipe_transfer_unmap(drv->pipe, transfer);
+  } else {
+ for (j = 0; j < views[i]->texture->array_size; ++j) {
+struct pipe_box dst_box = {0, 0, j, width, height, 1};
+drv->pipe->transfer_inline_write(drv->pipe, views[i]->texture, 0,
+ PIPE_TRANSFER_WRITE, _box,
+ data[i] + pitches[i] * j,
+ pitches[i] * 
views[i]->texture->array_size, 0);
+ }
   }
}
pipe_mutex_unlock(drv->mutex);
-- 
2.7.4

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


[Mesa-dev] [PATCH 02/11] vl: add entry point

2016-07-15 Thread Boyuan Zhang
Add entrypoint to distinguish H.264 decode and encode. For example, in patch 
5/11 when is calling "VaCreateContext", "pps" and "sps" shouldn't be allocated 
for H.264 encoding. So we need to use the entry_point to determine this is 
H.264 decode or H.264 encode. We can use config to determine the entrypoint 
since config_id is passed to us for VaCreateContext call. However, for 
VaDestoyContext call, only context_id is passed to us. So we need to know the 
entrypoint in order to not free the pps/sps for encoding case.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/include/pipe/p_video_state.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/include/pipe/p_video_state.h 
b/src/gallium/include/pipe/p_video_state.h
index 754d013..39b3905 100644
--- a/src/gallium/include/pipe/p_video_state.h
+++ b/src/gallium/include/pipe/p_video_state.h
@@ -131,6 +131,7 @@ enum pipe_h264_enc_rate_control_method
 struct pipe_picture_desc
 {
enum pipe_video_profile profile;
+   enum pipe_video_entrypoint entry_point;
 };
 
 struct pipe_quant_matrix
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] gallium/sw/kms: Fix multiple imports from PRIME FDs

2016-07-15 Thread Emil Velikov
On 15 July 2016 at 08:27, Tomasz Figa  wrote:
> When a buffer with a GEM handle already existing in our context is
> (re-)imported from a PRIME FD, the resulting GEM handle is exactly the
> same as the original one. Since the GEM handles are not reference
> counted, we need to detect duplicate imports and reference count our
> internal buffer structs ourselves.
>
> Signed-off-by: Tomasz Figa 
> ---
>  src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 30 
> +--
>  1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
> b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> index 21ac0d7..c4f56cb 100644
> --- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> +++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> @@ -211,7 +211,9 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
>  }
>
>  static struct kms_sw_displaytarget *
> -kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd)
> +kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd,
> +unsigned width, unsigned height,
> +unsigned stride)
>  {
> uint32_t handle = -1;
> struct kms_sw_displaytarget * kms_sw_dt;
> @@ -222,6 +224,17 @@ kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys 
> *kms_sw, int fd)
> if (ret)
>return NULL;
>
> +   LIST_FOR_EACH_ENTRY(kms_sw_dt, _sw->bo_list, link) {
> +  if (kms_sw_dt->handle == handle) {
> + kms_sw_dt->ref_count++;
> +
> + DEBUG_PRINT("KMS-DEBUG: imported buffer %u (size %u)\n",
> + kms_sw_dt->handle, kms_sw_dt->size);
> +
> + return kms_sw_dt;
> +  }
> +   }
> +
> kms_sw_dt = CALLOC_STRUCT(kms_sw_displaytarget);
> if (!kms_sw_dt)
>return NULL;
> @@ -229,6 +242,9 @@ kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys 
> *kms_sw, int fd)
> kms_sw_dt->ref_count = 1;
> kms_sw_dt->handle = handle;
> kms_sw_dt->size = lseek(fd, 0, SEEK_END);
> +   kms_sw_dt->width = width;
> +   kms_sw_dt->height = height;
> +   kms_sw_dt->stride = stride;
>
> if (kms_sw_dt->size == (off_t)-1) {
>FREE(kms_sw_dt);
> @@ -274,14 +290,12 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
>
> switch(whandle->type) {
> case DRM_API_HANDLE_TYPE_FD:
> -  kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, 
> whandle->handle);
> -  if (kms_sw_dt) {
> - kms_sw_dt->ref_count++;
> - kms_sw_dt->width = templ->width0;
> - kms_sw_dt->height = templ->height0;
> - kms_sw_dt->stride = whandle->stride;
> +  kms_sw_dt = kms_sw_displaytarget_add_from_prime(kms_sw, 
> whandle->handle,
> +  templ->width0,
> +  templ->height0,
> +  whandle->stride);
> +  if (kms_sw_dt)
>   *stride = kms_sw_dt->stride;
> -  }
So there's actually a couple of things here:
 - kms_sw_displaytarget_add_from_prime now takes a width, height,
stride. not a bugfix but very nice imho.
 - DRM_API_HANDLE_TYPE_FD were ref_counted twice upon creation - once
in kms_sw_displaytarget_add_from_prime, and a second time immediatelly
after.
 - one should have checked the bo_list prior to importing the BO as prime FD.

Can we split the former (2/2) and get the other two (1/2) with CC:
mesa-stable... ?
Ideally we would have just a single
"LIST_FOR_EACH_ENTRY(..._sw->bo_list...)" block in
kms_sw_displaytarget_from_handle and none in
kms_sw_displaytarget_add_from_prime.

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


Re: [Mesa-dev] [PATCH v4 24/34] i965/gen8: Use the generic ISL-based path for texture surfaces

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---

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


Re: [Mesa-dev] [PATCH v4 19/34] i965/state: Add a helper for emitting a surface state using isl

2016-07-15 Thread Chad Versace
On Thu 14 Jul 2016, Chad Versace wrote:
> On Wed 13 Jul 2016, Jason Ekstrand wrote:
> > Reviewed-by: Topi Pohjolainen 
> > ---
> >  src/mesa/drivers/dri/i965/brw_state.h|  8 +++
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 79 
> > 
> >  2 files changed, 87 insertions(+)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
> > b/src/mesa/drivers/dri/i965/brw_state.h
> > index a16e876..91ebce9 100644
> > --- a/src/mesa/drivers/dri/i965/brw_state.h
> > +++ b/src/mesa/drivers/dri/i965/brw_state.h
> > @@ -274,6 +274,14 @@ GLuint translate_tex_format(struct brw_context *brw,
> >  int brw_get_texture_swizzle(const struct gl_context *ctx,
> >  const struct gl_texture_object *t);
> >  
> 
> Move the forward declaration below to the top of the header. As written,
> it looks like the function's return type.

> > +struct isl_view;
> > +void brw_emit_surface_state(struct brw_context *brw,
> > +struct intel_mipmap_tree *mt,
> > +const struct isl_view *view,
> > +uint32_t mocs, bool for_gather,
> > +uint32_t *surf_offset, int surf_index,
> > +unsigned read_domains, unsigned write_domains);

Ping! Unresolved issue^^^

Fix that, and this patch is
Reviewed-by: Chad Versace 

But keep reading...



> > +   if (aux_surf) {
> > +  /* On gen7 and prior, the bottom 12 bits of the MCS base address are
> > +   * used to store other information.  This should be ok, however, 
> > because
> > +   * surface buffer addresses are always 4K page alinged.
> > +   */
> 
> Could you please insert the original comment from gen7_wm_surface_state?
> Because...
> 
> > +  assert((aux_offset & 0xfff) == 0);
> > +  drm_intel_bo_emit_reloc(brw->batch.bo,
> > +  *surf_offset + 4 * ss_info.aux_reloc_dw,
> > +  mt->mcs_mt->bo, dw[ss_info.aux_reloc_dw] & 
> > 0xfff,
>  
> 
> 
> ...that ^^^ bit of code REALLY confused me until I found the original
> comment. What's happening is obvious in retrospect, yet terribly obscure
> without a fuller comment.

I prefer you insert the original comment, or at least some more
explanation. My r-b stands with or without a comment update.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] main/shaderimage: image unit invalid if texture is incomplete, independently of the level

2016-07-15 Thread Francisco Jerez
Alejandro Piñeiro  writes:

> On 14/07/16 21:24, Francisco Jerez wrote:
>> Alejandro Piñeiro  writes:
>>
>>> Without this commit, a image is considered valid if the level of the
>>> texture bound to the image is complete, something we can check as mesa
>>> save independently if it is "base incomplete" of "mipmap incomplete".
>>>
>>> But, from the OpenGL 4.3 Core Specification, section 8.25 ("Texture
>>> Image Loads and Stores"):
>>>
>>>   "An access is considered invalid if:
>>> the texture bound to the selected image unit is incomplete;"
>>>
>>> This implies that the access to the image unit is invalid if the
>>> texture is incomplete, no mattering details about the specific texture
>>> level bound to the image.
>>>
>>> This fixes:
>>> GL44-CTS.shader_image_load_store.incomplete_textures
>>> ---
>>>
>>> Current piglit test is not testing what this commit tries to fix. I
>>> will send a patch to piglit in short.
>>>
>>>  src/mesa/main/shaderimage.c | 14 +++---
>>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
>>> index 90643c4..d20cd90 100644
>>> --- a/src/mesa/main/shaderimage.c
>>> +++ b/src/mesa/main/shaderimage.c
>>> @@ -469,10 +469,18 @@ _mesa_is_image_unit_valid(struct gl_context *ctx, 
>>> struct gl_image_unit *u)
>>> if (!t->_BaseComplete && !t->_MipmapComplete)
>>> _mesa_test_texobj_completeness(ctx, t);
>>>  
>>> +   /* From the OpenGL 4.3 Core Specification, Chapter 8.25, Texture Image
>>> +* Loads and Stores:
>>> +*
>>> +*  "An access is considered invalid if:
>>> +*the texture bound to the selected image unit is incomplete;"
>>> +*/
>>> +   if (!t->_BaseComplete ||
>>> +   !t->_MipmapComplete)
>>> +  return GL_FALSE;
>> I don't think this is correct, AFAIUI a texture having _MipmapComplete
>> equal to false doesn't imply that the texture as a whole would be
>> considered incomplete according to the GL's definition of completeness.
>> Whether or not it's considered complete usually depends on the sampler
>> state while you're doing regular texture sampling: If the sampler a
>> texture object is used with has any of the mipmap filtering modes
>> enabled you need to check _MipmapComplete, otherwise you need to check
>> _BaseComplete.  The problem when you attempt to carry over this
>> definition to shader images (as the spec implies) is that image units
>> have no sampler state as such, and that they can only ever access one
>> specified level of the texture at a time (potentially a texture level
>> other than the base).  This patch makes image units behave like a
>> sampler unit with mipmap filtering enabled for the purpose of texture
>> completeness validation, which is almost definitely too strong.
>
> Yes, I didn't realize that _BaseComplete and _MipmapComplete were not
> checking the state at all. Thanks for pointing it.
>
>> An alternative would be to do something along the lines of:
>>
>> | if (!_mesa_is_texture_complete(t, >Sampler))
>> |return GL_FALSE;
>
> Yes, that is what I wanted, to return false if the texture is incomplete.
>
>>
>> The problem is that you would then run into problems when some of the
>> non-base mipmap levels are missing but the sampler state baked into the
>> gl_texture_object says that you aren't mipmapping, so the GL spec would
>> normally consider the texture to be complete and
>> _mesa_is_texture_complete would return true accordingly, but still you
>> wouldn't be able to use any of the missing texture levels as shader
>> image if the application tried to bind them to an image unit (that's the
>> reason for the u->Level vs t->BaseLevel checks below you're removing).
>
> Ok, then if I understand correctly, the solution is not about replacing
> the level checks for _mesa_is_texture_complete, but keeping current
> checks, and add a _mesa_is_texture_complete check. Just checked and
> everything seems to work fine (except that now the behaviour is more
> strict, see below). I will send a patch in short.
>

Yeah, that would likely work and get the CTS test to pass, but it would
still be more strict than the spec says and consider cases that are OK
according to the spec to be incomplete, so I was reluctant to call it a
solution.

I think the ideal solution would be for the state of an image unit to be
independent from the filtering and sampling state, and depend on the
completeness of the bound level *only*.  Any idea if this CTS (or your
equivalent piglit test) passes on other GL implementations that support
image load/store (e.g. nVidia's -- I would be surprised if it does).

>> Honestly I think the current definition of image unit completeness is
>> broken, because it considers the image unit state to be complete in
>> cases where the image unit state is unusable (because the target image
>> level may be missing even though the texture object itself is considered
>> complete), 

Re: [Mesa-dev] [PATCH] st/nine: add missing copyright headers

2016-07-15 Thread Axel Davy
Some copyrights are not correct, please look at the log of 
https://github.com/chrisbmr/Mesa-3D/tree/gallium-nine/src/gallium/state_trackers/nine

to find out.

Axel

On 14/07/2016 20:17, Vedran Miletić wrote :

Few files were missing the copyright headers. This patch adds correct
copyright headers according to the commit author and date.

Signed-off-by: Vedran Miletić 
---
  src/gallium/state_trackers/nine/nine_dump.c  | 21 +
  src/gallium/state_trackers/nine/nine_dump.h  | 21 +
  src/gallium/state_trackers/nine/nine_ff.c| 21 +
  src/gallium/state_trackers/nine/nine_ff.h| 21 +
  src/gallium/state_trackers/nine/nine_flags.h | 22 +-
  src/gallium/state_trackers/nine/nine_pdata.h | 21 +
  6 files changed, 126 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/nine/nine_dump.c 
b/src/gallium/state_trackers/nine/nine_dump.c
index 1ca5505..28145d0 100644
--- a/src/gallium/state_trackers/nine/nine_dump.c
+++ b/src/gallium/state_trackers/nine/nine_dump.c
@@ -1,3 +1,24 @@
+/*
+ * Copyright 2011 Joakim Sindholt 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE. */
  
  #include "nine_debug.h"

  #include "nine_pipe.h"
diff --git a/src/gallium/state_trackers/nine/nine_dump.h 
b/src/gallium/state_trackers/nine/nine_dump.h
index a0ffe7b..2ee08bd 100644
--- a/src/gallium/state_trackers/nine/nine_dump.h
+++ b/src/gallium/state_trackers/nine/nine_dump.h
@@ -1,3 +1,24 @@
+/*
+ * Copyright 2011 Joakim Sindholt 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHOR(S) AND/OR THEIR SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE. */
  
  #ifndef _NINE_DUMP_H_

  #define _NINE_DUMP_H_
diff --git a/src/gallium/state_trackers/nine/nine_ff.c 
b/src/gallium/state_trackers/nine/nine_ff.c
index 899e54e..0cd0c77 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -1,3 +1,24 @@
+/*
+ * Copyright 2011 Joakim Sindholt 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * the Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 

Re: [Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()

2016-07-15 Thread Anuj Phogat
On Fri, Jul 15, 2016 at 12:34 PM, Brian Paul  wrote:
> On 07/15/2016 01:19 PM, Anuj Phogat wrote:
>>
>> On Fri, Jul 15, 2016 at 10:14 AM, Brian Paul  wrote:
>>>
>>> If numSamples > 0, we can compute the size of the whole mipmapped
>>> texture.
>>> That's the case for glTexStorage(GL_PROXY_TEXTURE_x).
>>>
>>> Also, multiply the texture size by numSamples for MSAA textures.
>>> ---
>>>   src/mesa/main/teximage.c | 48
>>> +---
>>>   1 file changed, 45 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>>> index c75f605..0f13d61 100644
>>> --- a/src/mesa/main/teximage.c
>>> +++ b/src/mesa/main/teximage.c
>>> @@ -40,6 +40,7 @@
>>>   #include "image.h"
>>>   #include "imports.h"
>>>   #include "macros.h"
>>> +#include "mipmap.h"
>>>   #include "multisample.h"
>>>   #include "pixelstore.h"
>>>   #include "state.h"
>>> @@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx,
>>> GLenum target,
>>> mesa_format format, GLuint numSamples,
>>> GLint width, GLint height, GLint depth)
>>>   {
>>> +   uint64_t bytes, mbytes;
>>> +
>>> +   assert(numSamples > 0);
>>> +
>>> +   if (numLevels > 0) {
>>> +  /* Compute total memory for a whole mipmap.  This is the path
>>> +   * taken for glTexStorage(GL_PROXY_TEXTURE_x).
>>> +   */
>>> +  unsigned l;
>>> +
>>> +  assert(level == 0);
>>> +
>>> +  bytes = 0;
>>> +
>>> +  for (l = 0; l < numLevels; l++) {
>>> + GLint nextWidth, nextHeight, nextDepth;
>>> +
>>> + /* XXX this doesn't yet account for multisampling */
>>> + bytes += _mesa_format_image_size64(format, width, height,
>>> depth);
>>> +
>>> + if (_mesa_next_mipmap_level_size(target, 0, width, height,
>>> depth,
>>> +  , ,
>>> +  )) {
>>> +width = nextWidth;
>>> +height = nextHeight;
>>> +depth = nextDepth;
>>> + }
>>> + else {
>>> +break;
>>> + }
>>> +  }
>>> +   }
>>> +   else {
>>
>> nitpick. Use } else {
>>
>>> +  /* We just compute the size of one mipmap level.  This is the path
>>> +   * taken for glTexImage(GL_PROXY_TEXTURE_x).
>>> +   */
>>> +  bytes = _mesa_format_image_size64(format, width, height, depth);
>>
>> Don't we need to multiply bytes by _mesa_num_tex_faces() here too?
>
>
> Uh, that's done a few lines below.
>
Right. I can now see it's a common code. Sorry for the noise.
>>> +   }
>>> +
>>> +   bytes *= _mesa_num_tex_faces(target);
>>> +   bytes *= numSamples;
>>> +
>>> +   mbytes = bytes / (1024 * 1024); /* convert to MB */
>>> +
>>>  /* We just check if the image size is less than MaxTextureMbytes.
>>>   * Some drivers may do more specific checks.
>>>   */
>>> -   uint64_t bytes = _mesa_format_image_size64(format, width, height,
>>> depth);
>>> -   uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */
>>> -   mbytes *= _mesa_num_tex_faces(target);
>>>  return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes;
>>>   }
>>>
>>> --
>>> 1.9.1
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=Chw7SvWUSVQKjs40uL5HS7a3CnCLscN8vvbeFek5DJ8=OMMsCQ7_rpU1xc2WbqI6X64jcC4_RwtUhV_nnNtgtCE=
>
>

Series is:
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 05/10] egl/android: Respect buffer mask in droid_image_get_buffers

2016-07-15 Thread Emil Velikov
On 15 July 2016 at 08:53, Tomasz Figa  wrote:
> Drivers can request different set of buffers depending on the buffer
> mask they pass to the get_buffers callback. This patch makes
> droid_image_get_buffers() respect this mask.
>
> Signed-off-by: Tomasz Figa 
> ---
>  src/egl/drivers/dri2/platform_android.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index de1e5e6..7495445 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -434,16 +434,23 @@ droid_image_get_buffers(__DRIdrawable *driDrawable,
>  {
> struct dri2_egl_surface *dri2_surf = loaderPrivate;
>
> +   images->image_mask = 0;
> +
> if (update_buffers(dri2_surf) < 0)
>return 0;
>
> -   if (get_back_bo(dri2_surf) < 0) {
> -  _eglError(EGL_BAD_PARAMETER, "get_back_bo");
> +   if (buffer_mask & __DRI_IMAGE_BUFFER_FRONT) {
> +  _eglLog(_EGL_WARNING, "Front buffer is not supported for window 
> surfaces");
Not sure if using EGL_WARNING won't cause too much unnecessary "spam".
Although we could tweak that at later stage, if needed.

Reviewed-by: Emil Velikov 

Related: other platforms (platform_drm and platform_wayland) could use
the same fix. I believe they all share the EGL semantics of "Thou
shall not have a front buffer"

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


Re: [Mesa-dev] [Mesa-stable] i915: Enable EGL_KHR_{fence, wait}_sync

2016-07-15 Thread Mauro Rossi
2016-07-15 21:18 GMT+02:00 Emil Velikov :

> Hi Mauro,
>
> On 14 July 2016 at 04:33, Mauro Rossi  wrote:
> > Sending patches to implement DRI2_Fence extension for i915,
> > to enable EGL_KHR_fence_sync and EGL_KHR_wait_sync.
> >
> > It is the step-by-step porting to i915 of i965/sync,
> > plus patch to support {server,client}_wait_sync without bound context.
> >
> > [PATCH 1/3] i915/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync'
> > [PATCH 2/3] i915/sync: Implement DRI2_Fence extension
> These two are
> Acked-by: Emil Velikov 
>
> > [PATCH 3/3] i915: store reference to the context within struct
> >
> And this one needs a re-spin to include locking, as done my Tomasz.
>

I'm already doing the re-spin, I will submit v2 by step by step replication
of Tomasz patch for i915.


> > Motivation is to support (web)chromium which requires
> EGL_KHR_{fence,wait}_sync
> > Tested with marshmallow-x86 build on Asus Eee PC 1015PEM
> >
> Did you perform any tests as stated in the i965 "Implement DRI2_Fence
> extension" patch ? Afaict the new functionality is nicely separated so
> there's little chance for regressions but giving it greater testing
> would be appreciated.
>

Tests were performed by Paulo and they consisted in checking chromium
browser that was crashing without those features.

I will test on intel G33 in the weekend and  perform Android CTS deqp EGL
and report back.


>
> > Spotted by Paulo Travaglia 
> >
> > Cc: "12.0" 
> I'm not sold that these are stable material - they add feature and
> don't fix bug(s). If anything Android could use some updates to honour
> the lack of the EGL (EGL_KHR_fence_sync and EGL_KHR_wait_sync)
> extensions.
>

Thanks, I understand your point about additional features for mesa-stable.

It depends if we consider that these are step-by-step cloned from i965 ones,
with the only difference that 'brw' was renamed as 'intel' as in all other
similar functions in i915

Also these capabilities are independent from underlying HW, if I understood
correctly



> That said if the Intel devs are OK with having these in stable I won't
> object too much ;-)
>
> Thanks
> Emil
>

Merging in mesa-dev will be ok, If patches not accepted for mesa-stable it
is not a problem,
because they can be used as they are in android-x86 marshmallow-x86 branch.

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


Re: [Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()

2016-07-15 Thread Brian Paul

On 07/15/2016 01:19 PM, Anuj Phogat wrote:

On Fri, Jul 15, 2016 at 10:14 AM, Brian Paul  wrote:

If numSamples > 0, we can compute the size of the whole mipmapped texture.
That's the case for glTexStorage(GL_PROXY_TEXTURE_x).

Also, multiply the texture size by numSamples for MSAA textures.
---
  src/mesa/main/teximage.c | 48 +---
  1 file changed, 45 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index c75f605..0f13d61 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -40,6 +40,7 @@
  #include "image.h"
  #include "imports.h"
  #include "macros.h"
+#include "mipmap.h"
  #include "multisample.h"
  #include "pixelstore.h"
  #include "state.h"
@@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, 
GLenum target,
mesa_format format, GLuint numSamples,
GLint width, GLint height, GLint depth)
  {
+   uint64_t bytes, mbytes;
+
+   assert(numSamples > 0);
+
+   if (numLevels > 0) {
+  /* Compute total memory for a whole mipmap.  This is the path
+   * taken for glTexStorage(GL_PROXY_TEXTURE_x).
+   */
+  unsigned l;
+
+  assert(level == 0);
+
+  bytes = 0;
+
+  for (l = 0; l < numLevels; l++) {
+ GLint nextWidth, nextHeight, nextDepth;
+
+ /* XXX this doesn't yet account for multisampling */
+ bytes += _mesa_format_image_size64(format, width, height, depth);
+
+ if (_mesa_next_mipmap_level_size(target, 0, width, height, depth,
+  , ,
+  )) {
+width = nextWidth;
+height = nextHeight;
+depth = nextDepth;
+ }
+ else {
+break;
+ }
+  }
+   }
+   else {

nitpick. Use } else {


+  /* We just compute the size of one mipmap level.  This is the path
+   * taken for glTexImage(GL_PROXY_TEXTURE_x).
+   */
+  bytes = _mesa_format_image_size64(format, width, height, depth);

Don't we need to multiply bytes by _mesa_num_tex_faces() here too?


Uh, that's done a few lines below.


+   }
+
+   bytes *= _mesa_num_tex_faces(target);
+   bytes *= numSamples;
+
+   mbytes = bytes / (1024 * 1024); /* convert to MB */
+
 /* We just check if the image size is less than MaxTextureMbytes.
  * Some drivers may do more specific checks.
  */
-   uint64_t bytes = _mesa_format_image_size64(format, width, height, depth);
-   uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */
-   mbytes *= _mesa_num_tex_faces(target);
 return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes;
  }

--
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=Chw7SvWUSVQKjs40uL5HS7a3CnCLscN8vvbeFek5DJ8=OMMsCQ7_rpU1xc2WbqI6X64jcC4_RwtUhV_nnNtgtCE=


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


Re: [Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT

2016-07-15 Thread Emil Velikov
On 15 July 2016 at 18:57, Tomasz Figa  wrote:
> [Adding Haixia to the thread.]
>
> On Sat, Jul 16, 2016 at 2:52 AM, Eric Anholt  wrote:
>> Tomasz Figa  writes:
>>
>>> From: Haixia Shi 
>>>
>>> Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to
>>> hard-coded non-zero values. These two attributes are required on Android.
>>>
>>> Signed-off-by: Tomasz Figa 
>>> ---
>>>  src/egl/drivers/dri2/platform_android.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/src/egl/drivers/dri2/platform_android.c 
>>> b/src/egl/drivers/dri2/platform_android.c
>>> index b33f4e8..f42febc 100644
>>> --- a/src/egl/drivers/dri2/platform_android.c
>>> +++ b/src/egl/drivers/dri2/platform_android.c
>>> @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
>>> _EGLDisplay *dpy)
>>>   EGL_NATIVE_VISUAL_TYPE, 0,
>>>   EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE,
>>>   EGL_RECORDABLE_ANDROID, EGL_TRUE,
>>> + EGL_MAX_PBUFFER_WIDTH, 4096,
>>> + EGL_MAX_PBUFFER_HEIGHT, 4096,
>>>   EGL_NONE
>>
>> It seems weird to me to pick a plausible value that hardware might have,
>> without actually asking the hardware for the value.  Could we use some
>> MAX_INT-type value to make it obvious that we're just lying and leaving
>> it up to buffer creation time to error out?
>
> If I remember correctly, there are dEQP tests which attempt to use
> pbuffers bigger and bigger until reaching the limits and checking if
> they work properly. Haixia, what was the story behind hardcoding these
> values?
>
> I suppose the proper way would be to query the driver indeed...
>
IIRC we had a similar case, where when requesting the
EGL_LARGEST_PBUFFER we were capping to the width/height 4k in
_eglInitSurface. The reason behind the hardcoded (gross?) workaround
was that one cannot query the sane limits, at least from the xlib/xcb
side of EGL. See commit 582ae91e3a615afdecbb8c3dc98d1397ebee1cd6 for
more.

Perhaps the dEQP tests should set EGL_LARGEST_PBUFFER ? Alternatively
I'm wondering if we cannot have a common path for this/these
workarounds ?

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


Re: [Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()

2016-07-15 Thread Anuj Phogat
On Fri, Jul 15, 2016 at 10:14 AM, Brian Paul  wrote:
> If numSamples > 0, we can compute the size of the whole mipmapped texture.
> That's the case for glTexStorage(GL_PROXY_TEXTURE_x).
>
> Also, multiply the texture size by numSamples for MSAA textures.
> ---
>  src/mesa/main/teximage.c | 48 
> +---
>  1 file changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index c75f605..0f13d61 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -40,6 +40,7 @@
>  #include "image.h"
>  #include "imports.h"
>  #include "macros.h"
> +#include "mipmap.h"
>  #include "multisample.h"
>  #include "pixelstore.h"
>  #include "state.h"
> @@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, 
> GLenum target,
>mesa_format format, GLuint numSamples,
>GLint width, GLint height, GLint depth)
>  {
> +   uint64_t bytes, mbytes;
> +
> +   assert(numSamples > 0);
> +
> +   if (numLevels > 0) {
> +  /* Compute total memory for a whole mipmap.  This is the path
> +   * taken for glTexStorage(GL_PROXY_TEXTURE_x).
> +   */
> +  unsigned l;
> +
> +  assert(level == 0);
> +
> +  bytes = 0;
> +
> +  for (l = 0; l < numLevels; l++) {
> + GLint nextWidth, nextHeight, nextDepth;
> +
> + /* XXX this doesn't yet account for multisampling */
> + bytes += _mesa_format_image_size64(format, width, height, depth);
> +
> + if (_mesa_next_mipmap_level_size(target, 0, width, height, depth,
> +  , ,
> +  )) {
> +width = nextWidth;
> +height = nextHeight;
> +depth = nextDepth;
> + }
> + else {
> +break;
> + }
> +  }
> +   }
> +   else {
nitpick. Use } else {

> +  /* We just compute the size of one mipmap level.  This is the path
> +   * taken for glTexImage(GL_PROXY_TEXTURE_x).
> +   */
> +  bytes = _mesa_format_image_size64(format, width, height, depth);
Don't we need to multiply bytes by _mesa_num_tex_faces() here too?
> +   }
> +
> +   bytes *= _mesa_num_tex_faces(target);
> +   bytes *= numSamples;
> +
> +   mbytes = bytes / (1024 * 1024); /* convert to MB */
> +
> /* We just check if the image size is less than MaxTextureMbytes.
>  * Some drivers may do more specific checks.
>  */
> -   uint64_t bytes = _mesa_format_image_size64(format, width, height, depth);
> -   uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */
> -   mbytes *= _mesa_num_tex_faces(target);
> return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes;
>  }
>
> --
> 1.9.1
>
> ___
> 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] [Mesa-stable] i915: Enable EGL_KHR_{fence, wait}_sync

2016-07-15 Thread Emil Velikov
Hi Mauro,

On 14 July 2016 at 04:33, Mauro Rossi  wrote:
> Sending patches to implement DRI2_Fence extension for i915,
> to enable EGL_KHR_fence_sync and EGL_KHR_wait_sync.
>
> It is the step-by-step porting to i915 of i965/sync,
> plus patch to support {server,client}_wait_sync without bound context.
>
> [PATCH 1/3] i915/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync'
> [PATCH 2/3] i915/sync: Implement DRI2_Fence extension
These two are
Acked-by: Emil Velikov 

> [PATCH 3/3] i915: store reference to the context within struct
>
And this one needs a re-spin to include locking, as done my Tomasz.

> Motivation is to support (web)chromium which requires 
> EGL_KHR_{fence,wait}_sync
> Tested with marshmallow-x86 build on Asus Eee PC 1015PEM
>
Did you perform any tests as stated in the i965 "Implement DRI2_Fence
extension" patch ? Afaict the new functionality is nicely separated so
there's little chance for regressions but giving it greater testing
would be appreciated.

> Spotted by Paulo Travaglia 
>
> Cc: "12.0" 
I'm not sold that these are stable material - they add feature and
don't fix bug(s). If anything Android could use some updates to honour
the lack of the EGL (EGL_KHR_fence_sync and EGL_KHR_wait_sync)
extensions.

That said if the Intel devs are OK with having these in stable I won't
object too much ;-)

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


Re: [Mesa-dev] [PATCH v4 18/34] i965/blorp: Use the generic ISL path for texture surfaces on gen6

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/gen6_blorp.c | 76 
> +-
>  1 file changed, 2 insertions(+), 74 deletions(-)

Patches 14-18 are
Reviewed-by: Chad Versace 

That's the whole series, now. Did I miss anything?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 13/34] i965/blorp: Add a generic ISL-based surface state emit path

2016-07-15 Thread Chad Versace
On Thu 14 Jul 2016, Jason Ekstrand wrote:
> On Thu, Jul 14, 2016 at 2:26 PM, Chad Versace 
> wrote:
> 
> > On Wed 13 Jul 2016, Jason Ekstrand wrote:
> > > Reviewed-by: Topi Pohjolainen 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_blorp.c | 157
> > ++
> > >  src/mesa/drivers/dri/i965/brw_blorp.h |   6 ++
> > >  2 files changed, 163 insertions(+)



> > > +   struct isl_view view = {
> > > +  .format = surface->brw_surfaceformat,
> > > +  .base_level = 0,
> > > +  .levels = 1,
> > > +  .base_array_layer = 0,
> > > +  .array_len = 1,
> > > +  .channel_select = {
> > > + ISL_CHANNEL_SELECT_RED,
> > > + ISL_CHANNEL_SELECT_GREEN,
> > > + ISL_CHANNEL_SELECT_BLUE,
> > > + ISL_CHANNEL_SELECT_ALPHA,
> > > +  },
> > > +  .usage = is_render_target ? ISL_SURF_USAGE_RENDER_TARGET_BIT :
> > > +  ISL_SURF_USAGE_TEXTURE_BIT,
> > > +   };
> >
> > Are you confident that blorp never requires ISL_SURF_USAGE_CUBE_MAP_BIT?
> >
> 
> Yes, very confident.  That's only required if you're going to use a cube
> sampler.  Blorp has no need for cube samplers.

Ok. That's what I thought too. Just wanted to confirm.

> 
> 
> >
> > > +
> > > +   uint32_t offset, tile_x, tile_y;
> > > +   offset = brw_blorp_compute_tile_offsets(surface, _x, _y);
> > > +
> > > +   uint32_t surf_offset;
> > > +   uint32_t *dw = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
> > > +  ss_info.num_dwords * 4,
> > ss_info.ss_align,
> > > +  _offset);
> > > +
> > > +   const uint32_t mocs = is_render_target ? ss_info.rb_mocs :
> > ss_info.tex_mocs;
> > > +
> > > +   isl_surf_fill_state(>isl_dev, dw, .surf = , .view = ,
> > > +   .address = surface->mt->bo->offset64 + offset,
> > > +   .aux_surf = aux_surf, .aux_usage = aux_usage,
> > > +   .aux_address = aux_offset,
> > > +   .mocs = mocs, .clear_color = clear_color,
> > > +   .x_offset_sa = tile_x, .y_offset_sa = tile_y);
> >
> > Whoa! Where did x_offset_sa and y_offset_sa come from? It's not on
> > master, and I didn't see it in any earlier patches.
> >

Yep, I see it now.

This patch is
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 34/34] i965/context: Remove some unnecessary vfuncs

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h   | 17 -
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c  |  3 +--
>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |  1 -
>  src/mesa/drivers/dri/i965/gen8_surface_state.c|  1 -
>  4 files changed, 1 insertion(+), 21 deletions(-)

Reviewed-by: Chad Versace 

I'm done with all the non-blorp patches, I believe. Let me know if
I missed anything. I'll resume at the blorp patches now.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 33/34] i965: Get rid of gen6_surface_state.c

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> The only useful thing left was gen6_init_vtable_surface_functions which we
> can easily put in brw_wm_surface_state.c.
> 
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources   |  1 -
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  7 
>  src/mesa/drivers/dri/i965/gen6_surface_state.c   | 48 
> 
>  3 files changed, 7 insertions(+), 49 deletions(-)
>  delete mode 100644 src/mesa/drivers/dri/i965/gen6_surface_state.c

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


Re: [Mesa-dev] [PATCH v4 25/34] i965/gen8: Use the generic ISL-based path for renderbuffer surfaces

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_state.h  |  16 --
>  src/mesa/drivers/dri/i965/gen8_surface_state.c | 249 
> +
>  2 files changed, 2 insertions(+), 263 deletions(-)

That diff has a lot of -'s :)  Bye bye code!

Looks good to me,
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 29/34] i965/gen4-6: Use the generic ISL-based path for texture surfaces

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 94 
> +---
>  1 file changed, 1 insertion(+), 93 deletions(-)

Patches 28 and 29 are
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 31/34] i965/state: Account for the element size in emit_buffer_surface_state

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c  | 11 ++-
>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |  9 +
>  src/mesa/drivers/dri/i965/gen8_surface_state.c|  9 +
>  3 files changed, 16 insertions(+), 13 deletions(-)

Patches 30 and 31 are
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 32/34] i965: Use ISL for emitting buffer surface states

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_binding_tables.c|  2 +-
>  src/mesa/drivers/dri/i965/brw_context.h   |  8 --
>  src/mesa/drivers/dri/i965/brw_state.h |  9 +++
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c  | 93 
> +++
>  src/mesa/drivers/dri/i965/gen7_cs_state.c |  2 +-
>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 47 
>  src/mesa/drivers/dri/i965/gen8_surface_state.c| 42 --
>  7 files changed, 55 insertions(+), 148 deletions(-)

Patch 32 is
Reviewed-by: Chad Versace 

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


Re: [Mesa-dev] [PATCH v4 27/34] i965/gen7: Use the generic ISL-based path for renderbuffer surfaces

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_state.h |   7 -
>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 194 
> +-
>  2 files changed, 1 insertion(+), 200 deletions(-)

More --'s !

Patches 26 and 27 (the gen7 patches) are
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

2016-07-15 Thread Andy Furniss

Andy Furniss wrote:


omx doesn't have this issue, for 30mbit the files produced are 53M
and 26M.


Actually by default omx will make the same size files, I lucked into that
behavior playing around with the control-rate param.

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


Re: [Mesa-dev] [PATCH v4 23/34] i965/state: Add generic surface update functions based on ISL

2016-07-15 Thread Chad Versace
On Wed 13 Jul 2016, Jason Ekstrand wrote:
> Reviewed-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/brw_state.h|   9 ++
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 184 
> +++
>  2 files changed, 193 insertions(+)


> +void
> +brw_update_texture_surface(struct gl_context *ctx,
> +   unsigned unit,
> +   uint32_t *surf_offset,
> +   bool for_gather,
> +   uint32_t plane)
> +{
> +   struct brw_context *brw = brw_context(ctx);
> +   struct gl_texture_object *obj = ctx->Texture.Unit[unit]._Current;
> +
> +   if (obj->Target == GL_TEXTURE_BUFFER) {
> +  brw_update_buffer_texture_surface(ctx, unit, surf_offset);
> +
> +   } else {
> +  struct intel_texture_object *intel_obj = intel_texture_object(obj);
> +  struct intel_mipmap_tree *mt = intel_obj->mt;
> +  struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, unit);
> +  /* If this is a view with restricted NumLayers, then our effective 
> depth
> +   * is not just the miptree depth.
> +   */
> +  const unsigned mt_num_layers =
> + mt->logical_depth0 * (_mesa_is_cube_map_texture(mt->target) ? 6 : 
> 1);
> +  const unsigned depth = (obj->Immutable && obj->Target != GL_TEXTURE_3D 
> ?
> +  obj->NumLayers : mt_num_layers);

Since 'depth' here is no longer depth, I would prefer that it be named
better. Below, the code does 'view.array_len = depth', so the name
'view_array_len' or 'view_num_layers' seems appropriate. Just
a suggestion.


...

> +  struct isl_view view = {
> + .format = format,
> + .base_level = obj->MinLevel + obj->BaseLevel,
> + .levels = intel_obj->_MaxLevel - obj->BaseLevel + 1,
> + .base_array_layer = obj->MinLayer,
> + .array_len = depth,
> + .channel_select = {
> +swizzle_to_scs(GET_SWZ(swizzle, 0), need_green_to_blue),
> +swizzle_to_scs(GET_SWZ(swizzle, 1), need_green_to_blue),
> +swizzle_to_scs(GET_SWZ(swizzle, 2), need_green_to_blue),
> +swizzle_to_scs(GET_SWZ(swizzle, 3), need_green_to_blue),
> + },
> + .usage = ISL_SURF_USAGE_TEXTURE_BIT,
> +  };
> +
> +  if (obj->Target == GL_TEXTURE_CUBE_MAP ||
> +  obj->Target == GL_TEXTURE_CUBE_MAP_ARRAY)
> + view.usage |= ISL_SURF_USAGE_CUBE_BIT;
> +
> +  brw_emit_surface_state(brw, mt, ,
> + surface_state_infos[brw->gen].tex_mocs, 
> for_gather,
> + surf_offset, surf_index,
> + I915_GEM_DOMAIN_SAMPLER, 0);
> +   }



Looks good.
Reviewed-by: Chad Versace 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 04/10] egl/android: Stop leaking DRI images

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> Hi Eric,
>
> On Sat, Jul 16, 2016 at 3:05 AM, Eric Anholt  wrote:
>> Tomasz Figa  writes:
>>
>>> Current implementation of the DRI image loader does not free the images
>>> created in get_back_bo() and so leaks memory. Moreover, it creates a new
>>> image every time the DRI driver queries for buffers, even if the backing
>>> native buffer has not changed. leaking memory again.
>>>
>>> This patch adds missing call to destroyImage() in droid_enqueue_buffer()
>>> and a check if image is already created to get_back_bo() to fix the
>>> above.
>>
>> This patch is:
>>
>> Reviewed-by: Eric Anholt 
>>
>> But I noticed in review, it looks like droid_destroy_surface() could
>> also use an image destroy.
>
> Thanks for review!
>
> It already calls droid_window_cancel_buffer(), which in turns calls
> droid_window_enqueue_buffer() (typo in commit message...). Or you mean
> something else I didn't notice?

Ah, I missed that path.  Excellent.


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


Re: [Mesa-dev] [PATCH 10/10] egl/android: Add fallback to kms_swrast driver

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> If no hardware driver is present, it is possible to fall back to
> the kms_swrast driver with any DRI node that supports dumb GEM create
> and mmap IOCTLs with softpipe/llvmpipe drivers. This patch makes the
> Android EGL platform code retry probe with kms_swrast if hardware-only
> probe fails.

This seems sensible, and if you change the "int swrast" and 0/1s to some
sort of boolean (I guess EGLBoolean?), it's:

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 08/10] egl/android: Make get_fourcc() accept HAL formats

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> There are DRI_IMAGE_FOURCC macros, for which there are no corresponding
> DRI_IMAGE_FORMAT macros. To support such formats we need to make the
> lookup function take the native format directly. As a side effect, it
> simplifies all existing calls to this function, because they all called
> get_format() first to convert from native to DRI_IMAGE_FORMAT.
>
> Signed-off-by: Tomasz Figa 
> ---
>  src/egl/drivers/dri2/platform_android.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 4473400..26d7b35 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -69,18 +69,20 @@ get_format_bpp(int native)
>  }
>  
>  /* createImageFromFds requires fourcc format */
> -static int get_fourcc(int format)
> +static int get_fourcc(int native)
>  {
> -   switch(format) {
> -   case __DRI_IMAGE_FORMAT_RGB565:   return __DRI_IMAGE_FOURCC_RGB565;
> -   case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
> -   case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
> -   case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR;
> -   case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR;
> +   switch (native) {
> +   case HAL_PIXEL_FORMAT_RGB_565:   return __DRI_IMAGE_FOURCC_RGB565;
> +   case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FOURCC_ARGB;
> +   case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FOURCC_ABGR;
> +   case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
> +   default:
> +  _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native);
> }
> return -1;
>  }
>  
> +#ifdef HAS_GRALLOC_DRM_HEADERS
>  static int get_format(int format)
>  {
> switch (format) {
> @@ -95,6 +97,8 @@ static int get_format(int format)
> }
> return -1;
>  }
> +#endif
> +
>  static int
>  get_native_buffer_fd(struct ANativeWindowBuffer *buf)
>  {
> @@ -435,7 +439,7 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
>return -1;
> }
>  
> -   fourcc = get_fourcc(get_format(dri2_surf->buffer->format));
> +   fourcc = get_fourcc(dri2_surf->buffer->format);
>  
> pitch = dri2_surf->buffer->stride *
>get_format_bpp(dri2_surf->buffer->format);
> @@ -525,7 +529,7 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, 
> _EGLContext *ctx,
> if (fd < 0)
>  return NULL;
>  
> -   const int fourcc = get_fourcc(get_format(buf->format));
> +   const int fourcc = get_fourcc(buf->format);
> const int pitch = buf->stride * get_format_bpp(buf->format);
>  
> const EGLint attr_list[14] = {
> -- 

It looks like this patch could get moved before the previous one, and
then the HAS_GRALLOC_DRM_HEADERS additions could all be in that patch.

I don't know enough about the state of various grallocs to review that
one.


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


Re: [Mesa-dev] [PATCH 06/10] egl/android: Fix support for pbuffers

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> From: Nicolas Boichat 
>
> Existing image loader code supports creating images only for window
> surfaces. Moreover droid_create_surface() passes wrong surface type to
> dri2_get_dri_config(), resulting in incorrect configs being returned for
> pbuffers. This patch fixes these issues.
>
> In addition, the config generation code is fixed to include single
> buffered contexts required for pbuffers and make sure that generated
> configs support only surfaces which can handle their supported buffering
> modes.
>
> Signed-off-by: Nicolas Boichat 
> Signed-off-by: Tomasz Figa 
> ---
>  src/egl/drivers/dri2/egl_dri2.h |  1 +
>  src/egl/drivers/dri2/platform_android.c | 61 
> +++--
>  2 files changed, 51 insertions(+), 11 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index 317de06..3ffc177 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -287,6 +287,7 @@ struct dri2_egl_surface
> struct ANativeWindow *window;
> struct ANativeWindowBuffer *buffer;
> __DRIimage *dri_image;
> +   __DRIimage *dri_front_image;
>  
> /* EGL-owned buffers */
> __DRIbuffer   *local_buffers[__DRI_BUFFER_COUNT];
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 7495445..0f707dd 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -728,6 +754,19 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
> _EGLDisplay *dpy)
>/* there is no front buffer so no OpenGL */
>dri2_conf->base.RenderableType &= ~EGL_OPENGL_BIT;
>dri2_conf->base.Conformant &= ~EGL_OPENGL_BIT;
> +
> +  for (j = 0; j < 2; j++) {
> + /* Unsupported color space variants should not affect surface type. 
> */
> + if (!dri2_conf->dri_single_config[j] && 
> !dri2_conf->dri_double_config[j])
> +continue;
> +
> + /* Pbuffers support only single buffering. */
> + if (!dri2_conf->dri_single_config[j])
> +dri2_conf->base.SurfaceType &= ~EGL_PBUFFER_BIT;
> + /* Windows support only double buffering. */
> + else if (!dri2_conf->dri_double_config[j])
> +dri2_conf->base.SurfaceType &= ~EGL_WINDOW_BIT;
> +  }

Style nitpick, I'd either drop the "else" or use some braces and put the
comments within the inner blocks.  Having the "else if" separated from
the "if" by the comment looked weird.  Up to you, though.

The actual contents of the patch are:

Reviewed-by: Eric Anholt 


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


[Mesa-dev] [Bug 96943] [gallium] glCopyPixels is affected by enabled texture state

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96943

--- Comment #2 from Ilia Mirkin  ---
(In reply to Roland Scheidegger from comment #1)
> The piglit test is probably wrong (I didn't really look), at least different
> results based on enabled texturing don't surprise me. This is one of the
> more weird "features" of glCopyPixels(), glDrawPixels() and friends.
> From the respective man pages:
> "Texture mapping, fog, and all the fragment operations are applied before
> the fragments are written to the frame buffer." So if you don't disable
> texturing, you'll get texturing on top of your copied pixels (which just
> represent the primary color), in whatever way the shader specified (albeit
> the texture coords should be constant IIRC).

OK, so in that case, any time that a texture unit is enabled, we should be
falling back to the drawpixels-style shader? (The multiply, btw, is coming from
the texture combine logic, which defaults to "combine" aka "multiply".)

-- 
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 04/10] egl/android: Stop leaking DRI images

2016-07-15 Thread Tomasz Figa
Hi Eric,

On Sat, Jul 16, 2016 at 3:05 AM, Eric Anholt  wrote:
> Tomasz Figa  writes:
>
>> Current implementation of the DRI image loader does not free the images
>> created in get_back_bo() and so leaks memory. Moreover, it creates a new
>> image every time the DRI driver queries for buffers, even if the backing
>> native buffer has not changed. leaking memory again.
>>
>> This patch adds missing call to destroyImage() in droid_enqueue_buffer()
>> and a check if image is already created to get_back_bo() to fix the
>> above.
>
> This patch is:
>
> Reviewed-by: Eric Anholt 
>
> But I noticed in review, it looks like droid_destroy_surface() could
> also use an image destroy.

Thanks for review!

It already calls droid_window_cancel_buffer(), which in turns calls
droid_window_enqueue_buffer() (typo in commit message...). Or you mean
something else I didn't notice?

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


[Mesa-dev] [Bug 96943] [gallium] glCopyPixels is affected by enabled texture state

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96943

--- Comment #1 from Roland Scheidegger  ---
(In reply to Ilia Mirkin from comment #0)
> The recently rewritten copy-pixels test has exposed some failures in
> st/mesa. When there's an overlapping copy (among other conditions), the
> operation becomes a fb read + draw of that texture with the current fragment
> shader modified in the same way as glDrawPixels does it. (So this problem
> might extend itself to glDrawPixels as well).
> 
> Doing a glDisable(GL_TEXTURE_2D) before the glCopyPixels() call in the
> piglit fixes the issue. Effectively that texture is being multiplied with
> the copied data, whereas from what I can tell, it shouldn't be. I think the
> multiplication comes from the ff-generated shader.
> 
> [An alternative is that the piglit test and i965 are wrong and what gallium
> is doing is correct. I don't think that's the case, since the only
> disagreement is on the overlapped copy.]


The piglit test is probably wrong (I didn't really look), at least different
results based on enabled texturing don't surprise me. This is one of the more
weird "features" of glCopyPixels(), glDrawPixels() and friends.
>From the respective man pages:
"Texture mapping, fog, and all the fragment operations are applied before the
fragments are written to the frame buffer." So if you don't disable texturing,
you'll get texturing on top of your copied pixels (which just represent the
primary color), in whatever way the shader specified (albeit the texture coords
should be constant IIRC).

Near certainly this actually isn't what an app wants to do... And yes I'd be
very surprised if mesa (or any other implementation) actually gets it right all
the time.

-- 
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 04/10] egl/android: Stop leaking DRI images

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> Current implementation of the DRI image loader does not free the images
> created in get_back_bo() and so leaks memory. Moreover, it creates a new
> image every time the DRI driver queries for buffers, even if the backing
> native buffer has not changed. leaking memory again.
>
> This patch adds missing call to destroyImage() in droid_enqueue_buffer()
> and a check if image is already created to get_back_bo() to fix the
> above.

This patch is:

Reviewed-by: Eric Anholt 

But I noticed in review, it looks like droid_destroy_surface() could
also use an image destroy.


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


Re: [Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT

2016-07-15 Thread Tomasz Figa
[Adding Haixia to the thread.]

On Sat, Jul 16, 2016 at 2:52 AM, Eric Anholt  wrote:
> Tomasz Figa  writes:
>
>> From: Haixia Shi 
>>
>> Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to
>> hard-coded non-zero values. These two attributes are required on Android.
>>
>> Signed-off-by: Tomasz Figa 
>> ---
>>  src/egl/drivers/dri2/platform_android.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/src/egl/drivers/dri2/platform_android.c 
>> b/src/egl/drivers/dri2/platform_android.c
>> index b33f4e8..f42febc 100644
>> --- a/src/egl/drivers/dri2/platform_android.c
>> +++ b/src/egl/drivers/dri2/platform_android.c
>> @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
>> _EGLDisplay *dpy)
>>   EGL_NATIVE_VISUAL_TYPE, 0,
>>   EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE,
>>   EGL_RECORDABLE_ANDROID, EGL_TRUE,
>> + EGL_MAX_PBUFFER_WIDTH, 4096,
>> + EGL_MAX_PBUFFER_HEIGHT, 4096,
>>   EGL_NONE
>
> It seems weird to me to pick a plausible value that hardware might have,
> without actually asking the hardware for the value.  Could we use some
> MAX_INT-type value to make it obvious that we're just lying and leaving
> it up to buffer creation time to error out?

If I remember correctly, there are dEQP tests which attempt to use
pbuffers bigger and bigger until reaching the limits and checking if
they work properly. Haixia, what was the story behind hardcoding these
values?

I suppose the proper way would be to query the driver indeed...

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


Re: [Mesa-dev] [PATCH 4/4] anv: Handle VK_WHOLE_SIZE properly for buffer views

2016-07-15 Thread Jason Ekstrand
On Fri, Jul 15, 2016 at 9:57 AM, Nanley Chery  wrote:

> On Thu, Jul 14, 2016 at 09:20:08PM -0700, Jason Ekstrand wrote:
> > The old calculation, which used view->offset, encorporated buffer->offset
> > into the size calculation where it doesn't belong.  This meant that, if
> > buffer->offset > buffer->size, you would always get a negative size.
> This
> > fixes 170 dEQP-VK.renderpass.attachment.* Vulkan CTS tests on Haswell.
> >
>
> Nice patch.
>
> > Signed-off-by: Jason Ekstrand 
> > Cc: "12.0" 
> > ---
> >  src/intel/vulkan/anv_image.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> > index 23fdd93..fe5b124 100644
> > --- a/src/intel/vulkan/anv_image.c
> > +++ b/src/intel/vulkan/anv_image.c
> > @@ -631,7 +631,7 @@ void anv_buffer_view_init(struct anv_buffer_view
> *view,
> > view->bo = buffer->bo;
> > view->offset = buffer->offset + pCreateInfo->offset;
> > view->range = pCreateInfo->range == VK_WHOLE_SIZE ?
> > - buffer->size - view->offset : pCreateInfo->range;
> > + buffer->size - pCreateInfo->offset :
> pCreateInfo->range;
> >
>
> This is almost correct. The range member definition (11.2. Buffer Views)
> has a corner case for VK_WHOLE_SIZE. It states that if
> R = (buffer_size - buffer_view_offset) is not a multiple of
> buffer_view_format_size, then you must set the range member to
> the nearest smaller multiple of buffer_view_format_size.
>

Thanks for your care!  I was not thinking of that corner-case.


> Which is to say,
>  if (requested_range == VK_WHOLE_SIZE)
> actual_range = ALIGN_DOWN(R, buffer_view_format_size);
>

That said, the hardware packet is in number of elements so we divide by the
format size and round down in isl_buffer_fill_state so I think it's ok.
--Jason


>
> - Nanley
>
> > if (buffer->usage & VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT) {
> >view->surface_state = alloc_surface_state(device, cmd_buffer);
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 03/10] egl/android: Add some useful error messages

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> It is much easier to debug issues when the application gives some
> meaningful error messages. This patch adds few to the EGL Android
> platform backend.
>
> Signed-off-by: Tomasz Figa 

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> From: Haixia Shi 
>
> Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to
> hard-coded non-zero values. These two attributes are required on Android.
>
> Signed-off-by: Tomasz Figa 
> ---
>  src/egl/drivers/dri2/platform_android.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index b33f4e8..f42febc 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
> _EGLDisplay *dpy)
>   EGL_NATIVE_VISUAL_TYPE, 0,
>   EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE,
>   EGL_RECORDABLE_ANDROID, EGL_TRUE,
> + EGL_MAX_PBUFFER_WIDTH, 4096,
> + EGL_MAX_PBUFFER_HEIGHT, 4096,
>   EGL_NONE

It seems weird to me to pick a plausible value that hardware might have,
without actually asking the hardware for the value.  Could we use some
MAX_INT-type value to make it obvious that we're just lying and leaving
it up to buffer creation time to error out?


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


Re: [Mesa-dev] [PATCH 02/10] egl/android: Check return value of dri2_get_dri_config()

2016-07-15 Thread Eric Anholt
Tomasz Figa  writes:

> It might return NULL if specific config variant is unsupported.
>
> Signed-off-by: Tomasz Figa 

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

2016-07-15 Thread Andy Furniss

Zhang, Boyuan wrote:

Hi Andy,

Thanks for the testing. I will look into the memory issue. For the
cbr test, what was the bitrate you set? And by saying testing high
rates, how high was the rate approximately?


Testing more shows that I get the same size file independent of
framerate. An example inputting rawvideo and asking gstreamer for 30mbit
with 500 frames 2560x1440 for both 25fps and 50fps produces 60M byte
files for both.

omx doesn't have this issue, for 30mbit the files produced are 53M and 26M.

Also noted that omx takes 3.8 seconds and vaapi 13.8 for the same input.




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


Re: [Mesa-dev] [PATCH 10/14] isl: Add support for HiZ surfaces

2016-07-15 Thread Nanley Chery
On Thu, Jul 14, 2016 at 04:18:33PM -0700, Jason Ekstrand wrote:
> On Thu, Jul 14, 2016 at 4:13 PM, Nanley Chery  wrote:
> 
> > On Thu, Jul 14, 2016 at 03:57:09PM -0700, Jason Ekstrand wrote:
> > > On Thu, Jul 14, 2016 at 3:45 PM, Nanley Chery 
> > wrote:
> > >
> > > > On Sat, Jul 09, 2016 at 12:17:28PM -0700, Jason Ekstrand wrote:
> > > > > ---
> > > > >  src/intel/isl/isl.c | 11 +++
> > > > >  src/intel/isl/isl.h | 17 +
> > > > >  src/intel/isl/isl_format_layout.csv |  1 +
> > > > >  src/intel/isl/isl_gen6.c|  8 
> > > > >  src/intel/isl/isl_gen7.c| 10 +-
> > > > >  src/intel/isl/isl_gen8.c|  3 ++-
> > > > >  6 files changed, 48 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > > > > index 8c114a2..9ccdea2 100644
> > > > > --- a/src/intel/isl/isl.c
> > > > > +++ b/src/intel/isl/isl.c
> > > > > @@ -167,6 +167,16 @@ isl_tiling_get_info(const struct isl_device
> > *dev,
> > > > >break;
> > > > > }
> > > > >
> > > > > +   case ISL_TILING_HIZ:
> > > > > +  /* HiZ buffers are required to have ISL_FORMAT_HIZ which is
> > an 8x4
> > > > > +   * 128bpb format.  The tiling has the same physical
> > dimensions as
> > > > > +   * Y-tiling but actually has two HiZ columns per Y-tiled
> > column.
> > > > > +   */
> > > > > +  assert(bs == 16);
> > > > > +  logical_el = isl_extent2d(16, 16);
> > > > > +  phys_B = isl_extent2d(128, 32);
> > > > > +  break;
> > > > > +
> > > > > default:
> > > > >unreachable("not reached");
> > > > > } /* end switch */
> > > > > @@ -221,6 +231,7 @@ isl_surf_choose_tiling(const struct isl_device
> > *dev,
> > > > >CHOOSE(ISL_TILING_LINEAR);
> > > > > }
> > > > >
> > > > > +   CHOOSE(ISL_TILING_HIZ);
> > > > > CHOOSE(ISL_TILING_Ys);
> > > > > CHOOSE(ISL_TILING_Yf);
> > > > > CHOOSE(ISL_TILING_Y0);
> > > > > diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> > > > > index 85af2d1..9a60bbd 100644
> > > > > --- a/src/intel/isl/isl.h
> > > > > +++ b/src/intel/isl/isl.h
> > > > > @@ -345,6 +345,14 @@ enum isl_format {
> > > > > ISL_FORMAT_ASTC_LDR_2D_12X10_FLT16 =638,
> > > > > ISL_FORMAT_ASTC_LDR_2D_12X12_FLT16 =639,
> > > > >
> > > > > +   /* The formats that follow are internal to ISL and as such don't
> > > > have an
> > > > > +* explicit number.  We'll just let the C compiler assign it for
> > > > us.  Any
> > > > > +* actual hardware formats *must* come before these in the list.
> > > > > +*/
> > > > > +
> > > > > +   /* Formats for color compression surfaces */
> > > > > +   ISL_FORMAT_HIZ,
> > > >
> > > > Why is HiZ a color compression surface instead of a depth compression
> > > > surface?
> > > >
> > >
> > > Aux surfaces then?  It's not really "color" compression...
> > >
> >
> > That works.
> >
> > >
> > > >
> > > > > +
> > > > > /* Hardware doesn't understand this out-of-band value */
> > > > > ISL_FORMAT_UNSUPPORTED = UINT16_MAX,
> > > > >  };
> > > > > @@ -392,6 +400,9 @@ enum isl_txc {
> > > > > ISL_TXC_ETC1,
> > > > > ISL_TXC_ETC2,
> > > > > ISL_TXC_ASTC,
> > > > > +
> > > > > +   /* Used for auxiliary surface formats */
> > > > > +   ISL_TXC_HIZ,
> > > > >  };
> > > > >
> > > > >  /**
> > > > > @@ -410,6 +421,7 @@ enum isl_tiling {
> > > > > ISL_TILING_Y0, /**< Legacy Y tiling */
> > > > > ISL_TILING_Yf, /**< Standard 4K tiling. The 'f' means "four". */
> > > > > ISL_TILING_Ys, /**< Standard 64K tiling. The 's' means
> > "sixty-four".
> > > > */
> > > > > +   ISL_TILING_HIZ, /**< Tiling format for HiZ surfaces */
> > > > >  };
> > > > >
> > > > >  /**
> > > > > @@ -423,6 +435,7 @@ typedef uint32_t isl_tiling_flags_t;
> > > > >  #define ISL_TILING_Y0_BIT (1u << ISL_TILING_Y0)
> > > > >  #define ISL_TILING_Yf_BIT (1u << ISL_TILING_Yf)
> > > > >  #define ISL_TILING_Ys_BIT (1u << ISL_TILING_Ys)
> > > > > +#define ISL_TILING_HIZ_BIT(1u << ISL_TILING_HIZ)
> > > > >  #define ISL_TILING_ANY_MASK   (~0u)
> > > > >  #define ISL_TILING_NON_LINEAR_MASK(~ISL_TILING_LINEAR_BIT)
> > > > >
> > > > > @@ -505,6 +518,7 @@ typedef uint64_t isl_surf_usage_flags_t;
> > > > >  #define ISL_SURF_USAGE_DISPLAY_FLIP_X_BIT  (1u << 10)
> > > > >  #define ISL_SURF_USAGE_DISPLAY_FLIP_Y_BIT  (1u << 11)
> > > > >  #define ISL_SURF_USAGE_STORAGE_BIT (1u << 12)
> > > > > +#define ISL_SURF_USAGE_HIZ_BIT (1u << 13)
> > > > >  /** @} */
> > > > >
> > > > >  /**
> > > > > @@ -966,6 +980,9 @@ isl_format_has_bc_compression(enum isl_format
> > fmt)
> > > > > case ISL_TXC_ETC2:
> > > > > case ISL_TXC_ASTC:
> > > > >return false;
> > > > > +
> > > > > +   case 

[Mesa-dev] [PATCH 4/4] mesa: handle numLevels, numSamples in _mesa_test_proxy_teximage()

2016-07-15 Thread Brian Paul
If numSamples > 0, we can compute the size of the whole mipmapped texture.
That's the case for glTexStorage(GL_PROXY_TEXTURE_x).

Also, multiply the texture size by numSamples for MSAA textures.
---
 src/mesa/main/teximage.c | 48 +---
 1 file changed, 45 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index c75f605..0f13d61 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -40,6 +40,7 @@
 #include "image.h"
 #include "imports.h"
 #include "macros.h"
+#include "mipmap.h"
 #include "multisample.h"
 #include "pixelstore.h"
 #include "state.h"
@@ -1268,12 +1269,53 @@ _mesa_test_proxy_teximage(struct gl_context *ctx, 
GLenum target,
   mesa_format format, GLuint numSamples,
   GLint width, GLint height, GLint depth)
 {
+   uint64_t bytes, mbytes;
+
+   assert(numSamples > 0);
+
+   if (numLevels > 0) {
+  /* Compute total memory for a whole mipmap.  This is the path
+   * taken for glTexStorage(GL_PROXY_TEXTURE_x).
+   */
+  unsigned l;
+
+  assert(level == 0);
+
+  bytes = 0;
+
+  for (l = 0; l < numLevels; l++) {
+ GLint nextWidth, nextHeight, nextDepth;
+
+ /* XXX this doesn't yet account for multisampling */
+ bytes += _mesa_format_image_size64(format, width, height, depth);
+
+ if (_mesa_next_mipmap_level_size(target, 0, width, height, depth,
+  , ,
+  )) {
+width = nextWidth;
+height = nextHeight;
+depth = nextDepth;
+ }
+ else {
+break;
+ }
+  }
+   }
+   else {
+  /* We just compute the size of one mipmap level.  This is the path
+   * taken for glTexImage(GL_PROXY_TEXTURE_x).
+   */
+  bytes = _mesa_format_image_size64(format, width, height, depth);
+   }
+
+   bytes *= _mesa_num_tex_faces(target);
+   bytes *= numSamples;
+
+   mbytes = bytes / (1024 * 1024); /* convert to MB */
+
/* We just check if the image size is less than MaxTextureMbytes.
 * Some drivers may do more specific checks.
 */
-   uint64_t bytes = _mesa_format_image_size64(format, width, height, depth);
-   uint64_t mbytes = bytes / (1024 * 1024); /* convert to MB */
-   mbytes *= _mesa_num_tex_faces(target);
return mbytes <= (uint64_t) ctx->Const.MaxTextureMbytes;
 }
 
-- 
1.9.1

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


[Mesa-dev] [PATCH 1/4] mesa: use _mesa_clear_texture_image() in clear_texture_fields()

2016-07-15 Thread Brian Paul
This avoids a failed assert(img->_BaseFormat != -1) in
init_teximage_fields_ms() because the internalFormat argument is GL_NONE.
This was hit when using glTexStorage() to do a proxy texture test.

Fixes a failure with the updated Piglit tex3d-maxsize test.

Cc: 
---
 src/mesa/main/texstorage.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index f4a0760..72ed869 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -179,9 +179,7 @@ clear_texture_fields(struct gl_context *ctx,
 return;
 }
 
- _mesa_init_teximage_fields(ctx, texImage,
-0, 0, 0, 0, /* w, h, d, border */
-GL_NONE, MESA_FORMAT_NONE);
+ _mesa_clear_texture_image(ctx, texImage);
   }
}
 }
-- 
1.9.1

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


[Mesa-dev] [PATCH 3/4] mesa: add proxy texture targets in _mesa_next_mipmap_level_size()

2016-07-15 Thread Brian Paul
So we can use it for computing size of proxy textures.
---
 src/mesa/main/mipmap.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 5ff53f4..996e3f8 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -1777,7 +1777,8 @@ _mesa_next_mipmap_level_size(GLenum target, GLint border,
}
 
if ((srcHeight - 2 * border > 1) && 
-   (target != GL_TEXTURE_1D_ARRAY_EXT)) {
+   target != GL_TEXTURE_1D_ARRAY_EXT &&
+   target != GL_PROXY_TEXTURE_1D_ARRAY_EXT) {
   *dstHeight = (srcHeight - 2 * border) / 2 + 2 * border;
}
else {
@@ -1785,8 +1786,10 @@ _mesa_next_mipmap_level_size(GLenum target, GLint border,
}
 
if ((srcDepth - 2 * border > 1) &&
-   (target != GL_TEXTURE_2D_ARRAY_EXT &&
-target != GL_TEXTURE_CUBE_MAP_ARRAY)) {
+   target != GL_TEXTURE_2D_ARRAY_EXT &&
+   target != GL_PROXY_TEXTURE_2D_ARRAY_EXT &&
+   target != GL_TEXTURE_CUBE_MAP_ARRAY &&
+   target != GL_PROXY_TEXTURE_CUBE_MAP_ARRAY) {
   *dstDepth = (srcDepth - 2 * border) / 2 + 2 * border;
}
else {
-- 
1.9.1

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


[Mesa-dev] [PATCH 2/4] mesa: add numLevels, numSamples to Driver.TestProxyTexImage()

2016-07-15 Thread Brian Paul
So that the function can work properly with glTexStorage(), where we know
how many mipmap levels there are.  And so we can compute storage for MSAA
textures.

Also, remove the obsolete texture border parameter.

A subsequent patch will update _mesa_test_proxy_teximage() to use these
new parameters.
---
 src/mesa/drivers/common/meta_copy_image.c |  6 +++---
 src/mesa/main/dd.h|  5 +++--
 src/mesa/main/teximage.c  | 22 --
 src/mesa/main/teximage.h  |  7 ---
 src/mesa/main/texstorage.c|  4 ++--
 src/mesa/main/textureview.c   |  5 +++--
 src/mesa/state_tracker/st_cb_texture.c| 19 ---
 7 files changed, 39 insertions(+), 29 deletions(-)

diff --git a/src/mesa/drivers/common/meta_copy_image.c 
b/src/mesa/drivers/common/meta_copy_image.c
index ebea428..e1c90a3 100644
--- a/src/mesa/drivers/common/meta_copy_image.c
+++ b/src/mesa/drivers/common/meta_copy_image.c
@@ -101,9 +101,9 @@ make_view(struct gl_context *ctx, struct gl_texture_image 
*tex_image,
0, internal_format,
GL_NONE, GL_NONE);
 
-   if (!ctx->Driver.TestProxyTexImage(ctx, tex_obj->Target, 0, tex_format,
-  tex_image->Width, tex_image->Height,
-  tex_image->Depth, 0)) {
+   if (!ctx->Driver.TestProxyTexImage(ctx, tex_obj->Target, 1, 0, tex_format,
+  1, tex_image->Width, tex_image->Height,
+  tex_image->Depth)) {
   _mesa_DeleteTextures(1, view_tex_name);
   *view_tex_name = 0;
   return false;
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 4891e2a..114cbd2 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -308,9 +308,10 @@ struct dd_function_table {
 * \return GL_TRUE if the image is OK, GL_FALSE if too large
 */
GLboolean (*TestProxyTexImage)(struct gl_context *ctx, GLenum target,
-  GLint level, mesa_format format,
+  GLuint numLevels, GLint level,
+  mesa_format format, GLuint numSamples,
   GLint width, GLint height,
-  GLint depth, GLint border);
+  GLint depth);
/*@}*/
 

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 080bcbf..c75f605 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1253,18 +1253,20 @@ error_check_subtexture_dimensions(struct gl_context 
*ctx, GLuint dims,
  * and texturing will effectively be disabled.
  *
  * \param target  any texture target/type
+ * \param numLevels  number of mipmap levels in the texture or 0 if not known
  * \param level  as passed to glTexImage
  * \param format  the MESA_FORMAT_x for the tex image
+ * \param numSamples  number of samples per texel
  * \param width  as passed to glTexImage
  * \param height  as passed to glTexImage
  * \param depth  as passed to glTexImage
- * \param border  as passed to glTexImage
  * \return GL_TRUE if the image is acceptable, GL_FALSE if not acceptable.
  */
 GLboolean
-_mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target, GLint level,
-  mesa_format format,
-  GLint width, GLint height, GLint depth, GLint border)
+_mesa_test_proxy_teximage(struct gl_context *ctx, GLenum target,
+  GLuint numLevels, GLint level,
+  mesa_format format, GLuint numSamples,
+  GLint width, GLint height, GLint depth)
 {
/* We just check if the image size is less than MaxTextureMbytes.
 * Some drivers may do more specific checks.
@@ -2949,8 +2951,8 @@ teximage(struct gl_context *ctx, GLboolean compressed, 
GLuint dims,
 
/* check that the texture won't take too much memory, etc */
sizeOK = ctx->Driver.TestProxyTexImage(ctx, proxy_target(target),
-  level, texFormat,
-  width, height, depth, border);
+  0, level, texFormat, 1,
+  width, height, depth);
 
if (_mesa_is_proxy_texture(target)) {
   /* Proxy texture: just clear or set state depending on error checking */
@@ -3646,8 +3648,8 @@ copyteximage(struct gl_context *ctx, GLuint dims,
assert(texFormat != MESA_FORMAT_NONE);
 
if (!ctx->Driver.TestProxyTexImage(ctx, proxy_target(target),
-  level, texFormat,
-  width, height, 1, border)) {
+  0, level, texFormat, 1,
+  width, height, 1)) {
   _mesa_error(ctx, GL_OUT_OF_MEMORY,
 

[Mesa-dev] [Bug 96943] [gallium] glCopyPixels is affected by enabled texture state

2016-07-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=96943

Bug ID: 96943
   Summary: [gallium] glCopyPixels is affected by enabled texture
state
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: imir...@alum.mit.edu
QA Contact: mesa-dev@lists.freedesktop.org

The recently rewritten copy-pixels test has exposed some failures in st/mesa.
When there's an overlapping copy (among other conditions), the operation
becomes a fb read + draw of that texture with the current fragment shader
modified in the same way as glDrawPixels does it. (So this problem might extend
itself to glDrawPixels as well).

Doing a glDisable(GL_TEXTURE_2D) before the glCopyPixels() call in the piglit
fixes the issue. Effectively that texture is being multiplied with the copied
data, whereas from what I can tell, it shouldn't be. I think the multiplication
comes from the ff-generated shader.

[An alternative is that the piglit test and i965 are wrong and what gallium is
doing is correct. I don't think that's the case, since the only disagreement is
on the overlapped copy.]

-- 
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 4/4] anv: Handle VK_WHOLE_SIZE properly for buffer views

2016-07-15 Thread Nanley Chery
On Thu, Jul 14, 2016 at 09:20:08PM -0700, Jason Ekstrand wrote:
> The old calculation, which used view->offset, encorporated buffer->offset
> into the size calculation where it doesn't belong.  This meant that, if
> buffer->offset > buffer->size, you would always get a negative size.  This
> fixes 170 dEQP-VK.renderpass.attachment.* Vulkan CTS tests on Haswell.
> 

Nice patch.

> Signed-off-by: Jason Ekstrand 
> Cc: "12.0" 
> ---
>  src/intel/vulkan/anv_image.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
> index 23fdd93..fe5b124 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -631,7 +631,7 @@ void anv_buffer_view_init(struct anv_buffer_view *view,
> view->bo = buffer->bo;
> view->offset = buffer->offset + pCreateInfo->offset;
> view->range = pCreateInfo->range == VK_WHOLE_SIZE ?
> - buffer->size - view->offset : pCreateInfo->range;
> + buffer->size - pCreateInfo->offset : pCreateInfo->range;
>  

This is almost correct. The range member definition (11.2. Buffer Views)
has a corner case for VK_WHOLE_SIZE. It states that if 
R = (buffer_size - buffer_view_offset) is not a multiple of
buffer_view_format_size, then you must set the range member to
the nearest smaller multiple of buffer_view_format_size.

Which is to say,
 if (requested_range == VK_WHOLE_SIZE)
actual_range = ALIGN_DOWN(R, buffer_view_format_size);

- Nanley

> if (buffer->usage & VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT) {
>view->surface_state = alloc_surface_state(device, cmd_buffer);
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/4] genxml: Make gen6-7 blending look more like gen8

2016-07-15 Thread Jason Ekstrand
On Fri, Jul 15, 2016 at 3:38 AM, Kenneth Graunke 
wrote:

> On Thursday, July 14, 2016 9:20:05 PM PDT Jason Ekstrand wrote:
> > This renames BLEND_STATE to BLEND_STATE_ENTRY and adds an new struct
> > BLEND_STATE which is just an array of 8 BLEND_STATE_ENTRYs.  This will
> make
> > it much easier to write gen-agnostic blend handling code.
> >
> > Signed-off-by: Jason Ekstrand 
> > Cc: "12.0" 
> > ---
> >  src/intel/genxml/gen6.xml|  8 +++-
> >  src/intel/genxml/gen7.xml|  8 +++-
> >  src/intel/genxml/gen75.xml   |  8 +++-
> >  src/intel/vulkan/gen7_pipeline.c | 25 +
> >  4 files changed, 34 insertions(+), 15 deletions(-)
>
> The series is:
> Reviewed-by: Kenneth Graunke 
>
> though my review on patch 4 is pretty light.
>

Thanks!  I'm sure Nanley can take patch 4.  I think he might have written
that code after all. :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

2016-07-15 Thread Zhang, Boyuan
Hi Andy,

Thanks for the testing. I will look into the memory issue. For the cbr test, 
what was the bitrate you set? And by saying testing high rates, how high was 
the rate approximately?

Regards,
Boyuan

-Original Message-
From: Andy Furniss [mailto:adf.li...@gmail.com] 
Sent: July-15-16 9:42 AM
To: Christian König; Zhang, Boyuan; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

Christian König wrote:
> Am 05.07.2016 um 13:17 schrieb Christian König:
>> Am 01.07.2016 um 18:18 schrieb Andy Furniss:
>>> Christian König wrote:
 Am 01.07.2016 um 18:02 schrieb Andy Furniss:
> Christian König wrote:
>> Am 01.07.2016 um 16:42 schrieb Andy Furniss:
>>> Boyuan Zhang wrote:
 Signed-off-by: Boyuan Zhang 
>>>
>>> Is this supposed to be the same functionally as the first version?
>>>
>>> I notice on Tonga that I previously got cabac, but don't now.
>>>
>>> I see the new options are now in radeon_vce_52.c whereas before 
>>> radeon_vce_40_2_2.c was changed - is this why?
>>
>> We wanted to keep the code for the old firmware versions as it 
>> is, because we otherwise would need to test them again.
>>
>> Because of this we moved all modifications into radeon_vce_52.c.
>
> Oh OK, I guess it's early days but cabac was one thing that seemed OK.
>
> There are many issued on Tonga using vaapi - but then I suppose 
> gstreamer and ffmpeg are not really set up for it yet.
>
> eg. worse first = gpu vm fault/lock with gstreamer but not ffmpeg.
>
> to provoke do
>
> gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12, 
> width=1920, height=1080, framerate=60/1 ! vaapih264enc | fakesink
>
> then flip away/back to another desktop soon will lock.
>
> Maybe I am too early eg. other patches needed? or does what you 
> say above mean that vaapienc shouldn't even be enabled for older chips?

 Tonga should be perfectly supported, you just need recent enough 
 firmware.

 What does "dmesg | grep 'Found VCE firmware Version'" give you?
>>>
>>> Found VCE firmware Version: 50.17 Binary ID: 3
>>
>> Mhm, well looks like we haven't released the right firmware for Tonga 
>> yet :(
>>
>> Going to leave you a note when we have everything together.
>
> The new firmware landed on Monday and the final patchset was released 
> yesterday night.
>
> Have fun testing it,

Found VCE firmware Version: 52.4 Binary ID: 3

No luck I'm afraid. The above test will still hard lock me after about
30 seconds.

I also notice it's eating memory 2.6 gig by the time I lock.

Replace vaapih264enc with omxh264enc and all is OK, will run for ages no 
increasing memory usage. In fact I think this firmware & or kernel has fixed a 
powerplay omx issue - will update my bug for that when I have tested more.

FWIW the above test would make cqp with a qp of 0 - testing cbr does also 
leak/lock, though specifying bitrates does sort of work, the result is much 
higher than requested (maybe some framerate assumption - I am testing high 
rates.




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


Re: [Mesa-dev] [PATCH 01/12] vl: add parameters for VAAPI encode

2016-07-15 Thread Andy Furniss

Christian König wrote:

Am 05.07.2016 um 13:17 schrieb Christian König:

Am 01.07.2016 um 18:18 schrieb Andy Furniss:

Christian König wrote:

Am 01.07.2016 um 18:02 schrieb Andy Furniss:

Christian König wrote:

Am 01.07.2016 um 16:42 schrieb Andy Furniss:

Boyuan Zhang wrote:

Signed-off-by: Boyuan Zhang 


Is this supposed to be the same functionally as the first version?

I notice on Tonga that I previously got cabac, but don't now.

I see the new options are now in radeon_vce_52.c whereas before
radeon_vce_40_2_2.c was changed - is this why?


We wanted to keep the code for the old firmware versions as it is,
because we otherwise would need to test them again.

Because of this we moved all modifications into radeon_vce_52.c.


Oh OK, I guess it's early days but cabac was one thing that seemed OK.

There are many issued on Tonga using vaapi - but then I suppose
gstreamer and ffmpeg are not really set up for it yet.

eg. worse first = gpu vm fault/lock with gstreamer but not ffmpeg.

to provoke do

gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12, width=1920,
height=1080, framerate=60/1 ! vaapih264enc | fakesink

then flip away/back to another desktop soon will lock.

Maybe I am too early eg. other patches needed? or does what you say
above mean that vaapienc shouldn't even be enabled for older chips?


Tonga should be perfectly supported, you just need recent enough
firmware.

What does "dmesg | grep 'Found VCE firmware Version'" give you?


Found VCE firmware Version: 50.17 Binary ID: 3


Mhm, well looks like we haven't released the right firmware for Tonga
yet :(

Going to leave you a note when we have everything together.


The new firmware landed on Monday and the final patchset was released
yesterday night.

Have fun testing it,


Found VCE firmware Version: 52.4 Binary ID: 3

No luck I'm afraid. The above test will still hard lock me after about 
30 seconds.


I also notice it's eating memory 2.6 gig by the time I lock.

Replace vaapih264enc with omxh264enc and all is OK, will run for ages
no increasing memory usage. In fact I think this firmware & or kernel
has fixed a powerplay omx issue - will update my bug for that when I
have tested more.

FWIW the above test would make cqp with a qp of 0 - testing cbr does
also leak/lock, though specifying bitrates does sort of work, the result
is much higher than requested (maybe some framerate assumption - I am 
testing

high rates.




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


Re: [Mesa-dev] [PATCH] egl/dri2: dri2_make_current: Make sure display is initialized before using it

2016-07-15 Thread Emil Velikov
On 15 July 2016 at 09:28, Nicolas Boichat  wrote:
> android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
> eglTerminate, followed by eglReleaseThread. In that case, the
> display will not be initialized when eglReleaseThread calls
> MakeCurrent with NULL parameters, to unbind the context, which
> causes a a segfault in drv->API.MakeCurrent (dri2_make_current),
> either in glFlush or in a latter call.
>
> A similar case is observed in this bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=69622, where the test
> call eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL).
>
> This patch:
>  1. Validates that the display is initialized, if ctx/dsurf/rsurf
> are not all NULL.
>  2. Does not call glFlush/unBindContext is there is no display.
>  3. However, it still goes through the normal path as
> drv->API.DestroyContext decrements the reference count on the
> context, and frees the structure.
>
> Cc: "11.2 12.0" 
> Signed-off-by: Nicolas Boichat 
> ---
>
> I did not actually test the case reported on the bug, only the CTS
> test, would be nice if someone can try it out (Rhys? Chad?).
>
> Applies after "egl/dri2: dri2_make_current: Set EGL error if bindContext
> fails", but wanted to keep the 2 patches separate as they are different
> problems and discussions.
>
>  src/egl/drivers/dri2/egl_dri2.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index 2e97d85..3269e52 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1166,7 +1166,8 @@ dri2_destroy_context(_EGLDriver *drv, _EGLDisplay 
> *disp, _EGLContext *ctx)
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>
> if (_eglPutContext(ctx)) {
> -  dri2_dpy->core->destroyContext(dri2_ctx->dri_context);
> +  if (dri2_dpy)
Not sure if this is the right place/we need this.

When calling eglDestroyContext (after eglTerminate or not) this cannot
happen since the _EGL_CHECK_CONTEXT macro will dive into the _eglCheck
functions and will bail out since the since the dpy is no initialized.

The only case we can reach this is from dri2_make_current. See below for more.


> @@ -1189,6 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
> _EGLSurface *dsurf,
> __DRIdrawable *ddraw, *rdraw;
> __DRIcontext *cctx;
>
> +   /* Check that the display is initialized */
> +   if ((ctx != NULL || dsurf != NULL || rsurf != NULL) && !dri2_dpy)
> +  return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent error");
> +
Was doing to say "the first few lines in eglMakeCurrent) should
already handle these" only to realise that dri2_dpy doesn't wrap
around/subclass the respective _EGLfoo type (_EGLDisplay), like the
dri2_egl_{surface,context...} :-\

At the same time, dri2_make_current cannot (should not really) do
anything in the !dri2_dpy case, since we cannot:
 - call unbind the old ctx bind the new one, or even restore/rebind
the original ctx
 - free any of the ctx/surf resources. The latter should already be
gone, as upon eglTerminate walk over the ctx/surf lists and tear them
all down (see _eglReleaseDisplayResources).

Thus something like the following should be fine imho.

if (!dri2_dpy)
   /* copy/reword some my earlier comment in here */
   return 0;

> /* make new bindings */
> if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, 
> _rsurf)) {
>/* _eglBindContext already sets the EGL error (in 
> _eglCheckMakeCurrent) */
> @@ -1196,14 +1201,14 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
> _EGLSurface *dsurf,
> }
>
> /* flush before context switch */
> -   if (old_ctx && dri2_drv->glFlush)
> +   if (old_ctx && dri2_dpy && dri2_drv->glFlush)
Mildly related: We might want to bail out in dri2_load on
!dri2_drv->glFlush and drop the check here. If we cannot get glapi
and/or glFlush symbol things are seriously stuffed and pretending to
continue just won't work.

>  dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf)
>  {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
> +   if (!dri2_dpy)
> +  return EGL_TRUE;
Analogous to the ctx hunk, this shouldn't be needed.

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


Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads

2016-07-15 Thread Iago Toral
On Fri, 2016-07-15 at 21:20 +1000, Timothy Arceri wrote:
> On Fri, 2016-07-15 at 13:16 +0200, Iago Toral wrote:
> > 
> > On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote:
> > > 
> > > On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote:
> > > > 
> > > > 
> > > > We totally ignored this before because there were no piglit
> > > > tests
> > > > for
> > > > indirect loads in tessellation stages with doubles.
> > > > 
> > > > Cc: "12.0" 
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86
> > > > 
> > > >  1 file changed, 64 insertions(+), 22 deletions(-)
> > > > 
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > > index 55383ff..7d5af78 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > > @@ -2926,31 +2926,73 @@
> > > > fs_visitor::nir_emit_tes_intrinsic(const
> > > > fs_builder ,
> > > >   }
> > > >    } else {
> > > >   /* Indirect indexing - use per-slot offsets as well.
> > > > */
> > > > - const fs_reg srcs[] = {
> > > > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> > > > -indirect_offset
> > > > - };
> > > > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> > > > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
> > > >  
> > > > - if (first_component != 0) {
> > > > -unsigned read_components =
> > > > -instr->num_components + first_component;
> > > > -fs_reg tmp = bld.vgrf(dest.type, read_components);
> > > > -inst =
> > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT,
> > > > tmp,
> > > > -payload);
> > > > -inst->regs_written = read_components;
> > > > -for (unsigned i = 0; i < instr->num_components;
> > > > i++)
> > > > {
> > > > -   bld.MOV(offset(dest, bld, i),
> > > > -   offset(tmp, bld, i + first_component));
> > > > + /* We can only read two double components with each
> > > > URB
> > > > read, so
> > > > +  * we send two read messages in that case, each one
> > > > loading
> > > > up to
> > > > +  * two double components.
> > > > +  */
> > > > + unsigned num_iterations = 1;
> > > > + unsigned num_components = instr->num_components;
> > > > + fs_reg orig_dest = dest;
> > > > + if (type_sz(dest.type) == 8) {
> > > Hi,
> > > 
> > > Not your fault as its not currently enabled but can you add the
> > > following here to allow component packing to work once it finally
> > > gets
> > > enabled:
> > > 
> > >                first_component = first_component / 2;
> > > 
> > > I believe that should be enought to keep it working once the
> > > other
> > > patches land.
> > I think this is already being done in master, right after the
> > assignment to first_component.
> Oh yes you are right. All looks good to me then :)

great!

> > 
> > 
> > > 
> > > Also I don't think this patch is going to apply cleanly to stable
> > > as
> > > the component packing cahnges only landed after branching.

Aha, good point. In that case I think it is probably better to just
drop Cc to stable. Thanks!

Iago

> > > Thanks,
> > > Tim
> > > 
> > > > 
> > > > 
> > > > +if (instr->num_components > 2) {
> > > > +   num_iterations = 2;
> > > > +   num_components = 2;
> > > > +}
> > > > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4),
> > > > dest.type);
> > > > +dest = tmp;
> > > > + }
> > > > +
> > > > + for (unsigned iter = 0; iter < num_iterations;
> > > > iter++)
> > > > {
> > > > +const fs_reg srcs[] = {
> > > > +   retype(brw_vec1_grf(0, 0),
> > > > BRW_REGISTER_TYPE_UD),
> > > > +   indirect_offset
> > > > +};
> > > > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD,
> > > > 2);
> > > > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs),
> > > > 0);
> > > > +
> > > > +if (first_component != 0) {
> > > > +   unsigned read_components =
> > > > +   num_components + first_component;
> > > > +   fs_reg tmp = bld.vgrf(dest.type,
> > > > read_components);
> > > > +   inst =
> > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp,
> > > > +   payload);
> > > > +   for (unsigned i = 0; i < num_components; i++) {
> > > > +  bld.MOV(offset(dest, bld, i),
> > > > +  offset(tmp, bld, i +
> > > > first_component));
> > > > +   }
> > > > +} else {
> > > > +   inst =
> > > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest,
> > > > +   

Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads

2016-07-15 Thread Timothy Arceri
On Fri, 2016-07-15 at 13:16 +0200, Iago Toral wrote:
> On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote:
> > On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote:
> > > 
> > > We totally ignored this before because there were no piglit tests
> > > for
> > > indirect loads in tessellation stages with doubles.
> > > 
> > > Cc: "12.0" 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86
> > > 
> > >  1 file changed, 64 insertions(+), 22 deletions(-)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > index 55383ff..7d5af78 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const
> > > fs_builder ,
> > >   }
> > >    } else {
> > >   /* Indirect indexing - use per-slot offsets as well. */
> > > - const fs_reg srcs[] = {
> > > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> > > -indirect_offset
> > > - };
> > > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> > > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
> > >  
> > > - if (first_component != 0) {
> > > -unsigned read_components =
> > > -instr->num_components + first_component;
> > > -fs_reg tmp = bld.vgrf(dest.type, read_components);
> > > -inst =
> > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT,
> > > tmp,
> > > -payload);
> > > -inst->regs_written = read_components;
> > > -for (unsigned i = 0; i < instr->num_components; i++)
> > > {
> > > -   bld.MOV(offset(dest, bld, i),
> > > -   offset(tmp, bld, i + first_component));
> > > + /* We can only read two double components with each URB
> > > read, so
> > > +  * we send two read messages in that case, each one
> > > loading
> > > up to
> > > +  * two double components.
> > > +  */
> > > + unsigned num_iterations = 1;
> > > + unsigned num_components = instr->num_components;
> > > + fs_reg orig_dest = dest;
> > > + if (type_sz(dest.type) == 8) {
> > Hi,
> > 
> > Not your fault as its not currently enabled but can you add the
> > following here to allow component packing to work once it finally
> > gets
> > enabled:
> > 
> >                first_component = first_component / 2;
> > 
> > I believe that should be enought to keep it working once the other
> > patches land.
> 
> I think this is already being done in master, right after the
> assignment to first_component.

Oh yes you are right. All looks good to me then :)

> 
> > Also I don't think this patch is going to apply cleanly to stable
> > as
> > the component packing cahnges only landed after branching.
> > 
> > Thanks,
> > Tim
> > 
> > > 
> > > +if (instr->num_components > 2) {
> > > +   num_iterations = 2;
> > > +   num_components = 2;
> > > +}
> > > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4),
> > > dest.type);
> > > +dest = tmp;
> > > + }
> > > +
> > > + for (unsigned iter = 0; iter < num_iterations; iter++)
> > > {
> > > +const fs_reg srcs[] = {
> > > +   retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> > > +   indirect_offset
> > > +};
> > > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> > > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs),
> > > 0);
> > > +
> > > +if (first_component != 0) {
> > > +   unsigned read_components =
> > > +   num_components + first_component;
> > > +   fs_reg tmp = bld.vgrf(dest.type,
> > > read_components);
> > > +   inst =
> > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp,
> > > +   payload);
> > > +   for (unsigned i = 0; i < num_components; i++) {
> > > +  bld.MOV(offset(dest, bld, i),
> > > +  offset(tmp, bld, i +
> > > first_component));
> > > +   }
> > > +} else {
> > > +   inst =
> > > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest,
> > > +   payload);
> > > +}
> > > +inst->mlen = 2;
> > > +inst->offset = imm_offset;
> > > +inst->regs_written =
> > > +   ((num_components + first_component) *
> > > type_sz(dest.type) / 4);
> > > +
> > > +/* If we are reading 64-bit data using 32-bit read
> > > messages we need
> > > + * build proper 64-bit data elements by shuffling
> > > the
> > > low and high
> > > + * 32-bit components around like we do 

Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads

2016-07-15 Thread Iago Toral
On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote:
> On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote:
> > 
> > We totally ignored this before because there were no piglit tests
> > for
> > indirect loads in tessellation stages with doubles.
> > 
> > Cc: "12.0" 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86
> > 
> >  1 file changed, 64 insertions(+), 22 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > index 55383ff..7d5af78 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const
> > fs_builder ,
> >   }
> >    } else {
> >   /* Indirect indexing - use per-slot offsets as well. */
> > - const fs_reg srcs[] = {
> > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> > -indirect_offset
> > - };
> > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
> >  
> > - if (first_component != 0) {
> > -unsigned read_components =
> > -instr->num_components + first_component;
> > -fs_reg tmp = bld.vgrf(dest.type, read_components);
> > -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT,
> > tmp,
> > -payload);
> > -inst->regs_written = read_components;
> > -for (unsigned i = 0; i < instr->num_components; i++) {
> > -   bld.MOV(offset(dest, bld, i),
> > -   offset(tmp, bld, i + first_component));
> > + /* We can only read two double components with each URB
> > read, so
> > +  * we send two read messages in that case, each one
> > loading
> > up to
> > +  * two double components.
> > +  */
> > + unsigned num_iterations = 1;
> > + unsigned num_components = instr->num_components;
> > + fs_reg orig_dest = dest;
> > + if (type_sz(dest.type) == 8) {
> Hi,
> 
> Not your fault as its not currently enabled but can you add the
> following here to allow component packing to work once it finally
> gets
> enabled:
> 
>                first_component = first_component / 2;
> 
> I believe that should be enought to keep it working once the other
> patches land.

I think this is already being done in master, right after the
assignment to first_component.

> Also I don't think this patch is going to apply cleanly to stable as
> the component packing cahnges only landed after branching.
> 
> Thanks,
> Tim
> 
> > 
> > +if (instr->num_components > 2) {
> > +   num_iterations = 2;
> > +   num_components = 2;
> > +}
> > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4),
> > dest.type);
> > +dest = tmp;
> > + }
> > +
> > + for (unsigned iter = 0; iter < num_iterations; iter++) {
> > +const fs_reg srcs[] = {
> > +   retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> > +   indirect_offset
> > +};
> > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
> > +
> > +if (first_component != 0) {
> > +   unsigned read_components =
> > +   num_components + first_component;
> > +   fs_reg tmp = bld.vgrf(dest.type, read_components);
> > +   inst =
> > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp,
> > +   payload);
> > +   for (unsigned i = 0; i < num_components; i++) {
> > +  bld.MOV(offset(dest, bld, i),
> > +  offset(tmp, bld, i + first_component));
> > +   }
> > +} else {
> > +   inst =
> > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest,
> > +   payload);
> > +}
> > +inst->mlen = 2;
> > +inst->offset = imm_offset;
> > +inst->regs_written =
> > +   ((num_components + first_component) *
> > type_sz(dest.type) / 4);
> > +
> > +/* If we are reading 64-bit data using 32-bit read
> > messages we need
> > + * build proper 64-bit data elements by shuffling the
> > low and high
> > + * 32-bit components around like we do for other
> > things
> > like UBOs
> > + * or SSBOs.
> > + */
> > +if (type_sz(dest.type) == 8) {
> > +   shuffle_32bit_load_result_to_64bit_data(
> > +  bld, dest, retype(dest, BRW_REGISTER_TYPE_F),
> > num_components);
> > +
> > +   for (unsigned c = 0; c < num_components; c++) {
> > +  

Re: [Mesa-dev] [PATCH] egl/dri2: dri2_make_current: Make sure display is initialized before using it

2016-07-15 Thread Rhys Kidd
Whilst I don't know that code as well as I'd like. It does get my

Tested-by: Rhys Kidd 

for fixing that piglit on i965 ILK. Thanks for the two patches!

On 15 July 2016 at 04:28, Nicolas Boichat  wrote:

> android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
> eglTerminate, followed by eglReleaseThread. In that case, the
> display will not be initialized when eglReleaseThread calls
> MakeCurrent with NULL parameters, to unbind the context, which
> causes a a segfault in drv->API.MakeCurrent (dri2_make_current),
> either in glFlush or in a latter call.
>
> A similar case is observed in this bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=69622, where the test
> call eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL).
>
> This patch:
>  1. Validates that the display is initialized, if ctx/dsurf/rsurf
> are not all NULL.
>  2. Does not call glFlush/unBindContext is there is no display.
>  3. However, it still goes through the normal path as
> drv->API.DestroyContext decrements the reference count on the
> context, and frees the structure.
>
> Cc: "11.2 12.0" 
> Signed-off-by: Nicolas Boichat 
> ---
>
> I did not actually test the case reported on the bug, only the CTS
> test, would be nice if someone can try it out (Rhys? Chad?).
>
> Applies after "egl/dri2: dri2_make_current: Set EGL error if bindContext
> fails", but wanted to keep the 2 patches separate as they are different
> problems and discussions.
>
>  src/egl/drivers/dri2/egl_dri2.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c
> b/src/egl/drivers/dri2/egl_dri2.c
> index 2e97d85..3269e52 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1166,7 +1166,8 @@ dri2_destroy_context(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLContext *ctx)
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
>
> if (_eglPutContext(ctx)) {
> -  dri2_dpy->core->destroyContext(dri2_ctx->dri_context);
> +  if (dri2_dpy)
> + dri2_dpy->core->destroyContext(dri2_ctx->dri_context);
>free(dri2_ctx);
> }
>
> @@ -1189,6 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *dsurf,
> __DRIdrawable *ddraw, *rdraw;
> __DRIcontext *cctx;
>
> +   /* Check that the display is initialized */
> +   if ((ctx != NULL || dsurf != NULL || rsurf != NULL) && !dri2_dpy)
> +  return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent error");
> +
> /* make new bindings */
> if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf,
> _rsurf)) {
>/* _eglBindContext already sets the EGL error (in
> _eglCheckMakeCurrent) */
> @@ -1196,14 +1201,14 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *dsurf,
> }
>
> /* flush before context switch */
> -   if (old_ctx && dri2_drv->glFlush)
> +   if (old_ctx && dri2_dpy && dri2_drv->glFlush)
>dri2_drv->glFlush();
>
> ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
> rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
> cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
>
> -   if (old_ctx) {
> +   if (old_ctx && dri2_dpy) {
>__DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
>dri2_dpy->core->unbindContext(old_cctx);
> }
> @@ -1292,6 +1297,8 @@ static EGLBoolean
>  dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf)
>  {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
> +   if (!dri2_dpy)
> +  return EGL_TRUE;
> return dri2_dpy->vtbl->destroy_surface(drv, dpy, surf);
>  }
>
> --
> 2.8.0.rc3.226.g39d4020
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads

2016-07-15 Thread Timothy Arceri
On Fri, 2016-07-15 at 20:59 +1000, Timothy Arceri wrote:
> On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote:
> > We totally ignored this before because there were no piglit tests
> > for
> > indirect loads in tessellation stages with doubles.
> > 
> > Cc: "12.0" 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86
> > 
> >  1 file changed, 64 insertions(+), 22 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > index 55383ff..7d5af78 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const
> > fs_builder ,
> >   }
> >    } else {
> >   /* Indirect indexing - use per-slot offsets as well. */
> > - const fs_reg srcs[] = {
> > -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> > -indirect_offset
> > - };
> > - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> > - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
> >  
> > - if (first_component != 0) {
> > -unsigned read_components =
> > -instr->num_components + first_component;
> > -fs_reg tmp = bld.vgrf(dest.type, read_components);
> > -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT,
> > tmp,
> > -payload);
> > -inst->regs_written = read_components;
> > -for (unsigned i = 0; i < instr->num_components; i++) {
> > -   bld.MOV(offset(dest, bld, i),
> > -   offset(tmp, bld, i + first_component));
> > + /* We can only read two double components with each URB
> > read, so
> > +  * we send two read messages in that case, each one
> > loading
> > up to
> > +  * two double components.
> > +  */
> > + unsigned num_iterations = 1;
> > + unsigned num_components = instr->num_components;
> > + fs_reg orig_dest = dest;
> > + if (type_sz(dest.type) == 8) {
> 
> Hi,
> 
> Not your fault as its not currently enabled but can you add the
> following here to allow component packing to work once it finally
> gets
> enabled:
> 
>                first_component = first_component / 2;
> 
> I believe that should be enought to keep it working once the other
> patches land.
> 
> Also I don't think this patch is going to apply cleanly to stable as
> the component packing cahnges only landed after branching.
> 
> Thanks,
> Tim

Also for what its worth both patches are:

Reviewed-by: Timothy Arceri 

You may want to wait a little for feedback from others before pushing
as I'm still fairly new to this code.

> 
> > +if (instr->num_components > 2) {
> > +   num_iterations = 2;
> > +   num_components = 2;
> > +}
> > +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4),
> > dest.type);
> > +dest = tmp;
> > + }
> > +
> > + for (unsigned iter = 0; iter < num_iterations; iter++) {
> > +const fs_reg srcs[] = {
> > +   retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> > +   indirect_offset
> > +};
> > +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> > +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
> > +
> > +if (first_component != 0) {
> > +   unsigned read_components =
> > +   num_components + first_component;
> > +   fs_reg tmp = bld.vgrf(dest.type, read_components);
> > +   inst =
> > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp,
> > +   payload);
> > +   for (unsigned i = 0; i < num_components; i++) {
> > +  bld.MOV(offset(dest, bld, i),
> > +  offset(tmp, bld, i + first_component));
> > +   }
> > +} else {
> > +   inst =
> > bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest,
> > +   payload);
> > +}
> > +inst->mlen = 2;
> > +inst->offset = imm_offset;
> > +inst->regs_written =
> > +   ((num_components + first_component) *
> > type_sz(dest.type) / 4);
> > +
> > +/* If we are reading 64-bit data using 32-bit read
> > messages we need
> > + * build proper 64-bit data elements by shuffling the
> > low and high
> > + * 32-bit components around like we do for other
> > things
> > like UBOs
> > + * or SSBOs.
> > + */
> > +if (type_sz(dest.type) == 8) {
> > +   shuffle_32bit_load_result_to_64bit_data(
> > +  bld, dest, retype(dest, BRW_REGISTER_TYPE_F),
> > 

Re: [Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads

2016-07-15 Thread Timothy Arceri
On Fri, 2016-07-15 at 11:04 +0200, Iago Toral Quiroga wrote:
> We totally ignored this before because there were no piglit tests for
> indirect loads in tessellation stages with doubles.
> 
> Cc: "12.0" 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86
> 
>  1 file changed, 64 insertions(+), 22 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index 55383ff..7d5af78 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const
> fs_builder ,
>   }
>    } else {
>   /* Indirect indexing - use per-slot offsets as well. */
> - const fs_reg srcs[] = {
> -retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> -indirect_offset
> - };
> - fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> - bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
>  
> - if (first_component != 0) {
> -unsigned read_components =
> -instr->num_components + first_component;
> -fs_reg tmp = bld.vgrf(dest.type, read_components);
> -inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT,
> tmp,
> -payload);
> -inst->regs_written = read_components;
> -for (unsigned i = 0; i < instr->num_components; i++) {
> -   bld.MOV(offset(dest, bld, i),
> -   offset(tmp, bld, i + first_component));
> + /* We can only read two double components with each URB
> read, so
> +  * we send two read messages in that case, each one loading
> up to
> +  * two double components.
> +  */
> + unsigned num_iterations = 1;
> + unsigned num_components = instr->num_components;
> + fs_reg orig_dest = dest;
> + if (type_sz(dest.type) == 8) {

Hi,

Not your fault as its not currently enabled but can you add the
following here to allow component packing to work once it finally gets
enabled:

               first_component = first_component / 2;

I believe that should be enought to keep it working once the other
patches land.

Also I don't think this patch is going to apply cleanly to stable as
the component packing cahnges only landed after branching.

Thanks,
Tim

> +if (instr->num_components > 2) {
> +   num_iterations = 2;
> +   num_components = 2;
> +}
> +fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), dest.type);
> +dest = tmp;
> + }
> +
> + for (unsigned iter = 0; iter < num_iterations; iter++) {
> +const fs_reg srcs[] = {
> +   retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
> +   indirect_offset
> +};
> +fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> +bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
> +
> +if (first_component != 0) {
> +   unsigned read_components =
> +   num_components + first_component;
> +   fs_reg tmp = bld.vgrf(dest.type, read_components);
> +   inst =
> bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp,
> +   payload);
> +   for (unsigned i = 0; i < num_components; i++) {
> +  bld.MOV(offset(dest, bld, i),
> +  offset(tmp, bld, i + first_component));
> +   }
> +} else {
> +   inst =
> bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest,
> +   payload);
> +}
> +inst->mlen = 2;
> +inst->offset = imm_offset;
> +inst->regs_written =
> +   ((num_components + first_component) *
> type_sz(dest.type) / 4);
> +
> +/* If we are reading 64-bit data using 32-bit read
> messages we need
> + * build proper 64-bit data elements by shuffling the
> low and high
> + * 32-bit components around like we do for other things
> like UBOs
> + * or SSBOs.
> + */
> +if (type_sz(dest.type) == 8) {
> +   shuffle_32bit_load_result_to_64bit_data(
> +  bld, dest, retype(dest, BRW_REGISTER_TYPE_F),
> num_components);
> +
> +   for (unsigned c = 0; c < num_components; c++) {
> +  bld.MOV(offset(orig_dest, bld, iter * 2 + c),
> +  offset(dest, bld, c));
> +   }
> +}
> +
> +/* If we are loading double data and we need a second
> read message
> + * adjust the offset
> + */
> +if (num_iterations > 1) {
> +   num_components = instr->num_components - 2;
> +   imm_offset++;
>  

Re: [Mesa-dev] [PATCH 1/4] genxml: Make gen6-7 blending look more like gen8

2016-07-15 Thread Kenneth Graunke
On Thursday, July 14, 2016 9:20:05 PM PDT Jason Ekstrand wrote:
> This renames BLEND_STATE to BLEND_STATE_ENTRY and adds an new struct
> BLEND_STATE which is just an array of 8 BLEND_STATE_ENTRYs.  This will make
> it much easier to write gen-agnostic blend handling code.
> 
> Signed-off-by: Jason Ekstrand 
> Cc: "12.0" 
> ---
>  src/intel/genxml/gen6.xml|  8 +++-
>  src/intel/genxml/gen7.xml|  8 +++-
>  src/intel/genxml/gen75.xml   |  8 +++-
>  src/intel/vulkan/gen7_pipeline.c | 25 +
>  4 files changed, 34 insertions(+), 15 deletions(-)

The series is:
Reviewed-by: Kenneth Graunke 

though my review on patch 4 is pretty light.


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] VAAPI egl interop on radeon

2016-07-15 Thread Jan Burgmeier
Hi, 

I am developing an application which uses vaapi and egl. My goal is to use 
vaDeriveImage and vaAcquireBufferHandle to get the drm buffer id which then can 
be used to create a EGLImageKHR. My problem is, that on amd hardware (AMD 
GX-212ZC SOC with Radeon(TM) R1E Graphics and AMD GX-424CC SOC with Radeon(TM) 
R5E Graphics) vaDeriveImage fails with "invalid VASurfaceID" and when I do 
vaGetImage as a fallback to get the image vaAcquireBufferHandle fails with 
"invalid VABufferID". The same code works on Intel hardware. 

Mesa version: 11.2.2 

- Should this work in general? 
- Is there any special setting needed? 

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


[Mesa-dev] [PATCH 2/2] i965/tes/scalar: fix 64-bit indirect input loads

2016-07-15 Thread Iago Toral Quiroga
We totally ignored this before because there were no piglit tests for
indirect loads in tessellation stages with doubles.

Cc: "12.0" 
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 86 
 1 file changed, 64 insertions(+), 22 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 55383ff..7d5af78 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -2926,31 +2926,73 @@ fs_visitor::nir_emit_tes_intrinsic(const fs_builder 
,
  }
   } else {
  /* Indirect indexing - use per-slot offsets as well. */
- const fs_reg srcs[] = {
-retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
-indirect_offset
- };
- fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
- bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
 
- if (first_component != 0) {
-unsigned read_components =
-instr->num_components + first_component;
-fs_reg tmp = bld.vgrf(dest.type, read_components);
-inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp,
-payload);
-inst->regs_written = read_components;
-for (unsigned i = 0; i < instr->num_components; i++) {
-   bld.MOV(offset(dest, bld, i),
-   offset(tmp, bld, i + first_component));
+ /* We can only read two double components with each URB read, so
+  * we send two read messages in that case, each one loading up to
+  * two double components.
+  */
+ unsigned num_iterations = 1;
+ unsigned num_components = instr->num_components;
+ fs_reg orig_dest = dest;
+ if (type_sz(dest.type) == 8) {
+if (instr->num_components > 2) {
+   num_iterations = 2;
+   num_components = 2;
+}
+fs_reg tmp = fs_reg(VGRF, alloc.allocate(4), dest.type);
+dest = tmp;
+ }
+
+ for (unsigned iter = 0; iter < num_iterations; iter++) {
+const fs_reg srcs[] = {
+   retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UD),
+   indirect_offset
+};
+fs_reg payload = bld.vgrf(BRW_REGISTER_TYPE_UD, 2);
+bld.LOAD_PAYLOAD(payload, srcs, ARRAY_SIZE(srcs), 0);
+
+if (first_component != 0) {
+   unsigned read_components =
+   num_components + first_component;
+   fs_reg tmp = bld.vgrf(dest.type, read_components);
+   inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, tmp,
+   payload);
+   for (unsigned i = 0; i < num_components; i++) {
+  bld.MOV(offset(dest, bld, i),
+  offset(tmp, bld, i + first_component));
+   }
+} else {
+   inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest,
+   payload);
+}
+inst->mlen = 2;
+inst->offset = imm_offset;
+inst->regs_written =
+   ((num_components + first_component) * type_sz(dest.type) / 4);
+
+/* If we are reading 64-bit data using 32-bit read messages we need
+ * build proper 64-bit data elements by shuffling the low and high
+ * 32-bit components around like we do for other things like UBOs
+ * or SSBOs.
+ */
+if (type_sz(dest.type) == 8) {
+   shuffle_32bit_load_result_to_64bit_data(
+  bld, dest, retype(dest, BRW_REGISTER_TYPE_F), 
num_components);
+
+   for (unsigned c = 0; c < num_components; c++) {
+  bld.MOV(offset(orig_dest, bld, iter * 2 + c),
+  offset(dest, bld, c));
+   }
+}
+
+/* If we are loading double data and we need a second read message
+ * adjust the offset
+ */
+if (num_iterations > 1) {
+   num_components = instr->num_components - 2;
+   imm_offset++;
 }
- } else {
-inst = bld.emit(SHADER_OPCODE_URB_READ_SIMD8_PER_SLOT, dest,
-payload);
-inst->regs_written = instr->num_components;
  }
- inst->mlen = 2;
- inst->offset = imm_offset;
   }
   break;
}
-- 
2.1.4

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


[Mesa-dev] [PATCH 1/2] i965/tcs/scalar: only update imm_offset for second message in 64bit input loads

2016-07-15 Thread Iago Toral Quiroga
Our indirect URB read messages take both a direct and an indirect offset
so when we emit the second message for a 64-bit input load we can just
always incremement the immediate offset, even for the indirect case.
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 129984a..55383ff 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -2507,13 +2507,7 @@ fs_visitor::nir_emit_tcs_intrinsic(const fs_builder ,
   */
  if (num_iterations > 1) {
 num_components = instr->num_components - 2;
-if (indirect_offset.file == BAD_FILE) {
-   imm_offset++;
-} else {
-   fs_reg new_indirect = bld.vgrf(BRW_REGISTER_TYPE_UD, 1);
-   bld.ADD(new_indirect, indirect_offset, brw_imm_ud(1u));
-   indirect_offset = new_indirect;
-}
+imm_offset++;
  }
   }
   break;
-- 
2.1.4

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


[Mesa-dev] [PATCH v2] main/shaderimage: image unit is invalid if texture is incomplete

2016-07-15 Thread Alejandro Piñeiro
From the OpenGL 4.3 Core Specification, section 8.25 ("Texture
Image Loads and Stores"):

  "An access is considered invalid if:
the texture bound to the selected image unit is incomplete;"

This fixes:
GL44-CTS.shader_image_load_store.incomplete_textures

v2: use _mesa_is_texture_complete, maintain image-texture level
checks (Curro)
---
 src/mesa/main/shaderimage.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
index 90643c4..94bb1e4 100644
--- a/src/mesa/main/shaderimage.c
+++ b/src/mesa/main/shaderimage.c
@@ -469,6 +469,15 @@ _mesa_is_image_unit_valid(struct gl_context *ctx, struct 
gl_image_unit *u)
if (!t->_BaseComplete && !t->_MipmapComplete)
_mesa_test_texobj_completeness(ctx, t);
 
+   /* From the OpenGL 4.3 Core Specification, Chapter 8.25, Texture Image
+* Loads and Stores:
+*
+*  "An access is considered invalid if:
+*the texture bound to the selected image unit is incomplete;"
+*/
+   if (!_mesa_is_texture_complete(t, >Sampler))
+  return GL_FALSE;
+
if (u->Level < t->BaseLevel ||
u->Level > t->_MaxLevel ||
(u->Level == t->BaseLevel && !t->_BaseComplete) ||
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] main/shaderimage: image unit invalid if texture is incomplete, independently of the level

2016-07-15 Thread Alejandro Piñeiro
On 14/07/16 21:24, Francisco Jerez wrote:
> Alejandro Piñeiro  writes:
>
>> Without this commit, a image is considered valid if the level of the
>> texture bound to the image is complete, something we can check as mesa
>> save independently if it is "base incomplete" of "mipmap incomplete".
>>
>> But, from the OpenGL 4.3 Core Specification, section 8.25 ("Texture
>> Image Loads and Stores"):
>>
>>   "An access is considered invalid if:
>> the texture bound to the selected image unit is incomplete;"
>>
>> This implies that the access to the image unit is invalid if the
>> texture is incomplete, no mattering details about the specific texture
>> level bound to the image.
>>
>> This fixes:
>> GL44-CTS.shader_image_load_store.incomplete_textures
>> ---
>>
>> Current piglit test is not testing what this commit tries to fix. I
>> will send a patch to piglit in short.
>>
>>  src/mesa/main/shaderimage.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
>> index 90643c4..d20cd90 100644
>> --- a/src/mesa/main/shaderimage.c
>> +++ b/src/mesa/main/shaderimage.c
>> @@ -469,10 +469,18 @@ _mesa_is_image_unit_valid(struct gl_context *ctx, 
>> struct gl_image_unit *u)
>> if (!t->_BaseComplete && !t->_MipmapComplete)
>> _mesa_test_texobj_completeness(ctx, t);
>>  
>> +   /* From the OpenGL 4.3 Core Specification, Chapter 8.25, Texture Image
>> +* Loads and Stores:
>> +*
>> +*  "An access is considered invalid if:
>> +*the texture bound to the selected image unit is incomplete;"
>> +*/
>> +   if (!t->_BaseComplete ||
>> +   !t->_MipmapComplete)
>> +  return GL_FALSE;
> I don't think this is correct, AFAIUI a texture having _MipmapComplete
> equal to false doesn't imply that the texture as a whole would be
> considered incomplete according to the GL's definition of completeness.
> Whether or not it's considered complete usually depends on the sampler
> state while you're doing regular texture sampling: If the sampler a
> texture object is used with has any of the mipmap filtering modes
> enabled you need to check _MipmapComplete, otherwise you need to check
> _BaseComplete.  The problem when you attempt to carry over this
> definition to shader images (as the spec implies) is that image units
> have no sampler state as such, and that they can only ever access one
> specified level of the texture at a time (potentially a texture level
> other than the base).  This patch makes image units behave like a
> sampler unit with mipmap filtering enabled for the purpose of texture
> completeness validation, which is almost definitely too strong.

Yes, I didn't realize that _BaseComplete and _MipmapComplete were not
checking the state at all. Thanks for pointing it.

> An alternative would be to do something along the lines of:
>
> | if (!_mesa_is_texture_complete(t, >Sampler))
> |return GL_FALSE;

Yes, that is what I wanted, to return false if the texture is incomplete.

>
> The problem is that you would then run into problems when some of the
> non-base mipmap levels are missing but the sampler state baked into the
> gl_texture_object says that you aren't mipmapping, so the GL spec would
> normally consider the texture to be complete and
> _mesa_is_texture_complete would return true accordingly, but still you
> wouldn't be able to use any of the missing texture levels as shader
> image if the application tried to bind them to an image unit (that's the
> reason for the u->Level vs t->BaseLevel checks below you're removing).

Ok, then if I understand correctly, the solution is not about replacing
the level checks for _mesa_is_texture_complete, but keeping current
checks, and add a _mesa_is_texture_complete check. Just checked and
everything seems to work fine (except that now the behaviour is more
strict, see below). I will send a patch in short.

> Honestly I think the current definition of image unit completeness is
> broken, because it considers the image unit state to be complete in
> cases where the image unit state is unusable (because the target image
> level may be missing even though the texture object itself is considered
> complete), and because it considers it to be incomplete in cases where
> you really have no reason to care (e.g. why should you care what the
> filtering mode from the sampler state says if you aren't doing any
> filtering at all, as long as the one level you've bound to the image
> unit is present and complete).

Well, yes in general the spec is being perhaps too strict. But I assume
that if we want to follow the spec, we don't have any other option.

FWIW, when testing the patch I mentioned before, some of the piglit
tests start to fail. The reason is that with that patch everything is
more strict, so the piglit tests need to set the filtering to NEAREST in
order to not fail. I will send a piglit patch soon too.
>
>> +
>> if 

[Mesa-dev] [PATCH] egl/dri2: dri2_make_current: Make sure display is initialized before using it

2016-07-15 Thread Nicolas Boichat
android.opengl.cts.WrapperTest#testGetIntegerv1 CTS test calls
eglTerminate, followed by eglReleaseThread. In that case, the
display will not be initialized when eglReleaseThread calls
MakeCurrent with NULL parameters, to unbind the context, which
causes a a segfault in drv->API.MakeCurrent (dri2_make_current),
either in glFlush or in a latter call.

A similar case is observed in this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69622, where the test
call eglTerminate, then eglMakeCurrent(dpy, NULL, NULL, NULL).

This patch:
 1. Validates that the display is initialized, if ctx/dsurf/rsurf
are not all NULL.
 2. Does not call glFlush/unBindContext is there is no display.
 3. However, it still goes through the normal path as
drv->API.DestroyContext decrements the reference count on the
context, and frees the structure.

Cc: "11.2 12.0" 
Signed-off-by: Nicolas Boichat 
---

I did not actually test the case reported on the bug, only the CTS
test, would be nice if someone can try it out (Rhys? Chad?).

Applies after "egl/dri2: dri2_make_current: Set EGL error if bindContext
fails", but wanted to keep the 2 patches separate as they are different
problems and discussions.

 src/egl/drivers/dri2/egl_dri2.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 2e97d85..3269e52 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1166,7 +1166,8 @@ dri2_destroy_context(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLContext *ctx)
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
 
if (_eglPutContext(ctx)) {
-  dri2_dpy->core->destroyContext(dri2_ctx->dri_context);
+  if (dri2_dpy)
+ dri2_dpy->core->destroyContext(dri2_ctx->dri_context);
   free(dri2_ctx);
}
 
@@ -1189,6 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
__DRIdrawable *ddraw, *rdraw;
__DRIcontext *cctx;
 
+   /* Check that the display is initialized */
+   if ((ctx != NULL || dsurf != NULL || rsurf != NULL) && !dri2_dpy)
+  return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent error");
+
/* make new bindings */
if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, _rsurf)) {
   /* _eglBindContext already sets the EGL error (in _eglCheckMakeCurrent) 
*/
@@ -1196,14 +1201,14 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
}
 
/* flush before context switch */
-   if (old_ctx && dri2_drv->glFlush)
+   if (old_ctx && dri2_dpy && dri2_drv->glFlush)
   dri2_drv->glFlush();
 
ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
 
-   if (old_ctx) {
+   if (old_ctx && dri2_dpy) {
   __DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
   dri2_dpy->core->unbindContext(old_cctx);
}
@@ -1292,6 +1297,8 @@ static EGLBoolean
 dri2_destroy_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
+   if (!dri2_dpy)
+  return EGL_TRUE;
return dri2_dpy->vtbl->destroy_surface(drv, dpy, surf);
 }
 
-- 
2.8.0.rc3.226.g39d4020

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


[Mesa-dev] [PATCH v3] egl/dri2: dri2_make_current: Set EGL error if bindContext fails

2016-07-15 Thread Nicolas Boichat
From: Nicolas Boichat 

Without this, if a configuration is, say, available only on GLES2/3, but
not on GLES1, and is rejected by the dri module's bindContext call,
eglMakeCurrent fails with error "EGL_SUCCESS".

In this patch, we set error to EGL_BAD_MATCH, which is what CTS/dEQP
dEQP-EGL.functional.surfaceless_context expect.

Cc: "11.2 12.0" 
Signed-off-by: Nicolas Boichat 
---

Emil: Took the opportunity to at least document where eglError is set. I guess,
in an ideal world, functions returning EGLBoolean should be annotated to tell
if they set (or not) the EGL error, so that callers know what to do on error.

 src/egl/drivers/dri2/egl_dri2.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index bfde640..2e97d85 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1190,8 +1190,10 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
__DRIcontext *cctx;
 
/* make new bindings */
-   if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, _rsurf))
+   if (!_eglBindContext(ctx, dsurf, rsurf, _ctx, _dsurf, _rsurf)) {
+  /* _eglBindContext already sets the EGL error (in _eglCheckMakeCurrent) 
*/
   return EGL_FALSE;
+   }
 
/* flush before context switch */
if (old_ctx && dri2_drv->glFlush)
@@ -1231,7 +1233,11 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
   _eglPutSurface(old_rsurf);
   _eglPutContext(old_ctx);
 
-  return EGL_FALSE;
+  /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, but
+   * setting the error to EGL_BAD_MATCH is surely better than leaving it
+   * as EGL_SUCCESS.
+   */
+  return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
}
 }
 
-- 
2.8.0.rc3.226.g39d4020

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


Re: [Mesa-dev] [PATCH v2] egl/dri2: dri2_make_current: Set EGL error if bindContext fails

2016-07-15 Thread Nicolas Boichat
Please ignore this patch, I'll resend along with some slightly
improved/annotated EGL error handling.

On Thu, Jul 14, 2016 at 12:22 PM, Nicolas Boichat  wrote:
> From: Nicolas Boichat 
>
> Without this, if a configuration is, say, available only on GLES2/3, but
> not on GLES1, and is rejected by the dri module's bindContext call,
> eglMakeCurrent fails with error "EGL_SUCCESS".
>
> In this patch, we set error to EGL_BAD_MATCH, which is what CTS/dEQP
> dEQP-EGL.functional.surfaceless_context expect.
>
> Cc: "11.2 12.0" 
> Signed-off-by: Nicolas Boichat 
> Reviewed-by: Emil Velikov 
> ---
>  src/egl/drivers/dri2/egl_dri2.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index bfde640..3cbdd0a 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1231,6 +1231,7 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
> _EGLSurface *dsurf,
>_eglPutSurface(old_rsurf);
>_eglPutContext(old_ctx);
>
> +  _eglError(EGL_BAD_MATCH, "eglMakeCurrent error");

I think you meant I should use "eglMakeCurrent" as error string.

>return EGL_FALSE;
> }
>  }
> --
> 2.8.0.rc3.226.g39d4020
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 10/10] egl/android: Add fallback to kms_swrast driver

2016-07-15 Thread Tomasz Figa
If no hardware driver is present, it is possible to fall back to
the kms_swrast driver with any DRI node that supports dumb GEM create
and mmap IOCTLs with softpipe/llvmpipe drivers. This patch makes the
Android EGL platform code retry probe with kms_swrast if hardware-only
probe fails.

Signed-off-by: Tomasz Figa 
---
 src/egl/drivers/dri2/platform_android.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 9c8156c..f0afca1 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -870,11 +870,14 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *dpy)
 }
 
 static int
-droid_probe_device(_EGLDisplay *dpy, int fd)
+droid_probe_device(_EGLDisplay *dpy, int fd, int swrast)
 {
struct dri2_egl_display *dri2_dpy = dpy->DriverData;
 
-   dri2_dpy->driver_name = loader_get_driver_for_fd(fd, 0);
+   if (swrast)
+  dri2_dpy->driver_name = strdup("kms_swrast");
+   else
+  dri2_dpy->driver_name = loader_get_driver_for_fd(fd, 0);
if (!dri2_dpy->driver_name)
   return -1;
 
@@ -891,7 +894,7 @@ droid_probe_device(_EGLDisplay *dpy, int fd)
 
 #ifdef HAS_GRALLOC_DRM_HEADERS
 static int
-droid_open_device(_EGLDisplay *dpy)
+droid_open_device(_EGLDisplay *dpy, int swrast)
 {
const hw_module_t *mod;
int fd = -1, err;
@@ -909,13 +912,13 @@ droid_open_device(_EGLDisplay *dpy)
   return -1;
}
 
-   return droid_probe_device(dpy, fd);
+   return droid_probe_device(dpy, fd, swrast);
 }
 #else
 #define DRM_RENDER_DEV_NAME  "%s/renderD%d"
 
 static int
-droid_open_device(_EGLDisplay *dpy)
+droid_open_device(_EGLDisplay *dpy, int swrast)
 {
struct dri2_egl_display *dri2_dpy = dpy->DriverData;
const int limit = 64;
@@ -933,7 +936,7 @@ droid_open_device(_EGLDisplay *dpy)
   if (fd < 0)
  continue;
 
-  if (!droid_probe_device(dpy, fd))
+  if (!droid_probe_device(dpy, fd, swrast))
  return 0;
}
 
@@ -1015,9 +1018,11 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
*dpy)
 
dpy->DriverData = (void *) dri2_dpy;
 
-   if (droid_open_device(dpy) < 0) {
-  err = "DRI2: failed to open device";
-  goto cleanup_display;
+   if (droid_open_device(dpy, 0) < 0) {
+  if (droid_open_device(dpy, 1) < 0) {
+ err = "DRI2: failed to open device";
+ goto cleanup_display;
+  }
}
 
dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) == 
DRM_NODE_RENDER;
-- 
2.8.0.rc3.226.g39d4020

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


[Mesa-dev] [PATCH 07/10] egl/android: Make drm_gralloc headers optional

2016-07-15 Thread Tomasz Figa
We can support render nodes alone without any private headers, so let's
make support for control nodes depend on presence of private drm_gralloc
headers.

Signed-off-by: Tomasz Figa 
---
 src/egl/Android.mk  |   1 +
 src/egl/drivers/dri2/egl_dri2.h |   2 +
 src/egl/drivers/dri2/platform_android.c | 194 ++--
 3 files changed, 138 insertions(+), 59 deletions(-)

diff --git a/src/egl/Android.mk b/src/egl/Android.mk
index bfd56a7..72ec02a 100644
--- a/src/egl/Android.mk
+++ b/src/egl/Android.mk
@@ -41,6 +41,7 @@ LOCAL_SRC_FILES := \
 LOCAL_CFLAGS := \
-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_ANDROID \
-D_EGL_BUILT_IN_DRIVER_DRI2 \
+   -DHAS_GRALLOC_DRM_HEADERS \
-DHAVE_ANDROID_PLATFORM
 
 LOCAL_C_INCLUDES := \
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 3ffc177..6f9623b 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -65,7 +65,9 @@
 #endif
 
 #include 
+#ifdef HAS_GRALLOC_DRM_HEADERS
 #include 
+#endif
 #include 
 
 #endif /* HAVE_ANDROID_PLATFORM */
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 0f707dd..4473400 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -38,7 +38,10 @@
 #include "loader.h"
 #include "egl_dri2.h"
 #include "egl_dri2_fallbacks.h"
+
+#ifdef HAS_GRALLOC_DRM_HEADERS
 #include "gralloc_drm.h"
+#endif
 
 static int
 get_format_bpp(int native)
@@ -104,11 +107,13 @@ get_native_buffer_fd(struct ANativeWindowBuffer *buf)
return (handle && handle->numFds) ? handle->data[0] : -1;
 }
 
+#ifdef HAS_GRALLOC_DRM_HEADERS
 static int
 get_native_buffer_name(struct ANativeWindowBuffer *buf)
 {
return gralloc_drm_get_gem_handle(buf->handle);
 }
+#endif
 
 static EGLBoolean
 droid_window_dequeue_buffer(struct dri2_egl_surface *dri2_surf)
@@ -210,6 +215,7 @@ droid_window_cancel_buffer(_EGLDisplay *disp, struct 
dri2_egl_surface *dri2_surf
droid_window_enqueue_buffer(disp, dri2_surf);
 }
 
+#ifdef HAS_GRALLOC_DRM_HEADERS
 static __DRIbuffer *
 droid_alloc_local_buffer(struct dri2_egl_surface *dri2_surf,
  unsigned int att, unsigned int format)
@@ -228,6 +234,7 @@ droid_alloc_local_buffer(struct dri2_egl_surface *dri2_surf,
 
return dri2_surf->local_buffers[att];
 }
+#endif
 
 static void
 droid_free_local_buffers(struct dri2_egl_surface *dri2_surf)
@@ -509,53 +516,43 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
 }
 
 static _EGLImage *
-dri2_create_image_android_native_buffer(_EGLDisplay *disp,
-_EGLContext *ctx,
-struct ANativeWindowBuffer *buf)
+droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx,
+ struct ANativeWindowBuffer *buf)
 {
-   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   struct dri2_egl_image *dri2_img;
-   int name, fd;
-   int format;
-
-   if (ctx != NULL) {
-  /* From the EGL_ANDROID_image_native_buffer spec:
-   *
-   * * If  is EGL_NATIVE_BUFFER_ANDROID and  is not
-   *   EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated.
-   */
-  _eglError(EGL_BAD_CONTEXT, "eglCreateEGLImageKHR: for "
-"EGL_NATIVE_BUFFER_ANDROID, the context must be "
-"EGL_NO_CONTEXT");
-  return NULL;
-   }
-
-   if (!buf || buf->common.magic != ANDROID_NATIVE_BUFFER_MAGIC ||
-   buf->common.version != sizeof(*buf)) {
-  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
-  return NULL;
-   }
+   int fd;
 
fd = get_native_buffer_fd(buf);
-   if (fd >= 0) {
-  const int fourcc = get_fourcc(get_format(buf->format));
-  const int pitch = buf->stride * get_format_bpp(buf->format);
+   if (fd < 0)
+  return NULL;
+
+   const int fourcc = get_fourcc(get_format(buf->format));
+   const int pitch = buf->stride * get_format_bpp(buf->format);
+
+   const EGLint attr_list[14] = {
+  EGL_WIDTH, buf->width,
+  EGL_HEIGHT, buf->height,
+  EGL_LINUX_DRM_FOURCC_EXT, fourcc,
+  EGL_DMA_BUF_PLANE0_FD_EXT, fd,
+  EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch,
+  EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
+  EGL_NONE, 0
+   };
 
-  const EGLint attr_list[14] = {
- EGL_WIDTH, buf->width,
- EGL_HEIGHT, buf->height,
- EGL_LINUX_DRM_FOURCC_EXT, fourcc,
- EGL_DMA_BUF_PLANE0_FD_EXT, fd,
- EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch,
- EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
- EGL_NONE, 0
-  };
+   if (fourcc == -1 || pitch == 0)
+  return NULL;
 
-  if (fourcc == -1 || pitch == 0)
- return NULL;
+   return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
+}
 
-  return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
-   }
+static _EGLImage *

[Mesa-dev] [PATCH 09/10] egl/android: Add support for YV12 pixel format

2016-07-15 Thread Tomasz Figa
This patch adds support for YV12 pixel format to the Android platform
backend. Only creating EGL images is supported, it is not added to the
list of available visuals.

Signed-off-by: Tomasz Figa 
Signed-off-by: Kalyan Kondapally 
---
 src/egl/drivers/dri2/platform_android.c | 82 -
 1 file changed, 70 insertions(+), 12 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 26d7b35..9c8156c 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -43,6 +43,8 @@
 #include "gralloc_drm.h"
 #endif
 
+#define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
+
 static int
 get_format_bpp(int native)
 {
@@ -60,6 +62,9 @@ get_format_bpp(int native)
case HAL_PIXEL_FORMAT_RGB_565:
   bpp = 2;
   break;
+   case HAL_PIXEL_FORMAT_YV12:
+  bpp = 1;
+  break;
default:
   bpp = 0;
   break;
@@ -76,6 +81,7 @@ static int get_fourcc(int native)
case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FOURCC_ARGB;
case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FOURCC_ABGR;
case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
+   case HAL_PIXEL_FORMAT_YV12:  return __DRI_IMAGE_FOURCC_YVU420;
default:
   _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native);
}
@@ -523,6 +529,10 @@ static _EGLImage *
 droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx,
  struct ANativeWindowBuffer *buf)
 {
+   unsigned int offsets[3] = { 0, 0, 0 };
+   unsigned int pitches[3] = { 0, 0, 0 };
+   unsigned int total_planes = 1;
+   int p, index;
int fd;
 
fd = get_native_buffer_fd(buf);
@@ -530,21 +540,69 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, 
_EGLContext *ctx,
   return NULL;
 
const int fourcc = get_fourcc(buf->format);
-   const int pitch = buf->stride * get_format_bpp(buf->format);
-
-   const EGLint attr_list[14] = {
-  EGL_WIDTH, buf->width,
-  EGL_HEIGHT, buf->height,
-  EGL_LINUX_DRM_FOURCC_EXT, fourcc,
-  EGL_DMA_BUF_PLANE0_FD_EXT, fd,
-  EGL_DMA_BUF_PLANE0_PITCH_EXT, pitch,
-  EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
-  EGL_NONE, 0
-   };
+   pitches[0] = buf->stride * get_format_bpp(buf->format);
 
-   if (fourcc == -1 || pitch == 0)
+   if (fourcc == -1 || pitches[0] == 0)
   return NULL;
 
+   switch (buf->format) {
+   case HAL_PIXEL_FORMAT_YV12:
+  /* Y plane is at offset 0 and fds[0] is already set. */
+  /* Cr plane is located after Y plane */
+  offsets[1] = offsets[0] + pitches[0] * buf->height;
+  pitches[1] = ALIGN(pitches[0] / 2, 16);
+  /* Cb plane is located after Cr plane */
+  offsets[2] = offsets[1] + pitches[1] * buf->height / 2;
+  pitches[2] = pitches[1];
+  total_planes = 3;
+  break;
+   default:
+  break;
+   }
+
+   /* TODO: Do we need to pass in the following or defaults suffice:
+* EGL_YUV_COLOR_SPACE_HINT_EXT,
+* EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT,
+* EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
+*/
+   EGLint plane_fd_attr[] = {
+  EGL_DMA_BUF_PLANE0_FD_EXT,
+  EGL_DMA_BUF_PLANE1_FD_EXT,
+  EGL_DMA_BUF_PLANE2_FD_EXT,
+   };
+
+   EGLint plane_pitch_attr[] = {
+  EGL_DMA_BUF_PLANE0_PITCH_EXT,
+  EGL_DMA_BUF_PLANE1_PITCH_EXT,
+  EGL_DMA_BUF_PLANE2_PITCH_EXT,
+   };
+
+   EGLint plane_offset_attr[] = {
+  EGL_DMA_BUF_PLANE0_OFFSET_EXT,
+  EGL_DMA_BUF_PLANE1_OFFSET_EXT,
+  EGL_DMA_BUF_PLANE2_OFFSET_EXT,
+   };
+
+   EGLint attr_list[25];
+   attr_list[0] = EGL_WIDTH;
+   attr_list[1] = buf->width;
+   attr_list[2] = EGL_HEIGHT;
+   attr_list[3] = buf->height;
+   attr_list[4] = EGL_LINUX_DRM_FOURCC_EXT;
+   attr_list[5] = fourcc;
+   index = 5;
+
+   for (p = 0; p < total_planes; ++p) {
+  attr_list[++index] = plane_fd_attr[p];
+  attr_list[++index] = fd;
+  attr_list[++index] = plane_pitch_attr[p];
+  attr_list[++index] = pitches[p];
+  attr_list[++index] = plane_offset_attr[p];
+  attr_list[++index] = offsets[p];
+   }
+
+   attr_list[++index] = EGL_NONE;
+
return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
 }
 
-- 
2.8.0.rc3.226.g39d4020

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


[Mesa-dev] [PATCH 08/10] egl/android: Make get_fourcc() accept HAL formats

2016-07-15 Thread Tomasz Figa
There are DRI_IMAGE_FOURCC macros, for which there are no corresponding
DRI_IMAGE_FORMAT macros. To support such formats we need to make the
lookup function take the native format directly. As a side effect, it
simplifies all existing calls to this function, because they all called
get_format() first to convert from native to DRI_IMAGE_FORMAT.

Signed-off-by: Tomasz Figa 
---
 src/egl/drivers/dri2/platform_android.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 4473400..26d7b35 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -69,18 +69,20 @@ get_format_bpp(int native)
 }
 
 /* createImageFromFds requires fourcc format */
-static int get_fourcc(int format)
+static int get_fourcc(int native)
 {
-   switch(format) {
-   case __DRI_IMAGE_FORMAT_RGB565:   return __DRI_IMAGE_FOURCC_RGB565;
-   case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
-   case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
-   case __DRI_IMAGE_FORMAT_ABGR: return __DRI_IMAGE_FOURCC_ABGR;
-   case __DRI_IMAGE_FORMAT_XBGR: return __DRI_IMAGE_FOURCC_XBGR;
+   switch (native) {
+   case HAL_PIXEL_FORMAT_RGB_565:   return __DRI_IMAGE_FOURCC_RGB565;
+   case HAL_PIXEL_FORMAT_BGRA_: return __DRI_IMAGE_FOURCC_ARGB;
+   case HAL_PIXEL_FORMAT_RGBA_: return __DRI_IMAGE_FOURCC_ABGR;
+   case HAL_PIXEL_FORMAT_RGBX_: return __DRI_IMAGE_FOURCC_XBGR;
+   default:
+  _eglLog(_EGL_WARNING, "unsupported native buffer format 0x%x", native);
}
return -1;
 }
 
+#ifdef HAS_GRALLOC_DRM_HEADERS
 static int get_format(int format)
 {
switch (format) {
@@ -95,6 +97,8 @@ static int get_format(int format)
}
return -1;
 }
+#endif
+
 static int
 get_native_buffer_fd(struct ANativeWindowBuffer *buf)
 {
@@ -435,7 +439,7 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
   return -1;
}
 
-   fourcc = get_fourcc(get_format(dri2_surf->buffer->format));
+   fourcc = get_fourcc(dri2_surf->buffer->format);
 
pitch = dri2_surf->buffer->stride *
   get_format_bpp(dri2_surf->buffer->format);
@@ -525,7 +529,7 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, 
_EGLContext *ctx,
if (fd < 0)
   return NULL;
 
-   const int fourcc = get_fourcc(get_format(buf->format));
+   const int fourcc = get_fourcc(buf->format);
const int pitch = buf->stride * get_format_bpp(buf->format);
 
const EGLint attr_list[14] = {
-- 
2.8.0.rc3.226.g39d4020

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


[Mesa-dev] [PATCH 06/10] egl/android: Fix support for pbuffers

2016-07-15 Thread Tomasz Figa
From: Nicolas Boichat 

Existing image loader code supports creating images only for window
surfaces. Moreover droid_create_surface() passes wrong surface type to
dri2_get_dri_config(), resulting in incorrect configs being returned for
pbuffers. This patch fixes these issues.

In addition, the config generation code is fixed to include single
buffered contexts required for pbuffers and make sure that generated
configs support only surfaces which can handle their supported buffering
modes.

Signed-off-by: Nicolas Boichat 
Signed-off-by: Tomasz Figa 
---
 src/egl/drivers/dri2/egl_dri2.h |  1 +
 src/egl/drivers/dri2/platform_android.c | 61 +++--
 2 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 317de06..3ffc177 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -287,6 +287,7 @@ struct dri2_egl_surface
struct ANativeWindow *window;
struct ANativeWindowBuffer *buffer;
__DRIimage *dri_image;
+   __DRIimage *dri_front_image;
 
/* EGL-owned buffers */
__DRIbuffer   *local_buffers[__DRI_BUFFER_COUNT];
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 7495445..0f707dd 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -286,7 +286,7 @@ droid_create_surface(_EGLDriver *drv, _EGLDisplay *disp, 
EGLint type,
   window->query(window, NATIVE_WINDOW_HEIGHT, _surf->base.Height);
}
 
-   config = dri2_get_dri_config(dri2_conf, EGL_WINDOW_BIT,
+   config = dri2_get_dri_config(dri2_conf, type,
 dri2_surf->base.GLColorspace);
if (!config)
   goto cleanup_surface;
@@ -347,6 +347,9 @@ droid_destroy_surface(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *surf)
   dri2_surf->window->common.decRef(_surf->window->common);
}
 
+   if (dri2_surf->dri_front_image)
+  dri2_dpy->image->destroyImage(dri2_surf->dri_front_image);
+
(*dri2_dpy->core->destroyDrawable)(dri2_surf->dri_drawable);
 
free(dri2_surf);
@@ -378,6 +381,29 @@ update_buffers(struct dri2_egl_surface *dri2_surf)
 }
 
 static int
+get_front_bo(struct dri2_egl_surface *dri2_surf, unsigned int format)
+{
+   struct dri2_egl_display *dri2_dpy =
+  dri2_egl_display(dri2_surf->base.Resource.Display);
+
+   if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
+  _eglLog(_EGL_WARNING, "Front buffer is not supported for window 
surfaces");
+  return -1;
+   }
+
+   if (dri2_surf->dri_front_image)
+  return 0;
+
+   dri2_surf->dri_front_image =
+  dri2_dpy->image->createImage(dri2_dpy->dri_screen,
+   dri2_surf->base.Width,
+   dri2_surf->base.Height,
+   format, 0, dri2_surf);
+
+   return dri2_surf->dri_front_image ? 0 : -1;
+}
+
+static int
 get_back_bo(struct dri2_egl_surface *dri2_surf)
 {
struct dri2_egl_display *dri2_dpy =
@@ -385,6 +411,11 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
int fourcc, pitch;
int offset = 0, fd;
 
+   if (dri2_surf->base.Type != EGL_WINDOW_BIT) {
+  _eglLog(_EGL_WARNING, "Back buffer is not supported for pbuffer 
surfaces");
+  return -1;
+   }
+
if (dri2_surf->dri_image)
   return 0;
 
@@ -440,8 +471,11 @@ droid_image_get_buffers(__DRIdrawable *driDrawable,
   return 0;
 
if (buffer_mask & __DRI_IMAGE_BUFFER_FRONT) {
-  _eglLog(_EGL_WARNING, "Front buffer is not supported for window 
surfaces");
-  return 0;
+  if (get_front_bo(dri2_surf, format) < 0)
+ return 0;
+
+  images->front = dri2_surf->dri_front_image;
+  images->image_mask |= __DRI_IMAGE_BUFFER_FRONT;
}
 
if (buffer_mask & __DRI_IMAGE_BUFFER_BACK) {
@@ -698,14 +732,6 @@ droid_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay 
*dpy)
   for (j = 0; dri2_dpy->driver_configs[j]; j++) {
  const EGLint surface_type = EGL_WINDOW_BIT | EGL_PBUFFER_BIT;
  struct dri2_egl_config *dri2_conf;
- unsigned int double_buffered = 0;
-
- dri2_dpy->core->getConfigAttrib(dri2_dpy->driver_configs[j],
-__DRI_ATTRIB_DOUBLE_BUFFER, _buffered);
-
- /* support only double buffered configs */
- if (!double_buffered)
-continue;
 
  dri2_conf = dri2_add_config(dpy, dri2_dpy->driver_configs[j],
count + 1, surface_type, config_attrs, visuals[i].rgba_masks);
@@ -728,6 +754,19 @@ droid_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay 
*dpy)
   /* there is no front buffer so no OpenGL */
   dri2_conf->base.RenderableType &= ~EGL_OPENGL_BIT;
   dri2_conf->base.Conformant &= ~EGL_OPENGL_BIT;
+
+  for (j = 0; j < 2; j++) {
+ /* Unsupported color space variants should not affect surface 

[Mesa-dev] [PATCH 01/10] egl/android: Set EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT

2016-07-15 Thread Tomasz Figa
From: Haixia Shi 

Set config attributes EGL_MAX_PBUFFER_WIDTH and EGL_MAX_PBUFFER_HEIGHT to
hard-coded non-zero values. These two attributes are required on Android.

Signed-off-by: Tomasz Figa 
---
 src/egl/drivers/dri2/platform_android.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index b33f4e8..f42febc 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -655,6 +655,8 @@ droid_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay 
*dpy)
  EGL_NATIVE_VISUAL_TYPE, 0,
  EGL_FRAMEBUFFER_TARGET_ANDROID, EGL_TRUE,
  EGL_RECORDABLE_ANDROID, EGL_TRUE,
+ EGL_MAX_PBUFFER_WIDTH, 4096,
+ EGL_MAX_PBUFFER_HEIGHT, 4096,
  EGL_NONE
};
int count, i, j;
-- 
2.8.0.rc3.226.g39d4020

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


  1   2   >