Re: [Mesa-dev] Stable release process

2016-11-19 Thread Daniel Stone
Hey Marek,

On 18 November 2016 at 19:09, Marek Olšák  wrote:
> On Fri, Nov 18, 2016 at 7:45 PM, Kai Wasserbäch
>  wrote:
>> wouldn't a tool like Phabricator be much better for reviewing and reliably
>> tracking whether a patch has landed or not? Especially if you use it in
>> combination with Arcanist? While I'm certainly not a core developer, I find
>> patchwork clunky. Sometimes it doesn't pick up R-bs or doesn't recognise 
>> series,
>> which makes seeing the actual state of a patch a bit tricky from time to 
>> time.
>>
>> In addition you would get things like automatically closure of bugs, nice
>> referencing features and lots of other nice features. And AFAIK 
>> freedesktop.org
>> already has a Phabricator instance, which could be used.
>
> OK, off topic we go.
>
> I have some experience with Phabricator and Arcanist from LLVM and
> it's not very good.
>
> Phabricator (or Arcanist) doesn't support patch series. You can only
> submit one patch, or a range of commits as one patch (which is pretty
> bad - why would anyone on Earth want to do that). It also doesn't
> support downloading patches in the mbox format (only plain diffs).
> Based on that, I don't recommend it.

Off-topic indeed. Arcanist is crippled, as you say, and I don't like
its UI. But git-phab does exist to let you attach patch series, e.g.
https://phabricator.freedesktop.org/T7573 contains a load.

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


Re: [Mesa-dev] UDL & Modeset with Mesa 13.0.1 - Segmentation fault

2016-11-19 Thread poma
On 18.11.2016 14:45, Emil Velikov wrote:
> On 17 November 2016 at 20:15, poma  wrote:
>>
>> Airlie solved everything concerning the kernel,
>> so it seems, now it's user space turn.
>>
>> = mesa-libgbm-12.0.3 - works OK
>> ...
>> [   714.429] (II) Loading sub module "glamoregl"
>> [   714.429] (II) LoadModule: "glamoregl"
>> [   714.430] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
>> [   714.480] (II) Module glamoregl: vendor="X.Org Foundation"
>> [   714.481]compiled for 1.19.0, module version = 1.0.0
>> [   714.481]ABI class: X.Org ANSI C Emulation, version 0.4
>> ...
>> [   714.481] (II) glamor: OpenGL accelerated X.org driver based.
>> [   714.633] (II) glamor: EGL version 1.4 (DRI2):
>> [   714.633] EGL_MESA_drm_image required.
>> [   714.634] (EE) modeset(0): glamor initialization failed
>> [   714.634] (II) modeset(0): ShadowFB: preferred NO, enabled NO
>> ...
>> [   714.643] (==) Depth 24 pixmap format is 32 bpp
>> [   714.645] (==) modeset(0): Backing store enabled
>> [   714.645] (==) modeset(0): Silken mouse enabled
>> [   714.645] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR 
>> disabled message.
>> [   714.646] (==) modeset(0): DPMS enabled
>> [   714.646] (--) RandR disabled
>> [   714.669] (II) AIGLX: Screen 0 is not DRI2 capable
>> [   714.669] (EE) AIGLX: reverting to software rendering
>> [   714.683] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
>> [   714.686] (II) IGLX: Loaded and initialized swrast
>> [   714.686] (II) GLX: Initialized DRISWRAST GL provider for screen 0
>> [   714.691] (II) modeset(0): Damage tracking initialized
>> ...
>>
>> = mesa-libgbm-13.0.1 - not quite
>> ...
>> [  2324.953] (II) Loading sub module "glamoregl"
>> [  2324.953] (II) LoadModule: "glamoregl"
>> [  2324.953] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
>> [  2325.000] (II) Module glamoregl: vendor="X.Org Foundation"
>> [  2325.000]compiled for 1.19.0, module version = 1.0.0
>> [  2325.000]ABI class: X.Org ANSI C Emulation, version 0.4
>> ...
>> [  2325.001] (II) glamor: OpenGL accelerated X.org driver based.
>> [  2325.002] (EE)
>> [  2325.002] (EE) Backtrace:
>> [  2325.006] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x59e389]
>> [  2325.008] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) 
>> [0x7f69d836ac2f]
>> [  2325.009] (EE) 2: /lib64/libgbm.so.1 
>> (gbm_surface_has_free_buffers+0x1505) [0x7f69d2b64685]
>> [  2325.010] (EE) 3: /lib64/libgbm.so.1 
>> (gbm_surface_has_free_buffers+0x1b98) [0x7f69d2b653b8]
>> [  2325.011] (EE) 4: /lib64/libgbm.so.1 
>> (gbm_surface_has_free_buffers+0x1498) [0x7f69d2b644c8]
>> [  2325.012] (EE) 5: /lib64/libgbm.so.1 (gbm_create_device+0x4c) 
>> [0x7f69d2b61a4c]
>> [  2325.014] (EE) 6: /usr/lib64/xorg/modules/libglamoregl.so 
>> (glamor_egl_init+0x83) [0x7f69d2d73fb3]
>> [  2325.015] (EE) 7: /usr/lib64/xorg/modules/drivers/modesetting_drv.so 
>> (_init+0x4d21) [0x7f69d2facfd1]
>> [  2325.016] (EE) 8: /usr/libexec/Xorg (InitOutput+0xa82) [0x47d6c2]
>> [  2325.017] (EE) 9: /usr/libexec/Xorg (InitFonts+0x216) [0x43ae36]
>> [  2325.020] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf1) 
>> [0x7f69d7fb8731]
>> [  2325.022] (EE) 11: /usr/libexec/Xorg (_start+0x29) [0x424d29]
>> [  2325.024] (EE) 12: ? (?+0x29) [0x29]
>> [  2325.025] (EE)
>> [  2325.025] (EE) Segmentation fault at address 0xc
>> [  2325.025] (EE)
>> Fatal server error:
>> [  2325.025] (EE) Caught signal 11 (Segmentation fault). Server aborting
>> [  2325.026] (EE)
>> [  2325.026] (EE)
>> ...
>> [  2325.027] (EE) Server terminated with error (1). Closing log file.
>>
>>
>> A call to not load the module(s) is not at all useful:
>> Section "Module"
>> Disable  "glx"
>> Disable  "glamoregl"
>> EndSection
>>
>> ...
>> (WW) "glx" will not be loaded unless you've specified it to be loaded 
>> elsewhere.
>> (WW) "glamoregl" will not be loaded unless you've specified it to be loaded 
>> elsewhere.
>> (II) "glx" will be loaded even though the default is to disable it.
>> ...
>> (II) Loading sub module "glamoregl"
>> (II) LoadModule: "glamoregl"
>> (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
>> (II) Module glamoregl: vendor="X.Org Foundation"
>> compiled for 1.19.0, module version = 1.0.0
>> ABI class: X.Org ANSI C Emulation, version 0.4
>> (II) glamor: OpenGL accelerated X.org driver based.
>> (EE)
>> (EE) Backtrace:
>> ...
>>
>> Therefore, until the issue resolved, there remain two workarounds:
>> downgrade mesa to 12.0.3, what works
>> OR
>> leave mesa 13.0.1 and:
>> # rm /usr/lib64/xorg/modules/libglamoregl.so
>>
> Is that with libdrm 2.4.72 or later ? Older ones are known to be
> broken with non-pci devices.
> Additionally ensure that your pthread-stubs package does _not_ have
> the following commit/patch [1].
> 
> Thanks
> Emil
> 
> [1] 
> https://cgit.freedesktop.org/xcb/pthread-stubs/commit/?id=fa6db2f9c018c54a47e94c0175450303d700aa92
> 

libdrm 2.4.71 -> 2.4.73 did the trick.

Apropos pthread-stubs within Fedora:
htt

Re: [Mesa-dev] [PATCH] swr: mark streamout buffers as written

2016-11-19 Thread Cherniak, Bruce
Reviewed-by: Bruce Cherniak  

> On Nov 17, 2016, at 7:49 PM, Ilia Mirkin  wrote:
> 
> Signed-off-by: Ilia Mirkin 
> ---
> src/gallium/drivers/swr/swr_state.cpp | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/src/gallium/drivers/swr/swr_state.cpp 
> b/src/gallium/drivers/swr/swr_state.cpp
> index 1c58d2a..520faea 100644
> --- a/src/gallium/drivers/swr/swr_state.cpp
> +++ b/src/gallium/drivers/swr/swr_state.cpp
> @@ -682,6 +682,13 @@ swr_update_resource_status(struct pipe_context *pipe,
>  swr_resource_read(ib->buffer);
>}
> 
> +   /* transform feedback buffers */
> +   for (uint32_t i = 0; i < ctx->num_so_targets; i++) {
> +  struct pipe_stream_output_target *target = ctx->so_targets[i];
> +  if (target && target->buffer)
> + swr_resource_write(target->buffer);
> +   }
> +
>/* texture sampler views */
>for (uint32_t j : {PIPE_SHADER_VERTEX, PIPE_SHADER_FRAGMENT}) {
>   for (uint32_t i = 0; i < ctx->num_sampler_views[j]; i++) {
> -- 
> 2.7.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


[Mesa-dev] [PATCH 3/4] swr: [rasterizer memory] only clear up to the LOD size

2016-11-19 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp 
b/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
index 31a40a3..ee13f55 100644
--- a/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
+++ b/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
@@ -60,6 +60,12 @@ struct StoreRasterTileClear
 UINT x, UINT y, // (x, y) pixel coordinate to start of raster tile.
 uint32_t renderTargetArrayIndex)
 {
+// If we're outside of the surface, stop.
+uint32_t lodWidth = std::max(pDstSurface->width >> 
pDstSurface->lod, 1U);
+uint32_t lodHeight = std::max(pDstSurface->height >> 
pDstSurface->lod, 1U);
+if (x >= lodWidth || y >= lodHeight)
+return;
+
 // Compute destination address for raster tile.
 uint8_t* pDstTile = (uint8_t*)ComputeSurfaceAddress(
 x, y, pDstSurface->arrayIndex + renderTargetArrayIndex,
@@ -73,7 +79,7 @@ struct StoreRasterTileClear
 UINT dstBytesPerRow = 0;
 
 // For each raster tile pixel in row 0 (rx, 0)
-for (UINT rx = 0; (rx < KNOB_TILE_X_DIM) && ((x + rx) < 
pDstSurface->width); ++rx)
+for (UINT rx = 0; (rx < KNOB_TILE_X_DIM) && ((x + rx) < lodWidth); 
++rx)
 {
 memcpy(pDst, dstFormattedColor, dstBytesPerPixel);
 
@@ -86,7 +92,7 @@ struct StoreRasterTileClear
 pDst = pDstTile + pDstSurface->pitch;
 
 // For each remaining row in the rest of the raster tile
-for (UINT ry = 1; (ry < KNOB_TILE_Y_DIM) && ((y + ry) < 
pDstSurface->height); ++ry)
+for (UINT ry = 1; (ry < KNOB_TILE_Y_DIM) && ((y + ry) < lodHeight); 
++ry)
 {
 // copy row
 memcpy(pDst, pDstTile, dstBytesPerRow);
-- 
2.7.3

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


[Mesa-dev] [PATCH 2/4] swr: [rasterizer memory] hook up stencil clears for ClearTile

2016-11-19 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp 
b/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
index 8501e21..31a40a3 100644
--- a/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
+++ b/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
@@ -156,16 +156,19 @@ void StoreHotTileClear(
 {
 PFN_STORE_TILES_CLEAR pfnStoreTilesClear = NULL;
 
-SWR_ASSERT(renderTargetIndex != SWR_ATTACHMENT_STENCIL);  ///@todo Not 
supported yet.
-
-if (renderTargetIndex != SWR_ATTACHMENT_DEPTH)
+if (renderTargetIndex == SWR_ATTACHMENT_STENCIL)
 {
-pfnStoreTilesClear = sStoreTilesClearColorTable[pDstSurface->format];
+SWR_ASSERT(pDstSurface->format == R8_UINT);
+pfnStoreTilesClear = StoreMacroTileClear::StoreClear;
 }
-else
+else if (renderTargetIndex == SWR_ATTACHMENT_DEPTH)
 {
 pfnStoreTilesClear = sStoreTilesClearDepthTable[pDstSurface->format];
 }
+else
+{
+pfnStoreTilesClear = sStoreTilesClearColorTable[pDstSurface->format];
+}
 
 SWR_ASSERT(pfnStoreTilesClear != NULL);
 
-- 
2.7.3

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


[Mesa-dev] [PATCH 4/4] swr: [rasterizer core] use ClearTile helper to store fast clears

2016-11-19 Thread Ilia Mirkin
No point in clearing the hot tile and then storing that - may as well
just store the clear color to the surface directly. Use the helper that
already exists for this purpose.

Signed-off-by: Ilia Mirkin 
---

My theory is that this is going to be a very modest perf improvement. Instead
of first clearing the hot tile and then storing it, we store the clear color
directly.

It does bring up a rare case where a tile might be cleared, stored, and then
re-used with the same buffer. In that case, the former logic would avoid the
load while the new logic will end up reloading the clear color/etc. There was
a grand total of one piglit that was hit by this:

  fbo-attachments-blit-scaled-linear

(and that is the reason that we have to set the hottile to INVALID rather than
the post state when storing.)

 src/gallium/drivers/swr/rasterizer/core/backend.cpp | 17 ++---
 src/gallium/drivers/swr/rasterizer/core/tilemgr.cpp | 15 +--
 2 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/core/backend.cpp 
b/src/gallium/drivers/swr/rasterizer/core/backend.cpp
index c45c0a7..ff08233 100644
--- a/src/gallium/drivers/swr/rasterizer/core/backend.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/backend.cpp
@@ -358,16 +358,19 @@ void ProcessStoreTileBE(DRAW_CONTEXT *pDC, uint32_t 
workerId, uint32_t macroTile
 HOTTILE *pHotTile = pContext->pHotTileMgr->GetHotTileNoLoad(pContext, pDC, 
macroTile, attachment, false);
 if (pHotTile)
 {
-// clear if clear is pending (i.e., not rendered to), then mark as 
dirty for store.
+// clear the surface directly
 if (pHotTile->state == HOTTILE_CLEAR)
 {
-PFN_CLEAR_TILES pfnClearTiles = sClearTilesTable[srcFormat];
-SWR_ASSERT(pfnClearTiles != nullptr);
-
-pfnClearTiles(pDC, attachment, macroTile, 
pHotTile->renderTargetArrayIndex, pHotTile->clearData, pDesc->rect);
+pContext->pfnClearTile(GetPrivateState(pDC), attachment,
+x * KNOB_MACROTILE_X_DIM, y * KNOB_MACROTILE_Y_DIM,
+pHotTile->renderTargetArrayIndex,
+(const float *)pHotTile->clearData);
+
+// Since the state is effectively uninitialized, make sure that we
+// reload any data.
+pHotTile->state = HOTTILE_INVALID;
 }
-
-if (pHotTile->state == HOTTILE_DIRTY || pDesc->postStoreTileState == 
(SWR_TILE_STATE)HOTTILE_DIRTY)
+else if (pHotTile->state == HOTTILE_DIRTY || pDesc->postStoreTileState 
== (SWR_TILE_STATE)HOTTILE_DIRTY)
 {
 int32_t destX = KNOB_MACROTILE_X_DIM * x;
 int32_t destY = KNOB_MACROTILE_Y_DIM * y;
diff --git a/src/gallium/drivers/swr/rasterizer/core/tilemgr.cpp 
b/src/gallium/drivers/swr/rasterizer/core/tilemgr.cpp
index f398667..a4a6152 100644
--- a/src/gallium/drivers/swr/rasterizer/core/tilemgr.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/tilemgr.cpp
@@ -151,17 +151,12 @@ HOTTILE* HotTileMgr::GetHotTile(SWR_CONTEXT* pContext, 
DRAW_CONTEXT* pDC, uint32
 
 if (hotTile.state == HOTTILE_CLEAR)
 {
-if (attachment == SWR_ATTACHMENT_STENCIL)
-ClearStencilHotTile(&hotTile);
-else if (attachment == SWR_ATTACHMENT_DEPTH)
-ClearDepthHotTile(&hotTile);
-else
-ClearColorHotTile(&hotTile);
-
-hotTile.state = HOTTILE_DIRTY;
+pContext->pfnClearTile(GetPrivateState(pDC), attachment,
+x * KNOB_MACROTILE_X_DIM, y * KNOB_MACROTILE_Y_DIM,
+hotTile.renderTargetArrayIndex,
+(const float *)hotTile.clearData);
 }
-
-if (hotTile.state == HOTTILE_DIRTY)
+else if (hotTile.state == HOTTILE_DIRTY)
 {
 pContext->pfnStoreTile(GetPrivateState(pDC), format, 
attachment,
 x * KNOB_MACROTILE_X_DIM, y * KNOB_MACROTILE_Y_DIM, 
hotTile.renderTargetArrayIndex, hotTile.pBuffer);
-- 
2.7.3

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


[Mesa-dev] [PATCH 1/4] swr: [rasterizer memory] add support for clearing Z32F_X32 and Z16

2016-11-19 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp 
b/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
index 717d12c..8501e21 100644
--- a/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
+++ b/src/gallium/drivers/swr/rasterizer/memory/ClearTile.cpp
@@ -282,7 +282,9 @@ void StoreHotTileClear(
 memset(sStoreTilesClearDepthTable, 0, sizeof(sStoreTilesClearDepthTable)); 
\
 \
 sStoreTilesClearDepthTable[R32_FLOAT] = StoreMacroTileClear::StoreClear; \
+sStoreTilesClearDepthTable[R32_FLOAT_X8X24_TYPELESS] = 
StoreMacroTileClear::StoreClear; \
 sStoreTilesClearDepthTable[R24_UNORM_X8_TYPELESS] = 
StoreMacroTileClear::StoreClear; \
+sStoreTilesClearDepthTable[R16_UNORM] = StoreMacroTileClear::StoreClear; \
 
 //
 /// @brief Sets up tables for ClearTile
-- 
2.7.3

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


[Mesa-dev] [PATCH] swr: report a reasonable max lod bias

2016-11-19 Thread Ilia Mirkin
This is the same value that llvmpipe uses. Since swr uses the same
sampler logic, makes sense for this value to also be the same. Most
applications don't care.

Signed-off-by: Ilia Mirkin 
---

I kind of assume this is dependent on my layout patches since LODs weren't
always properly handled before.

 src/gallium/drivers/swr/swr_screen.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index 36afcc3..9affa02 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -406,7 +406,7 @@ swr_get_paramf(struct pipe_screen *screen, enum pipe_capf 
param)
case PIPE_CAPF_MAX_TEXTURE_ANISOTROPY:
   return 0.0;
case PIPE_CAPF_MAX_TEXTURE_LOD_BIAS:
-  return 0.0;
+  return 16.0; /* arbitrary */
case PIPE_CAPF_GUARD_BAND_LEFT:
case PIPE_CAPF_GUARD_BAND_TOP:
case PIPE_CAPF_GUARD_BAND_RIGHT:
-- 
2.7.3

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


[Mesa-dev] [PATCH] swr: calculate viewport width/height based on the scale

2016-11-19 Thread Ilia Mirkin
The former calculations were for min/max y. The width/height don't take
translate into account.

Signed-off-by: Ilia Mirkin 
---

Not sure that this fixes anything. However it probably should, since you're
supposed to clip triangles at the viewport boundary. There are definitely
dEQP tests for this, but maybe not piglits.

 src/gallium/drivers/swr/swr_state.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index 520faea..f7b77fd 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -1018,9 +1018,9 @@ swr_update_derived(struct pipe_context *pipe,
   SWR_VIEWPORT_MATRICES *vpm = &ctx->derived.vpm;
 
   vp->x = state->translate[0] - state->scale[0];
-  vp->width = state->translate[0] + state->scale[0];
+  vp->width = 2 * state->scale[0];
   vp->y = state->translate[1] - fabs(state->scale[1]);
-  vp->height = state->translate[1] + fabs(state->scale[1]);
+  vp->height = 2 * fabs(state->scale[1]);
   util_viewport_zmin_zmax(state, rasterizer->clip_halfz,
   &vp->minZ, &vp->maxZ);
 
-- 
2.7.3

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


[Mesa-dev] [PATCH v2] swr: calculate viewport width/height based on the scale

2016-11-19 Thread Ilia Mirkin
The former calculations were for min/max y. The width/height don't take
translate into account.

Signed-off-by: Ilia Mirkin 
---

v1 -> v2: also fix clamping logic to respect viewport offset

 src/gallium/drivers/swr/swr_state.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index 520faea..c889a68 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -1018,9 +1018,9 @@ swr_update_derived(struct pipe_context *pipe,
   SWR_VIEWPORT_MATRICES *vpm = &ctx->derived.vpm;
 
   vp->x = state->translate[0] - state->scale[0];
-  vp->width = state->translate[0] + state->scale[0];
+  vp->width = 2 * state->scale[0];
   vp->y = state->translate[1] - fabs(state->scale[1]);
-  vp->height = state->translate[1] + fabs(state->scale[1]);
+  vp->height = 2 * fabs(state->scale[1]);
   util_viewport_zmin_zmax(state, rasterizer->clip_halfz,
   &vp->minZ, &vp->maxZ);
 
@@ -1035,8 +1035,8 @@ swr_update_derived(struct pipe_context *pipe,
* size.  OpenGL allows for -ve x,y in the viewport. */
   vp->x = std::max(vp->x, 0.0f);
   vp->y = std::max(vp->y, 0.0f);
-  vp->width = std::min(vp->width, (float)fb->width);
-  vp->height = std::min(vp->height, (float)fb->height);
+  vp->width = std::min(vp->width, (float)fb->width - vp->x);
+  vp->height = std::min(vp->height, (float)fb->height - vp->x);
 
   SwrSetViewports(ctx->swrContext, 1, vp, vpm);
}
-- 
2.7.3

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


[Mesa-dev] [Bug 98714] Weird whitish spots and green stuff mostly on black.

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98714

--- Comment #1 from Vedran Miletić  ---
There are rendering issues on R9 380X as well, but of different kind. What
version of Mesa and LLVM are you using?

-- 
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 98714] Weird whitish spots and green stuff mostly on black.

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98714

Vedran Miletić  changed:

   What|Removed |Added

 CC||ved...@miletic.net

-- 
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 98783] Talos rendering garbage in menu when using Vulkan

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98783

Bug ID: 98783
   Summary: Talos rendering garbage in menu when using Vulkan
   Product: Mesa
   Version: git
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ved...@miletic.net
QA Contact: mesa-dev@lists.freedesktop.org

I'm using Mesa and LLVM git snapshots on kernel 4.8.8 on Tonga (R9 380X).
Running Talos public beta gives:

[  587.728078] amdgpu :01:00.0: GPU fault detected: 147 0x0002c802
[  587.728083] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  587.728087] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x050C8002
[  587.728090] VM fault (0x02, vmid 2) at page 0, write from 'TC3' (0x54433300)
(200)
[  587.728096] amdgpu :01:00.0: GPU fault detected: 147 0x0002c802
[  587.728100] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  587.728102] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x050C8002
[  587.728105] VM fault (0x02, vmid 2) at page 0, write from 'TC3' (0x54433300)
(200)
[  587.728143] amdgpu :01:00.0: GPU fault detected: 147 0x00024002
[  587.728149] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  587.728153] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x05040002
[  587.728156] VM fault (0x02, vmid 2) at page 0, write from 'TC8' (0x54433800)
(64)
[  587.728302] amdgpu :01:00.0: GPU fault detected: 147 0x00028002
[  587.728309] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  587.728314] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x05080002
[  587.728319] VM fault (0x02, vmid 2) at page 0, write from 'TC11'
(0x54433131) (128)
[  587.742639] amdgpu :01:00.0: GPU fault detected: 147 0x00028802
[  587.742645] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  587.742648] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x05088002
[  587.742652] VM fault (0x02, vmid 2) at page 0, write from 'TC9' (0x54433900)
(136)
[  587.742658] amdgpu :01:00.0: GPU fault detected: 147 0x00024002
[  587.742661] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  587.742665] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x05040002
[  587.742667] VM fault (0x02, vmid 2) at page 0, write from 'TC8' (0x54433800)
(64)
[  587.742807] amdgpu :01:00.0: GPU fault detected: 147 0x00028002
[  587.742812] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  587.742816] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x05080002
[  587.742819] VM fault (0x02, vmid 2) at page 0, write from 'TC11'
(0x54433131) (128)

Screenshot incoming.

-- 
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 98783] Talos rendering garbage in menu when using Vulkan

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98783

--- Comment #1 from Vedran Miletić  ---
Created attachment 128071
  --> https://bugs.freedesktop.org/attachment.cgi?id=128071&action=edit
Menu garbage

-- 
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 98783] Talos Principle rendering garbage in main menu animation when using Vulkan

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98783

Vedran Miletić  changed:

   What|Removed |Added

Summary|Talos rendering garbage in  |Talos Principle rendering
   |menu when using Vulkan  |garbage in main menu
   ||animation when using Vulkan

-- 
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 07/12] docs/submittingpatches: flesh out "how to nominate" methods

2016-11-19 Thread Matt Turner

On 11/16, Emil Velikov wrote:

From: Emil Velikov 

Currently things are a bit buried within the text, making it harder to
find out. Move at the top and be clear what is _not_ a good idea.

We had some people consistently using the "bad" way and then being
unhappy that their patches were missed/delayed.

Cc: Marek Olšák 
Signed-off-by: Emil Velikov 
---
docs/submittingpatches.html | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html
index 77b870a..0ab 100644
--- a/docs/submittingpatches.html
+++ b/docs/submittingpatches.html
@@ -184,6 +184,24 @@ as the issues are resolved first.
Nominating a commit for a stable branch


+There are three ways to nominate patch for inclusion of the stable branch and
+release.
+
+
+ By adding the Cc: mesa-stable@ tag as described below.
+ Sending the commit ID (as seen in master branch) to the mesa-stable@ 
mailing list.
+ Forwarding the patch from the mesa-dev@ mailing list.
+
+
+
+Note: sending [re]sending patch identical to one on mesa-dev@ or one that


"sending [re]sending"?

Just "resending" seems sufficient.


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


[Mesa-dev] [PATCH 4/7] anv/cmd_buffer: Apply remaining flushes in EndCommandBuffer

2016-11-19 Thread Jason Ekstrand
Otherwise, some pipe flushes may just never happen.  This is unlikely to
cause problems depending on how the kernel schedules batches, but we
shouldn't count on it.
---
 src/intel/vulkan/genX_cmd_buffer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 8e03cca..1ad28fd 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -453,6 +453,8 @@ genX(EndCommandBuffer)(
 {
ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
 
+   genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
+
anv_cmd_buffer_end_batch_buffer(cmd_buffer);
 
return VK_SUCCESS;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 5/7] anv/blorp: Rework flushing around resolves

2016-11-19 Thread Jason Ekstrand
It turns out that the flushing required around resolves is a bit more
extensive than I first thought.  You actually need render cache flush
and a CS stall both before *and* after the resolve.
---
 src/intel/vulkan/anv_blorp.c | 32 ++--
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index f4b6c7e..24b98ab 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1334,6 +1334,21 @@ ccs_resolve_attachment(struct anv_cmd_buffer *cmd_buffer,
get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
 att_state->aux_usage, &surf);
 
+   /* From the Sky Lake PRM Vol. 7, "Render Target Resolve":
+*
+*"When performing a render target resolve, PIPE_CONTROL with end of
+*pipe sync must be delivered."
+*
+* This comment is a bit cryptic and doesn't really tell you what's going
+* or what's really needed.  It appears that fast clear ops are not
+* properly synchronized with other drawing.  We need to use a PIPE_CONTROL
+* to ensure that the contents of the previous draw hit the render target
+* before we resolve and then use a second PIPE_CONTROL after the resolve
+* to ensure that it is completed before any additional drawing occurs.
+*/
+   cmd_buffer->state.pending_pipe_bits |=
+  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
+
for (uint32_t layer = 0; layer < fb->layers; layer++) {
   blorp_ccs_resolve(batch, &surf,
 iview->isl.base_level,
@@ -1341,6 +1356,9 @@ ccs_resolve_attachment(struct anv_cmd_buffer *cmd_buffer,
 iview->isl.format,
 BLORP_FAST_CLEAR_OP_RESOLVE_FULL);
}
+
+   cmd_buffer->state.pending_pipe_bits |=
+  ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
 }
 
 void
@@ -1353,13 +1371,6 @@ anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer 
*cmd_buffer)
struct blorp_batch batch;
blorp_batch_init(&cmd_buffer->device->blorp, &batch, cmd_buffer, 0);
 
-   /* From the Sky Lake PRM Vol. 7, "Render Target Resolve":
-*
-*"When performing a render target resolve, PIPE_CONTROL with end of
-*pipe sync must be delivered."
-*/
-   cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
-
for (uint32_t i = 0; i < subpass->color_count; ++i) {
   ccs_resolve_attachment(cmd_buffer, &batch,
  subpass->color_attachments[i]);
@@ -1403,13 +1414,6 @@ anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer 
*cmd_buffer)
render_area.offset.x, render_area.offset.y,
render_area.extent.width, render_area.extent.height);
 
- /* From the Sky Lake PRM Vol. 7, "Render Target Resolve":
-  *
-  *"When performing a render target resolve, PIPE_CONTROL with end
-  *of pipe sync must be delivered."
-  */
- cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
-
  ccs_resolve_attachment(cmd_buffer, &batch, dst_att);
   }
 
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 1/7] anv/cmd_buffer: Make setup_attachments take a RenderPassBeginInfo

2016-11-19 Thread Jason Ekstrand
---
 src/intel/vulkan/genX_cmd_buffer.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 0feae41..8e03cca 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -229,8 +229,7 @@ need_input_attachment_state(const struct 
anv_render_pass_attachment *att)
 static void
 genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer *cmd_buffer,
struct anv_render_pass *pass,
-   struct anv_framebuffer *framebuffer,
-   const VkClearValue *clear_values)
+   const VkRenderPassBeginInfo *begin)
 {
const struct isl_device *isl_dev = &cmd_buffer->device->isl_dev;
struct anv_cmd_state *state = &cmd_buffer->state;
@@ -299,7 +298,8 @@ genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer 
*cmd_buffer,
assert(next_state.offset == state->render_pass_states.offset +
state->render_pass_states.alloc_size);
 
-   if (framebuffer) {
+   if (begin) {
+  ANV_FROM_HANDLE(anv_framebuffer, framebuffer, begin->framebuffer);
   assert(pass->attachment_count == framebuffer->attachment_count);
 
   if (need_null_state) {
@@ -345,7 +345,7 @@ genX(cmd_buffer_setup_attachments)(struct anv_cmd_buffer 
*cmd_buffer,
 
  state->attachments[i].pending_clear_aspects = clear_aspects;
  if (clear_aspects)
-state->attachments[i].clear_value = clear_values[i];
+state->attachments[i].clear_value = begin->pClearValues[i];
 
  struct anv_image_view *iview = framebuffer->attachments[i];
  assert(iview->vk_format == att->format);
@@ -439,7 +439,7 @@ genX(BeginCommandBuffer)(
   cmd_buffer->state.framebuffer = NULL;
 
   genX(cmd_buffer_setup_attachments)(cmd_buffer, cmd_buffer->state.pass,
- NULL, NULL);
+ NULL);
 
   cmd_buffer->state.dirty |= ANV_CMD_DIRTY_RENDER_TARGETS;
}
@@ -2061,8 +2061,7 @@ void genX(CmdBeginRenderPass)(
cmd_buffer->state.framebuffer = framebuffer;
cmd_buffer->state.pass = pass;
cmd_buffer->state.render_area = pRenderPassBegin->renderArea;
-   genX(cmd_buffer_setup_attachments)(cmd_buffer, pass, framebuffer,
-  pRenderPassBegin->pClearValues);
+   genX(cmd_buffer_setup_attachments)(cmd_buffer, pass, pRenderPassBegin);
 
genX(flush_pipeline_select_3d)(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] [PATCH 3/7] anv/blorp: Use regular blorp clears for subpass clears

2016-11-19 Thread Jason Ekstrand
At vkCmdNextSubpass time, we have the actual framebuffer so we can use
regular blorp_clear for subpass clears.  For fast clears, there is no
attachment version, so this will make fast clears a bit easier.
---
 src/intel/vulkan/anv_blorp.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index ae650de..f4b6c7e 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1163,24 +1163,33 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
   .layerCount = cmd_buffer->state.framebuffer->layers,
};
 
+   struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
   const uint32_t a = cmd_state->subpass->color_attachments[i];
+  struct anv_attachment_state *att_state = &cmd_state->attachments[a];
 
-  if (!cmd_state->attachments[a].pending_clear_aspects)
+  if (!att_state->pending_clear_aspects)
  continue;
 
-  assert(cmd_state->attachments[a].pending_clear_aspects ==
- VK_IMAGE_ASPECT_COLOR_BIT);
+  assert(att_state->pending_clear_aspects == VK_IMAGE_ASPECT_COLOR_BIT);
 
-  VkClearAttachment clear_att = {
- .aspectMask = VK_IMAGE_ASPECT_COLOR_BIT,
- .colorAttachment = i, /* Use attachment index relative to subpass */
- .clearValue = cmd_state->attachments[a].clear_value,
-  };
+  struct anv_image_view *iview = fb->attachments[a];
+  const struct anv_image *image = iview->image;
+  struct blorp_surf surf;
+  get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
+   att_state->aux_usage, &surf);
+
+  const VkRect2D render_area = cmd_buffer->state.render_area;
 
-  clear_color_attachment(cmd_buffer, &batch, &clear_att, 1, &clear_rect);
+  blorp_clear(&batch, &surf, iview->isl.format, iview->isl.swizzle,
+  iview->isl.base_level,
+  iview->isl.base_array_layer, fb->layers,
+  render_area.offset.x, render_area.offset.y,
+  render_area.offset.x + render_area.extent.width,
+  render_area.offset.y + render_area.extent.height,
+  vk_to_isl_color(att_state->clear_value.color), NULL);
 
-  cmd_state->attachments[a].pending_clear_aspects = 0;
+  att_state->pending_clear_aspects = 0;
}
 
const uint32_t ds = cmd_state->subpass->depth_stencil_attachment;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 2/7] anv/blorp: Add a vk_to_isl_color helper

2016-11-19 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_blorp.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 2fccf5c..ae650de 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -786,6 +786,19 @@ void anv_CmdFillBuffer(
blorp_batch_finish(&batch);
 }
 
+static union isl_color_value
+vk_to_isl_color(VkClearColorValue color)
+{
+   return (union isl_color_value) {
+  .u32 = {
+ color.uint32[0],
+ color.uint32[1],
+ color.uint32[2],
+ color.uint32[3],
+  },
+   };
+}
+
 void anv_CmdClearColorImage(
 VkCommandBuffer commandBuffer,
 VkImage _image,
@@ -802,9 +815,6 @@ void anv_CmdClearColorImage(
struct blorp_batch batch;
blorp_batch_init(&cmd_buffer->device->blorp, &batch, cmd_buffer, 0);
 
-   union isl_color_value clear_color;
-   memcpy(clear_color.u32, pColor->uint32, sizeof(pColor->uint32));
-
struct blorp_surf surf;
get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
 image->aux_usage, &surf);
@@ -836,7 +846,7 @@ void anv_CmdClearColorImage(
  src_format.isl_format, src_format.swizzle,
  level, base_layer, layer_count,
  0, 0, level_width, level_height,
- clear_color, color_write_disable);
+ vk_to_isl_color(*pColor), color_write_disable);
   }
}
 
@@ -963,9 +973,8 @@ clear_color_attachment(struct anv_cmd_buffer *cmd_buffer,
uint32_t binding_table =
   binding_table_for_surface_state(cmd_buffer, att_state->color_rt_state);
 
-   union isl_color_value clear_color;
-   memcpy(clear_color.u32, attachment->clearValue.color.uint32,
-  sizeof(clear_color.u32));
+   union isl_color_value clear_color =
+  vk_to_isl_color(attachment->clearValue.color);
 
for (uint32_t r = 0; r < rectCount; ++r) {
   const VkOffset2D offset = pRects[r].rect.offset;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 0/7] anv: Add support for fast clears

2016-11-19 Thread Jason Ekstrand
This little series builds on top of the input attachment series I sent out
earlier this week and adds support for fast clears in Vulkan.  I've tested
it on both Sky Lake and Haswell and it has no regressions over the input
attachments series.

Jason Ekstrand (7):
  anv/cmd_buffer: Make setup_attachments take a RenderPassBeginInfo
  anv/blorp: Add a vk_to_isl_color helper
  anv/blorp: Use regular blorp clears for subpass clears
  anv/cmd_buffer: Apply remaining flushes in EndCommandBuffer
  anv/blorp: Rework flushing around resolves
  anv: Add support for fast clears on gen9
  anv: Enable fast clears on gen7-8

 src/intel/vulkan/anv_blorp.c   | 172 +
 src/intel/vulkan/anv_image.c   |   2 +-
 src/intel/vulkan/anv_private.h |   3 +
 src/intel/vulkan/genX_cmd_buffer.c | 138 -
 4 files changed, 254 insertions(+), 61 deletions(-)

-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 6/7] anv: Add support for fast clears on gen9

2016-11-19 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_blorp.c   | 102 -
 src/intel/vulkan/anv_private.h |   3 ++
 src/intel/vulkan/genX_cmd_buffer.c | 100 ++--
 3 files changed, 176 insertions(+), 29 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 24b98ab..cab1906 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1178,16 +1178,35 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
   struct blorp_surf surf;
   get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
att_state->aux_usage, &surf);
+  surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
 
   const VkRect2D render_area = cmd_buffer->state.render_area;
 
-  blorp_clear(&batch, &surf, iview->isl.format, iview->isl.swizzle,
-  iview->isl.base_level,
-  iview->isl.base_array_layer, fb->layers,
-  render_area.offset.x, render_area.offset.y,
-  render_area.offset.x + render_area.extent.width,
-  render_area.offset.y + render_area.extent.height,
-  vk_to_isl_color(att_state->clear_value.color), NULL);
+  if (att_state->fast_clear) {
+ blorp_fast_clear(&batch, &surf, iview->isl.format,
+  iview->isl.base_level,
+  iview->isl.base_array_layer, fb->layers,
+  render_area.offset.x, render_area.offset.y,
+  render_area.offset.x + render_area.extent.width,
+  render_area.offset.y + render_area.extent.height);
+
+ /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
+  *
+  *"After Render target fast clear, pipe-control with color cache
+  *write-flush must be issued before sending any DRAW commands on
+  *that render target."
+  */
+ cmd_buffer->state.pending_pipe_bits |=
+ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
+  } else {
+ blorp_clear(&batch, &surf, iview->isl.format, iview->isl.swizzle,
+ iview->isl.base_level,
+ iview->isl.base_array_layer, fb->layers,
+ render_area.offset.x, render_area.offset.y,
+ render_area.offset.x + render_area.extent.width,
+ render_area.offset.y + render_area.extent.height,
+ surf.clear_color, NULL);
+  }
 
   att_state->pending_clear_aspects = 0;
}
@@ -1298,10 +1317,12 @@ ccs_resolve_attachment(struct anv_cmd_buffer 
*cmd_buffer,
struct anv_attachment_state *att_state =
   &cmd_buffer->state.attachments[att];
 
-   assert(att_state->aux_usage != ISL_AUX_USAGE_CCS_D);
-   if (att_state->aux_usage != ISL_AUX_USAGE_CCS_E)
+   if (att_state->aux_usage == ISL_AUX_USAGE_NONE)
   return; /* Nothing to resolve */
 
+   assert(att_state->aux_usage == ISL_AUX_USAGE_CCS_E ||
+  att_state->aux_usage == ISL_AUX_USAGE_CCS_D);
+
struct anv_render_pass *pass = cmd_buffer->state.pass;
struct anv_subpass *subpass = cmd_buffer->state.subpass;
unsigned subpass_idx = subpass - pass->subpasses;
@@ -1312,14 +1333,17 @@ ccs_resolve_attachment(struct anv_cmd_buffer 
*cmd_buffer,
 * of a particular attachment.  That way we only resolve once but it's
 * still hot in the cache.
 */
+   bool found_draw = false;
+   enum anv_subpass_usage usage = 0;
for (uint32_t s = subpass_idx + 1; s < pass->subpass_count; s++) {
-  enum anv_subpass_usage usage = pass->attachments[att].subpass_usage[s];
+  usage |= pass->attachments[att].subpass_usage[s];
 
   if (usage & (ANV_SUBPASS_USAGE_DRAW | ANV_SUBPASS_USAGE_RESOLVE_DST)) {
  /* We found another subpass that draws to this attachment.  We'll
   * wait to resolve until then.
   */
- return;
+ found_draw = true;
+ break;
   }
}
 
@@ -1327,12 +1351,60 @@ ccs_resolve_attachment(struct anv_cmd_buffer 
*cmd_buffer,
const struct anv_image *image = iview->image;
assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
 
-   if (image->aux_usage == ISL_AUX_USAGE_CCS_E)
+   enum blorp_fast_clear_op resolve_op = BLORP_FAST_CLEAR_OP_NONE;
+   if (!found_draw) {
+  /* This is the last subpass that writes to this attachment so we need to
+   * resolve here.  Ideally, we would like to only resolve if the storeOp
+   * is set to VK_ATTACHMENT_STORE_OP_STORE.  However, we need to ensure
+   * that the CCS bits are set to "resolved" because there may be copy or
+   * blit operations (which may ignore CCS) between now and the next time
+   * we render and we need to ensure that anything they write will be
+   * respected in the next render.  Unfortunately, the hardware does not
+   * provide us wit

[Mesa-dev] [PATCH 7/7] anv: Enable fast clears on gen7-8

2016-11-19 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_image.c   |  2 +-
 src/intel/vulkan/genX_cmd_buffer.c | 47 --
 2 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 6f19c84..e60373a 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -195,7 +195,7 @@ make_surface(const struct anv_device *dev,
  add_surface(image, &image->aux_surface);
   }
} else if (aspect == VK_IMAGE_ASPECT_COLOR_BIT && vk_info->samples == 1) {
-  if (dev->info.gen >= 9 && !unlikely(INTEL_DEBUG & DEBUG_NO_RBC)) {
+  if (!unlikely(INTEL_DEBUG & DEBUG_NO_RBC)) {
  assert(image->aux_surface.isl.size == 0);
  ok = isl_surf_get_ccs_surf(&dev->isl_dev, &anv_surf->isl,
 &image->aux_surface.isl);
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 38579ce..985bae0 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -242,6 +242,21 @@ color_attachment_compute_aux_usage(struct anv_device 
*device,
   render_area.extent.height != iview->extent.height)
  att_state->fast_clear = false;
 
+  if (GEN_GEN <= 7) {
+ /* On gen7, we can't do multi-LOD or multi-layer fast-clears.  We
+  * technically can, but it comes with crazy restrictions that we
+  * don't want to deal with now.
+  */
+ if (iview->isl.base_level > 0 ||
+ iview->isl.base_array_layer > 0 ||
+ iview->isl.array_len > 1)
+att_state->fast_clear = false;
+  }
+
+  /* On Broadwell and earlier, we can only handle 0/1 clear colors */
+  if (GEN_GEN <= 8 && !att_state->clear_color_is_zero_one)
+ att_state->fast_clear = false;
+
   if (att_state->fast_clear) {
  memcpy(fast_clear_color->u32, att_state->clear_value.color.uint32,
 sizeof(fast_clear_color->u32));
@@ -256,18 +271,26 @@ color_attachment_compute_aux_usage(struct anv_device 
*device,
   att_state->input_aux_usage = ISL_AUX_USAGE_CCS_E;
} else if (att_state->fast_clear) {
   att_state->aux_usage = ISL_AUX_USAGE_CCS_D;
-  /* From the Sky Lake PRM, RENDER_SURFACE_STATE::AuxiliarySurfaceMode:
-   *
-   *"If Number of Multisamples is MULTISAMPLECOUNT_1, AUX_CCS_D
-   *setting is only allowed if Surface Format supported for Fast
-   *Clear. In addition, if the surface is bound to the sampling
-   *engine, Surface Format must be supported for Render Target
-   *Compression for surfaces bound to the sampling engine."
-   *
-   * In other words, we can't sample from a fast-cleared image if it
-   * doesn't also support color compression.
-   */
-  att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
+  if (GEN_GEN >= 9) {
+ /* From the Sky Lake PRM, RENDER_SURFACE_STATE::AuxiliarySurfaceMode:
+  *
+  *"If Number of Multisamples is MULTISAMPLECOUNT_1, AUX_CCS_D
+  *setting is only allowed if Surface Format supported for Fast
+  *Clear. In addition, if the surface is bound to the sampling
+  *engine, Surface Format must be supported for Render Target
+  *Compression for surfaces bound to the sampling engine."
+  *
+  * In other words, we can't sample from a fast-cleared image if it
+  * doesn't also support color compression.
+  */
+ att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
+  } else if (GEN_GEN == 8) {
+ /* Broadwell can sample from fast-cleared images */
+ att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
+  } else {
+ /* Ivy Bridge and Haswell cannot */
+ att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
+  }
} else {
   att_state->aux_usage = ISL_AUX_USAGE_NONE;
   att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
-- 
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 3/3] glsl/lower_output_reads: remove unused mem_ctx

2016-11-19 Thread Marek Olšák
For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Nov 17, 2016 at 11:00 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> ---
>  src/compiler/glsl/lower_output_reads.cpp | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/src/compiler/glsl/lower_output_reads.cpp 
> b/src/compiler/glsl/lower_output_reads.cpp
> index b0045f0..851078b 100644
> --- a/src/compiler/glsl/lower_output_reads.cpp
> +++ b/src/compiler/glsl/lower_output_reads.cpp
> @@ -40,22 +40,20 @@
>  namespace {
>
>  class output_read_remover : public ir_hierarchical_visitor {
>  protected:
> /**
>  * A hash table mapping from the original ir_variable shader outputs
>  * (ir_var_shader_out mode) to the new temporaries to be used instead.
>  */
> hash_table *replacements;
>
> -   void *mem_ctx;
> -
> unsigned stage;
>  public:
> output_read_remover(unsigned stage);
> ~output_read_remover();
> virtual ir_visitor_status visit(class ir_dereference_variable *);
> virtual ir_visitor_status visit_leave(class ir_emit_vertex *);
> virtual ir_visitor_status visit_leave(class ir_return *);
> virtual ir_visitor_status visit_leave(class ir_function_signature *);
>  };
>
> @@ -73,29 +71,27 @@ public:
>  static unsigned
>  hash_table_var_hash(const void *key)
>  {
> const ir_variable * var = static_cast(key);
> return _mesa_key_hash_string(var->name);
>  }
>
>  output_read_remover::output_read_remover(unsigned stage)
>  {
> this->stage = stage;
> -   mem_ctx = ralloc_context(NULL);
> replacements = _mesa_hash_table_create(NULL, hash_table_var_hash,
>_mesa_key_pointer_equal);
>  }
>
>  output_read_remover::~output_read_remover()
>  {
> _mesa_hash_table_destroy(replacements, NULL);
> -   ralloc_free(mem_ctx);
>  }
>
>  ir_visitor_status
>  output_read_remover::visit(ir_dereference_variable *ir)
>  {
> if (ir->var->data.mode != ir_var_shader_out)
>return visit_continue;
>
> hash_entry *entry = _mesa_hash_table_search(replacements, ir->var);
> ir_variable *temp = entry ? (ir_variable *) entry->data : NULL;
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4] clover: restore support for LLVM <= 3.9

2016-11-19 Thread Francisco Jerez
Vedran Miletić  writes:

> The commit 8e430ff8b060b4e8e922bae24b3c57837da6ea77 support for LLVM
> 3.9 and older versionsin  Clover. This patch restores it and refactors
> the support using Clover compatibility layer for LLVM.
>
> Signed-off-by: Vedran Miletić 
> ---
>  .../state_trackers/clover/llvm/codegen/bitcode.cpp |  9 ++
>  src/gallium/state_trackers/clover/llvm/compat.hpp  | 35 
> ++
>  2 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp 
> b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> index 5dcc4f8..4b4ae41 100644
> --- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
> @@ -32,6 +32,7 @@
>  ///
>  
>  #include "llvm/codegen.hpp"
> +#include "llvm/compat.hpp"
>  #include "llvm/metadata.hpp"
>  #include "core/error.hpp"
>  #include "util/algorithm.hpp"
> @@ -99,13 +100,7 @@ clover::llvm::parse_module_library(const module &m, 
> ::llvm::LLVMContext &ctx,
> auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
>  as_string(m.secs[0].data), " "), 
> ctx);
>  
> -   if (::llvm::Error err = mod.takeError()) {
> -  std::string msg;
> -  ::llvm::handleAllErrors(std::move(err), [&](::llvm::ErrorInfoBase 
> &EIB) {
> - msg = EIB.message();
> - fail(r_log, error(CL_INVALID_PROGRAM), msg.c_str());
> -  });
> -   }
> +   compat::handle_module_error(mod, r_log);
>  
> return std::unique_ptr<::llvm::Module>(std::move(*mod));
>  }
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index a963cff..b29100f 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -39,6 +39,11 @@
>  #include 
>  #include 
>  #include 
> +#if HAVE_LLVM >= 0x0400
> +#include 
> +#else
> +#include 
> +#endif
>  
>  #if HAVE_LLVM >= 0x0307
>  #include 
> @@ -53,6 +58,14 @@
>  #include 
>  #include 
>  
> +#if HAVE_LLVM >= 0x0307
> +#include 
> +#endif
> +
> +namespace llvm {
> +   class Module;
> +}
> +
>  namespace clover {
> namespace llvm {
>namespace compat {
> @@ -158,6 +171,28 @@ namespace clover {
>  #else
>   const auto default_reloc_model = ::llvm::Reloc::Default;
>  #endif
> +
> +#if HAVE_LLVM >= 0x0400
> + typedef ::llvm::Expected> 
> bitcode_module;
> +#elif HAVE_LLVM >= 0x0307
> + typedef ::llvm::ErrorOr> 
> bitcode_module;
> +#else
> + typedef ::llvm::ErrorOr<::llvm::Module *> bitcode_module;
> +#endif
> +

You could avoid the preprocessor conditionals above (and also the
previous hunk) by making the function below a template parameterized on
the module type and let the compiler deduce the correct type by itself
(see attachment).

> + inline void
> + handle_module_error(bitcode_module &mod, std::string &r_log) {
> +#if HAVE_LLVM >= 0x0400
> +if (::llvm::Error err = mod.takeError()) {
> +   ::llvm::handleAllErrors(std::move(err), 
> [&](::llvm::ErrorInfoBase &EIB) {
> +  fail(r_log, error(CL_INVALID_PROGRAM), 
> EIB.message().c_str());
> +   });
> +}
> +#else
> +if (!mod)
> +   fail(r_log, error(CL_INVALID_PROGRAM), 
> mod.getError().message());
> +#endif

To improve the usefulness/complexity ratio of this helper, let's not
hard-code any error handling policy here, instead just call an error
handler function provided as argument (see attachment) so the specific
error code and message are in control of the caller.  With the attached
patch squashed in, patch is:

Reviewed-by: Francisco Jerez 

> + }
>}
> }
>  }
> -- 
> 2.7.4

diff --git a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
index 4b4ae41..d09207b 100644
--- a/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
+++ b/src/gallium/state_trackers/clover/llvm/codegen/bitcode.cpp
@@ -100,7 +100,9 @@ clover::llvm::parse_module_library(const module &m, ::llvm::LLVMContext &ctx,
auto mod = ::llvm::parseBitcodeFile(::llvm::MemoryBufferRef(
 as_string(m.secs[0].data), " "), ctx);
 
-   compat::handle_module_error(mod, r_log);
+   compat::handle_module_error(mod, [&](const std::string &s) {
+ fail(r_log, error(CL_INVALID_PROGRAM), s);
+  });
 
return std::unique_ptr<::llvm::Module>(std::move(*mod));
 }
diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp b/src/gallium/state_trackers/clover/llvm/compat.hpp
index b29100f..81592ce 100644
--- a/src/gallium/state_trackers/clover/llvm/compat.hpp
+++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
@@ -58,14 +58,6 @@
 #include 
 #include 
 
-#if HAVE_LLVM >= 0x0307
-#include 
-#endif
-
-namespace llvm {
-   clas

Re: [Mesa-dev] [PATCH v5 09/11] swr: Modify gen_knobs.{cpp|h} creation script

2016-11-19 Thread Emil Velikov
Hi George,

Thanks for sorting things.. There's a pretty trivial nitpick below,
but please don't bother addressing it.
Things are pretty good as-is - check with Tim/others and land the series.

On 18 November 2016 at 20:38, George Kyriazis  wrote:
> Modify gen_knobs.py so that each invocation creates a single generated
> file.  This is more similar to how the other generators behave.
>
> v5: remove Scoscript edits from this commit; moved to commit that first
> adds SConscript
>
> Acked-by: Emil Velikov 
> ---
>  src/gallium/drivers/swr/Makefile.am| 15 ++-
>  .../drivers/swr/rasterizer/scripts/gen_knobs.py| 51 
> --

> @@ -235,6 +245,7 @@ libswrAVX2_la_LDFLAGS = \
>  include $(top_srcdir)/install-gallium-links.mk
>
>  EXTRA_DIST = \
> +   SConscript \

IIRC I've mentioned it a couple of times - this should be part of the
commit that introduces the file.

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


Re: [Mesa-dev] [PATCH] clover: Implement clSetCommandQueueProperty() from OpenCL 1.0

2016-11-19 Thread Francisco Jerez
Edward O'Callaghan  writes:

> Signed-off-by: Edward O'Callaghan 
> ---
>  include/CL/cl.h|  6 
>  src/gallium/state_trackers/clover/api/dispatch.cpp |  2 +-
>  src/gallium/state_trackers/clover/api/queue.cpp| 34 
> ++
>  src/gallium/state_trackers/clover/core/queue.cpp   |  3 ++
>  src/gallium/state_trackers/clover/core/queue.hpp   |  1 +
>  5 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/include/CL/cl.h b/include/CL/cl.h
> index 316565d..51adf65 100644
> --- a/include/CL/cl.h
> +++ b/include/CL/cl.h
> @@ -656,6 +656,12 @@ clGetCommandQueueInfo(cl_command_queue  /* 
> command_queue */,
>void */* param_value */,
>size_t *  /* param_value_size_ret */) 
> CL_API_SUFFIX__VERSION_1_0;
>  
> +extern CL_API_ENTRY cl_int CL_API_CALL
> +clSetCommandQueueProperty(cl_command_queue/* command_queue */,
> +  cl_command_queue_properties /* properties */,
> +  cl_bool /* param_value */,
> +  cl_command_queue_properties /* properties */) 
> CL_API_SUFFIX__VERSION_1_0;
> +

I guess this change is likely to get lost when we import future API
headers from Khronos, because the function has been removed from the API
headers by them.  If we do include a declaration of this entry point in
the headers it should probably be marked with both:

  CL_EXT_PREFIX__VERSION_1_0_DEPRECATED 
  CL_EXT_SUFFIX__VERSION_1_0_DEPRECATED

so users get a deprecation warning if they use it by mistake.

Also, the declaration doesn't seem to match the CL 1.0 spec, the fourth
argument is supposed to be a pointer type as in your definition below.

>  /* Memory Object APIs */
>  extern CL_API_ENTRY cl_mem CL_API_CALL
>  clCreateBuffer(cl_context   /* context */,
> diff --git a/src/gallium/state_trackers/clover/api/dispatch.cpp 
> b/src/gallium/state_trackers/clover/api/dispatch.cpp
> index 8f4cfdc..0f64914 100644
> --- a/src/gallium/state_trackers/clover/api/dispatch.cpp
> +++ b/src/gallium/state_trackers/clover/api/dispatch.cpp
> @@ -37,7 +37,7 @@ namespace clover {
>clRetainCommandQueue,
>clReleaseCommandQueue,
>clGetCommandQueueInfo,
> -  NULL, // clSetCommandQueueProperty
> +  clSetCommandQueueProperty,
>clCreateBuffer,
>clCreateImage2D,
>clCreateImage3D,
> diff --git a/src/gallium/state_trackers/clover/api/queue.cpp 
> b/src/gallium/state_trackers/clover/api/queue.cpp
> index 06a2863..7734e19 100644
> --- a/src/gallium/state_trackers/clover/api/queue.cpp
> +++ b/src/gallium/state_trackers/clover/api/queue.cpp
> @@ -105,6 +105,40 @@ clGetCommandQueueInfo(cl_command_queue d_q, 
> cl_command_queue_info param,
>  }
>  
>  CLOVER_API cl_int
> +clSetCommandQueueProperty(cl_command_queue d_q,
> + cl_command_queue_properties props, cl_bool enabled,

Align this and the next line to the first function argument.  The CL
spec refers to the third argument of this entry point as 'enable', which
makes more sense to me than 'enabled'.

> + cl_command_queue_properties *old_props) try {
> +   //throws CL_INVALID_COMMAND_QUEUE if command_queue is not a valid.
> +   auto &q = obj(d_q);
> +
> +   if (props & ~(CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE |
> + CL_QUEUE_PROFILING_ENABLE))
> +  throw error(CL_INVALID_VALUE);
> +
> +   if (!old_props) // If old_properties is NULL, it is ignored.

Inverted condition as you pointed out already.

> +*old_props = q.propertices();
> +

Typo in the previous line and below, did you compile-test this at all? ;)

> +   if (enabled == CL_TRUE) {
> +  if (q.propertices() & props)
> + return CL_SUCCESS;
> +   } else { // CL_FALSE
> +  if (q.propertices() & ~props)
> + return CL_SUCCESS;
> +   }
> +

I don't think this does what 'enable' is supposed to do.  IIUC it
controls whether the specified properties are added or subtracted from
the current set of enabled properties, e.g.:

| q.properties(enable ? q.properties() | props :
|   q.properties() & ~props);

> +   // TODO how to determine if device supports props???

All devices should be able to support both properties.  I'd drop this
comment and the conditional below.

> +   if (1)
> +  q.propertices(props);
> +   else
> +  throw error(CL_INVALID_QUEUE_PROPERTIES);
> +
> +   return CL_SUCCESS;
> +
> +} catch (error &e) {
> +   return e.get();
> +}
> +
> +CLOVER_API cl_int
>  clFlush(cl_command_queue d_q) try {
> obj(d_q).flush();
> return CL_SUCCESS;
> diff --git a/src/gallium/state_trackers/clover/core/queue.cpp 
> b/src/gallium/state_trackers/clover/core/queue.cpp
> index c91b97a..24b15f3 100644
> --- a/src/gallium/state_trackers/clover/core/queue.cpp
> +++ b/src/gallium/state_trackers/clover/core/queue.cpp
> @@ -87,6 +87,9 @@ command_queue::pro

[Mesa-dev] [Bug 98789] ./rasterizer/core/clip.h(429): ASSERT: numEmittedVerts <= 7

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98789

Bug ID: 98789
   Summary: ./rasterizer/core/clip.h(429): ASSERT: numEmittedVerts
<= 7
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: imir...@alum.mit.edu
QA Contact: mesa-dev@lists.freedesktop.org

Looks like some stack stomping is preventing a full backtrace in gdb:

deqp/modules/gles2 $ KNOB_SINGLE_THREADED=1 DISPLAY=:0 GALLIUM_DRIVER=swr
LIBGL_ALWAYS_SOFTWARE=1 LD_LIBRARY_PATH=/home/ilia/install/lib gdb --args
./deqp-gles2 --deqp-visibility=hidden
--deqp-case=dEQP-GLES2.functional.shaders.invariance.highp.loop_2
GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./deqp-gles2...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/ilia/src/deqp/modules/gles2/deqp-gles2
--deqp-visibility=hidden
--deqp-case=dEQP-GLES2.functional.shaders.invariance.highp.loop_2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
dEQP Core git-aa4099c48f58c93d951b64451ef87adb31fce406 (0xaa4099c4) starting..
  target implementation = 'X11 GLX'
SWR detected AVX2

Test case 'dEQP-GLES2.functional.shaders.invariance.highp.loop_2'..
Vertex shader compile time = 4.425000 ms
Fragment shader compile time = 0.368000 ms
Link time = 0.982000 ms
Vertex shader compile time = 0.653000 ms
Fragment shader compile time = 0.354000 ms
Link time = 0.886000 ms
vert shader  0x77fcf000
frag shader  0x77fcd000
vert shader  0x77fcb000
frag shader  0x77fc9000
fetch shader 0x77fc7000
vert shader  0x77fc5000
frag shader  0x77fc3000
./rasterizer/core/clip.h(429): ASSERT: numEmittedVerts <= 7
ClipSimd
Unexpected vertex count from clipper.

Program received signal SIGTRAP, Trace/breakpoint trap.
Clipper<3u>::ClipSimd(float __vector const&, float __vector const&, PA_STATE&,
long long __vector const&, long long __vector const&) (this=0x7ffcfce0, 
vPrimMask=..., vClipMask=..., pa=..., vPrimId=..., vViewportIdx=...)
at ./rasterizer/core/clip.h:431
431 uint32_t numEmittedPrims = GetNumPrims(clipTopology,
numEmittedVerts);
(gdb) bt
#0  Clipper<3u>::ClipSimd(float __vector const&, float __vector const&,
PA_STATE&, long long __vector const&, long long __vector const&)
(this=0x7ffcfce0, 
vPrimMask=..., vClipMask=..., pa=..., vPrimId=..., vViewportIdx=...)
at ./rasterizer/core/clip.h:431
Backtrace stopped: Cannot access memory at address 0x7fffbf20cb0f

OTOH with valgrind I get this on exit:

./rasterizer/core/clip.h(429): ASSERT: numEmittedVerts <= 7
ClipSimd
Unexpected vertex count from clipper.
==9673== 
==9673== Process terminating with default action of signal 5 (SIGTRAP)
==9673==at 0x10243787: Clipper<3u>::ClipSimd(float __vector(8) const&,
float __vector(8) const&, PA_STATE&, long long __vector(4) const&, long long
__vector(4) const&) (clip.h:431)
==9673==by 0x1024101F: Clipper<3u>::ExecuteStage(PA_STATE&, simdvector*,
unsigned int, long long __vector(4), long long __vector(4)) (clip.h:558)
==9673==by 0x1023F6A0: ClipTriangles(DRAW_CONTEXT*, PA_STATE&, unsigned
int, simdvector*, unsigned int, long long __vector(4), long long __vector(4))
(clip.cpp:187)
==9673==by 0x10288CF7: void ProcessDraw, std::integral_constant, std::integral_constant, std::integral_constant, std::integral_constant, std::integral_constant >(SWR_CONTEXT*, DRAW_CONTEXT*,
unsigned int, void*) (frontend.cpp:1370)
==9673==by 0x106C6CB7: WorkOnFifoFE(SWR_CONTEXT*, unsigned int, unsigned
int&) (threads.cpp:645)
==9673==by 0xFF2E3B9: void QueueWork(SWR_CONTEXT*) (api.cpp:214)
==9673==by 0xFF2D82C: QueueDraw(SWR_CONTEXT*) (api.cpp:243)
==9673==by 0xFF2C28E: DrawInstanced(void*, PRIMITIVE_TOPOLOGY, unsigned
int, unsigned int, unsigned int, unsigned int) (api.cpp:1140)
==9673==by 0xFF2C355: SwrDrawInstanced(void*, PRIMITIVE_TOPOLOGY, unsigned
int, unsigned int, unsigned int, unsigned int) (api.cpp:1186)
==9673==by 0xFF0B181: swr_draw_vbo(pipe_context*, pipe_draw_info const*)
(swr_dra

[Mesa-dev] [PATCH] i965: remove dead code path in brw_tcs_precompile()

2016-11-19 Thread Timothy Arceri
The glsl linker will have already failed if we tried linking a tcs
without a tes.
---
 src/mesa/drivers/dri/i965/brw_tcs.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c 
b/src/mesa/drivers/dri/i965/brw_tcs.c
index ec3f3cb..7e1a65f 100644
--- a/src/mesa/drivers/dri/i965/brw_tcs.c
+++ b/src/mesa/drivers/dri/i965/brw_tcs.c
@@ -398,6 +398,7 @@ brw_tcs_precompile(struct gl_context *ctx,
struct brw_program *btcp = brw_program(prog);
const struct gl_linked_shader *tes =
   shader_prog->_LinkedShaders[MESA_SHADER_TESS_EVAL];
+   assert(tes);
 
memset(&key, 0, sizeof(key));
 
@@ -410,14 +411,10 @@ brw_tcs_precompile(struct gl_context *ctx,
  _LinkedShaders[MESA_SHADER_TESS_CTRL]->info.TessCtrl.VerticesOut;
}
 
-   if (tes) {
-  key.tes_primitive_mode = tes->info.TessEval.PrimitiveMode;
-  key.quads_workaround = brw->gen < 9 &&
- tes->info.TessEval.PrimitiveMode == GL_QUADS &&
- tes->info.TessEval.Spacing == GL_EQUAL;
-   } else {
-  key.tes_primitive_mode = GL_TRIANGLES;
-   }
+   key.tes_primitive_mode = tes->info.TessEval.PrimitiveMode;
+   key.quads_workaround = brw->gen < 9 &&
+  tes->info.TessEval.PrimitiveMode == GL_QUADS &&
+  tes->info.TessEval.Spacing == GL_EQUAL;
 
key.outputs_written = prog->nir->info->outputs_written;
key.patch_outputs_written = prog->nir->info->patch_outputs_written;
-- 
2.7.4

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


[Mesa-dev] [PATCH] anv: Implement a depth stall restriction on gen7

2016-11-19 Thread Jason Ekstrand
Fixes 61 Vulkan CTS tests on Haswell

Cc: "13.0" 
---
 src/intel/vulkan/anv_genX.h|  2 ++
 src/intel/vulkan/genX_blorp_exec.c |  2 ++
 src/intel/vulkan/genX_cmd_buffer.c | 31 +++
 3 files changed, 35 insertions(+)

diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
index 7937170..296b1ae 100644
--- a/src/intel/vulkan/anv_genX.h
+++ b/src/intel/vulkan/anv_genX.h
@@ -42,6 +42,8 @@ void genX(cmd_buffer_emit_state_base_address)(struct 
anv_cmd_buffer *cmd_buffer)
 
 void genX(cmd_buffer_apply_pipe_flushes)(struct anv_cmd_buffer *cmd_buffer);
 
+void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer *cmd_buffer);
+
 void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
 void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer *cmd_buffer);
 
diff --git a/src/intel/vulkan/genX_blorp_exec.c 
b/src/intel/vulkan/genX_blorp_exec.c
index a705de0..721b6e5 100644
--- a/src/intel/vulkan/genX_blorp_exec.c
+++ b/src/intel/vulkan/genX_blorp_exec.c
@@ -150,6 +150,8 @@ genX(blorp_exec)(struct blorp_batch *batch,
 
genX(flush_pipeline_select_3d)(cmd_buffer);
 
+   genX(cmd_buffer_emit_gen7_depth_flush)(cmd_buffer);
+
blorp_exec(batch, params);
 
cmd_buffer->state.vb_dirty = ~0;
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 985bae0..b873a69 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -1978,6 +1978,35 @@ genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer 
*cmd_buffer)
}
 }
 
+void
+genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer *cmd_buffer)
+{
+   if (GEN_GEN > 7)
+  return;
+
+   /* From the Haswell PRM, documentation for 3DSTATE_DEPTH_BUFFER:
+*
+*"Restriction: Prior to changing Depth/Stencil Buffer state (i.e., any
+*combination of 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS,
+*3DSTATE_STENCIL_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER) SW must first
+*issue a pipelined depth stall (PIPE_CONTROL with Depth Stall bit
+*set), followed by a pipelined depth cache flush (PIPE_CONTROL with
+*Depth Flush Bit set, followed by another pipelined depth stall
+*(PIPE_CONTROL with Depth Stall Bit set), unless SW can otherwise
+*guarantee that the pipeline from WM onwards is already flushed (e.g.,
+*via a preceding MI_FLUSH)."
+*/
+   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
+  pipe.DepthStallEnable = true;
+   }
+   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
+  pipe.DepthCacheFlushEnable = true;
+   }
+   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
+  pipe.DepthStallEnable = true;
+   }
+}
+
 static void
 cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer *cmd_buffer)
 {
@@ -1994,6 +2023,8 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer 
*cmd_buffer)
/* FIXME: Implement the PMA stall W/A */
/* FIXME: Width and Height are wrong */
 
+   genX(cmd_buffer_emit_gen7_depth_flush)(cmd_buffer);
+
/* Emit 3DSTATE_DEPTH_BUFFER */
if (has_depth) {
   anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_DEPTH_BUFFER), db) {
-- 
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] i965: remove dead code path in brw_tcs_precompile()

2016-11-19 Thread Timothy Arceri
On Sun, 2016-11-20 at 09:40 +1100, Timothy Arceri wrote:
> The glsl linker will have already failed if we tried linking a tcs
> without a tes.

Actually this used by SSO. Please ignore.

> ---
>  src/mesa/drivers/dri/i965/brw_tcs.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
> b/src/mesa/drivers/dri/i965/brw_tcs.c
> index ec3f3cb..7e1a65f 100644
> --- a/src/mesa/drivers/dri/i965/brw_tcs.c
> +++ b/src/mesa/drivers/dri/i965/brw_tcs.c
> @@ -398,6 +398,7 @@ brw_tcs_precompile(struct gl_context *ctx,
> struct brw_program *btcp = brw_program(prog);
> const struct gl_linked_shader *tes =
>    shader_prog->_LinkedShaders[MESA_SHADER_TESS_EVAL];
> +   assert(tes);
>  
> memset(&key, 0, sizeof(key));
>  
> @@ -410,14 +411,10 @@ brw_tcs_precompile(struct gl_context *ctx,
>   _LinkedShaders[MESA_SHADER_TESS_CTRL]-
> >info.TessCtrl.VerticesOut;
> }
>  
> -   if (tes) {
> -  key.tes_primitive_mode = tes->info.TessEval.PrimitiveMode;
> -  key.quads_workaround = brw->gen < 9 &&
> - tes->info.TessEval.PrimitiveMode ==
> GL_QUADS &&
> - tes->info.TessEval.Spacing == GL_EQUAL;
> -   } else {
> -  key.tes_primitive_mode = GL_TRIANGLES;
> -   }
> +   key.tes_primitive_mode = tes->info.TessEval.PrimitiveMode;
> +   key.quads_workaround = brw->gen < 9 &&
> +  tes->info.TessEval.PrimitiveMode ==
> GL_QUADS &&
> +  tes->info.TessEval.Spacing == GL_EQUAL;
>  
> key.outputs_written = prog->nir->info->outputs_written;
> key.patch_outputs_written = prog->nir->info-
> >patch_outputs_written;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 98790] clipping failures exposed by dEQP

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98790

Bug ID: 98790
   Summary: clipping failures exposed by dEQP
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: imir...@alum.mit.edu
QA Contact: mesa-dev@lists.freedesktop.org

dEQP-GLES2.functional.clipping.polygon_edge.quad_at_origin_4,Fail
dEQP-GLES2.functional.clipping.polygon_edge.quad_near_edge_2,Fail
dEQP-GLES2.functional.clipping.triangle_vertex.clip_two.clip_pos_y_pos_z_and_neg_x_neg_y_neg_z,Fail

Feel free to split this bug up into more if it's a bunch of separate issues.

You can run these with

./deqp-gles2 --deqp-visibility=hidden --deqp-case=...

In all cases the results are close, just not 100% right. Usually an edge or
part of an edge off.

-- 
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 98791] alpha back-and-forth between hot tiles picks up corruption

2016-11-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98791

Bug ID: 98791
   Summary: alpha back-and-forth between hot tiles picks up
corruption
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/swr
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: imir...@alum.mit.edu
QA Contact: mesa-dev@lists.freedesktop.org

dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_alpha

The test sticks some data in via glTexImage2D (into each level), then renders a
gradient to a FB, and then runs glCopyTexSubImage to overwrite part of each
level's data with the new data. It appears that the first 32 pixels of level0
are good, but the next 32, which have the partial copy over them, were
improperly initialized. Like a load was missing?

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


[Mesa-dev] [PATCH 2/6] mesa: remove unneeded #includes in errors.c

2016-11-19 Thread Brian Paul
---
 src/mesa/main/errors.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 654343d..3a40c74 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -35,12 +35,6 @@
 #include "imports.h"
 #include "context.h"
 #include "debug_output.h"
-#include "dispatch.h"
-#include "hash.h"
-#include "mtypes.h"
-#include "version.h"
-#include "util/hash_table.h"
-#include "util/simple_list.h"
 
 
 static FILE *LogFile = NULL;
-- 
1.9.1

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


[Mesa-dev] [PATCH 4/6] r200: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Brian Paul
And include "util/simple_list.h" where it is needed in r200_state.c
Compile tested only.
---
 src/mesa/drivers/dri/r200/r200_context.c | 1 -
 src/mesa/drivers/dri/r200/r200_ioctl.h   | 2 --
 src/mesa/drivers/dri/r200/r200_state.c   | 1 +
 src/mesa/drivers/dri/r200/r200_swtcl.c   | 1 -
 src/mesa/drivers/dri/r200/r200_tex.c | 1 -
 5 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/r200/r200_context.c 
b/src/mesa/drivers/dri/r200/r200_context.c
index 2a42ab3..8f354c1 100644
--- a/src/mesa/drivers/dri/r200/r200_context.c
+++ b/src/mesa/drivers/dri/r200/r200_context.c
@@ -37,7 +37,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #include "main/api_arrayelt.h"
 #include "main/api_exec.h"
 #include "main/context.h"
-#include "util/simple_list.h"
 #include "main/imports.h"
 #include "main/extensions.h"
 #include "main/version.h"
diff --git a/src/mesa/drivers/dri/r200/r200_ioctl.h 
b/src/mesa/drivers/dri/r200/r200_ioctl.h
index 25a9dd3..42feec7 100644
--- a/src/mesa/drivers/dri/r200/r200_ioctl.h
+++ b/src/mesa/drivers/dri/r200/r200_ioctl.h
@@ -35,8 +35,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #ifndef __R200_IOCTL_H__
 #define __R200_IOCTL_H__
 
-#include "util/simple_list.h"
-
 #include "radeon_bo_gem.h"
 #include "radeon_cs_gem.h"
 
diff --git a/src/mesa/drivers/dri/r200/r200_state.c 
b/src/mesa/drivers/dri/r200/r200_state.c
index 3671231..4a248d2 100644
--- a/src/mesa/drivers/dri/r200/r200_state.c
+++ b/src/mesa/drivers/dri/r200/r200_state.c
@@ -61,6 +61,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #include "r200_swtcl.h"
 #include "r200_vertprog.h"
 
+#include "util/simple_list.h"
 
 /* =
  * Alpha blending
diff --git a/src/mesa/drivers/dri/r200/r200_swtcl.c 
b/src/mesa/drivers/dri/r200/r200_swtcl.c
index 72f09ae..6ca85f5 100644
--- a/src/mesa/drivers/dri/r200/r200_swtcl.c
+++ b/src/mesa/drivers/dri/r200/r200_swtcl.c
@@ -38,7 +38,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #include "main/image.h"
 #include "main/imports.h"
 #include "main/macros.h"
-#include "util/simple_list.h"
 
 #include "swrast/s_context.h"
 #include "swrast/s_fog.h"
diff --git a/src/mesa/drivers/dri/r200/r200_tex.c 
b/src/mesa/drivers/dri/r200/r200_tex.c
index 2a95f2d..0ddb686 100644
--- a/src/mesa/drivers/dri/r200/r200_tex.c
+++ b/src/mesa/drivers/dri/r200/r200_tex.c
@@ -36,7 +36,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #include "main/context.h"
 #include "main/enums.h"
 #include "main/image.h"
-#include "util/simple_list.h"
 #include "main/teximage.h"
 #include "main/texobj.h"
 #include "main/samplerobj.h"
-- 
1.9.1

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


[Mesa-dev] [PATCH 1/6] mesa: remove trailing whitespace in errors.c

2016-11-19 Thread Brian Paul
---
 src/mesa/main/errors.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 9932b4a..654343d 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -122,7 +122,7 @@ flush_delayed_errors( struct gl_context *ctx )
char s[MAX_DEBUG_MESSAGE_LENGTH];
 
if (ctx->ErrorDebugCount) {
-  _mesa_snprintf(s, MAX_DEBUG_MESSAGE_LENGTH, "%d similar %s errors", 
+  _mesa_snprintf(s, MAX_DEBUG_MESSAGE_LENGTH, "%d similar %s errors",
  ctx->ErrorDebugCount,
  _mesa_enum_to_string(ctx->ErrorValue));
 
@@ -145,10 +145,10 @@ _mesa_warning( struct gl_context *ctx, const char 
*fmtString, ... )
 {
char str[MAX_DEBUG_MESSAGE_LENGTH];
va_list args;
-   va_start( args, fmtString );  
+   va_start( args, fmtString );
(void) _mesa_vsnprintf( str, MAX_DEBUG_MESSAGE_LENGTH, fmtString, args );
va_end( args );
-   
+
if (ctx)
   flush_delayed_errors( ctx );
 
@@ -175,7 +175,7 @@ _mesa_problem( const struct gl_context *ctx, const char 
*fmtString, ... )
if (numCalls < 50) {
   numCalls++;
 
-  va_start( args, fmtString );  
+  va_start( args, fmtString );
   _mesa_vsnprintf( str, MAX_DEBUG_MESSAGE_LENGTH, fmtString, args );
   va_end( args );
   fprintf(stderr, "Mesa %s implementation error: %s\n",
@@ -264,7 +264,7 @@ _mesa_gl_debug(struct gl_context *ctx,
  * If debugging is enabled (either at compile-time via the DEBUG macro, or
  * run-time via the MESA_DEBUG environment variable), report the error with
  * _mesa_debug().
- * 
+ *
  * \param ctx the GL context.
  * \param error the error value.
  * \param fmtString printf() style format string, followed by optional args
@@ -346,7 +346,7 @@ _mesa_error_no_memory(const char *caller)
 /**
  * Report debug information.  Print error message to stderr via fprintf().
  * No-op if DEBUG mode not enabled.
- * 
+ *
  * \param ctx GL context.
  * \param fmtString printf()-style format string, followed by optional args.
  */
-- 
1.9.1

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


[Mesa-dev] [PATCH 3/6] i915: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Brian Paul
Compile tested only.
---
 src/mesa/drivers/dri/i915/i830_texblend.c | 1 -
 src/mesa/drivers/dri/i915/intel_syncobj.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i830_texblend.c 
b/src/mesa/drivers/dri/i915/i830_texblend.c
index 661e424..c29b572 100644
--- a/src/mesa/drivers/dri/i915/i830_texblend.c
+++ b/src/mesa/drivers/dri/i915/i830_texblend.c
@@ -28,7 +28,6 @@
 #include "main/glheader.h"
 #include "main/macros.h"
 #include "main/mtypes.h"
-#include "util/simple_list.h"
 #include "main/enums.h"
 #include "main/mm.h"
 
diff --git a/src/mesa/drivers/dri/i915/intel_syncobj.c 
b/src/mesa/drivers/dri/i915/intel_syncobj.c
index d0a99aa..0766a16 100644
--- a/src/mesa/drivers/dri/i915/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i915/intel_syncobj.c
@@ -38,7 +38,6 @@
  * performance bottleneck, though.
  */
 
-#include "util/simple_list.h"
 #include "main/imports.h"
 
 #include "intel_context.h"
-- 
1.9.1

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


[Mesa-dev] [PATCH 6/6] tnl: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Brian Paul
---
 src/mesa/tnl/t_vertex_generic.c | 1 -
 src/mesa/tnl/t_vertex_sse.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/src/mesa/tnl/t_vertex_generic.c b/src/mesa/tnl/t_vertex_generic.c
index 6c40c86..7f871a4 100644
--- a/src/mesa/tnl/t_vertex_generic.c
+++ b/src/mesa/tnl/t_vertex_generic.c
@@ -29,7 +29,6 @@
 #include "main/glheader.h"
 #include "main/context.h"
 #include "main/macros.h"
-#include "util/simple_list.h"
 #include "swrast/s_chan.h"
 #include "t_context.h"
 #include "t_vertex.h"
diff --git a/src/mesa/tnl/t_vertex_sse.c b/src/mesa/tnl/t_vertex_sse.c
index 14e7812..191a68d 100644
--- a/src/mesa/tnl/t_vertex_sse.c
+++ b/src/mesa/tnl/t_vertex_sse.c
@@ -29,7 +29,6 @@
 
 #include "main/glheader.h"
 #include "main/context.h"
-#include "util/simple_list.h"
 #include "main/enums.h"
 #include "swrast/s_chan.h"
 #include "t_context.h"
-- 
1.9.1

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


[Mesa-dev] [PATCH 5/6] radeon: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Brian Paul
Compile tested only.
---
 src/mesa/drivers/dri/radeon/radeon_ioctl.h   | 1 -
 src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c | 1 -
 src/mesa/drivers/dri/radeon/radeon_queryobj.c| 1 -
 src/mesa/drivers/dri/radeon/radeon_swtcl.c   | 1 -
 src/mesa/drivers/dri/radeon/radeon_tex.c | 1 -
 5 files changed, 5 deletions(-)

diff --git a/src/mesa/drivers/dri/radeon/radeon_ioctl.h 
b/src/mesa/drivers/dri/radeon/radeon_ioctl.h
index 2fe0e57..701dcdd 100644
--- a/src/mesa/drivers/dri/radeon/radeon_ioctl.h
+++ b/src/mesa/drivers/dri/radeon/radeon_ioctl.h
@@ -36,7 +36,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #ifndef __RADEON_IOCTL_H__
 #define __RADEON_IOCTL_H__
 
-#include "util/simple_list.h"
 #include "radeon_bo_gem.h"
 #include "radeon_cs_gem.h"
 
diff --git a/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c 
b/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c
index c71766d..19e6296 100644
--- a/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c
+++ b/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 
-#include "util/simple_list.h"
 #include "main/teximage.h"
 #include "main/texobj.h"
 #include "main/enums.h"
diff --git a/src/mesa/drivers/dri/radeon/radeon_queryobj.c 
b/src/mesa/drivers/dri/radeon/radeon_queryobj.c
index c5fbc60..cd0075a 100644
--- a/src/mesa/drivers/dri/radeon/radeon_queryobj.c
+++ b/src/mesa/drivers/dri/radeon/radeon_queryobj.c
@@ -29,7 +29,6 @@
 #include "radeon_debug.h"
 
 #include "main/imports.h"
-#include "util/simple_list.h"
 
 #include 
 
diff --git a/src/mesa/drivers/dri/radeon/radeon_swtcl.c 
b/src/mesa/drivers/dri/radeon/radeon_swtcl.c
index adc1468..f2bc462 100644
--- a/src/mesa/drivers/dri/radeon/radeon_swtcl.c
+++ b/src/mesa/drivers/dri/radeon/radeon_swtcl.c
@@ -37,7 +37,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #include "main/enums.h"
 #include "main/imports.h"
 #include "main/macros.h"
-#include "util/simple_list.h"
 
 #include "math/m_xform.h"
 
diff --git a/src/mesa/drivers/dri/radeon/radeon_tex.c 
b/src/mesa/drivers/dri/radeon/radeon_tex.c
index 083a5e1..c3b83fa 100644
--- a/src/mesa/drivers/dri/radeon/radeon_tex.c
+++ b/src/mesa/drivers/dri/radeon/radeon_tex.c
@@ -36,7 +36,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #include "main/context.h"
 #include "main/enums.h"
 #include "main/image.h"
-#include "util/simple_list.h"
 #include "main/teximage.h"
 #include "main/texobj.h"
 
-- 
1.9.1

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


[Mesa-dev] [PATCH] gallium: create a debug screen wrapper around swrast screens

2016-11-19 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/gallium/auxiliary/target-helpers/inline_sw_helper.h | 3 +++
 src/gallium/auxiliary/target-helpers/sw_helper.h| 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/gallium/auxiliary/target-helpers/inline_sw_helper.h 
b/src/gallium/auxiliary/target-helpers/inline_sw_helper.h
index 5bb77a5..3d9d824 100644
--- a/src/gallium/auxiliary/target-helpers/inline_sw_helper.h
+++ b/src/gallium/auxiliary/target-helpers/inline_sw_helper.h
@@ -55,6 +55,9 @@ sw_screen_create_named(struct sw_winsys *winsys, const char 
*driver)
   screen = swr_create_screen(winsys);
 #endif
 
+   if (screen)
+  screen = debug_screen_wrap(screen);
+
return screen;
 }
 
diff --git a/src/gallium/auxiliary/target-helpers/sw_helper.h 
b/src/gallium/auxiliary/target-helpers/sw_helper.h
index 5e4e9f7..d1945ad 100644
--- a/src/gallium/auxiliary/target-helpers/sw_helper.h
+++ b/src/gallium/auxiliary/target-helpers/sw_helper.h
@@ -57,6 +57,9 @@ sw_screen_create_named(struct sw_winsys *winsys, const char 
*driver)
   screen = swr_create_screen(winsys);
 #endif
 
+   if (screen)
+  screen = debug_screen_wrap(screen);
+
return screen;
 }
 
-- 
2.7.3

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


[Mesa-dev] list.h vs. simple_list.h

2016-11-19 Thread Brian Paul

It seems a bit silly to have two linked list utilities.

git-grep indicates that list.h is used more than simple_list.h so maybe 
we can switch uses of the later to the former.  In fact, I've already 
found a few files that include simple_list.h but don't actually need it.


I may pick away at this over Thanksgiving week while travelling.  Speak 
up if there's any concerns.


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


Re: [Mesa-dev] [PATCH] anv: Implement a depth stall restriction on gen7

2016-11-19 Thread Jordan Justen
On 2016-11-19 15:08:11, Jason Ekstrand wrote:
> Fixes 61 Vulkan CTS tests on Haswell
> 
> Cc: "13.0" 
> ---
>  src/intel/vulkan/anv_genX.h|  2 ++
>  src/intel/vulkan/genX_blorp_exec.c |  2 ++
>  src/intel/vulkan/genX_cmd_buffer.c | 31 +++
>  3 files changed, 35 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> index 7937170..296b1ae 100644
> --- a/src/intel/vulkan/anv_genX.h
> +++ b/src/intel/vulkan/anv_genX.h
> @@ -42,6 +42,8 @@ void genX(cmd_buffer_emit_state_base_address)(struct 
> anv_cmd_buffer *cmd_buffer)
>  
>  void genX(cmd_buffer_apply_pipe_flushes)(struct anv_cmd_buffer *cmd_buffer);
>  
> +void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer 
> *cmd_buffer);
> +
>  void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
>  void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer *cmd_buffer);
>  
> diff --git a/src/intel/vulkan/genX_blorp_exec.c 
> b/src/intel/vulkan/genX_blorp_exec.c
> index a705de0..721b6e5 100644
> --- a/src/intel/vulkan/genX_blorp_exec.c
> +++ b/src/intel/vulkan/genX_blorp_exec.c
> @@ -150,6 +150,8 @@ genX(blorp_exec)(struct blorp_batch *batch,
>  
> genX(flush_pipeline_select_3d)(cmd_buffer);
>  
> +   genX(cmd_buffer_emit_gen7_depth_flush)(cmd_buffer);
> +
> blorp_exec(batch, params);
>  
> cmd_buffer->state.vb_dirty = ~0;
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 985bae0..b873a69 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -1978,6 +1978,35 @@ genX(flush_pipeline_select_gpgpu)(struct 
> anv_cmd_buffer *cmd_buffer)
> }
>  }
>  
> +void
> +genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer *cmd_buffer)
> +{
> +   if (GEN_GEN > 7)

Should it be?

   if (!GEN_IS_HASWELL)

Reviewed-by: Jordan Justen 

> +  return;
> +
> +   /* From the Haswell PRM, documentation for 3DSTATE_DEPTH_BUFFER:
> +*
> +*"Restriction: Prior to changing Depth/Stencil Buffer state (i.e., 
> any
> +*combination of 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS,
> +*3DSTATE_STENCIL_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER) SW must first
> +*issue a pipelined depth stall (PIPE_CONTROL with Depth Stall bit
> +*set), followed by a pipelined depth cache flush (PIPE_CONTROL with
> +*Depth Flush Bit set, followed by another pipelined depth stall
> +*(PIPE_CONTROL with Depth Stall Bit set), unless SW can otherwise
> +*guarantee that the pipeline from WM onwards is already flushed 
> (e.g.,
> +*via a preceding MI_FLUSH)."
> +*/
> +   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
> +  pipe.DepthStallEnable = true;
> +   }
> +   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
> +  pipe.DepthCacheFlushEnable = true;
> +   }
> +   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
> +  pipe.DepthStallEnable = true;
> +   }
> +}
> +
>  static void
>  cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer *cmd_buffer)
>  {
> @@ -1994,6 +2023,8 @@ cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer 
> *cmd_buffer)
> /* FIXME: Implement the PMA stall W/A */
> /* FIXME: Width and Height are wrong */
>  
> +   genX(cmd_buffer_emit_gen7_depth_flush)(cmd_buffer);
> +
> /* Emit 3DSTATE_DEPTH_BUFFER */
> if (has_depth) {
>anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_DEPTH_BUFFER), db) {
> -- 
> 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] anv: Implement a depth stall restriction on gen7

2016-11-19 Thread Jason Ekstrand
On Nov 19, 2016 6:56 PM, "Jordan Justen"  wrote:
>
> On 2016-11-19 15:08:11, Jason Ekstrand wrote:
> > Fixes 61 Vulkan CTS tests on Haswell
> >
> > Cc: "13.0" 
> > ---
> >  src/intel/vulkan/anv_genX.h|  2 ++
> >  src/intel/vulkan/genX_blorp_exec.c |  2 ++
> >  src/intel/vulkan/genX_cmd_buffer.c | 31 +++
> >  3 files changed, 35 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> > index 7937170..296b1ae 100644
> > --- a/src/intel/vulkan/anv_genX.h
> > +++ b/src/intel/vulkan/anv_genX.h
> > @@ -42,6 +42,8 @@ void genX(cmd_buffer_emit_state_base_address)(struct
anv_cmd_buffer *cmd_buffer)
> >
> >  void genX(cmd_buffer_apply_pipe_flushes)(struct anv_cmd_buffer
*cmd_buffer);
> >
> > +void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer
*cmd_buffer);
> > +
> >  void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
> >  void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer
*cmd_buffer);
> >
> > diff --git a/src/intel/vulkan/genX_blorp_exec.c
b/src/intel/vulkan/genX_blorp_exec.c
> > index a705de0..721b6e5 100644
> > --- a/src/intel/vulkan/genX_blorp_exec.c
> > +++ b/src/intel/vulkan/genX_blorp_exec.c
> > @@ -150,6 +150,8 @@ genX(blorp_exec)(struct blorp_batch *batch,
> >
> > genX(flush_pipeline_select_3d)(cmd_buffer);
> >
> > +   genX(cmd_buffer_emit_gen7_depth_flush)(cmd_buffer);
> > +
> > blorp_exec(batch, params);
> >
> > cmd_buffer->state.vb_dirty = ~0;
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
> > index 985bae0..b873a69 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -1978,6 +1978,35 @@ genX(flush_pipeline_select_gpgpu)(struct
anv_cmd_buffer *cmd_buffer)
> > }
> >  }
> >
> > +void
> > +genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer
*cmd_buffer)
> > +{
> > +   if (GEN_GEN > 7)
>
> Should it be?
>
>if (!GEN_IS_HASWELL)

I thought it applied to ivy bridge as well

> Reviewed-by: Jordan Justen 
>
> > +  return;
> > +
> > +   /* From the Haswell PRM, documentation for 3DSTATE_DEPTH_BUFFER:
> > +*
> > +*"Restriction: Prior to changing Depth/Stencil Buffer state
(i.e., any
> > +*combination of 3DSTATE_DEPTH_BUFFER, 3DSTATE_CLEAR_PARAMS,
> > +*3DSTATE_STENCIL_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER) SW must
first
> > +*issue a pipelined depth stall (PIPE_CONTROL with Depth Stall
bit
> > +*set), followed by a pipelined depth cache flush (PIPE_CONTROL
with
> > +*Depth Flush Bit set, followed by another pipelined depth stall
> > +*(PIPE_CONTROL with Depth Stall Bit set), unless SW can
otherwise
> > +*guarantee that the pipeline from WM onwards is already
flushed (e.g.,
> > +*via a preceding MI_FLUSH)."
> > +*/
> > +   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
> > +  pipe.DepthStallEnable = true;
> > +   }
> > +   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
> > +  pipe.DepthCacheFlushEnable = true;
> > +   }
> > +   anv_batch_emit(&cmd_buffer->batch, GENX(PIPE_CONTROL), pipe) {
> > +  pipe.DepthStallEnable = true;
> > +   }
> > +}
> > +
> >  static void
> >  cmd_buffer_emit_depth_stencil(struct anv_cmd_buffer *cmd_buffer)
> >  {
> > @@ -1994,6 +2023,8 @@ cmd_buffer_emit_depth_stencil(struct
anv_cmd_buffer *cmd_buffer)
> > /* FIXME: Implement the PMA stall W/A */
> > /* FIXME: Width and Height are wrong */
> >
> > +   genX(cmd_buffer_emit_gen7_depth_flush)(cmd_buffer);
> > +
> > /* Emit 3DSTATE_DEPTH_BUFFER */
> > if (has_depth) {
> >anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_DEPTH_BUFFER),
db) {
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radeonsi: Fix resource leak in gs_copy_shader allocation failure path

2016-11-19 Thread Mun Gwan-gyeong
CID 1394028

Signed-off-by: Mun Gwan-gyeong 
---
 src/gallium/drivers/radeonsi/si_shader.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 917e148..608cb72 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -6137,9 +6137,15 @@ si_generate_gs_copy_shader(struct si_screen *sscreen,
 
outputs = MALLOC(gsinfo->num_outputs * sizeof(outputs[0]));
 
+   if (!outputs)
+   return NULL;
+
shader = CALLOC_STRUCT(si_shader);
-   if (!shader)
+   if (!shader) {
+   FREE(outputs);
return NULL;
+   }
+
 
shader->selector = gs_selector;
shader->is_gs_copy_shader = true;
-- 
2.10.2

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


[Mesa-dev] list.h vs. simple_list.h

2016-11-19 Thread Brian Paul

[resending, original msg didn't appear on list]

It seems a bit silly to have two linked list utilities.

git-grep indicates that list.h is used more than simple_list.h so maybe 
we can switch uses of the later to the former.  In fact, I've already 
found a few files that include simple_list.h but don't actually need it.


I may pick away at this over Thanksgiving week while travelling.  Speak 
up if there's any concerns.


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


[Mesa-dev] [PATCH] swr: call swr_update_derived unconditionally when drawing/clearing

2016-11-19 Thread Ilia Mirkin
Currently a sequence like draw/map/draw/map will cause the second map to
not wait for the second draw. This is because the first map will clear
the resource business bit, and the second draw won't reset it since no
state has changed.

swr_update_derived does a tiny bit of extra work, including updating the
SWR_BACKEND_STATE as well as waiting for prending fences. If that's a
problem, we could call swr_update_resource_status directly from
draw/clear handlers.

Fixes clearbuffer-stencil, clearbuffer-depth, clearbuffer-depth-stencil,
and clearbuffer-display-lists.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/swr/swr_clear.cpp | 3 +--
 src/gallium/drivers/swr/swr_draw.cpp  | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_clear.cpp 
b/src/gallium/drivers/swr/swr_clear.cpp
index 7ac308e..f59179f 100644
--- a/src/gallium/drivers/swr/swr_clear.cpp
+++ b/src/gallium/drivers/swr/swr_clear.cpp
@@ -40,8 +40,7 @@ swr_clear(struct pipe_context *pipe,
if (!swr_check_render_cond(pipe))
   return;
 
-   if (ctx->dirty)
-  swr_update_derived(pipe);
+   swr_update_derived(pipe);
 
if (buffers & PIPE_CLEAR_COLOR && fb->nr_cbufs) {
   for (unsigned i = 0; i < fb->nr_cbufs; ++i)
diff --git a/src/gallium/drivers/swr/swr_draw.cpp 
b/src/gallium/drivers/swr/swr_draw.cpp
index fc39f6f..c4d5e5c 100644
--- a/src/gallium/drivers/swr/swr_draw.cpp
+++ b/src/gallium/drivers/swr/swr_draw.cpp
@@ -90,8 +90,7 @@ swr_draw_vbo(struct pipe_context *pipe, const struct 
pipe_draw_info *info)
}
 
/* Update derived state, pass draw info to update function */
-   if (ctx->dirty)
-  swr_update_derived(pipe, info);
+   swr_update_derived(pipe, info);
 
swr_update_draw_context(ctx);
 
-- 
2.7.3

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


[Mesa-dev] [PATCH] intel: aubinator: Fix resource leak in gen_spec_load_from_path

2016-11-19 Thread Mun Gwan-gyeong
This fixes resource leak in gen_spec_load_from_path XML_ParserCreate
failure path

CID 1373564

Signed-off-by: Mun Gwan-gyeong 
---
 src/intel/tools/decoder.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/tools/decoder.c b/src/intel/tools/decoder.c
index 6bd02bf..633251a 100644
--- a/src/intel/tools/decoder.c
+++ b/src/intel/tools/decoder.c
@@ -539,6 +539,7 @@ gen_spec_load_from_path(const struct gen_device_info 
*devinfo,
XML_SetUserData(ctx.parser, &ctx);
if (ctx.parser == NULL) {
   fprintf(stderr, "failed to create parser\n");
+  fclose(input);
   free(filename);
   return NULL;
}
-- 
2.10.2

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


Re: [Mesa-dev] [PATCH 1/6] mesa: remove trailing whitespace in errors.c

2016-11-19 Thread Vinson Lee
On Sat, Nov 19, 2016 at 6:26 PM, Brian Paul  wrote:
> ---
>  src/mesa/main/errors.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> index 9932b4a..654343d 100644
> --- a/src/mesa/main/errors.c
> +++ b/src/mesa/main/errors.c
> @@ -122,7 +122,7 @@ flush_delayed_errors( struct gl_context *ctx )
> char s[MAX_DEBUG_MESSAGE_LENGTH];
>
> if (ctx->ErrorDebugCount) {
> -  _mesa_snprintf(s, MAX_DEBUG_MESSAGE_LENGTH, "%d similar %s errors",
> +  _mesa_snprintf(s, MAX_DEBUG_MESSAGE_LENGTH, "%d similar %s errors",
>   ctx->ErrorDebugCount,
>   _mesa_enum_to_string(ctx->ErrorValue));
>
> @@ -145,10 +145,10 @@ _mesa_warning( struct gl_context *ctx, const char 
> *fmtString, ... )
>  {
> char str[MAX_DEBUG_MESSAGE_LENGTH];
> va_list args;
> -   va_start( args, fmtString );
> +   va_start( args, fmtString );
> (void) _mesa_vsnprintf( str, MAX_DEBUG_MESSAGE_LENGTH, fmtString, args );
> va_end( args );
> -
> +
> if (ctx)
>flush_delayed_errors( ctx );
>
> @@ -175,7 +175,7 @@ _mesa_problem( const struct gl_context *ctx, const char 
> *fmtString, ... )
> if (numCalls < 50) {
>numCalls++;
>
> -  va_start( args, fmtString );
> +  va_start( args, fmtString );
>_mesa_vsnprintf( str, MAX_DEBUG_MESSAGE_LENGTH, fmtString, args );
>va_end( args );
>fprintf(stderr, "Mesa %s implementation error: %s\n",
> @@ -264,7 +264,7 @@ _mesa_gl_debug(struct gl_context *ctx,
>   * If debugging is enabled (either at compile-time via the DEBUG macro, or
>   * run-time via the MESA_DEBUG environment variable), report the error with
>   * _mesa_debug().
> - *
> + *
>   * \param ctx the GL context.
>   * \param error the error value.
>   * \param fmtString printf() style format string, followed by optional args
> @@ -346,7 +346,7 @@ _mesa_error_no_memory(const char *caller)
>  /**
>   * Report debug information.  Print error message to stderr via fprintf().
>   * No-op if DEBUG mode not enabled.
> - *
> + *
>   * \param ctx GL context.
>   * \param fmtString printf()-style format string, followed by optional args.
>   */
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


Re: [Mesa-dev] [PATCH 2/6] mesa: remove unneeded #includes in errors.c

2016-11-19 Thread Vinson Lee
On Sat, Nov 19, 2016 at 6:26 PM, Brian Paul  wrote:
> ---
>  src/mesa/main/errors.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> index 654343d..3a40c74 100644
> --- a/src/mesa/main/errors.c
> +++ b/src/mesa/main/errors.c
> @@ -35,12 +35,6 @@
>  #include "imports.h"
>  #include "context.h"
>  #include "debug_output.h"
> -#include "dispatch.h"
> -#include "hash.h"
> -#include "mtypes.h"
> -#include "version.h"
> -#include "util/hash_table.h"
> -#include "util/simple_list.h"
>
>
>  static FILE *LogFile = NULL;
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


Re: [Mesa-dev] [PATCH 3/6] i915: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Vinson Lee
On Sat, Nov 19, 2016 at 6:26 PM, Brian Paul  wrote:
> Compile tested only.
> ---
>  src/mesa/drivers/dri/i915/i830_texblend.c | 1 -
>  src/mesa/drivers/dri/i915/intel_syncobj.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/i830_texblend.c 
> b/src/mesa/drivers/dri/i915/i830_texblend.c
> index 661e424..c29b572 100644
> --- a/src/mesa/drivers/dri/i915/i830_texblend.c
> +++ b/src/mesa/drivers/dri/i915/i830_texblend.c
> @@ -28,7 +28,6 @@
>  #include "main/glheader.h"
>  #include "main/macros.h"
>  #include "main/mtypes.h"
> -#include "util/simple_list.h"
>  #include "main/enums.h"
>  #include "main/mm.h"
>
> diff --git a/src/mesa/drivers/dri/i915/intel_syncobj.c 
> b/src/mesa/drivers/dri/i915/intel_syncobj.c
> index d0a99aa..0766a16 100644
> --- a/src/mesa/drivers/dri/i915/intel_syncobj.c
> +++ b/src/mesa/drivers/dri/i915/intel_syncobj.c
> @@ -38,7 +38,6 @@
>   * performance bottleneck, though.
>   */
>
> -#include "util/simple_list.h"
>  #include "main/imports.h"
>
>  #include "intel_context.h"
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


Re: [Mesa-dev] [PATCH 4/6] r200: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Vinson Lee
On Sat, Nov 19, 2016 at 6:26 PM, Brian Paul  wrote:
> And include "util/simple_list.h" where it is needed in r200_state.c
> Compile tested only.
> ---
>  src/mesa/drivers/dri/r200/r200_context.c | 1 -
>  src/mesa/drivers/dri/r200/r200_ioctl.h   | 2 --
>  src/mesa/drivers/dri/r200/r200_state.c   | 1 +
>  src/mesa/drivers/dri/r200/r200_swtcl.c   | 1 -
>  src/mesa/drivers/dri/r200/r200_tex.c | 1 -
>  5 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r200/r200_context.c 
> b/src/mesa/drivers/dri/r200/r200_context.c
> index 2a42ab3..8f354c1 100644
> --- a/src/mesa/drivers/dri/r200/r200_context.c
> +++ b/src/mesa/drivers/dri/r200/r200_context.c
> @@ -37,7 +37,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #include "main/api_arrayelt.h"
>  #include "main/api_exec.h"
>  #include "main/context.h"
> -#include "util/simple_list.h"
>  #include "main/imports.h"
>  #include "main/extensions.h"
>  #include "main/version.h"
> diff --git a/src/mesa/drivers/dri/r200/r200_ioctl.h 
> b/src/mesa/drivers/dri/r200/r200_ioctl.h
> index 25a9dd3..42feec7 100644
> --- a/src/mesa/drivers/dri/r200/r200_ioctl.h
> +++ b/src/mesa/drivers/dri/r200/r200_ioctl.h
> @@ -35,8 +35,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #ifndef __R200_IOCTL_H__
>  #define __R200_IOCTL_H__
>
> -#include "util/simple_list.h"
> -
>  #include "radeon_bo_gem.h"
>  #include "radeon_cs_gem.h"
>
> diff --git a/src/mesa/drivers/dri/r200/r200_state.c 
> b/src/mesa/drivers/dri/r200/r200_state.c
> index 3671231..4a248d2 100644
> --- a/src/mesa/drivers/dri/r200/r200_state.c
> +++ b/src/mesa/drivers/dri/r200/r200_state.c
> @@ -61,6 +61,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #include "r200_swtcl.h"
>  #include "r200_vertprog.h"
>
> +#include "util/simple_list.h"
>
>  /* =
>   * Alpha blending
> diff --git a/src/mesa/drivers/dri/r200/r200_swtcl.c 
> b/src/mesa/drivers/dri/r200/r200_swtcl.c
> index 72f09ae..6ca85f5 100644
> --- a/src/mesa/drivers/dri/r200/r200_swtcl.c
> +++ b/src/mesa/drivers/dri/r200/r200_swtcl.c
> @@ -38,7 +38,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #include "main/image.h"
>  #include "main/imports.h"
>  #include "main/macros.h"
> -#include "util/simple_list.h"
>
>  #include "swrast/s_context.h"
>  #include "swrast/s_fog.h"
> diff --git a/src/mesa/drivers/dri/r200/r200_tex.c 
> b/src/mesa/drivers/dri/r200/r200_tex.c
> index 2a95f2d..0ddb686 100644
> --- a/src/mesa/drivers/dri/r200/r200_tex.c
> +++ b/src/mesa/drivers/dri/r200/r200_tex.c
> @@ -36,7 +36,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #include "main/context.h"
>  #include "main/enums.h"
>  #include "main/image.h"
> -#include "util/simple_list.h"
>  #include "main/teximage.h"
>  #include "main/texobj.h"
>  #include "main/samplerobj.h"
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


Re: [Mesa-dev] [PATCH 5/6] radeon: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Vinson Lee
On Sat, Nov 19, 2016 at 6:26 PM, Brian Paul  wrote:
> Compile tested only.
> ---
>  src/mesa/drivers/dri/radeon/radeon_ioctl.h   | 1 -
>  src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c | 1 -
>  src/mesa/drivers/dri/radeon/radeon_queryobj.c| 1 -
>  src/mesa/drivers/dri/radeon/radeon_swtcl.c   | 1 -
>  src/mesa/drivers/dri/radeon/radeon_tex.c | 1 -
>  5 files changed, 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/radeon/radeon_ioctl.h 
> b/src/mesa/drivers/dri/radeon/radeon_ioctl.h
> index 2fe0e57..701dcdd 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_ioctl.h
> +++ b/src/mesa/drivers/dri/radeon/radeon_ioctl.h
> @@ -36,7 +36,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #ifndef __RADEON_IOCTL_H__
>  #define __RADEON_IOCTL_H__
>
> -#include "util/simple_list.h"
>  #include "radeon_bo_gem.h"
>  #include "radeon_cs_gem.h"
>
> diff --git a/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c 
> b/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c
> index c71766d..19e6296 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_mipmap_tree.c
> @@ -31,7 +31,6 @@
>  #include 
>  #include 
>
> -#include "util/simple_list.h"
>  #include "main/teximage.h"
>  #include "main/texobj.h"
>  #include "main/enums.h"
> diff --git a/src/mesa/drivers/dri/radeon/radeon_queryobj.c 
> b/src/mesa/drivers/dri/radeon/radeon_queryobj.c
> index c5fbc60..cd0075a 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_queryobj.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_queryobj.c
> @@ -29,7 +29,6 @@
>  #include "radeon_debug.h"
>
>  #include "main/imports.h"
> -#include "util/simple_list.h"
>
>  #include 
>
> diff --git a/src/mesa/drivers/dri/radeon/radeon_swtcl.c 
> b/src/mesa/drivers/dri/radeon/radeon_swtcl.c
> index adc1468..f2bc462 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_swtcl.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_swtcl.c
> @@ -37,7 +37,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #include "main/enums.h"
>  #include "main/imports.h"
>  #include "main/macros.h"
> -#include "util/simple_list.h"
>
>  #include "math/m_xform.h"
>
> diff --git a/src/mesa/drivers/dri/radeon/radeon_tex.c 
> b/src/mesa/drivers/dri/radeon/radeon_tex.c
> index 083a5e1..c3b83fa 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_tex.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_tex.c
> @@ -36,7 +36,6 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
> SOFTWARE.
>  #include "main/context.h"
>  #include "main/enums.h"
>  #include "main/image.h"
> -#include "util/simple_list.h"
>  #include "main/teximage.h"
>  #include "main/texobj.h"
>
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


Re: [Mesa-dev] [PATCH 6/6] tnl: remove unneeded #include "util/simple_list.h"

2016-11-19 Thread Vinson Lee
On Sat, Nov 19, 2016 at 6:26 PM, Brian Paul  wrote:
> ---
>  src/mesa/tnl/t_vertex_generic.c | 1 -
>  src/mesa/tnl/t_vertex_sse.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/src/mesa/tnl/t_vertex_generic.c b/src/mesa/tnl/t_vertex_generic.c
> index 6c40c86..7f871a4 100644
> --- a/src/mesa/tnl/t_vertex_generic.c
> +++ b/src/mesa/tnl/t_vertex_generic.c
> @@ -29,7 +29,6 @@
>  #include "main/glheader.h"
>  #include "main/context.h"
>  #include "main/macros.h"
> -#include "util/simple_list.h"
>  #include "swrast/s_chan.h"
>  #include "t_context.h"
>  #include "t_vertex.h"
> diff --git a/src/mesa/tnl/t_vertex_sse.c b/src/mesa/tnl/t_vertex_sse.c
> index 14e7812..191a68d 100644
> --- a/src/mesa/tnl/t_vertex_sse.c
> +++ b/src/mesa/tnl/t_vertex_sse.c
> @@ -29,7 +29,6 @@
>
>  #include "main/glheader.h"
>  #include "main/context.h"
> -#include "util/simple_list.h"
>  #include "main/enums.h"
>  #include "swrast/s_chan.h"
>  #include "t_context.h"
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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