[Mesa-dev] [PATCH 1/2] nv50/ir: fix srcMask computation for TG4 and TXF

[Ilia Mirkin]

This affects which inputs are marked as used. In a situation where only
the texture instruction uses an input, it might have been ignored as
unused due to input masks.

Affects subtests of KHR-GL45.texture_cube_map_array.sampling

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index 265aff1bd3e..24f4b57ce8f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -321,6 +321,8 @@ unsigned int Instruction::srcMask(unsigned int s) const
case TGSI_OPCODE_TXD:
case TGSI_OPCODE_TXL:
case TGSI_OPCODE_TXP:
+   case TGSI_OPCODE_TXF:
+   case TGSI_OPCODE_TG4:
case TGSI_OPCODE_TEX_LZ:
case TGSI_OPCODE_TXF_LZ:
case TGSI_OPCODE_LODQ:
-- 
2.13.0

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

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

[Aaron Watry]

On Tue, Aug 15, 2017 at 7:30 PM, Michel Dänzer  wrote:
> On 15/08/17 11:04 PM, Aaron Watry wrote:
>> On Mon, Aug 14, 2017 at 10:11 PM, Michel Dänzer  wrote:
>>> On 15/08/17 12:00 PM, Aaron Watry wrote:
 On Mon, Aug 14, 2017 at 7:54 PM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> https://bugs.llvm.org/show_bug.cgi?id=6823 still affects current LLVM.
> llvm-config --libs only reports the single shared library if LLVM was
> built with -DLLVM_LINK_LLVM_DYLIB=ON. llvm-config --shared-mode reports
> "shared" in that case, "static" otherwise (even if LLVM was built with
> -DLLVM_BUILD_LLVM_DYLIB=ON).
>
> Fixes: 3d8da1f678e1 ("configure: Trust LLVM >= 4.0 llvm-config --libs
>   for shared libraries")
> Signed-off-by: Michel Dänzer 

 Thanks Michel,

 Fixes a build error I've been encountering tonight with all of the
 combinations of llvm builds I've tried (VC_REV=on/off,
 shared_libraries=1/0, dylib=1/0

 Tested-by: Aaron Watry 

 FYI: I've settled for now on LLVM_APPEND_VC_REV=ON,
 BUILD_SHARED_LIBS=1 amongst the rest of my llvm build flags.
 Previously, I was able to get away with VC_REV=off,
 LLVM_BULID_LLVM_DYLIB=1.
>>>
>>> The latter should work again with this patch. I'm using
>>> LLVM_BULID_LLVM_DYLIB=ON LLVM_LINK_LLVM_DYLIB=ON, the latter removes the
>>> need for LLVM_APPEND_VC_REV=OFF with my patches.
>>
>> Huh, I just tried to rebuild things with:
>> -DLLVM_BUILD_LLVM_DYLIB=1 -DLLVM_LINK_LLVM_DYLIB=1  -DLLVM_APPEND_VC_REV=ON
>>
>> glxinfo works fine afterwords, but I get the following error when I
>> try to run opencl programs:
>> CommandLine Error: Option 'help-list' registered more than once!
>> LLVM ERROR: inconsistency in registered CommandLine options
>
> Works for me, at least for the piglit OpenCL tests.
>
>
>> I can go back to one of my other build configurations, but it's
>> looking like something in that is causing multiple
>> registrations/initializations of some llvm components.
>
> Right, make sure nothing's still linking the individual LLVM components
> for you, either dynamically or statically. Have you run at least make
> clean in the Mesa tree since changing the build configuration?

Yeah, my usual rebuild includes an out-of-tree rebuild with a full
reconfigure.  I suspect that I had both static library and .so
versions of LLVM installed simultaneously, or something similar.  I
deleted all of the llvm/clang artifacts out of $prefix, rebuilt LLVM,
did a git clean -fdx on my mesa tree (to clear out the configure
script, etc), and now things are working for me.

Probably just a case of too many local configuration changes in too
short a time leading to junk left around my system. Sorry for the
noise.

--Aaron

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

Re: [Mesa-dev] [PATCH 0/9] dri2: Swapbuffer update v3.

[Michel Dänzer]

On 16/08/17 03:31 AM, Thomas Hellstrom wrote:
> Implement back-to-fake-front flips,
> Fix EGL_BUFFER_PRESERVED path.
> Implement dri3 support for GLX_SWAP_EXCHANGE_OML and GLX_SWAP_COPY_OML.
> 
> The back-to-fake-front flips will save a full buffer copy in the case of a
> fake front being enabled and GLX_SWAP_UNDEFINED_OML.
> 
> Support for EGL_BUFFER_PRESERVED and GLX_SWAP_X_OML are mostly useful for
> things like glretrace if traces are capured with applications relying on a
> specific swapbuffer behavior.
> 
> The EGL_BUFFER_PRESERVED path previously made sure the present was done as
> a copy, but there was nothing making sure that after the present,
> the same back buffer was chosen.
> This has now been changed so that if the previous back buffer is
> idle, we reuse it. Otherwise we grab a new and copy the contents and
> buffer age from the previous back buffer. Server side flips are allowed.
> 
> GLX_SWAP_COPY_OML will behave like EGL_BUFFER_PRESERVED.
> 
> GLX_SWAP_EXCHANGE_OML will behave similarly, except that we try to reuse the
> previous fake front as the new back buffer if it's idle. If not, we grab
> a new back buffer and copy the contents and buffer age from the old fake 
> front.
> 
> v2:
> - Split the original patch,
> - Make sure we have a context for blitImage even if we don't have a
> current context.
> - Make sure the delayed backbuffer allocation is performed before
> glXSwapBuffers, glXCopyBuffers and querying buffer age.
> v3:
> - squash three patches related to the same change.
> - Address review comments by Michel Dänzer.

The series is

Reviewed-by: Michel Dänzer 


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

[Mesa-dev] [Bug 101766] Assertion `!"invalid type"' failed when constant expression involves literal of different type

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

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

--- Comment #4 from Ilia Mirkin  ---
Should be fixed with the below commit, which should appear in mesa 17.2. Thanks
for the report!

commit 978c4c597aa48e65bd6822a85e6b8f82ca9281f1
Author: Ilia Mirkin 
Date:   Tue Aug 15 13:47:08 2017 -0400

glsl/ast: update rhs in addition to the var's constant_value

We continue in the code to do some more things with the rhs, including
setting a constant initializer. If the type is wrong, this causes some
confusion down the line, leading to assertions. This makes sure that the
rhs processing continues to flow as-if the type was correct to start
with (even though the state has been marked as an error state).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101766
Signed-off-by: Ilia Mirkin 
Reviewed-by: Kenneth Graunke 
Cc: mesa-sta...@lists.freedesktop.org

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

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

[Ilia Mirkin]

[adding Julien, who did the nouveau va-api integration.]

On Tue, Aug 15, 2017 at 9:59 AM, Philipp Kerling  wrote:
> Hi,
>
> I recently noticed that hardware video decoding with the nouveau driver
> and libva does not play nicely with Wayland and decided to dig a bit.
>
> To use libva in conjunction with Wayland in EGL applications, you
> usually export the surface dmabuf via vaDeriveImage &
> vaAcquireBufferHandle and then import it in EGL via eglCreateImageKHR &
> EGL_LINUX_DMA_BUF_EXT.
> However, this does not work with nouveau.
>
> The first problem I could identify is that nouveau uses NV12 as buffer
> format and mesa vaDeriveImage cannot handle that (see FourCCs handled
> in vlVaDeriveImage). It seems to be easy to add though (just have to
> set num_planes/offset etc. correctly), and I did so locally. Also,
> nouveau always sets the interlaced flag on the buffer, which
> vlVaDeriveImage also errors out on. Not sure why it does that and what
> to do with that currently, I just removed the check locally.

The hw decoder produces an interlaced NV12 image -- i.e. the Y plane
is 2 images and the UV plane is 2 images, below one another. This is
in firmware written in falcon (VP3+) or xtensa (VP2) microcode by
NVIDIA. There is no open-source implementation, and thus would be
tricky to change. It's possible that this firmware supports other
output formats as well ... but we're not presently aware of it.
Presumably the 10-bit decoding is done *somehow*.

>
> Then I hit another problem, which is that NV12 uses two planes and thus
> has an offset into the buffer for the second plane, but nouveau cannot
> handle offsets in eglCreateImageKHR (see nouveau_screen_bo_from_handle
> which has a check for this).

The VP2-era hardware decoder (G84..G200, minus G98) wants a single
output buffer - you enter it in as a single base address and then an
offset to the UV plane. It's a 32-bit offset but a 40-bit VA space.
Later decoder generations (VP3+) have a separate address for both Y
and UV planes. Actually looking over the VP2 logic (which I'm sad to
say I wrote many years ago), it *might* be possible to have separate
buffers for the final output image (in the second VP step).

> Is there an easy/obvious way to add handling for the offset parameter
> in nouveau_screen.c? This might be all that is currently breaking hwdec
> on nouveau+Wayland, but I couldn't test it of course, so there might
> still be other problems lurking.

Well, strictly speaking this should be easy - while nouveau_bo has no
offset, nv04_resource does - specifically things tend to use
nv04_resource->address. I believe this offset stuff was added
recently, and I don't know much about EGL or Wayland or ... well a lot
of the new hotness. So e.g. in nv50_miptree_from_handle you could set
the mt->base.address = bo->offset + whandle->offset; I wonder if the
tiling stuff will be an issue -- the decoder can get *very* picking
about tiling -- somehow you'll have to ensure that the images are
allocated with proper tiling flags set -- see how nvc0_miptree_create
calls nvc0_miptree_init_layout_video, which sets tile_mode to 0x10.
That's not by coincidence.

BTW, note that you can't use a decoder in one thread and GL commands
in another thread. This will cause death in nouveau. Also note that
there are known (but unfixed) artifacts when decoding some H.264
videos.

Feel free to join us in #nouveau on irc.freenode.net.

Cheers,

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

Re: [Mesa-dev] [PATCH 06/11] loader_dri3: Honour the request to preserve back buffer content

[Michel Dänzer]

On 15/08/17 09:45 PM, Thomas Hellstrom wrote:
> On 08/15/2017 09:33 AM, Michel Dänzer wrote:
>> On 11/08/17 11:14 PM, Thomas Hellstrom wrote:
>>> EGL uses the force_copy parameter to loader_dri3_swap_buffers_msc()
>>> to indicate
>>> that it wants to preserve back buffer contents across a buffer swap.
>>>
>>> While the loader then turns off server-side page-flipping there's
>>> nothing to
>>> guarantee that a new backbuffer isn't chosen when EGL starts to
>>> render again,
>>> and that buffer's content is of course undefined.
>>>
>>> So rework the functionality:
>>> If the client supports local blits, allow server-side page flipping
>>> and when
>>> a new back is grabbed, if needed, blit the old back's content to the
>>> new back.
>>> If the client doesn't support local blits, disallow server-side
>>> page-flipping
>>> to avoid a client deadlock and then, when grabbing a new back buffer,
>>> sleep
>>> until the old back is idle, which may take a substantial time
>>> depending on
>>> swap interval.
>>>
>>> Signed-off-by: Thomas Hellstrom 
>> [...]
>>
>>> @@ -475,12 +476,21 @@ dri3_find_back(struct loader_dri3_drawable *draw)
>>>  int b;
>>>  xcb_generic_event_t *ev;
>>>  xcb_present_generic_event_t *ge;
>>> +   int num_to_consider = draw->num_back;
>>>/* Increase the likelyhood of reusing current buffer */
>>>  dri3_flush_present_events(draw);
>>>   +   /* Check whether we need to reuse the current back buffer as
>>> new back.
>>> +* In that case, wait until it's not busy anymore.
>>> +*/
>>> +   if (!draw->have_image_blit && draw->cur_blit_source != -1) {
>>> +  num_to_consider = 1;
>>> +  draw->cur_blit_source = -1;
>>> +   }
>> Is it possible that dri3_find_back gets called with
>> draw->cur_blit_source != -1, entering this block (assuming
>> !draw->have_image_blit)...
>>
>>
>>>  for (;;) {
>>> -  for (b = 0; b < draw->num_back; b++) {
>>> +  for (b = 0; b < num_to_consider; b++) {
>>>int id = LOADER_DRI3_BACK_ID((b + draw->cur_back) %
>>> draw->num_back);
>>>struct loader_dri3_buffer *buffer = draw->buffers[id];
>> ... Then later gets called again with draw->cur_blit_source == -1,
>> choosing a different back buffer here, because the previous one is still
>> busy?
>>
>>
> I don't think that's possible. If dri3_find_back returns a back buffer,
> it should be idle, in the sense that it's not currently in the swap
> chain or being scanned out from. It may still have a non-signaled fence
> though. If a later call to dri_find_back() decides it's busy then
> someone must have called swapBuffer in between and it's time to change
> back anyway...

Okay, then this patch is also

Reviewed-by: Michel Dänzer 


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

[Mesa-dev] nouveau hardware decoding and vaDeriveImage

[Philipp Kerling]

Hi,

I recently noticed that hardware video decoding with the nouveau driver
and libva does not play nicely with Wayland and decided to dig a bit.

To use libva in conjunction with Wayland in EGL applications, you
usually export the surface dmabuf via vaDeriveImage &
vaAcquireBufferHandle and then import it in EGL via eglCreateImageKHR &
EGL_LINUX_DMA_BUF_EXT.
However, this does not work with nouveau.

The first problem I could identify is that nouveau uses NV12 as buffer
format and mesa vaDeriveImage cannot handle that (see FourCCs handled
in vlVaDeriveImage). It seems to be easy to add though (just have to
set num_planes/offset etc. correctly), and I did so locally. Also,
nouveau always sets the interlaced flag on the buffer, which
vlVaDeriveImage also errors out on. Not sure why it does that and what
to do with that currently, I just removed the check locally.

Then I hit another problem, which is that NV12 uses two planes and thus
has an offset into the buffer for the second plane, but nouveau cannot
handle offsets in eglCreateImageKHR (see nouveau_screen_bo_from_handle
which has a check for this).
Is there an easy/obvious way to add handling for the offset parameter
in nouveau_screen.c? This might be all that is currently breaking hwdec
on nouveau+Wayland, but I couldn't test it of course, so there might
still be other problems lurking.

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

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

[Michel Dänzer]

On 15/08/17 11:04 PM, Aaron Watry wrote:
> On Mon, Aug 14, 2017 at 10:11 PM, Michel Dänzer  wrote:
>> On 15/08/17 12:00 PM, Aaron Watry wrote:
>>> On Mon, Aug 14, 2017 at 7:54 PM, Michel Dänzer  wrote:
 From: Michel Dänzer 

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

 Fixes: 3d8da1f678e1 ("configure: Trust LLVM >= 4.0 llvm-config --libs
   for shared libraries")
 Signed-off-by: Michel Dänzer 
>>>
>>> Thanks Michel,
>>>
>>> Fixes a build error I've been encountering tonight with all of the
>>> combinations of llvm builds I've tried (VC_REV=on/off,
>>> shared_libraries=1/0, dylib=1/0
>>>
>>> Tested-by: Aaron Watry 
>>>
>>> FYI: I've settled for now on LLVM_APPEND_VC_REV=ON,
>>> BUILD_SHARED_LIBS=1 amongst the rest of my llvm build flags.
>>> Previously, I was able to get away with VC_REV=off,
>>> LLVM_BULID_LLVM_DYLIB=1.
>>
>> The latter should work again with this patch. I'm using
>> LLVM_BULID_LLVM_DYLIB=ON LLVM_LINK_LLVM_DYLIB=ON, the latter removes the
>> need for LLVM_APPEND_VC_REV=OFF with my patches.
> 
> Huh, I just tried to rebuild things with:
> -DLLVM_BUILD_LLVM_DYLIB=1 -DLLVM_LINK_LLVM_DYLIB=1  -DLLVM_APPEND_VC_REV=ON
> 
> glxinfo works fine afterwords, but I get the following error when I
> try to run opencl programs:
> CommandLine Error: Option 'help-list' registered more than once!
> LLVM ERROR: inconsistency in registered CommandLine options

Works for me, at least for the piglit OpenCL tests.


> I can go back to one of my other build configurations, but it's
> looking like something in that is causing multiple
> registrations/initializations of some llvm components.

Right, make sure nothing's still linking the individual LLVM components
for you, either dynamically or statically. Have you run at least make
clean in the Mesa tree since changing the build configuration?


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

[Mesa-dev] [PATCH] radeonsi/gfx9: add a temporary workaround for a tessellation driver bug

[Marek Olšák]

From: Marek Olšák 

The workaround will do for now. The root cause is still unknown.

This fixes new piglit: 16in-1out

Cc: 17.1 17.2 
---
 src/gallium/drivers/radeonsi/si_state_draw.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index f17f570..a26e38d 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -187,21 +187,25 @@ static void si_emit_derived_tess_state(struct si_context 
*sctx,
/* Make sure the output data fits in the offchip buffer */
*num_patches = MIN2(*num_patches,
(sctx->screen->tess_offchip_block_dw_size * 4) /
output_patch_size);
 
/* Not necessary for correctness, but improves performance. The
 * specific value is taken from the proprietary driver.
 */
*num_patches = MIN2(*num_patches, 40);
 
-   if (sctx->b.chip_class == SI) {
+   if (sctx->b.chip_class == SI ||
+   /* TODO: fix GFX9 where a threadgroup contains more than 1 wave and
+* LS vertices per patch > HS vertices per patch. Piglit: 16in-1out 
*/
+   (sctx->b.chip_class == GFX9 &&
+num_tcs_input_cp > num_tcs_output_cp)) {
/* SI bug workaround, related to power management. Limit LS-HS
 * threadgroups to only one wave.
 */
unsigned one_wave = 64 / MAX2(num_tcs_input_cp, 
num_tcs_output_cp);
*num_patches = MIN2(*num_patches, one_wave);
}
 
/* The VGT HS block increments the patch ID unconditionally
 * within a single threadgroup. This results in incorrect
 * patch IDs when instanced draws are used.
-- 
2.7.4

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

[Mesa-dev] [PATCH 04/20] radeon/uvd: add mjpeg stream type

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/drivers/radeon/radeon_uvd.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/radeon/radeon_uvd.h 
b/src/gallium/drivers/radeon/radeon_uvd.h
index 0c3797e22c..a927c843da 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.h
+++ b/src/gallium/drivers/radeon/radeon_uvd.h
@@ -82,6 +82,7 @@
 #define RUVD_CODEC_MPEG2   0x0003
 #define RUVD_CODEC_MPEG4   0x0004
 #define RUVD_CODEC_H264_PERF   0x0007
+#define RUVD_CODEC_MJPEG   0x0008
 #define RUVD_CODEC_H2650x0010
 
 /* UVD decode target buffer tiling mode */
-- 
2.11.0

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

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

[Leo Liu]

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

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

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

-- 
2.11.0

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

[Mesa-dev] [PATCH 03/20] radeon/video: add mjpeg support

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/util/u_video.h  | 3 +++
 src/gallium/drivers/radeon/radeon_video.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_video.h 
b/src/gallium/auxiliary/util/u_video.h
index 251e144c79..0f2e969904 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -76,6 +76,9 @@ u_reduce_video_profile(enum pipe_video_profile profile)
   case PIPE_VIDEO_PROFILE_HEVC_MAIN_444:
  return PIPE_VIDEO_FORMAT_HEVC;
 
+  case PIPE_VIDEO_PROFILE_MJPEG_BASELINE:
+ return PIPE_VIDEO_FORMAT_MJPEG;
+
   default:
  return PIPE_VIDEO_FORMAT_UNKNOWN;
}
diff --git a/src/gallium/drivers/radeon/radeon_video.c 
b/src/gallium/drivers/radeon/radeon_video.c
index f7a1c4743d..0cff2a0df9 100644
--- a/src/gallium/drivers/radeon/radeon_video.c
+++ b/src/gallium/drivers/radeon/radeon_video.c
@@ -280,6 +280,8 @@ int rvid_get_video_param(struct pipe_screen *screen,
profile == 
PIPE_VIDEO_PROFILE_HEVC_MAIN_10);
else if (rscreen->family >= CHIP_CARRIZO)
return profile == PIPE_VIDEO_PROFILE_HEVC_MAIN;
+   case PIPE_VIDEO_FORMAT_MJPEG:
+   return true;
default:
return false;
}
-- 
2.11.0

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

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

[Leo Liu]

To find if the format is supported yuyv by sampling factor which
is embedded from bitstream. So we could use this info for buffer
relocation on the correct format.

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

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

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

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

[Leo Liu]

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

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

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

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

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture_mjpeg.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

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

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

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

[Leo Liu]

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

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

diff --git a/src/gallium/drivers/radeon/radeon_uvd.c 
b/src/gallium/drivers/radeon/radeon_uvd.c
index 59d1f199e9..5e5638d565 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -1543,6 +1543,8 @@ void ruvd_set_dt_surfaces(struct ruvd_msg *msg, struct 
radeon_surf *luma,
default:
case RUVD_SURFACE_TYPE_LEGACY:
msg->body.decode.dt_pitch = luma->u.legacy.level[0].nblk_x;
+   if (!chroma)
+   msg->body.decode.dt_pitch *= 2;
switch (luma->u.legacy.level[0].mode) {
case RADEON_SURF_MODE_LINEAR_ALIGNED:
msg->body.decode.dt_tiling_mode = RUVD_TILE_LINEAR;
@@ -1562,10 +1564,12 @@ void ruvd_set_dt_surfaces(struct ruvd_msg *msg, struct 
radeon_surf *luma,
}
 
msg->body.decode.dt_luma_top_offset = texture_offset(luma, 0, 
type);
-   msg->body.decode.dt_chroma_top_offset = texture_offset(chroma, 
0, type);
+   if (chroma)
+   msg->body.decode.dt_chroma_top_offset = 
texture_offset(chroma, 0, type);
if (msg->body.decode.dt_field_mode) {
msg->body.decode.dt_luma_bottom_offset = 
texture_offset(luma, 1, type);
-   msg->body.decode.dt_chroma_bottom_offset = 
texture_offset(chroma, 1, type);
+   if (chroma)
+   msg->body.decode.dt_chroma_bottom_offset = 
texture_offset(chroma, 1, type);
} else {
msg->body.decode.dt_luma_bottom_offset = 
msg->body.decode.dt_luma_top_offset;
msg->body.decode.dt_chroma_bottom_offset = 
msg->body.decode.dt_chroma_top_offset;
diff --git a/src/gallium/drivers/radeonsi/si_uvd.c 
b/src/gallium/drivers/radeonsi/si_uvd.c
index d17a6656a4..2441ad248c 100644
--- a/src/gallium/drivers/radeonsi/si_uvd.c
+++ b/src/gallium/drivers/radeonsi/si_uvd.c
@@ -131,7 +131,7 @@ static struct pb_buffer* si_uvd_set_dtb(struct ruvd_msg 
*msg, struct vl_video_bu
 
msg->body.decode.dt_field_mode = buf->base.interlaced;
 
-   ruvd_set_dt_surfaces(msg, >surface, >surface, type);
+   ruvd_set_dt_surfaces(msg, >surface, (chroma) ? >surface : 
NULL, type);
 
return luma->resource.buf;
 }
-- 
2.11.0

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

[Mesa-dev] [PATCH 19/20] st/va: relocate surface with yuyv stream

[Leo Liu]

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

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

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

[Mesa-dev] [PATCH 20/20] st/va: add mjpeg for config

[Leo Liu]

To enable mjpeg hw decode

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/config.c | 2 +-
 src/gallium/state_trackers/va/va_private.h | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/config.c 
b/src/gallium/state_trackers/va/config.c
index 7d3bd648d9..e2418d6a8f 100644
--- a/src/gallium/state_trackers/va/config.c
+++ b/src/gallium/state_trackers/va/config.c
@@ -52,7 +52,7 @@ vlVaQueryConfigProfiles(VADriverContextP ctx, VAProfile 
*profile_list, int *num_
*num_profiles = 0;
 
pscreen = VL_VA_PSCREEN(ctx);
-   for (p = PIPE_VIDEO_PROFILE_MPEG2_SIMPLE; p <= 
PIPE_VIDEO_PROFILE_HEVC_MAIN_444; ++p) {
+   for (p = PIPE_VIDEO_PROFILE_MPEG2_SIMPLE; p <= 
PIPE_VIDEO_PROFILE_MJPEG_BASELINE; ++p) {
   if (u_reduce_video_profile(p) == PIPE_VIDEO_FORMAT_MPEG4 && 
!debug_get_option_mpeg4())
  continue;
 
diff --git a/src/gallium/state_trackers/va/va_private.h 
b/src/gallium/state_trackers/va/va_private.h
index 9c09318127..0624ae879f 100644
--- a/src/gallium/state_trackers/va/va_private.h
+++ b/src/gallium/state_trackers/va/va_private.h
@@ -170,6 +170,8 @@ PipeToProfile(enum pipe_video_profile profile)
   return VAProfileHEVCMain;
case PIPE_VIDEO_PROFILE_HEVC_MAIN_10:
   return VAProfileHEVCMain10;
+   case PIPE_VIDEO_PROFILE_MJPEG_BASELINE:
+  return VAProfileJPEGBaseline;
case PIPE_VIDEO_PROFILE_MPEG4_AVC_EXTENDED:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH10:
case PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH422:
@@ -214,6 +216,8 @@ ProfileToPipe(VAProfile profile)
   return PIPE_VIDEO_PROFILE_HEVC_MAIN;
case VAProfileHEVCMain10:
   return PIPE_VIDEO_PROFILE_HEVC_MAIN_10;
+   case VAProfileJPEGBaseline:
+  return PIPE_VIDEO_PROFILE_MJPEG_BASELINE;
case VAProfileNone:
return PIPE_VIDEO_PROFILE_UNKNOWN;
default:
-- 
2.11.0

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

[Mesa-dev] [PATCH 12/20] st/va: add slice parameter handling for mjpeg

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture_mjpeg.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/va/picture_mjpeg.c 
b/src/gallium/state_trackers/va/picture_mjpeg.c
index 17f077962e..326c890c88 100644
--- a/src/gallium/state_trackers/va/picture_mjpeg.c
+++ b/src/gallium/state_trackers/va/picture_mjpeg.c
@@ -85,5 +85,27 @@ void vlVaHandleHuffmanTableBufferType(vlVaContext *context, 
vlVaBuffer *buf)
 
 void vlVaHandleSliceParameterBufferMJPEG(vlVaContext *context, vlVaBuffer *buf)
 {
-   /* TODO */
+   VASliceParameterBufferJPEGBaseline *mjpeg = buf->data;
+   int i;
+
+   assert(buf->size >= sizeof(VASliceParameterBufferJPEGBaseline) && 
buf->num_elements == 1);
+
+   context->desc.mjpeg.slice_parameter.slice_data_size = 
mjpeg->slice_data_size;
+   context->desc.mjpeg.slice_parameter.slice_data_offset = 
mjpeg->slice_data_offset;
+   context->desc.mjpeg.slice_parameter.slice_data_flag = 
mjpeg->slice_data_flag;
+   context->desc.mjpeg.slice_parameter.slice_horizontal_position = 
mjpeg->slice_horizontal_position;
+   context->desc.mjpeg.slice_parameter.slice_vertical_position = 
mjpeg->slice_vertical_position;
+
+   for (i = 0; i < mjpeg->num_components; ++i) {
+  context->desc.mjpeg.slice_parameter.components[i].component_selector =
+ mjpeg->components[i].component_selector;
+  context->desc.mjpeg.slice_parameter.components[i].dc_table_selector =
+ mjpeg->components[i].dc_table_selector;
+  context->desc.mjpeg.slice_parameter.components[i].ac_table_selector =
+ mjpeg->components[i].ac_table_selector;
+   }
+
+   context->desc.mjpeg.slice_parameter.num_components = mjpeg->num_components;
+   context->desc.mjpeg.slice_parameter.restart_interval = 
mjpeg->restart_interval;
+   context->desc.mjpeg.slice_parameter.num_mcus = mjpeg->num_mcus;
 }
-- 
2.11.0

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

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

[Leo Liu]

The current tier 1 mjpeg firmware only supports at the bitstream
level, the later tier 2 support will be at the buffers level with
newer hardware.

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

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

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

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/state_trackers/va/picture_mjpeg.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

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

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

Re: [Mesa-dev] [PATCH] radv/gfx9: for fast clear use is_linear flag.

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Tue, Aug 15, 2017, at 21:55, Dave Airlie wrote:
> From: Dave Airlie 
> 
> The legacy test won't work on gfx9.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_meta_clear.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/amd/vulkan/radv_meta_clear.c
> b/src/amd/vulkan/radv_meta_clear.c
> index e3d823fb58..af76a517aa 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -979,7 +979,7 @@ emit_fast_color_clear(struct radv_cmd_buffer
> *cmd_buffer,
>   if (iview->image->info.levels > 1)
>   goto fail;
>  
> -   if (iview->image->surface.u.legacy.level[0].mode <
> RADEON_SURF_MODE_1D)
> +   if (iview->image->surface.is_linear)
>   goto fail;
>   if (!radv_image_extent_compare(iview->image, >extent))
>   goto fail;
> -- 
> 2.13.5
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/5] i965/eu: add support for 1-OWord Block Read/Write messages

[Francisco Jerez]

Mark Janes  writes:

> This series resolves
> https://bugs.freedesktop.org/show_bug.cgi?id=101985, currently blocking
> 17.2 release.
>

I have doubts this series is ready for production, though I don't think
it makes a ton of sense for Gen7 fp64 vec4 spilling to be considered a
blocking issue for the 17.2 release?

> Tested-by: Mark Janes 
>
> Samuel Iglesias Gonsálvez  writes:
>
>> v2:
>> - Use nibctrl and the number of written/read owords to detect
>> each case of a 1-OWord Block Read/Write (Curro)
>>
>> Signed-off-by: Samuel Iglesias Gonsálvez 
>> ---
>>  src/intel/compiler/brw_eu.h | 14 +-
>>  src/intel/compiler/brw_eu_emit.c| 46 
>> +
>>  src/intel/compiler/brw_fs_generator.cpp |  4 +--
>>  3 files changed, 44 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
>> index a3a9c63239..de8470b4b5 100644
>> --- a/src/intel/compiler/brw_eu.h
>> +++ b/src/intel/compiler/brw_eu.h
>> @@ -342,15 +342,15 @@ void brw_oword_block_read(struct brw_codegen *p,
>>  unsigned brw_scratch_surface_idx(const struct brw_codegen *p);
>>  
>>  void brw_oword_block_read_scratch(struct brw_codegen *p,
>> -  struct brw_reg dest,
>> -  struct brw_reg mrf,
>> -  int num_regs,
>> -  unsigned offset);
>> +  struct brw_reg dest,
>> +  struct brw_reg mrf,
>> +  int num_owords,
>> +  unsigned offset);
>>  
>>  void brw_oword_block_write_scratch(struct brw_codegen *p,
>> -   struct brw_reg mrf,
>> -   int num_regs,
>> -   unsigned offset);
>> +   struct brw_reg mrf,
>> +   int num_owords,
>> +   unsigned offset);
>>  
>>  void gen7_block_read_scratch(struct brw_codegen *p,
>>   struct brw_reg dest,
>> diff --git a/src/intel/compiler/brw_eu_emit.c 
>> b/src/intel/compiler/brw_eu_emit.c
>> index 0b0d67a5c5..956ef263a2 100644
>> --- a/src/intel/compiler/brw_eu_emit.c
>> +++ b/src/intel/compiler/brw_eu_emit.c
>> @@ -2133,9 +2133,9 @@ brw_scratch_surface_idx(const struct brw_codegen *p)
>>   * register spilling.
>>   */
>>  void brw_oword_block_write_scratch(struct brw_codegen *p,
>> -   struct brw_reg mrf,
>> -   int num_regs,
>> -   unsigned offset)
>> +   struct brw_reg mrf,
>> +   int num_owords,
>> +   unsigned offset)
>>  {
>> const struct gen_device_info *devinfo = p->devinfo;
>> const unsigned target_cache =
>> @@ -2149,7 +2149,7 @@ void brw_oword_block_write_scratch(struct brw_codegen 
>> *p,
>>  
>> mrf = retype(mrf, BRW_REGISTER_TYPE_UD);
>>  
>> -   const unsigned mlen = 1 + num_regs;
>> +   const unsigned mlen = 1 + MAX2(1, num_owords / 2);
>>  
>> /* Set up the message header.  This is g0, with g0.2 filled with
>>  * the offset.  We don't want to leave our offset around in g0 or
>> @@ -2180,6 +2180,18 @@ void brw_oword_block_write_scratch(struct brw_codegen 
>> *p,
>>int send_commit_msg;
>>struct brw_reg src_header = retype(brw_vec8_grf(0, 0),
>>   BRW_REGISTER_TYPE_UW);
>> +  int msg_control = BRW_DATAPORT_OWORD_BLOCK_DWORDS(num_owords * 4);
>> +
>> +  /* By default for 1-oword, msg_control = 
>> BRW_DATAPORT_OWORD_BLOCK_1_OWORDLOW,
>> +   * fix it when we are writing the high part.
>> +   */
>> +  if (num_owords == 1 && brw_inst_nib_control(devinfo, insn) != 0) {
>> + msg_control = BRW_DATAPORT_OWORD_BLOCK_1_OWORDHIGH;
>> + /* The messages only work with group == 0, we use the group to 
>> know which
>> +  * message emit (1-OWORD LOW or 1-OWORD HIGH), so reset it to zero.
>> +  */
>> + brw_inst_set_group(devinfo, insn, 0);
>> +  }
>>  
>>brw_inst_set_compression(devinfo, insn, false);
>>  
>> @@ -2223,7 +2235,7 @@ void brw_oword_block_write_scratch(struct brw_codegen 
>> *p,
>>brw_set_dp_write_message(p,
>> insn,
>> brw_scratch_surface_idx(p),
>> -   BRW_DATAPORT_OWORD_BLOCK_DWORDS(num_regs * 8),
>> +   msg_control,
>> msg_type,
>> target_cache,
>> mlen,
>> @@ -2245,10 +2257,10 @@ void brw_oword_block_write_scratch(struct 
>> brw_codegen *p,
>>   */
>>  void
>>  

[Mesa-dev] [Bug 102237] Request for a new account

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
Approved.  Boyuan has been doing a lot of the Mesa multimedia development work
for our team for a while now.

-- 
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 102237] Request for a new account

[bugzilla-daemon]

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

Boyuan Zhang  changed:

   What|Removed |Added

 Attachment #133531|0   |1
is obsolete||

--- Comment #2 from Boyuan Zhang  ---
Created attachment 133533
  --> https://bugs.freedesktop.org/attachment.cgi?id=133533=edit
GPG in text/plain

Re-attach GPG in text/plain format

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

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

[Francisco Jerez]

Jan Vesely  writes:

> On Sat, 2017-08-12 at 20:14 -0700, Francisco Jerez wrote:
>> Jan Vesely  writes:
>> 
>> > On Sat, 2017-08-05 at 12:34 -0700, Francisco Jerez wrote:
>> > > Francisco Jerez  writes:
>> > > 
>> > > > Jan Vesely  writes:
>> > > > 
>> > > > > Hi,
>> > > > > 
>> > > > > thanks for detailed explanation. I indeed missed the writeBuffer part
>> > > > > in specs.
>> > > > > 
>> > > > > On Wed, 2017-08-02 at 15:05 -0700, Francisco Jerez wrote:
>> > > > > > These changes are somewhat redundant and potentially
>> > > > > > performance-impacting, the reason is that in the OpenCL API,
>> > > > > > clEnqueueWrite* commands are specified to block until the memory
>> > > > > > provided by the application as origin can be reused safely (i.e. 
>> > > > > > until
>> > > > > > soft_copy_op()() runs), not necessarily until the transfer to 
>> > > > > > graphics
>> > > > > > memory has completed (which is what hard_event::wait() will wait 
>> > > > > > for).
>> > > > > > OTOH reads and maps as implemented by soft_copy_op and friends are
>> > > > > > essentially blocking so the wait() call is redundant in most cases.
>> > > > > 
>> > > > > That explains a noticeable slowdown running piglit with these 
>> > > > > changes.
>> > > > > I'm not sure about the read part though. I expected it to be 
>> > > > > basically
>> > > > > a noop, but it changes behaviour.
>> > > > 
>> > > > I think this change would have slowed you down the most whenever the
>> > > > mapping operation performed by soft_copy_op() is able to proceed
>> > > > immediately, either because the buffer is idle (so the driver doesn't
>> > > > stall on transfer_map()) *or* because the driver is trying to be smart
>> > > > and creates a bounce buffer where data can be copied into immediately
>> > > > without stalling, then inserts a pipelined GPU copy from the bounce
>> > > > buffer into the real buffer.  With this patch you will stall on the GPU
>> > > > copy regardless (and whatever other work was already on the command
>> > > > stream which might be substantial), even though it wouldn't have been
>> > > > necessary in any of these cases.
>> > > > 
>> > > > > Adding clGetEventInfo(CL_EVENT_COMMAND_EXECUTION_STATUS) after a
>> > > > > blocking read in one of the piglit tests surprisingly returns
>> > > > > CL_QUEUED.
>> > > > > 
>> > > > 
>> > > > Hmm, yeah, that seems kind of debatable behaviour, although it's
>> > > > definitely legit for writes, not quite sure for reads...  I believe the
>> > > > reason why that happens is because the CPU copy proceeds very quickly
>> > > > (due to the reasons mentioned in the last paragraph), but the 
>> > > > hard_event
>> > > > is still associated with a pipe_fence synchronous with the GPU's 
>> > > > command
>> > > > stream, so it won't get signalled until the GPU catches up.
>> > 
>> > Hi,
>> > sorry for the delay, last week was submission week...
>> > 
>> 
>> No worries.
>> 
>> > The part that I'm still missing is what kind of GPU work needs to be
>> > done after clEnqueueRead*(). I assume all necessary work is completed
>> > before I can access the data.
>> > Also CL_QUEUED status was surprising. since we performed at least some
>> > of the work (we got the data), I'd expect CL_RUNNING or CL_SUBMITTED at
>> > least.
>> > 
>> 
>> The lag is not due to GPU work that needs to be performed after the
>> clEnqueueRead call, but due to GPU work that may precede it in the
>> command stream: Because clover doesn't know when the last time was that
>> the buffer was referenced by GPU work, the event is associated with a
>> fence synchronous with the current batch (which obviously won't signal
>> before any of the GPU work that actually referenced the buffer
>> completes).  However the pipe driver has a more accurate idea of when
>> the buffer was used last, so the transfer_map() operation is likely to
>> complete more quickly than the CL event status changes to CL_COMPLETE.
>> The reason you're seeing CL_QUEUED rather than CL_SUBMITTED is because
>> the read operation didn't even need to flush the current batch, so
>> there's no fence associated with the CL event object yet.
>
> thanks. so the event is waiting for the current batch, even if the
> buffer access is done out of order. The question is, why do we use the
> fence at all? If I understood correctly mapping the buffer will be
> delayed by the pipe driver if needed, so we don't really need the
> fence. Am I missing something?
>

The current CL event object implementation needs a gallium fence object
in order to find out what status it's in and in order to implement
waiting.  The problem is that it doesn't have any fence object available
that is close "enough" to the actual GPU operation that modified the
buffer for the last time.  There are several more or less hairy ways to
improve this, e.g. using a soft_event that's manually signaled when
triggered instead of a 

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

[Thomas Hellstrom]

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

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

v2: Eliminate the drawable have_back_format member.

Signed-off-by: Thomas Hellstrom 
---
 src/loader/loader_dri3_helper.c | 62 ++---
 src/loader/loader_dri3_helper.h |  1 +
 2 files changed, 53 insertions(+), 10 deletions(-)

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

[Mesa-dev] [PATCH 8/9] loader_dri3: Support GLX_SWAP_EXCHANGE_OML

[Thomas Hellstrom]

Add support for the exchange swap method. Since we're now forcing a fake front
buffer and we exchange the back and fake front on swaps, we don't need to add
much code.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Michel Dänzer 
---
 src/loader/loader_dri3_helper.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 3434af3..55e1471 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -777,7 +777,7 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
 * The force_copy parameter is used by EGL to attempt to preserve
 * the back buffer across a call to this function.
 */
-   if (draw->swap_method == __DRI_ATTRIB_SWAP_COPY || force_copy)
+   if (draw->swap_method != __DRI_ATTRIB_SWAP_UNDEFINED || force_copy)
   draw->cur_blit_source = LOADER_DRI3_BACK_ID(draw->cur_back);
 
/* Exchange the back and fake front. Even though the server knows about 
these
@@ -1504,8 +1504,10 @@ loader_dri3_get_buffers(__DRIdrawable *driDrawable,
if (!dri3_update_drawable(driDrawable, draw))
   return false;
 
-   /* pixmaps always have front buffers */
-   if (draw->is_pixmap)
+   /* pixmaps always have front buffers.
+* Exchange swaps also mandate fake front buffers.
+*/
+   if (draw->is_pixmap || draw->swap_method == __DRI_ATTRIB_SWAP_EXCHANGE)
   buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
 
if (buffer_mask & __DRI_IMAGE_BUFFER_FRONT) {
-- 
2.7.4

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

[Mesa-dev] [PATCH 0/9] dri2: Swapbuffer update v3.

[Thomas Hellstrom]

Implement back-to-fake-front flips,
Fix EGL_BUFFER_PRESERVED path.
Implement dri3 support for GLX_SWAP_EXCHANGE_OML and GLX_SWAP_COPY_OML.

The back-to-fake-front flips will save a full buffer copy in the case of a
fake front being enabled and GLX_SWAP_UNDEFINED_OML.

Support for EGL_BUFFER_PRESERVED and GLX_SWAP_X_OML are mostly useful for
things like glretrace if traces are capured with applications relying on a
specific swapbuffer behavior.

The EGL_BUFFER_PRESERVED path previously made sure the present was done as
a copy, but there was nothing making sure that after the present,
the same back buffer was chosen.
This has now been changed so that if the previous back buffer is
idle, we reuse it. Otherwise we grab a new and copy the contents and
buffer age from the previous back buffer. Server side flips are allowed.

GLX_SWAP_COPY_OML will behave like EGL_BUFFER_PRESERVED.

GLX_SWAP_EXCHANGE_OML will behave similarly, except that we try to reuse the
previous fake front as the new back buffer if it's idle. If not, we grab
a new back buffer and copy the contents and buffer age from the old fake front.

v2:
- Split the original patch,
- Make sure we have a context for blitImage even if we don't have a
current context.
- Make sure the delayed backbuffer allocation is performed before
glXSwapBuffers, glXCopyBuffers and querying buffer age.
v3:
- squash three patches related to the same change.
- Address review comments by Michel Dänzer.

Testing done:
piglit tests/quick without regressions on svga.
A modified piglit glx-swap-exchange posted for review on the piglit list.
That test required modifying the dri2 state tracke to advertise unconditional
support for GLX_SWAP_EXCHANGE_OML
A piglit glx-swap-copy test derived from the glx-swap-exchange test.
Not posted yet.


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

[Mesa-dev] [PATCH 3/9] loader_dri3: Increase the likelyhood of reusing the current swap buffer

[Thomas Hellstrom]

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Michel Dänzer 
---
 src/loader/loader_dri3_helper.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 131c9e9..b3f0482 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -56,6 +56,9 @@ static struct loader_dri3_blit_context blit_context = {
_MTX_INITIALIZER_NP, NULL
 };
 
+static void
+dri3_flush_present_events(struct loader_dri3_drawable *draw);
+
 /**
  * Do we have blit functionality in the image blit extension?
  *
@@ -482,6 +485,9 @@ dri3_find_back(struct loader_dri3_drawable *draw)
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
 
+   /* Increase the likelyhood of reusing current buffer */
+   dri3_flush_present_events(draw);
+
for (;;) {
   for (b = 0; b < draw->num_back; b++) {
  int id = LOADER_DRI3_BACK_ID((b + draw->cur_back) % draw->num_back);
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/9] loader_dri3/glx/egl: Optionally use a blit context for blitting operations

[Thomas Hellstrom]

The code was relying on us always having a current context for client local
image blit operations. Otherwise the blit would be skipped. However,
glxSwapBuffers, for example, doesn't require a current context and that was a
common problem in the dri1 era. It seems the problem has resurfaced with dri3.

If we don't have a current context when we want to blit, try creating a private
dri context and maintain a context cache of a single context.

Signed-off-by: Thomas Hellstrom 
---
 src/egl/drivers/dri2/egl_dri2.c  |   5 +-
 src/egl/drivers/dri2/egl_dri2.h  |   2 +
 src/egl/drivers/dri2/platform_x11_dri3.c |   9 ++
 src/glx/dri3_glx.c   |   1 +
 src/loader/loader_dri3_helper.c  | 243 ++-
 src/loader/loader_dri3_helper.h  |   3 +
 6 files changed, 196 insertions(+), 67 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 975d39d..ed79e0d 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -945,8 +945,11 @@ dri2_display_destroy(_EGLDisplay *disp)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
 
-   if (dri2_dpy->own_dri_screen)
+   if (dri2_dpy->own_dri_screen) {
+  if (dri2_dpy->vtbl->close_screen_notify)
+ dri2_dpy->vtbl->close_screen_notify(disp);
   dri2_dpy->core->destroyScreen(dri2_dpy->dri_screen);
+   }
if (dri2_dpy->fd >= 0)
   close(dri2_dpy->fd);
if (dri2_dpy->driver)
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 751e7a4..f471561 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -154,6 +154,8 @@ struct dri2_egl_display_vtbl {
  EGLuint64KHR *sbc);
 
__DRIdrawable *(*get_dri_drawable)(_EGLSurface *surf);
+
+   void (*close_screen_notify)(_EGLDisplay *dpy);
 };
 
 struct dri2_egl_display
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c 
b/src/egl/drivers/dri2/platform_x11_dri3.c
index 9917498..290b150 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -401,6 +401,14 @@ dri3_get_dri_drawable(_EGLSurface *surf)
return dri3_surf->loader_drawable.dri_drawable;
 }
 
+static void
+dri3_close_screen_notify(_EGLDisplay *dpy)
+{
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
+
+   loader_dri3_close_screen(dri2_dpy->dri_screen);
+}
+
 struct dri2_egl_display_vtbl dri3_x11_display_vtbl = {
.authenticate = dri3_authenticate,
.create_window_surface = dri3_create_window_surface,
@@ -420,6 +428,7 @@ struct dri2_egl_display_vtbl dri3_x11_display_vtbl = {
.create_wayland_buffer_from_image = 
dri2_fallback_create_wayland_buffer_from_image,
.get_sync_values = dri3_get_sync_values,
.get_dri_drawable = dri3_get_dri_drawable,
+   .close_screen_notify = dri3_close_screen_notify,
 };
 
 EGLBoolean
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index dc94740..b79fec7 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -572,6 +572,7 @@ dri3_destroy_screen(struct glx_screen *base)
struct dri3_screen *psc = (struct dri3_screen *) base;
 
/* Free the direct rendering per screen data */
+   loader_dri3_close_screen(psc->driScreen);
(*psc->core->destroyScreen) (psc->driScreen);
driDestroyConfigs(psc->driver_configs);
close(psc->fd);
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 5346d07..131c9e9 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -32,6 +32,7 @@
 
 #include 
 
+#include 
 #include "loader_dri3_helper.h"
 
 /* From xmlpool/options.h, user exposed so should be stable */
@@ -40,6 +41,121 @@
 #define DRI_CONF_VBLANK_DEF_INTERVAL_1 2
 #define DRI_CONF_VBLANK_ALWAYS_SYNC 3
 
+/**
+ * A cached blit context.
+ */
+struct loader_dri3_blit_context {
+   mtx_t mtx;
+   __DRIcontext *ctx;
+   __DRIscreen *cur_screen;
+   const __DRIcoreExtension *core;
+};
+
+/* For simplicity we maintain the cache only for a single screen at a time */
+static struct loader_dri3_blit_context blit_context = {
+   _MTX_INITIALIZER_NP, NULL
+};
+
+/**
+ * Do we have blit functionality in the image blit extension?
+ *
+ * \param draw[in]  The drawable intended to blit from / to.
+ * \return  true if we have blit functionality. false otherwise.
+ */
+static bool loader_dri3_have_image_blit(const struct loader_dri3_drawable 
*draw)
+{
+   return draw->ext->image->base.version >= 9 &&
+  draw->ext->image->blitImage != NULL;
+}
+
+/**
+ * Get and lock (for use with the current thread) a dri context associated
+ * with the drawable's dri screen. The context is intended to be used with
+ * the dri image extension's blitImage method.
+ *
+ * \param draw[in]  Pointer to the drawable whose dri screen we want a
+ * dri context for.
+ * \return A dri context or NULL if context creation failed.
+ *
+ * When the caller is 

[Mesa-dev] [PATCH 4/9] loader_dri3: Honor the request to preserve back buffer content

[Thomas Hellstrom]

EGL uses the force_copy parameter to loader_dri3_swap_buffers_msc() to indicate
that it wants to preserve back buffer contents across a buffer swap.

While the loader then turns off server-side page-flipping there's nothing to
guarantee that a new backbuffer isn't chosen when EGL starts to render again,
and that buffer's content is of course undefined.

So rework the functionality:
If the client supports local blits, allow server-side page flipping and when
a new back is grabbed, if needed, blit the old back's content to the new back.
If the client doesn't support local blits, disallow server-side page-flipping
to avoid a client deadlock and then, when grabbing a new back buffer, sleep
until the old back is idle, which may take a substantial time depending on
swap interval.

Signed-off-by: Thomas Hellstrom 
---
 src/loader/loader_dri3_helper.c | 54 ++---
 src/loader/loader_dri3_helper.h |  1 +
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index b3f0482..bc7c57f 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -268,6 +268,8 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_fake_front = 0;
draw->first_init = true;
 
+   draw->cur_blit_source = -1;
+
if (draw->ext->config)
   draw->ext->config->configQueryi(draw->dri_screen,
   "vblank_mode", _mode);
@@ -484,12 +486,21 @@ dri3_find_back(struct loader_dri3_drawable *draw)
int b;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
+   int num_to_consider = draw->num_back;
 
/* Increase the likelyhood of reusing current buffer */
dri3_flush_present_events(draw);
 
+   /* Check whether we need to reuse the current back buffer as new back.
+* In that case, wait until it's not busy anymore.
+*/
+   if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source != -1) {
+  num_to_consider = 1;
+  draw->cur_blit_source = -1;
+   }
+
for (;;) {
-  for (b = 0; b < draw->num_back; b++) {
+  for (b = 0; b < num_to_consider; b++) {
  int id = LOADER_DRI3_BACK_ID((b + draw->cur_back) % draw->num_back);
  struct loader_dri3_buffer *buffer = draw->buffers[id];
 
@@ -762,6 +773,13 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
0, 0, __BLIT_FLAG_FLUSH);
}
 
+   /* If we need to preload the new back buffer, remember the source.
+* The force_copy parameter is used by EGL to attempt to preserve
+* the back buffer across a call to this function.
+*/
+   if (force_copy)
+  draw->cur_blit_source = LOADER_DRI3_BACK_ID(draw->cur_back);
+
dri3_flush_present_events(draw);
 
if (back && !draw->is_pixmap) {
@@ -800,8 +818,13 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
*/
   if (draw->swap_interval == 0)
   options |= XCB_PRESENT_OPTION_ASYNC;
-  if (force_copy)
-  options |= XCB_PRESENT_OPTION_COPY;
+
+  /* If we need to populate the new back, but need to reuse the back
+   * buffer slot due to lack of local blit capabilities, make sure
+   * the server doesn't flip and we deadlock.
+   */
+  if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source != -1)
+ options |= XCB_PRESENT_OPTION_COPY;
 
   back->busy = 1;
   back->last_swap = draw->send_sbc;
@@ -1374,6 +1397,31 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
}
dri3_fence_await(draw->conn, buffer);
 
+   /*
+* Do we need to preserve the content of a previous buffer?
+*
+* Note that this blit is needed only to avoid a wait for a buffer that
+* is currently in the flip chain or being scanned out from. That's really
+* a tradeoff. If we're ok with the wait we can reduce the number of back
+* buffers to 1 for SWAP_EXCHANGE, and 1 for SWAP_COPY,
+* but in the latter case we must disallow page-flipping.
+*/
+   if (buffer_type == loader_dri3_buffer_back &&
+   draw->cur_blit_source != -1 &&
+   draw->buffers[draw->cur_blit_source] &&
+   buffer != draw->buffers[draw->cur_blit_source]) {
+
+  struct loader_dri3_buffer *source = draw->buffers[draw->cur_blit_source];
+
+  /* Avoid flushing here. Will propably do good for tiling hardware. */
+  (void) loader_dri3_blit_image(draw,
+buffer->image,
+source->image,
+0, 0, draw->width, draw->height,
+0, 0, 0);
+  buffer->last_swap = source->last_swap;
+  draw->cur_blit_source = -1;
+   }
/* Return the requested buffer */
return buffer;
 }
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 231d39d..165c3cc 100644
--- 

[Mesa-dev] [PATCH 7/9] loader_dri3: Eliminate the back-to-fake-front copy

[Thomas Hellstrom]

Eliminate the back-to-fake-front copy by exchanging the previous back buffer
and the fake front buffer. This is a gain except when we need to preserve
the back buffer content but in that case we still typically gain by replacing
a server-side blit by a client side non-flushing blit.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Michel Dänzer 
---
 src/loader/loader_dri3_helper.c | 50 +
 1 file changed, 31 insertions(+), 19 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 67dabe0..3434af3 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -771,13 +771,6 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
 back->image,
 0, 0, back->width, back->height,
 0, 0, __BLIT_FLAG_FLUSH);
-  /* Update the fake front */
-  if (draw->have_fake_front)
- (void) loader_dri3_blit_image(draw,
-   
draw->buffers[LOADER_DRI3_FRONT_ID]->image,
-   back->image,
-   0, 0, draw->width, draw->height,
-   0, 0, __BLIT_FLAG_FLUSH);
}
 
/* If we need to preload the new back buffer, remember the source.
@@ -787,6 +780,20 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
if (draw->swap_method == __DRI_ATTRIB_SWAP_COPY || force_copy)
   draw->cur_blit_source = LOADER_DRI3_BACK_ID(draw->cur_back);
 
+   /* Exchange the back and fake front. Even though the server knows about 
these
+* buffers, it has no notion of back and fake front.
+*/
+   if (back && draw->have_fake_front) {
+  struct loader_dri3_buffer *tmp;
+
+  tmp = dri3_fake_front_buffer(draw);
+  draw->buffers[LOADER_DRI3_FRONT_ID] = back;
+  draw->buffers[LOADER_DRI3_BACK_ID(draw->cur_back)] = tmp;
+
+  if (draw->swap_method == __DRI_ATTRIB_SWAP_COPY  || force_copy)
+ draw->cur_blit_source = LOADER_DRI3_FRONT_ID;
+   }
+
dri3_flush_present_events(draw);
 
if (back && !draw->is_pixmap) {
@@ -852,21 +859,26 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable 
*draw,
  remainder, 0, NULL);
   ret = (int64_t) draw->send_sbc;
 
-  /* If there's a fake front, then copy the source back buffer
-   * to the fake front to keep it up to date. This needs
-   * to reset the fence and make future users block until
-   * the X server is done copying the bits
+  /* Schedule a server-side back-preserving blit if necessary.
+   * This happens iff all conditions below are satisfied:
+   * a) We have a fake front,
+   * b) We need to preserve the back buffer,
+   * c) We don't have local blit capabilities.
*/
-  if (draw->have_fake_front && !draw->is_different_gpu) {
- dri3_fence_reset(draw->conn, draw->buffers[LOADER_DRI3_FRONT_ID]);
- dri3_copy_area(draw->conn,
-back->pixmap,
-draw->buffers[LOADER_DRI3_FRONT_ID]->pixmap,
+  if (!loader_dri3_have_image_blit(draw) && draw->cur_blit_source != -1 &&
+  draw->cur_blit_source != LOADER_DRI3_BACK_ID(draw->cur_back)) {
+ struct loader_dri3_buffer *new_back = dri3_back_buffer(draw);
+ struct loader_dri3_buffer *src = draw->buffers[draw->cur_blit_source];
+
+ dri3_fence_reset(draw->conn, new_back);
+ dri3_copy_area(draw->conn, src->pixmap,
+new_back->pixmap,
 dri3_drawable_gc(draw),
-0, 0, 0, 0,
-draw->width, draw->height);
- dri3_fence_trigger(draw->conn, draw->buffers[LOADER_DRI3_FRONT_ID]);
+0, 0, 0, 0, draw->width, draw->height);
+ dri3_fence_trigger(draw->conn, new_back);
+ new_back->last_swap = src->last_swap;
   }
+
   xcb_flush(draw->conn);
   if (draw->stamp)
  ++(*draw->stamp);
-- 
2.7.4

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

[Mesa-dev] [PATCH] glsl/ast: update rhs in addition to the var's constant_value

[Ilia Mirkin]

We continue in the code to do some more things with the rhs, including
setting a constant initializer. If the type is wrong, this causes some
confusion down the line, leading to assertions. This makes sure that the
rhs processing continues to flow as-if the type was correct to start
with (even though the state has been marked as an error state).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101766
Signed-off-by: Ilia Mirkin 
---
 src/compiler/glsl/ast_to_hir.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index c338ad79ca..5181708852 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -4495,7 +4495,7 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
   } else {
  if (var->type->is_numeric()) {
 /* Reduce cascading errors. */
-var->constant_value = type->qualifier.flags.q.constant
+rhs = var->constant_value = type->qualifier.flags.q.constant
? ir_constant::zero(state, var->type) : NULL;
  }
   }
-- 
2.13.0

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

[Mesa-dev] [PATCH 2/2] radv: Implement bc optimize.

[Bas Nieuwenhuizen]

Seems like we actually enabled it already, but did not implement
the shader part. With this patch we do.
---
 src/amd/common/ac_nir_to_llvm.c | 30 ++
 src/amd/common/ac_nir_to_llvm.h |  1 +
 src/amd/vulkan/radv_pipeline.c  |  3 +++
 3 files changed, 34 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index bf3baf28672..137da30e947 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5009,10 +5009,40 @@ handle_vs_inputs(struct nir_to_llvm_context *ctx,
handle_vs_input_decl(ctx, variable);
 }
 
+static void
+prepare_interp_optimize(struct nir_to_llvm_context *ctx,
+struct nir_shader *nir)
+{
+   if (!ctx->options->key.fs.multisample) {
+   return;
+   }
+
+   bool uses_center = false;
+   bool uses_centroid = false;
+   nir_foreach_variable(variable, >inputs) {
+   if (glsl_get_base_type(glsl_without_array(variable->type)) != 
GLSL_TYPE_FLOAT ||
+   variable->data.sample)
+   continue;
+
+   if (variable->data.centroid)
+   uses_centroid = true;
+   else
+   uses_center = true;
+   }
+
+   if (uses_center && uses_centroid) {
+   LLVMValueRef sel = LLVMBuildICmp(ctx->builder, LLVMIntSLT, 
ctx->prim_mask, ctx->ac.i32_0, "");
+   ctx->persp_centroid = LLVMBuildSelect(ctx->builder, sel, 
ctx->persp_center, ctx->persp_centroid, "");
+   ctx->linear_centroid = LLVMBuildSelect(ctx->builder, sel, 
ctx->linear_center, ctx->linear_centroid, "");
+   }
+}
+
 static void
 handle_fs_inputs(struct nir_to_llvm_context *ctx,
  struct nir_shader *nir)
 {
+   prepare_interp_optimize(ctx, nir);
+
nir_foreach_variable(variable, >inputs)
handle_fs_input_decl(ctx, variable);
 
diff --git a/src/amd/common/ac_nir_to_llvm.h b/src/amd/common/ac_nir_to_llvm.h
index 376db1387a4..53ea238c3c9 100644
--- a/src/amd/common/ac_nir_to_llvm.h
+++ b/src/amd/common/ac_nir_to_llvm.h
@@ -60,6 +60,7 @@ struct ac_fs_variant_key {
uint32_t col_format;
uint32_t is_int8;
uint32_t is_int10;
+   uint32_t multisample : 1;
 };
 
 union ac_shader_variant_key {
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index bd5eeb776c4..75371a0be5a 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -2069,6 +2069,9 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
if (modules[MESA_SHADER_FRAGMENT]) {
union ac_shader_variant_key key = {0};
key.fs.col_format = 
pipeline->graphics.blend.spi_shader_col_format;
+   if (pCreateInfo->pMultisampleState &&
+   pCreateInfo->pMultisampleState->rasterizationSamples > 1)
+   key.fs.multisample = true;
 
if (pipeline->device->physical_device->rad_info.chip_class < VI)
radv_pipeline_compute_get_int_clamp(pCreateInfo, 
_int8, _int10);
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] i965: make sure check_and_emit_atom gets inlined

[Scott D Phillips]

Tapani Pälli  writes:
> Improves performance of 3DMark "Ice Storm Unlimited" benchmark
> by 1-2% on Apollolake (on Android-IA using clang 3.8.256229).
>
> Change is based on the performance profiling work and results
> by Aravindan Muthukumar and Yogesh Marathe.
>
> Signed-off-by: Tapani Pälli 

Ya, this makes more sense to me. Given Yogesh is happy with his
benchmark too then this is
Reviewed-by: Scott D Phillips 

> ---
>  src/mesa/drivers/dri/i965/brw_state_upload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index f38c1946df..1ae45ba2ac 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -447,7 +447,7 @@ merge_ctx_state(struct brw_context *brw,
> state->brw |= brw->ctx.NewDriverState;
>  }
>  
> -static inline void
> +static ALWAYS_INLINE void
>  check_and_emit_atom(struct brw_context *brw,
>  struct brw_state_flags *state,
>  const struct brw_tracked_state *atom)
> -- 
> 2.13.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[sroland]

From: Roland Scheidegger 

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

diff --git a/docs/features.txt b/docs/features.txt
index ace4669..6f57ec2 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -232,7 +232,7 @@ GL 4.6, GLSL 4.60
   GL_ARB_shader_group_vote  DONE (i965, nvc0, 
radeonsi)
   GL_ARB_spirv_extensions   in progress (Nicolai 
Hähnle, Ian Romanick)
   GL_ARB_texture_filter_anisotropic not started
-  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
radeonsi, softpipe)
+  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
radeonsi, llvmpipe, softpipe)
   GL_KHR_no_error   started (Timothy 
Arceri)
 
 These are the extensions cherry-picked to make GLES 3.1
diff --git a/src/gallium/drivers/llvmpipe/lp_query.c 
b/src/gallium/drivers/llvmpipe/lp_query.c
index d5ed656..6f8ce94 100644
--- a/src/gallium/drivers/llvmpipe/lp_query.c
+++ b/src/gallium/drivers/llvmpipe/lp_query.c
@@ -155,6 +155,7 @@ llvmpipe_get_query_result(struct pipe_context *pipe,
   *result = pq->num_primitives_written;
   break;
case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
   vresult->b = pq->num_primitives_generated > pq->num_primitives_written;
   break;
case PIPE_QUERY_SO_STATISTICS: {
@@ -215,6 +216,7 @@ llvmpipe_begin_query(struct pipe_context *pipe, struct 
pipe_query *q)
   pq->num_primitives_generated = 
llvmpipe->so_stats.primitives_storage_needed;
   break;
case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
   pq->num_primitives_written = llvmpipe->so_stats.num_primitives_written;
   pq->num_primitives_generated = 
llvmpipe->so_stats.primitives_storage_needed;
   break;
@@ -264,6 +266,7 @@ llvmpipe_end_query(struct pipe_context *pipe, struct 
pipe_query *q)
  llvmpipe->so_stats.primitives_storage_needed - 
pq->num_primitives_generated;
   break;
case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
   pq->num_primitives_written =
  llvmpipe->so_stats.num_primitives_written - 
pq->num_primitives_written;
   pq->num_primitives_generated =
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 6c64133..32a4050 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -270,6 +270,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_DOUBLES:
case PIPE_CAP_INT64:
case PIPE_CAP_INT64_DIVMOD:
+   case PIPE_CAP_QUERY_SO_OVERFLOW:
   return 1;
 
case PIPE_CAP_VENDOR_ID:
@@ -357,7 +358,6 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_POST_DEPTH_COVERAGE:
case PIPE_CAP_BINDLESS_TEXTURE:
case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
-   case PIPE_CAP_QUERY_SO_OVERFLOW:
case PIPE_CAP_MEMOBJ:
   return 0;
}
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] softpipe: enable PIPE_CAP_QUERY_SO_OVERFLOW

[sroland]

From: Roland Scheidegger 

The driver was supposed to support this since way before the GL spec for it
existed, albeit it was apparently broken, so fix and enable it.
---
 docs/features.txt| 2 +-
 src/gallium/drivers/softpipe/sp_query.c  | 7 ++-
 src/gallium/drivers/softpipe/sp_screen.c | 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index ac7645d..ace4669 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -232,7 +232,7 @@ GL 4.6, GLSL 4.60
   GL_ARB_shader_group_vote  DONE (i965, nvc0, 
radeonsi)
   GL_ARB_spirv_extensions   in progress (Nicolai 
Hähnle, Ian Romanick)
   GL_ARB_texture_filter_anisotropic not started
-  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
radeonsi)
+  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
radeonsi, softpipe)
   GL_KHR_no_error   started (Timothy 
Arceri)
 
 These are the extensions cherry-picked to make GLES 3.1
diff --git a/src/gallium/drivers/softpipe/sp_query.c 
b/src/gallium/drivers/softpipe/sp_query.c
index bec0116..63f6c4b 100644
--- a/src/gallium/drivers/softpipe/sp_query.c
+++ b/src/gallium/drivers/softpipe/sp_query.c
@@ -63,6 +63,7 @@ softpipe_create_query(struct pipe_context *pipe,
   type == PIPE_QUERY_TIME_ELAPSED ||
   type == PIPE_QUERY_SO_STATISTICS ||
   type == PIPE_QUERY_SO_OVERFLOW_PREDICATE ||
+  type == PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE ||
   type == PIPE_QUERY_PRIMITIVES_EMITTED ||
   type == PIPE_QUERY_PRIMITIVES_GENERATED || 
   type == PIPE_QUERY_PIPELINE_STATISTICS ||
@@ -102,7 +103,9 @@ softpipe_begin_query(struct pipe_context *pipe, struct 
pipe_query *q)
   sq->so.primitives_storage_needed = 
softpipe->so_stats.primitives_storage_needed;
   break;
case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
-  sq->end = FALSE;
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
+  sq->so.num_primitives_written = 
softpipe->so_stats.num_primitives_written;
+  sq->so.primitives_storage_needed = 
softpipe->so_stats.primitives_storage_needed;
   break;
case PIPE_QUERY_PRIMITIVES_EMITTED:
   sq->so.num_primitives_written = 
softpipe->so_stats.num_primitives_written;
@@ -153,6 +156,7 @@ softpipe_end_query(struct pipe_context *pipe, struct 
pipe_query *q)
   sq->end = os_time_get_nano();
   break;
case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
   sq->so.num_primitives_written =
  softpipe->so_stats.num_primitives_written - 
sq->so.num_primitives_written;
   sq->so.primitives_storage_needed =
@@ -230,6 +234,7 @@ softpipe_get_query_result(struct pipe_context *pipe,
   vresult->b = TRUE;
   break;
case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
+   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
   vresult->b = sq->end != 0;
   break;
case PIPE_QUERY_TIMESTAMP_DISJOINT: {
diff --git a/src/gallium/drivers/softpipe/sp_screen.c 
b/src/gallium/drivers/softpipe/sp_screen.c
index 0feef21..2988095 100644
--- a/src/gallium/drivers/softpipe/sp_screen.c
+++ b/src/gallium/drivers/softpipe/sp_screen.c
@@ -220,6 +220,8 @@ softpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
   return 31;
case PIPE_CAP_DRAW_INDIRECT:
   return 1;
+   case PIPE_CAP_QUERY_SO_OVERFLOW:
+  return 1;
 
case PIPE_CAP_VENDOR_ID:
   return 0x;
@@ -307,7 +309,6 @@ softpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_POST_DEPTH_COVERAGE:
case PIPE_CAP_BINDLESS_TEXTURE:
case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
-   case PIPE_CAP_QUERY_SO_OVERFLOW:
case PIPE_CAP_MEMOBJ:
   return 0;
case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] mesa: framebuffer refcounting with atomic ops

[Marek Olšák]

I take back my Rb.

If *ptr == fb, it will crash.

Also, it's safer to first increment the fb counter and then decrement
the *ptr counter.

Basically, copy what pipe_reference_described does.

Marek

On Tue, Aug 15, 2017 at 3:04 PM, Marek Olšák  wrote:
> Reviewed-by: Marek Olšák 
>
> Marek
>
> On Tue, Aug 15, 2017 at 2:03 PM, Tapani Pälli  wrote:
>> Signed-off-by: Tapani Pälli 
>> ---
>>  src/mesa/main/framebuffer.c | 19 +--
>>  1 file changed, 5 insertions(+), 14 deletions(-)
>>
>> Use atomic ops in same manner as for shader objects, IMO makes
>> code easier to read.
>>
>> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
>> index 039762a074..69e28c8af7 100644
>> --- a/src/mesa/main/framebuffer.c
>> +++ b/src/mesa/main/framebuffer.c
>> @@ -45,7 +45,7 @@
>>  #include "texobj.h"
>>  #include "glformats.h"
>>  #include "state.h"
>> -
>> +#include "util/u_atomic.h"
>>
>>
>>  /**
>> @@ -243,25 +243,16 @@ _mesa_reference_framebuffer_(struct gl_framebuffer 
>> **ptr,
>>  {
>> if (*ptr) {
>>/* unreference old renderbuffer */
>> -  GLboolean deleteFlag = GL_FALSE;
>>struct gl_framebuffer *oldFb = *ptr;
>> -
>> -  mtx_lock(>Mutex);
>> -  assert(oldFb->RefCount > 0);
>> -  oldFb->RefCount--;
>> -  deleteFlag = (oldFb->RefCount == 0);
>> -  mtx_unlock(>Mutex);
>> -
>> -  if (deleteFlag)
>> - oldFb->Delete(oldFb);
>> +  assert(p_atomic_read(>RefCount) > 0);
>> +  if (p_atomic_dec_zero(>RefCount))
>> +  oldFb->Delete(oldFb);
>>
>>*ptr = NULL;
>> }
>>
>> if (fb) {
>> -  mtx_lock(>Mutex);
>> -  fb->RefCount++;
>> -  mtx_unlock(>Mutex);
>> +  p_atomic_inc(>RefCount);
>>*ptr = fb;
>> }
>>  }
>> --
>> 2.13.5
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] softpipe: enable PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE

[Roland Scheidegger]

Am 15.08.2017 um 17:32 schrieb Ilia Mirkin:
> On Tue, Aug 15, 2017 at 11:27 AM,   wrote:
>> From: Roland Scheidegger 
>>
>> The driver was supposed to support this since way before the GL spec for it
>> existed, albeit it was apparently broken, so fix and enable it.
>> ---
>>  docs/features.txt| 2 +-
>>  src/gallium/drivers/softpipe/sp_query.c  | 8 +++-
>>  src/gallium/drivers/softpipe/sp_screen.c | 3 ++-
>>  3 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/features.txt b/docs/features.txt
>> index ac7645d..ace4669 100644
>> --- a/docs/features.txt
>> +++ b/docs/features.txt
>> @@ -232,7 +232,7 @@ GL 4.6, GLSL 4.60
>>GL_ARB_shader_group_vote  DONE (i965, nvc0, 
>> radeonsi)
>>GL_ARB_spirv_extensions   in progress 
>> (Nicolai Hähnle, Ian Romanick)
>>GL_ARB_texture_filter_anisotropic not started
>> -  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
>> radeonsi)
>> +  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
>> radeonsi, softpipe)
>>GL_KHR_no_error   started (Timothy 
>> Arceri)
>>
>>  These are the extensions cherry-picked to make GLES 3.1
>> diff --git a/src/gallium/drivers/softpipe/sp_query.c 
>> b/src/gallium/drivers/softpipe/sp_query.c
>> index bec0116..b174aef 100644
>> --- a/src/gallium/drivers/softpipe/sp_query.c
>> +++ b/src/gallium/drivers/softpipe/sp_query.c
>> @@ -63,6 +63,7 @@ softpipe_create_query(struct pipe_context *pipe,
>>type == PIPE_QUERY_TIME_ELAPSED ||
>>type == PIPE_QUERY_SO_STATISTICS ||
>>type == PIPE_QUERY_SO_OVERFLOW_PREDICATE ||
>> +  type == PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE ||
>>type == PIPE_QUERY_PRIMITIVES_EMITTED ||
>>type == PIPE_QUERY_PRIMITIVES_GENERATED ||
>>type == PIPE_QUERY_PIPELINE_STATISTICS ||
>> @@ -102,7 +103,10 @@ softpipe_begin_query(struct pipe_context *pipe, struct 
>> pipe_query *q)
>>sq->so.primitives_storage_needed = 
>> softpipe->so_stats.primitives_storage_needed;
>>break;
>> case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
>> -  sq->end = FALSE;
>> +   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
>> +  sq->so.num_primitives_written = 
>> softpipe->so_stats.num_primitives_written;
>> +  sq->so.primitives_storage_needed = 
>> softpipe->so_stats.primitives_storage_needed;
>> +  break;
>>break;
> 
> One break has always been enough for me...
> 

Ah yes, indeed :-).
I'll also fix the short message title...

Roland

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

Re: [Mesa-dev] [PATCH 1/2] softpipe: enable PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE

[Ilia Mirkin]

On Tue, Aug 15, 2017 at 11:27 AM,   wrote:
> From: Roland Scheidegger 
>
> The driver was supposed to support this since way before the GL spec for it
> existed, albeit it was apparently broken, so fix and enable it.
> ---
>  docs/features.txt| 2 +-
>  src/gallium/drivers/softpipe/sp_query.c  | 8 +++-
>  src/gallium/drivers/softpipe/sp_screen.c | 3 ++-
>  3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/docs/features.txt b/docs/features.txt
> index ac7645d..ace4669 100644
> --- a/docs/features.txt
> +++ b/docs/features.txt
> @@ -232,7 +232,7 @@ GL 4.6, GLSL 4.60
>GL_ARB_shader_group_vote  DONE (i965, nvc0, 
> radeonsi)
>GL_ARB_spirv_extensions   in progress (Nicolai 
> Hähnle, Ian Romanick)
>GL_ARB_texture_filter_anisotropic not started
> -  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
> radeonsi)
> +  GL_ARB_transform_feedback_overflow_query  DONE (i965/gen6+, 
> radeonsi, softpipe)
>GL_KHR_no_error   started (Timothy 
> Arceri)
>
>  These are the extensions cherry-picked to make GLES 3.1
> diff --git a/src/gallium/drivers/softpipe/sp_query.c 
> b/src/gallium/drivers/softpipe/sp_query.c
> index bec0116..b174aef 100644
> --- a/src/gallium/drivers/softpipe/sp_query.c
> +++ b/src/gallium/drivers/softpipe/sp_query.c
> @@ -63,6 +63,7 @@ softpipe_create_query(struct pipe_context *pipe,
>type == PIPE_QUERY_TIME_ELAPSED ||
>type == PIPE_QUERY_SO_STATISTICS ||
>type == PIPE_QUERY_SO_OVERFLOW_PREDICATE ||
> +  type == PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE ||
>type == PIPE_QUERY_PRIMITIVES_EMITTED ||
>type == PIPE_QUERY_PRIMITIVES_GENERATED ||
>type == PIPE_QUERY_PIPELINE_STATISTICS ||
> @@ -102,7 +103,10 @@ softpipe_begin_query(struct pipe_context *pipe, struct 
> pipe_query *q)
>sq->so.primitives_storage_needed = 
> softpipe->so_stats.primitives_storage_needed;
>break;
> case PIPE_QUERY_SO_OVERFLOW_PREDICATE:
> -  sq->end = FALSE;
> +   case PIPE_QUERY_SO_OVERFLOW_ANY_PREDICATE:
> +  sq->so.num_primitives_written = 
> softpipe->so_stats.num_primitives_written;
> +  sq->so.primitives_storage_needed = 
> softpipe->so_stats.primitives_storage_needed;
> +  break;
>break;

One break has always been enough for me...

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

Re: [Mesa-dev] [PATCH] radeonsi: disable CE by default

[Dieter Nützel]

Hello Marek,

FWIW: Tested-by: Dieter... ;-)

I saw, you've committed it all the way.

But some numbers for RX580 for you.
Not only 'very small' amount, here.

Xeon X3470, ~3 GHz, 4/8 Cores, 24 GB
with R600_DEBUG=ce

glmark2
(final result) goes _down_ by ~5,6%
single tests in the range of 2 - 8%
(worse is [texture] texture-filter=nearest) - or _better_ ;-)

Best results _ever_.

Kernel
self compiled
4.13.0-rc2-1.g7262353-default+ (amd-staging-drm-next)
and
openSUSE Kernel:stable
4.12.7-1.g7dae241-default (which show the GREATEST numbers)

So I have to figure out which optimizations the openSUSE kernel team 
use... --- Hello Jiri, Stefan?!


Congrats to the whole 'AMD (Linux) Vega Team',
very impressive numbers on day-0.
I'll hope RX5xx see some further improvements, too.

Cheers,
Dieter


Am 13.08.2017 19:27, schrieb Marek Olšák:

From: Marek Olšák 

It makes performance worse by a very small (hard to measure) amount.
We've done extensive profiling of this feature internally.

Cc: 17.1 17.2 
---
 src/gallium/drivers/radeon/r600_pipe_common.c |  1 +
 src/gallium/drivers/radeon/r600_pipe_common.h |  4 ++--
 src/gallium/drivers/radeonsi/si_pipe.c| 24 
++--

 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 0038c9a..cb4b7a4 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -768,20 +768,21 @@ static const struct debug_named_value
common_debug_options[] = {
{ "switch_on_eop", DBG_SWITCH_ON_EOP, "Program WD/IA to switch on
end-of-packet." },
{ "forcedma", DBG_FORCE_DMA, "Use asynchronous DMA for all
operations when possible." },
{ "precompile", DBG_PRECOMPILE, "Compile one shader variant at
shader creation." },
{ "nowc", DBG_NO_WC, "Disable GTT write combining" },
{ "check_vm", DBG_CHECK_VM, "Check VM faults and dump debug info." },
{ "nodcc", DBG_NO_DCC, "Disable DCC." },
{ "nodccclear", DBG_NO_DCC_CLEAR, "Disable DCC fast clear." },
{ "norbplus", DBG_NO_RB_PLUS, "Disable RB+." },
 	{ "sisched", DBG_SI_SCHED, "Enable LLVM SI Machine Instruction 
Scheduler." },

{ "mono", DBG_MONOLITHIC_SHADERS, "Use old-style monolithic shaders
compiled on demand" },
+   { "ce", DBG_CE, "Force enable the constant engine" },
{ "noce", DBG_NO_CE, "Disable the constant engine"},
 	{ "unsafemath", DBG_UNSAFE_MATH, "Enable unsafe math shader 
optimizations" },
 	{ "nodccfb", DBG_NO_DCC_FB, "Disable separate DCC on the main 
framebuffer" },


DEBUG_NAMED_VALUE_END /* must be last */
 };

 static const char* r600_get_vendor(struct pipe_screen* pscreen)
 {
return "X.Org";
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 67b3c87..14bc63e 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -58,26 +58,26 @@
 #define R600_CONTEXT_STREAMOUT_FLUSH   (1u << 0)
 /* Pipeline & streamout query controls. */
 #define R600_CONTEXT_START_PIPELINE_STATS  (1u << 1)
 #define R600_CONTEXT_STOP_PIPELINE_STATS   (1u << 2)
 #define R600_CONTEXT_PRIVATE_FLAG  (1u << 3)

 /* special primitive types */
 #define R600_PRIM_RECTANGLE_LIST   PIPE_PRIM_MAX

 /* Debug flags. */
-/* logging */
+/* logging and features */
 #define DBG_TEX(1 << 0)
 #define DBG_NIR(1 << 1)
 #define DBG_COMPUTE(1 << 2)
 #define DBG_VM (1 << 3)
-/* gap - reuse */
+#define DBG_CE (1 << 4)
 /* shader logging */
 #define DBG_FS (1 << 5)
 #define DBG_VS (1 << 6)
 #define DBG_GS (1 << 7)
 #define DBG_PS (1 << 8)
 #define DBG_CS (1 << 9)
 #define DBG_TCS(1 << 10)
 #define DBG_TES(1 << 11)
 #define DBG_NO_IR  (1 << 12)
 #define DBG_NO_TGSI(1 << 13)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 2c65cc8..cac1d01 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -194,26 +194,38 @@ static struct pipe_context
*si_create_context(struct pipe_screen *screen,
sctx->b.b.create_video_codec = si_uvd_create_decoder;
sctx->b.b.create_video_buffer = si_video_buffer_create;
} else {
sctx->b.b.create_video_codec = vl_create_decoder;
sctx->b.b.create_video_buffer = vl_video_buffer_create;
}

sctx->b.gfx.cs = ws->cs_create(sctx->b.ctx, RING_GFX,
   si_context_gfx_flush, sctx);

-   /* SI + AMDGPU + CE = GPU hang */
-   if 

Re: [Mesa-dev] [PATCH] mesa: framebuffer refcounting with atomic ops

[Timothy Arceri]

On 16/08/17 00:23, Tapani Pälli wrote:

On 08/15/2017 05:14 PM, Timothy Arceri wrote:
We seem to revisit this every few months. Please search your email for 
all the details but the short answer is this makes some race 
conditions worse. You will need to address and follow the previous 
suggestions to be able to improve locking here.




ok will take a look,

Thanks;


I think I tried to address this and failed in my last attempt with the 
patch.


mesa: only lock framebuffer in compat profile

See Fredrik's comments.




On 15/08/17 23:04, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Marek

On Tue, Aug 15, 2017 at 2:03 PM, Tapani Pälli 
 wrote:

Signed-off-by: Tapani Pälli 
---
  src/mesa/main/framebuffer.c | 19 +--
  1 file changed, 5 insertions(+), 14 deletions(-)

Use atomic ops in same manner as for shader objects, IMO makes
code easier to read.

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 039762a074..69e28c8af7 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -45,7 +45,7 @@
  #include "texobj.h"
  #include "glformats.h"
  #include "state.h"
-
+#include "util/u_atomic.h"


  /**
@@ -243,25 +243,16 @@ _mesa_reference_framebuffer_(struct 
gl_framebuffer **ptr,

  {
 if (*ptr) {
/* unreference old renderbuffer */
-  GLboolean deleteFlag = GL_FALSE;
struct gl_framebuffer *oldFb = *ptr;
-
-  mtx_lock(>Mutex);
-  assert(oldFb->RefCount > 0);
-  oldFb->RefCount--;
-  deleteFlag = (oldFb->RefCount == 0);
-  mtx_unlock(>Mutex);
-
-  if (deleteFlag)
- oldFb->Delete(oldFb);
+  assert(p_atomic_read(>RefCount) > 0);
+  if (p_atomic_dec_zero(>RefCount))
+  oldFb->Delete(oldFb);

*ptr = NULL;
 }

 if (fb) {
-  mtx_lock(>Mutex);
-  fb->RefCount++;
-  mtx_unlock(>Mutex);
+  p_atomic_inc(>RefCount);
*ptr = fb;
 }
  }
--
2.13.5

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

Re: [Mesa-dev] [PATCH] mesa: framebuffer refcounting with atomic ops

[Tapani Pälli]

On 08/15/2017 05:14 PM, Timothy Arceri wrote:
We seem to revisit this every few months. Please search your email for 
all the details but the short answer is this makes some race 
conditions worse. You will need to address and follow the previous 
suggestions to be able to improve locking here.




ok will take a look,

Thanks;


On 15/08/17 23:04, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Marek

On Tue, Aug 15, 2017 at 2:03 PM, Tapani Pälli 
 wrote:

Signed-off-by: Tapani Pälli 
---
  src/mesa/main/framebuffer.c | 19 +--
  1 file changed, 5 insertions(+), 14 deletions(-)

Use atomic ops in same manner as for shader objects, IMO makes
code easier to read.

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 039762a074..69e28c8af7 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -45,7 +45,7 @@
  #include "texobj.h"
  #include "glformats.h"
  #include "state.h"
-
+#include "util/u_atomic.h"


  /**
@@ -243,25 +243,16 @@ _mesa_reference_framebuffer_(struct 
gl_framebuffer **ptr,

  {
 if (*ptr) {
/* unreference old renderbuffer */
-  GLboolean deleteFlag = GL_FALSE;
struct gl_framebuffer *oldFb = *ptr;
-
-  mtx_lock(>Mutex);
-  assert(oldFb->RefCount > 0);
-  oldFb->RefCount--;
-  deleteFlag = (oldFb->RefCount == 0);
-  mtx_unlock(>Mutex);
-
-  if (deleteFlag)
- oldFb->Delete(oldFb);
+  assert(p_atomic_read(>RefCount) > 0);
+  if (p_atomic_dec_zero(>RefCount))
+  oldFb->Delete(oldFb);

*ptr = NULL;
 }

 if (fb) {
-  mtx_lock(>Mutex);
-  fb->RefCount++;
-  mtx_unlock(>Mutex);
+  p_atomic_inc(>RefCount);
*ptr = fb;
 }
  }
--
2.13.5

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

Re: [Mesa-dev] [PATCH] mesa: framebuffer refcounting with atomic ops

[Timothy Arceri]

We seem to revisit this every few months. Please search your email for 
all the details but the short answer is this makes some race conditions 
worse. You will need to address and follow the previous suggestions to 
be able to improve locking here.


On 15/08/17 23:04, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Marek

On Tue, Aug 15, 2017 at 2:03 PM, Tapani Pälli  wrote:

Signed-off-by: Tapani Pälli 
---
  src/mesa/main/framebuffer.c | 19 +--
  1 file changed, 5 insertions(+), 14 deletions(-)

Use atomic ops in same manner as for shader objects, IMO makes
code easier to read.

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 039762a074..69e28c8af7 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -45,7 +45,7 @@
  #include "texobj.h"
  #include "glformats.h"
  #include "state.h"
-
+#include "util/u_atomic.h"


  /**
@@ -243,25 +243,16 @@ _mesa_reference_framebuffer_(struct gl_framebuffer **ptr,
  {
 if (*ptr) {
/* unreference old renderbuffer */
-  GLboolean deleteFlag = GL_FALSE;
struct gl_framebuffer *oldFb = *ptr;
-
-  mtx_lock(>Mutex);
-  assert(oldFb->RefCount > 0);
-  oldFb->RefCount--;
-  deleteFlag = (oldFb->RefCount == 0);
-  mtx_unlock(>Mutex);
-
-  if (deleteFlag)
- oldFb->Delete(oldFb);
+  assert(p_atomic_read(>RefCount) > 0);
+  if (p_atomic_dec_zero(>RefCount))
+  oldFb->Delete(oldFb);

*ptr = NULL;
 }

 if (fb) {
-  mtx_lock(>Mutex);
-  fb->RefCount++;
-  mtx_unlock(>Mutex);
+  p_atomic_inc(>RefCount);
*ptr = fb;
 }
  }
--
2.13.5

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

Re: [Mesa-dev] [PATCH] mesa: count uniform against storage when its bindless

[Timothy Arceri]

On 15/08/17 23:07, Marek Olšák wrote:

Reviewed-by: Marek Olšák 

Marek


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

Re: [Mesa-dev] [PATCH] mesa: count uniform against storage when its bindless

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Aug 15, 2017 at 12:42 PM, Timothy Arceri  wrote:
> Gallium drivers use this code path so we need to account for
> bindless after all.
>
> Fixes:  365d34540f33 ("mesa: correctly calculate the storage offset for i915")
> ---
>  src/mesa/program/ir_to_mesa.cpp | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
> index 87999ea317..0e6a95ce99 100644
> --- a/src/mesa/program/ir_to_mesa.cpp
> +++ b/src/mesa/program/ir_to_mesa.cpp
> @@ -492,21 +492,21 @@ ir_to_mesa_visitor::src_reg_for_float(float val)
>  {
> src_reg src(PROGRAM_CONSTANT, -1, NULL);
>
> src.index = _mesa_add_unnamed_constant(this->prog->Parameters,
>   (const gl_constant_value *), 1, 
> );
>
> return src;
>  }
>
>  static int
> -type_size(const struct glsl_type *type)
> +storage_type_size(const struct glsl_type *type, bool bindless)
>  {
> unsigned int i;
> int size;
>
> switch (type->base_type) {
> case GLSL_TYPE_UINT:
> case GLSL_TYPE_INT:
> case GLSL_TYPE_FLOAT:
> case GLSL_TYPE_BOOL:
>if (type->is_matrix()) {
> @@ -534,44 +534,52 @@ type_size(const struct glsl_type *type)
>}
>break;
> case GLSL_TYPE_UINT64:
> case GLSL_TYPE_INT64:
>if (type->vector_elements > 2)
>   return 2;
>else
>   return 1;
> case GLSL_TYPE_ARRAY:
>assert(type->length > 0);
> -  return type_size(type->fields.array) * type->length;
> +  return storage_type_size(type->fields.array, bindless) * type->length;
> case GLSL_TYPE_STRUCT:
>size = 0;
>for (i = 0; i < type->length; i++) {
> -size += type_size(type->fields.structure[i].type);
> +size += storage_type_size(type->fields.structure[i].type, bindless);
>}
>return size;
> case GLSL_TYPE_SAMPLER:
> case GLSL_TYPE_IMAGE:
> -  return 0;
> +  if (!bindless)
> + return 0;
> +  /* fall through */
> case GLSL_TYPE_SUBROUTINE:
>return 1;
> case GLSL_TYPE_ATOMIC_UINT:
> case GLSL_TYPE_VOID:
> case GLSL_TYPE_ERROR:
> case GLSL_TYPE_INTERFACE:
> case GLSL_TYPE_FUNCTION:
>assert(!"Invalid type in type_size");
>break;
> }
>
> return 0;
>  }
>
> +static int
> +type_size(const struct glsl_type *type)
> +{
> +   return storage_type_size(type, false);
> +}
> +
>  /**
>   * In the initial pass of codegen, we assign temporary numbers to
>   * intermediate results.  (not SSA -- variable assignments will reuse
>   * storage).  Actual register allocation for the Mesa VM occurs in a
>   * pass over the Mesa IR later.
>   */
>  src_reg
>  ir_to_mesa_visitor::get_temp(const glsl_type *type)
>  {
> src_reg src;
> @@ -2445,21 +2453,21 @@ add_uniform_to_shader::visit_field(const glsl_type 
> *type, const char *name,
> bool /* last_field */)
>  {
> /* opaque types don't use storage in the param list unless they are
>  * bindless samplers or images.
>  */
> if (type->contains_opaque() && !var->data.bindless)
>return;
>
> assert(_mesa_lookup_parameter_index(params, name) < 0);
>
> -   unsigned size = type_size(type) * 4;
> +   unsigned size = storage_type_size(type, var->data.bindless) * 4;
>
> int index = _mesa_add_parameter(params, PROGRAM_UNIFORM, name, size,
> type->gl_type, NULL, NULL);
>
> /* The first part of the uniform that's processed determines the base
>  * location of the whole uniform (for structures).
>  */
> if (this->idx < 0)
>this->idx = index;
>  }
> --
> 2.13.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] mesa: framebuffer refcounting with atomic ops

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Aug 15, 2017 at 2:03 PM, Tapani Pälli  wrote:
> Signed-off-by: Tapani Pälli 
> ---
>  src/mesa/main/framebuffer.c | 19 +--
>  1 file changed, 5 insertions(+), 14 deletions(-)
>
> Use atomic ops in same manner as for shader objects, IMO makes
> code easier to read.
>
> diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
> index 039762a074..69e28c8af7 100644
> --- a/src/mesa/main/framebuffer.c
> +++ b/src/mesa/main/framebuffer.c
> @@ -45,7 +45,7 @@
>  #include "texobj.h"
>  #include "glformats.h"
>  #include "state.h"
> -
> +#include "util/u_atomic.h"
>
>
>  /**
> @@ -243,25 +243,16 @@ _mesa_reference_framebuffer_(struct gl_framebuffer 
> **ptr,
>  {
> if (*ptr) {
>/* unreference old renderbuffer */
> -  GLboolean deleteFlag = GL_FALSE;
>struct gl_framebuffer *oldFb = *ptr;
> -
> -  mtx_lock(>Mutex);
> -  assert(oldFb->RefCount > 0);
> -  oldFb->RefCount--;
> -  deleteFlag = (oldFb->RefCount == 0);
> -  mtx_unlock(>Mutex);
> -
> -  if (deleteFlag)
> - oldFb->Delete(oldFb);
> +  assert(p_atomic_read(>RefCount) > 0);
> +  if (p_atomic_dec_zero(>RefCount))
> +  oldFb->Delete(oldFb);
>
>*ptr = NULL;
> }
>
> if (fb) {
> -  mtx_lock(>Mutex);
> -  fb->RefCount++;
> -  mtx_unlock(>Mutex);
> +  p_atomic_inc(>RefCount);
>*ptr = fb;
> }
>  }
> --
> 2.13.5
>
> ___
> 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 02/11] loader/dri3: Make sure we always have a context for image blit operations

[Thomas Hellstrom]

Hi, Michel, Thanks for reviewing.

On 08/15/2017 08:57 AM, Michel Dänzer wrote:

On 11/08/17 11:14 PM, Thomas Hellstrom wrote:

The code was relying on us always having a current context for client local
image blit operations. Otherwise the blit would be skipped. However,
glxSwapBuffers, for example, doesn't require a current context and that was a
common problem in the dri1 era. It seems the problem has resurfaced with dri3.

If we don't have a current context when we want to blit, try creating a private
dri context and maintain a context cache of a single context.

Signed-off-by: Thomas Hellstrom 

[...]


+/**
+ * A cached blit context.
+ */
+struct loader_dri3_blit_context {
+   mtx_t mtx;
+   __DRIcontext *ctx;
+   __DRIscreen *cur_screen;

The cur_screen field seems redundant with __DRIcontextRec::driScreenPriv.


Problem is __DRIcontextRec is opaque here, so we can't access its members.





@@ -149,6 +254,9 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
 draw->have_fake_front = 0;
 draw->first_init = true;
  
+   draw->have_image_blit = draw->ext->image->base.version >= 9 &&

+  draw->ext->image->blitImage != NULL;

Is it really worth having a dedicated drawable field for this? Seems
like open-coding this in loader_dri3_blit_image should be fine.


Sure, will do.





@@ -1340,7 +1426,7 @@ loader_dri3_get_buffers(__DRIdrawable *driDrawable,
return false;
  
 /* pixmaps always have front buffers */

-   if (draw->is_pixmap)
+//   if (draw->is_pixmap)
buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;


Hmm, this shouldn't be here. It's a leftover debug thing. I'll fix it up 
to the next version.



Either leave the line uncommented, or remove it and fix up the
indentation of the following line.



Thanks,

Thomas


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

Re: [Mesa-dev] [PATCH 06/11] loader_dri3: Honour the request to preserve back buffer content

[Thomas Hellstrom]

On 08/15/2017 09:33 AM, Michel Dänzer wrote:

On 11/08/17 11:14 PM, Thomas Hellstrom wrote:

EGL uses the force_copy parameter to loader_dri3_swap_buffers_msc() to indicate
that it wants to preserve back buffer contents across a buffer swap.

While the loader then turns off server-side page-flipping there's nothing to
guarantee that a new backbuffer isn't chosen when EGL starts to render again,
and that buffer's content is of course undefined.

So rework the functionality:
If the client supports local blits, allow server-side page flipping and when
a new back is grabbed, if needed, blit the old back's content to the new back.
If the client doesn't support local blits, disallow server-side page-flipping
to avoid a client deadlock and then, when grabbing a new back buffer, sleep
until the old back is idle, which may take a substantial time depending on
swap interval.

Signed-off-by: Thomas Hellstrom 

[...]


@@ -475,12 +476,21 @@ dri3_find_back(struct loader_dri3_drawable *draw)
 int b;
 xcb_generic_event_t *ev;
 xcb_present_generic_event_t *ge;
+   int num_to_consider = draw->num_back;
  
 /* Increase the likelyhood of reusing current buffer */

 dri3_flush_present_events(draw);
  
+   /* Check whether we need to reuse the current back buffer as new back.

+* In that case, wait until it's not busy anymore.
+*/
+   if (!draw->have_image_blit && draw->cur_blit_source != -1) {
+  num_to_consider = 1;
+  draw->cur_blit_source = -1;
+   }

Is it possible that dri3_find_back gets called with
draw->cur_blit_source != -1, entering this block (assuming
!draw->have_image_blit)...



 for (;;) {
-  for (b = 0; b < draw->num_back; b++) {
+  for (b = 0; b < num_to_consider; b++) {
   int id = LOADER_DRI3_BACK_ID((b + draw->cur_back) % draw->num_back);
   struct loader_dri3_buffer *buffer = draw->buffers[id];

... Then later gets called again with draw->cur_blit_source == -1,
choosing a different back buffer here, because the previous one is still
busy?


I don't think that's possible. If dri3_find_back returns a back buffer, 
it should be idle, in the sense that it's not currently in the swap 
chain or being scanned out from. It may still have a non-signaled fence 
though. If a later call to dri_find_back() decides it's busy then 
someone must have called swapBuffer in between and it's time to change 
back anyway...


/Thomas



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

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

[Thomas Hellstrom]

On 08/15/2017 09:32 AM, Michel Dänzer wrote:

On 11/08/17 11:14 PM, Thomas Hellstrom wrote:

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

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

Signed-off-by: Thomas Hellstrom 
---
  src/loader/loader_dri3_helper.c | 64 ++---
  src/loader/loader_dri3_helper.h |  3 ++
  2 files changed, 57 insertions(+), 10 deletions(-)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index dee0df8..0440633 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -35,6 +35,7 @@
  #include 
  #include "loader_dri3_helper.h"
  
+

  /* From xmlpool/options.h, user exposed so should be stable */
  #define DRI_CONF_VBLANK_NEVER 0
  #define DRI_CONF_VBLANK_DEF_INTERVAL_0 1

Drop this hunk.


Sure.



diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index c8f63fd..b06a9ad 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -159,6 +159,9 @@ struct loader_dri3_drawable {
  
 bool have_image_blit;

 unsigned int swap_method;
+
+   bool have_back_format;
+   unsigned int back_format;
  };

Is 0 a valid value for the back_format field? If not, the
have_back_format field is redundant.



I'll see if I can eliminate that field.

Thomas


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

[Mesa-dev] [Bug 102232] gallium/svga_msg.c build failure on non-x86 with gcc 7.1

[bugzilla-daemon]

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

Timo Aaltonen  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Timo Aaltonen  ---
I guess there's no need to build svga on non-x86.. closing

-- 
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] mesa: framebuffer refcounting with atomic ops

[Tapani Pälli]

Signed-off-by: Tapani Pälli 
---
 src/mesa/main/framebuffer.c | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

Use atomic ops in same manner as for shader objects, IMO makes
code easier to read.

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 039762a074..69e28c8af7 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -45,7 +45,7 @@
 #include "texobj.h"
 #include "glformats.h"
 #include "state.h"
-
+#include "util/u_atomic.h"
 
 
 /**
@@ -243,25 +243,16 @@ _mesa_reference_framebuffer_(struct gl_framebuffer **ptr,
 {
if (*ptr) {
   /* unreference old renderbuffer */
-  GLboolean deleteFlag = GL_FALSE;
   struct gl_framebuffer *oldFb = *ptr;
-
-  mtx_lock(>Mutex);
-  assert(oldFb->RefCount > 0);
-  oldFb->RefCount--;
-  deleteFlag = (oldFb->RefCount == 0);
-  mtx_unlock(>Mutex);
-
-  if (deleteFlag)
- oldFb->Delete(oldFb);
+  assert(p_atomic_read(>RefCount) > 0);
+  if (p_atomic_dec_zero(>RefCount))
+  oldFb->Delete(oldFb);
 
   *ptr = NULL;
}
 
if (fb) {
-  mtx_lock(>Mutex);
-  fb->RefCount++;
-  mtx_unlock(>Mutex);
+  p_atomic_inc(>RefCount);
   *ptr = fb;
}
 }
-- 
2.13.5

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

[Mesa-dev] [PATCH] a2xx: only update rasterizer settings when they're there

[Ilia Mirkin]

The rasterizer being empty can happen e.g. during clears

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c 
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index af9a69e86fb..42f27d278a2 100644
--- a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
+++ b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
@@ -222,7 +222,7 @@ fd2_emit_state(struct fd_context *ctx, const enum 
fd_dirty_3d_state dirty)
OUT_RING(ring, zsa->rb_alpha_ref);
}
 
-   if (dirty & (FD_DIRTY_RASTERIZER | FD_DIRTY_FRAMEBUFFER)) {
+   if (ctx->rasterizer && dirty & FD_DIRTY_RASTERIZER) {
struct fd2_rasterizer_stateobj *rasterizer =
fd2_rasterizer_stateobj(ctx->rasterizer);
OUT_PKT3(ring, CP_SET_CONSTANT, 3);
-- 
2.13.0

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

Re: [Mesa-dev] How to write using EGLImage?

[Julien Isorce]

Hi Christian,

Thx for the suggestion. Actually I thought about dmabuf (ref project
proposal), but not about opening the EGL so using an internal mesa
function. Also eglExportDMABUFImageMESA is still tagged 'MESA'
(EGL_MESA_image_dma_buf_export). Compared to EGL_*EXT*_image_dma_buf_import
.
This need more thought so I will see later.

Also for dmabuf, 'ideally' the spec should just be improved to pass the fd
directly to OMX_UseBuffer. Some board went ahead and exposed that as a
vendor omx extension.

But so far st_omx_pipe_texture_from_eglimage_v1 mentioned in previous email
works fine (color issue is fixed now). So we will keep it like this for now.

Thx
Julien


On 13 July 2017 at 16:39, Christian König  wrote:

> Hi Julien,
>
> sorry, totally missed that question.
>
> I think the cleanest approach would be that the OpenMAX state tracker
> dlopen()s the EGL and tries to export the eglImage into a dma_buf handle.
>
> No idea how to do this, but I'm pretty sure somebody on the mailing list
> should know the details how this can be solved.
>
> Regards,
> Christian.
>
>
> Am 13.07.2017 um 14:26 schrieb Julien Isorce:
>
> Hi,
>
> With Gurkirpal we have been blocked on this problem last week and that
> would be great to get some input.
> It is not really urgent because Gurkirpal switched to the encoder work for
> the time being.
>
> So the goal is from src/gallium/state_trackers/omx, to find a way to
> retrieve the underlying struct pipe_texture given we have an EGLDisplay and
> an EGLImage as inputs. So then we can tell the decoder to use it directly.
>
> In order to help Gurkirpal, I had another go more recently and here are 2
> solutions that seems to work but not sure if this is 100 % valid (build
> deps, safe). It builds and does not crash but some feedback would be great.
> By "it works", I just mean that I can print the pipe_texture->width0 and
> height0 and values are correct. I have not tried to use the pipe_texture,
> this will be Gurkirpal's job :) and because I am not sure this is the right
> way. Note that the 2 following functions return the same pointer.
>
>
> #include "dri_screen.h"
> #include "egl_dri2.h"
>
> static struct pipe_resource *
> st_omx_pipe_texture_from_eglimage_v1(EGLDisplay egldisplay, EGLImage
> eglimage)
> {
>   _EGLDisplay *disp = egldisplay;
>   struct dri2_egl_display *dri2_egl_dpy = disp->DriverData;
>   __DRIscreen *_dri_screen = dri2_egl_dpy->dri_screen;
>   struct dri_screen *st_dri_screen = dri_screen(_dri_screen);
>   __DRIimage *_dri_image = st_dri_screen->lookup_egl_image(st_dri_screen,
> eglimage);
>
>   return _dri_image->texture;
> }
>
> static struct pipe_resource *
> st_omx_pipe_texture_from_eglimage_v2(EGLDisplay egldisplay, EGLImage
> eglimage)
> {
>   _EGLImage *img = eglimage;
>   struct dri2_egl_image *dri2_egl_img = (struct dri2_egl_image*)img;
>__DRIimage *_dri_image = dri2_egl_img->dri_image;
>
>   return _dri_image->texture;
> }
>
> And in the Makefile.am it is required to have:
>
>  AM_CFLAGS = \
> +-I$(top_srcdir)/include \
> +   -I$(top_srcdir)/src/mapi \
> +   -I$(top_srcdir)/src/mesa \
> +   -I$(top_builddir)/src/mesa/drivers/dri/common \
> +   -I$(top_srcdir)/src/mesa/drivers/dri/common \
> +   -I$(top_srcdir)/src/egl/drivers/dri2 \
> +   -I$(top_srcdir)/src/egl/main \
> +   -I$(top_srcdir)/src/gbm/main \
> +   -I$(top_srcdir)/src/loader \
> +   -I$(top_srcdir)/src/gbm/backends/dri \
> +   -I$(top_srcdir)/src/gallium/state_trackers/dri \
> $(GALLIUM_CFLAGS) \
> +   $(LIBDRM_CFLAGS) \
> $(VISIBILITY_CFLAGS) \
> $(VL_CFLAGS) \
> $(XCB_DRI3_CFLAGS) \
>
> So I wonder if this is the right approach or this should be hook up in
> vl_screen or pipe_context somehow.
> It looks to me the v1 is safer because it calls lookup_egl_image which
> seems to go all the way down and internally calls _eglCheckResource so it
> does some validity check on the input pointers.
> The v2 looks simpler but it does not even use the egldisplay pointer.
> Also I wonder if there is a way to avoid using dri2_egl_display/dri2_egl_
> image.
>
> Thx
> Julien
>
>
> On 8 July 2017 at 22:38, Gurkirpal Singh  wrote:
>
>> Hi,
>>
>> As a part of my GSoC project[1] I'm working on adding OMX_UseEGLImage
>> support in gallium/st/omx.
>>
>> I have an egl_display[1] (OMX_NATIVE_WINDOWTYPE) and the EGLImage[2] in
>> the H.264 decoder component. I'm looking some sort of method to get mesa
>> pipe screen pointer (or some other pipe structure) from the egl_display and
>> from which I can get struct pipe_surface and eglimage pointer/id.
>>
>> [1] https://summerofcode.withgoogle.com/projects/#4737166321123328
>> [2] https://github.com/gpalsingh/mesa/blob/gsoc-dev/src/
>> gallium/state_trackers/omx_tizonia/h264dprc.c#L205
>>
>> Thanks,
>> Gurkirpal
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> 

Re: [Mesa-dev] [PATCH] egl: don't NULL deref the .get_capabilities function pointer

[Tapani Pälli]

seems rare scenario indeed but there's similar check for image extension 
caps;


Reviewed-by: Tapani Pälli 

On 08/07/2017 07:23 PM, Emil Velikov wrote:

From: Emil Velikov 

One could easily introduce version 3 of the DRI2fenceExtension,
extending the struct, while not implementing the above function.

Thus we'll end up with NULL pointer, and dereferencing it won't fare
too well.

Fixes: 0201f01dc4e ("egl: add EGL_ANDROID_native_fence_sync")
Cc: Rob Clark 
Signed-off-by: Emil Velikov 
---
Yes the scenario doesn't happen too often ;-)
---
  src/egl/drivers/dri2/egl_dri2.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 936b7c5199e..69d1f8d258f 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -676,7 +676,8 @@ dri2_setup_screen(_EGLDisplay *disp)
disp->Extensions.KHR_wait_sync = EGL_TRUE;
if (dri2_dpy->fence->get_fence_from_cl_event)
   disp->Extensions.KHR_cl_event2 = EGL_TRUE;
-  if (dri2_dpy->fence->base.version >= 2) {
+  if (dri2_dpy->fence->base.version >= 2 &&
+  dri2_dpy->fence->get_capabilities) {
   unsigned capabilities =
  dri2_dpy->fence->get_capabilities(dri2_dpy->dri_screen);
   disp->Extensions.ANDROID_native_fence_sync =


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

[Mesa-dev] [Bug 102232] gallium/svga_msg.c build failure on non-x86 with gcc 7.1

[bugzilla-daemon]

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

Bug ID: 102232
   Summary: gallium/svga_msg.c build failure on non-x86 with gcc
7.1
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: tjaal...@ubuntu.com
QA Contact: mesa-dev@lists.freedesktop.org

Hi, 17.2.0-rc3/4 (probably master too) fails to build on non-x86 with gcc 7.1:

for example with arm64:
../../../../../src/gallium/drivers/svga/svga_msg.c: In function
‘svga_host_log’:
../../../../../src/gallium/drivers/svga/svga_msg.c:86:4: error: output number 4
not directly addressable
 ({ \
 
asm volatile ("inl %%dx, %%eax;" :  \
^
   "=a"(ax),\
   ~~
   "=b"(bx),\
   ~~
   "=c"(cx),\
   ~~
   "=d"(dx),\
   ~~
   "=S"(si),\
   ~~
   "=D"(di) :   \
   ~~
   "a"(magic),  \
   ~~
   "b"(in_bx),  \
   ~~
   "c"(cmd),\
   ~~
   "d"(port_num),   \
   ~~
   "S"(in_si),  \
   ~~
   "D"(in_di) : \
   ~~
   "memory");   \
   ~~
 })
 ~~  
../../../../../src/gallium/drivers/svga/svga_msg.c:298:4: note: in expansion of
macro ‘VMW_PORT’
VMW_PORT(VMW_PORT_CMD_OPEN_CHANNEL,
^~~~
../../../../../src/gallium/drivers/svga/svga_msg.c:86:4: warning: asm operand
10 probably doesn’t match constraints


full buildlogs at
https://buildd.debian.org/status/package.php?p=mesa=experimental

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

Re: [Mesa-dev] Mesa (master): mesa: correctly calculate the storage offset for i915

[Timothy Arceri]

On 15/08/17 17:04, Michel Dänzer wrote:

On 15/08/17 07:22 AM, Timothy Arceri wrote:

Module: Mesa
Branch: master
Commit: 365d34540f331df57780dddf8da87235be0a6bcb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=365d34540f331df57780dddf8da87235be0a6bcb

Author: Timothy Arceri 
Date:   Tue Aug  1 17:35:06 2017 +1000

mesa: correctly calculate the storage offset for i915

When generating the storage offset for struct members we need
to skip opaque types as they no longer have backing storage.

Fixes: fcbb93e86024 ("mesa: stop assigning unused storage for non-bindless opaque 
types")

V2: simplify since bindless will never be supported in this code


Ironically, this broke a bunch of bindless piglits with radeonsi, e.g.
spec@arb_bindless_texture@conversions:



Grrr. Yeah this is my bad. I went over this code for 30 minutes 
yesterday because I was sure we needed more than what was in the patch, 
but couldn't remember why. I forgot that the uniform path was shared by 
the st. Patch incoming.

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

Re: [Mesa-dev] [PATCH v2 1/4] st/omx_bellagio: Rename state tracker and option

[Julien Isorce]

No objection from me. Please just re-double check it builds properly. Thx!

On 14 August 2017 at 09:10, Christian König  wrote:

> Am 12.08.2017 um 18:07 schrieb Gurkirpal Singh:
>
>> Changes --enable-omx option to --enable-omx-bellagio
>>
>> Signed-off-by: Gurkirpal Singh 
>> Reviewed-and-Tested-by: Julien Isorce 
>>
>
> Acked-by: Christian König 
>
> Any objections that I push this one to master preliminary?
>
> Regards,
> Christian.
>
>
> ---
>>   configure.ac   |   49 +-
>>   src/gallium/Makefile.am|4 +-
>>   src/gallium/state_trackers/omx/Makefile.am |   35 -
>>   src/gallium/state_trackers/omx/Makefile.sources|   10 -
>>   src/gallium/state_trackers/omx/entrypoint.c|  152 ---
>>   src/gallium/state_trackers/omx/entrypoint.h|   48 -
>>   src/gallium/state_trackers/omx/vid_dec.c   |  665 --
>>   src/gallium/state_trackers/omx/vid_dec.h   |  148 ---
>>   src/gallium/state_trackers/omx/vid_dec_h264.c  | 1032
>> 
>>   src/gallium/state_trackers/omx/vid_dec_h265.c  | 1013
>> 
>>   src/gallium/state_trackers/omx/vid_dec_mpeg12.c|  383 --
>>   src/gallium/state_trackers/omx/vid_enc.c   | 1278
>> 
>>   src/gallium/state_trackers/omx/vid_enc.h   |   96 --
>>   .../state_trackers/omx_bellagio/Makefile.am|   35 +
>>   .../state_trackers/omx_bellagio/Makefile.sources   |   10 +
>>   .../state_trackers/omx_bellagio/entrypoint.c   |  152 +++
>>   .../state_trackers/omx_bellagio/entrypoint.h   |   48 +
>>   src/gallium/state_trackers/omx_bellagio/vid_dec.c  |  665 ++
>>   src/gallium/state_trackers/omx_bellagio/vid_dec.h  |  148 +++
>>   .../state_trackers/omx_bellagio/vid_dec_h264.c | 1032
>> 
>>   .../state_trackers/omx_bellagio/vid_dec_h265.c | 1013
>> 
>>   .../state_trackers/omx_bellagio/vid_dec_mpeg12.c   |  383 ++
>>   src/gallium/state_trackers/omx_bellagio/vid_enc.c  | 1278
>> 
>>   src/gallium/state_trackers/omx_bellagio/vid_enc.h  |   96 ++
>>   src/gallium/targets/omx-bellagio/Makefile.am   |   75 ++
>>   src/gallium/targets/omx-bellagio/omx.sym   |   11 +
>>   src/gallium/targets/omx-bellagio/target.c  |2 +
>>   src/gallium/targets/omx/Makefile.am|   75 --
>>   src/gallium/targets/omx/omx.sym|   11 -
>>   src/gallium/targets/omx/target.c   |2 -
>>   30 files changed, 4977 insertions(+), 4972 deletions(-)
>>   delete mode 100644 src/gallium/state_trackers/omx/Makefile.am
>>   delete mode 100644 src/gallium/state_trackers/omx/Makefile.sources
>>   delete mode 100644 src/gallium/state_trackers/omx/entrypoint.c
>>   delete mode 100644 src/gallium/state_trackers/omx/entrypoint.h
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec.h
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h264.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec_h265.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_dec_mpeg12.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_enc.c
>>   delete mode 100644 src/gallium/state_trackers/omx/vid_enc.h
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/Makefile.am
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/Makefile.sources
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/entrypoint.h
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_dec.h
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/vid_dec_h264.c
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/vid_dec_h265.c
>>   create mode 100644 src/gallium/state_trackers/omx
>> _bellagio/vid_dec_mpeg12.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.c
>>   create mode 100644 src/gallium/state_trackers/omx_bellagio/vid_enc.h
>>   create mode 100644 src/gallium/targets/omx-bellagio/Makefile.am
>>   create mode 100644 src/gallium/targets/omx-bellagio/omx.sym
>>   create mode 100644 src/gallium/targets/omx-bellagio/target.c
>>   delete mode 100644 src/gallium/targets/omx/Makefile.am
>>   delete mode 100644 src/gallium/targets/omx/omx.sym
>>   delete mode 100644 src/gallium/targets/omx/target.c
>>
>
> ___
> 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

Re: [Mesa-dev] [PATCH 5/5] radv/gfx9: fix tile swizzle handling for gfx9

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

for the series.

On Tue, Aug 15, 2017, at 07:26, Dave Airlie wrote:
> From: David Airlie 
> 
> This sets the tile swizzle up properly for gfx9.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/vulkan/radv_device.c |  7 +++
>  src/amd/vulkan/radv_image.c  | 12 +---
>  2 files changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 85ba165b4c..9bdad6ad6f 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -2983,6 +2983,7 @@ radv_initialise_color_surface(struct radv_device
> *device,
>   S_028C74_PIPE_ALIGNED(meta.pipe_aligned);
>  
>   cb->cb_color_base += iview->image->surface.u.gfx9.surf_offset 
> >> 8;
> +   cb->cb_color_base |= iview->image->surface.tile_swizzle;
>   } else {
>   const struct legacy_surf_level *level_info = 
> >u.legacy.level[iview->base_mip];
>   unsigned pitch_tile_max, slice_tile_max, tile_mode_index;
> @@ -3024,8 +3025,7 @@ radv_initialise_color_surface(struct radv_device
> *device,
>   va = device->ws->buffer_get_va(iview->bo) + iview->image->offset;
>   va += iview->image->dcc_offset;
>   cb->cb_dcc_base = va >> 8;
> -   if (device->physical_device->rad_info.chip_class < GFX9)
> -   cb->cb_dcc_base |= iview->image->surface.tile_swizzle;
> +   cb->cb_dcc_base |= iview->image->surface.tile_swizzle;
>  
>   uint32_t max_slice = radv_surface_layer_count(iview);
>   cb->cb_color_view = S_028C6C_SLICE_START(iview->base_layer) |
> @@ -3041,8 +3041,7 @@ radv_initialise_color_surface(struct radv_device
> *device,
>   if (iview->image->fmask.size) {
>   va = device->ws->buffer_get_va(iview->bo) + 
> iview->image->offset + iview->image->fmask.offset;
>   cb->cb_color_fmask = va >> 8;
> -   if (device->physical_device->rad_info.chip_class < GFX9)
> -   cb->cb_color_fmask |=
> iview->image->fmask.tile_swizzle;
> +   cb->cb_color_fmask |= iview->image->fmask.tile_swizzle;
>   } else {
>   cb->cb_color_fmask = cb->cb_color_base;
>   }
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index 7a4b2d57a5..314964d64e 100644
> --- a/src/amd/vulkan/radv_image.c
> +++ b/src/amd/vulkan/radv_image.c
> @@ -215,9 +215,9 @@ si_set_mutable_tex_desc_fields(struct radv_device
> *device,
>   va += base_level_info->offset;
>  
>   state[0] = va >> 8;
> -   if (chip_class < GFX9)
> -   if (base_level_info->mode == RADEON_SURF_MODE_2D)
> -   state[0] |= image->surface.tile_swizzle;
> +   if (chip_class >= GFX9 ||
> +   base_level_info->mode == RADEON_SURF_MODE_2D)
> +   state[0] |= image->surface.tile_swizzle;
>   state[1] &= C_008F14_BASE_ADDRESS_HI;
>   state[1] |= S_008F14_BASE_ADDRESS_HI(va >> 40);
>  
> @@ -230,8 +230,7 @@ si_set_mutable_tex_desc_fields(struct radv_device
> *device,
>   meta_va += base_level_info->dcc_offset;
>   state[6] |= S_008F28_COMPRESSION_EN(1);
>   state[7] = meta_va >> 8;
> -   if (chip_class < GFX9)
> -   state[7] |= image->surface.tile_swizzle;
> +   state[7] |= image->surface.tile_swizzle;
>   }
>   }
>  
> @@ -479,8 +478,7 @@ si_make_texture_descriptor(struct radv_device
> *device,
>   }
>  
>   fmask_state[0] = va >> 8;
> -   if (device->physical_device->rad_info.chip_class < GFX9)
> -   fmask_state[0] |= image->fmask.tile_swizzle;
> +   fmask_state[0] |= image->fmask.tile_swizzle;
>   fmask_state[1] = S_008F14_BASE_ADDRESS_HI(va >> 40) |
>   S_008F14_DATA_FORMAT_GFX6(fmask_format) |
>   S_008F14_NUM_FORMAT_GFX6(num_format);
> -- 
> 2.13.5
> 
> ___
> 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 06/11] loader_dri3: Honour the request to preserve back buffer content

[Michel Dänzer]

On 11/08/17 11:14 PM, Thomas Hellstrom wrote:
> EGL uses the force_copy parameter to loader_dri3_swap_buffers_msc() to 
> indicate
> that it wants to preserve back buffer contents across a buffer swap.
> 
> While the loader then turns off server-side page-flipping there's nothing to
> guarantee that a new backbuffer isn't chosen when EGL starts to render again,
> and that buffer's content is of course undefined.
> 
> So rework the functionality:
> If the client supports local blits, allow server-side page flipping and when
> a new back is grabbed, if needed, blit the old back's content to the new back.
> If the client doesn't support local blits, disallow server-side page-flipping
> to avoid a client deadlock and then, when grabbing a new back buffer, sleep
> until the old back is idle, which may take a substantial time depending on
> swap interval.
> 
> Signed-off-by: Thomas Hellstrom 

[...]

> @@ -475,12 +476,21 @@ dri3_find_back(struct loader_dri3_drawable *draw)
> int b;
> xcb_generic_event_t *ev;
> xcb_present_generic_event_t *ge;
> +   int num_to_consider = draw->num_back;
>  
> /* Increase the likelyhood of reusing current buffer */
> dri3_flush_present_events(draw);
>  
> +   /* Check whether we need to reuse the current back buffer as new back.
> +* In that case, wait until it's not busy anymore.
> +*/
> +   if (!draw->have_image_blit && draw->cur_blit_source != -1) {
> +  num_to_consider = 1;
> +  draw->cur_blit_source = -1;
> +   }

Is it possible that dri3_find_back gets called with
draw->cur_blit_source != -1, entering this block (assuming
!draw->have_image_blit)...


> for (;;) {
> -  for (b = 0; b < draw->num_back; b++) {
> +  for (b = 0; b < num_to_consider; b++) {
>   int id = LOADER_DRI3_BACK_ID((b + draw->cur_back) % draw->num_back);
>   struct loader_dri3_buffer *buffer = draw->buffers[id];

... Then later gets called again with draw->cur_blit_source == -1,
choosing a different back buffer here, because the previous one is still
busy?


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

Re: [Mesa-dev] Mesa (master): mesa: correctly calculate the storage offset for i915

[Michel Dänzer]

On 15/08/17 07:22 AM, Timothy Arceri wrote:
> Module: Mesa
> Branch: master
> Commit: 365d34540f331df57780dddf8da87235be0a6bcb
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=365d34540f331df57780dddf8da87235be0a6bcb
> 
> Author: Timothy Arceri 
> Date:   Tue Aug  1 17:35:06 2017 +1000
> 
> mesa: correctly calculate the storage offset for i915
> 
> When generating the storage offset for struct members we need
> to skip opaque types as they no longer have backing storage.
> 
> Fixes: fcbb93e86024 ("mesa: stop assigning unused storage for non-bindless 
> opaque types")
> 
> V2: simplify since bindless will never be supported in this code

Ironically, this broke a bunch of bindless piglits with radeonsi, e.g.
spec@arb_bindless_texture@conversions:

arb_bindless_texture-conversions: ../../src/mesa/program/prog_parameter.c:240: 
_mesa_add_parameter: Assertion `size > 0' failed.

Thread 1 "arb_bindless_te" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fb7cdba242a in __GI_abort () at abort.c:89
#2  0x7fb7cdb99e67 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x7fb7c9bb1877 "size > 0", 
file=file@entry=0x7fb7c9b30350 "../../src/mesa/program/prog_parameter.c", 
line=line@entry=240, 
function=function@entry=0x7fb7c9b303b0 <__PRETTY_FUNCTION__.36870> 
"_mesa_add_parameter") at assert.c:92
#3  0x7fb7cdb99f12 in __GI___assert_fail 
(assertion=assertion@entry=0x7fb7c9bb1877 "size > 0", 
file=file@entry=0x7fb7c9b30350 "../../src/mesa/program/prog_parameter.c", 
line=line@entry=240, 
function=function@entry=0x7fb7c9b303b0 <__PRETTY_FUNCTION__.36870> 
"_mesa_add_parameter") at assert.c:101
#4  0x7fb7c95f11e1 in _mesa_add_parameter 
(paramList=paramList@entry=0x10040fb00, type=type@entry=PROGRAM_UNIFORM, 
name=name@entry=0x100414c30 "given_tex", size=, datatype=35678, 
values=values@entry=0x0, state=0x0)
at ../../src/mesa/program/prog_parameter.c:240
#5  0x7fb7c95e18ec in (anonymous 
namespace)::add_uniform_to_shader::visit_field (this=0x7fffe130, 
type=0x7fb7c9f57aa0 , name=0x100414c30 "given_tex") 
at ../../../src/mesa/program/ir_to_mesa.cpp:2458
#6  0x7fb7c96a140c in program_resource_visitor::process 
(this=this@entry=0x7fffe130, var=var@entry=0x100414c00) at 
../../../src/compiler/glsl/link_uniforms.cpp:96
#7  0x7fb7c95e776e in (anonymous namespace)::add_uniform_to_shader::process 
(var=0x100414c00, this=0x7fffe130) at 
../../../src/mesa/program/ir_to_mesa.cpp:2422
#8  _mesa_generate_parameters_list_for_uniforms 
(shader_program=shader_program@entry=0x10041f170, sh=sh@entry=0x10040fab0, 
params=) at ../../../src/mesa/program/ir_to_mesa.cpp:2491
#9  0x7fb7c95c887b in get_mesa_program_tgsi (shader=, 
shader_program=0x10041f170, ctx=0x1003b2e20) at 
../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:6835
#10 st_link_shader (ctx=, prog=) at 
../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:7190
#11 0x7fb7c95e9018 in _mesa_glsl_link_shader (ctx=ctx@entry=0x1003b2e20, 
prog=prog@entry=0x10041f170) at ../../../src/mesa/program/ir_to_mesa.cpp:3106
#12 0x7fb7c94eadd2 in link_program (no_error=, 
shProg=, ctx=) at 
../../../src/mesa/main/shaderapi.c:1163
#13 link_program_error (ctx=0x1003b2e20, shProg=0x10041f170) at 
../../../src/mesa/main/shaderapi.c:1241
#14 0x7fb7d0ac892b in stub_glLinkProgram (program=3) at 
tests/util/piglit-dispatch-gen.c:33822
#15 0x7fb7d0b20d05 in piglit_link_simple_program (vs=1, fs=2) at 
tests/util/piglit-shader.c:262
#16 0x00011ab8 in convert_sampler_to_uvec2 (data=0x0) at 
tests/spec/arb_bindless_texture/conversions.c:162
#17 0x7fb7d05872a1 in piglit_run_selected_subtests 
(all_subtests=0x100203c00 , selected_subtests=0x0, 
num_selected_subtests=0, previous_result=PIGLIT_SKIP) at 
tests/util/piglit-util.c:779
#18 0x00012041 in piglit_init (argc=1, argv=0x7fffe658) at 
tests/spec/arb_bindless_texture/conversions.c:367
#19 0x7fb7d0b3a076 in run_test (gl_fw=0x100216c20, argc=1, 
argv=0x7fffe658) at tests/util/piglit-framework-gl/piglit_fbo_framework.c:50
#20 0x7fb7d0b201bf in piglit_gl_test_run (argc=1, argv=0x7fffe658, 
config=0x7fffe510) at tests/util/piglit-framework-gl.c:223
#21 0x00011a1c in main (argc=1, argv=0x7fffe658) at 
tests/spec/arb_bindless_texture/conversions.c:41


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

Re: [Mesa-dev] [PATCH 02/11] loader/dri3: Make sure we always have a context for image blit operations

[Michel Dänzer]

On 11/08/17 11:14 PM, Thomas Hellstrom wrote:
> The code was relying on us always having a current context for client local
> image blit operations. Otherwise the blit would be skipped. However,
> glxSwapBuffers, for example, doesn't require a current context and that was a
> common problem in the dri1 era. It seems the problem has resurfaced with dri3.
> 
> If we don't have a current context when we want to blit, try creating a 
> private
> dri context and maintain a context cache of a single context.
> 
> Signed-off-by: Thomas Hellstrom 

[...]

> +/**
> + * A cached blit context.
> + */
> +struct loader_dri3_blit_context {
> +   mtx_t mtx;
> +   __DRIcontext *ctx;
> +   __DRIscreen *cur_screen;

The cur_screen field seems redundant with __DRIcontextRec::driScreenPriv.


> @@ -149,6 +254,9 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
> draw->have_fake_front = 0;
> draw->first_init = true;
>  
> +   draw->have_image_blit = draw->ext->image->base.version >= 9 &&
> +  draw->ext->image->blitImage != NULL;

Is it really worth having a dedicated drawable field for this? Seems
like open-coding this in loader_dri3_blit_image should be fine.


> @@ -1340,7 +1426,7 @@ loader_dri3_get_buffers(__DRIdrawable *driDrawable,
>return false;
>  
> /* pixmaps always have front buffers */
> -   if (draw->is_pixmap)
> +//   if (draw->is_pixmap)
>buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;

Either leave the line uncommented, or remove it and fix up the
indentation of the following line.


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

[Mesa-dev] [PATCH] i965: make sure check_and_emit_atom gets inlined

[Tapani Pälli]

Improves performance of 3DMark "Ice Storm Unlimited" benchmark
by 1-2% on Apollolake (on Android-IA using clang 3.8.256229).

Change is based on the performance profiling work and results
by Aravindan Muthukumar and Yogesh Marathe.

Signed-off-by: Tapani Pälli 
---
 src/mesa/drivers/dri/i965/brw_state_upload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index f38c1946df..1ae45ba2ac 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -447,7 +447,7 @@ merge_ctx_state(struct brw_context *brw,
state->brw |= brw->ctx.NewDriverState;
 }
 
-static inline void
+static ALWAYS_INLINE void
 check_and_emit_atom(struct brw_context *brw,
 struct brw_state_flags *state,
 const struct brw_tracked_state *atom)
-- 
2.13.5

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