Re: [Mesa-dev] [PATCH] anv/device: Enable sample shading on gen7+

[Jason Ekstrand]

On Aug 8, 2016 4:24 PM, "Anuj Phogat"  wrote:
>
> Passes all 30 min_sample_shading tests in vulkan cts.
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/anv_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index c2c5153..b0b48ea 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -375,7 +375,7 @@ void anv_GetPhysicalDeviceFeatures(
>.independentBlend = true,
>.geometryShader   = true,
>.tessellationShader   = false,
> -  .sampleRateShading= pdevice->info->gen >=
8,
> +  .sampleRateShading= pdevice->info->gen >=
7,

We don't support Sandy Bridge and probably never will. You can just set it
to true.  With that changed,

Reviewed-by: Jason Ekstrand 

>.dualSrcBlend = true,
>.logicOp  = true,
>.multiDrawIndirect= false,
> --
> 2.5.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] dri: use 'bool' instead 'int' for boolean variables

[Michel Dänzer]

On 09/08/16 05:59 AM, ⚛ wrote:
> On Mon, Aug 8, 2016 at 7:14 PM, Ian Romanick  wrote:
>> On 08/08/2016 09:38 AM, ⚛ wrote:
>>> On Mon, Aug 8, 2016 at 6:22 PM, Ian Romanick  wrote:
 I'm pretty sure this breaks ABI.  Did you try using an unpatched libGL
 with a patched *_dri.so (and vice-versa)?
>>>
>>> Can you be more specific?
>>
>> Eh... build Mesa.  Save the libGL and *_dri.so.  Apply patch.  Build
>> again.  Run applications with LD_PRELOAD and LIBGL_DRIVERS_PATH (or
>> EGL_DRIVERS_PATH) set to mix the old and new.
> 
> - The changes to the data structures in the patch do not necessarily
> imply that mixing-unpatched-patched libs will fail because the
> alignment of fields might stay the same.

Unless sizeof(bool) == sizeof(int), it would still break ABI at least on
big endian platforms.


-- 
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 97231] GL_DEPTH_CLAMP doesn't clamp to the far plane

[bugzilla-daemon]

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

--- Comment #10 from Roland Scheidegger  ---
(In reply to Jules Blok from comment #9)
> (In reply to Roland Scheidegger from comment #8)
> > So I think you're doing something unusual. With my earlier quick look, it
> > seemed like maybe you're relying on getting the clamped values already as
> > fragcoord.z in the shader?
> 
> We don't rely on that, we explicitly do our own clamping on gl_FragCoord.z
> in the pixel shader.
Ok. Albeit I'm actually missing that in the spec, if you do use early depth
test, does that still not change the value you see in the fs?

I actually looked again at what llvmpipe really does, and now honestly I've no
idea how this passes the piglit test. The problem is that we're actually only
doing depth clamp when we write depth in the fs - otherwise that code is
skipped (and the piglit test doesn't do that). Looks incorrect to me (you still
get another clamp against a max value of a fixed 1.0 elsewhere).
I might be able to look into fixing it, though an apitrace which actually works
would be helpful.

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

[Mesa-dev] [Bug 97214] X not running with error "Failed to make EGL context current"

[bugzilla-daemon]

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

Alexandr Zelinsky  changed:

   What|Removed |Added

   Keywords|regression  |

-- 
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 97214] X not running with error "Failed to make EGL context current"

[bugzilla-daemon]

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

Alexandr Zelinsky  changed:

   What|Removed |Added

   Keywords||bisected, regression

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

[Mesa-dev] [Bug 97136] [softpipe] piglit egl-create-context-verify-gl-flavor regression

[bugzilla-daemon]

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

Alexandr Zelinsky  changed:

   What|Removed |Added

 CC||mexahota...@w1l.ru

-- 
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] Call i965 GLSL IR backend optimisation from the common linker

[Timothy Arceri]

Ping ... most of these are tidy ups and can be reviewed individually.
Also patch 13 has landed.

On Wed, 2016-07-27 at 15:20 +1000, Timothy Arceri wrote:
> The ultimate goal is to be able to convert to NIR and make use of its
> optimisations before assigning varying and uniform locations. This
> should allow us to start removing some of the GLSL IR optimisation
> passes.
> 
> This series falls short of making use of NIR because
> lower_packed_varyings()
> modifies the IR after we assign varying locations. I can see two ways
> around this, listing them in increasing difficultly level they would
> be:
> 
> - replacing the current packing pass with one that follows the
> packing
> rules of ARB_enhanced_layouts this would mean we can no longer pack
> across slots and matrix and array packing effectivness would be
> slightly
> decreased.
> - write a NIR packing pass.
> 
> Even without converting to NIR this series solves a number of the
> other
> problems with converting to NIR earlier and provides a nice shader-db
> improvement on its own.
> 
> Broadwell shader-db results:
> 
> total instructions in shared programs: 8651650 -> 8644415 (-0.08%)
> instructions in affected programs: 38754 -> 31519 (-18.67%)
> total loops in shared programs:2085 -> 2085 (0.00%)
> helped:320
> HURT:  0
> GAINED:0
> 
> Ivybridge reported no difference.
> 
> ___
> 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] nir: Add an IO scalarizing pass using the intrinsic's first_component.

[Timothy Arceri]

On Mon, 2016-08-08 at 09:18 -0700, Eric Anholt wrote:
> Timothy Arceri  writes:
> 
> > 
> > On Sat, 2016-08-06 at 10:15 +1000, Timothy Arceri wrote:
> > > 
> > > On Fri, 2016-08-05 at 16:27 -0700, Eric Anholt wrote:
> > > > 
> > > > vc4 wants to have per-scalar IO load/stores so that dead code
> > > > elimination
> > > > can happen on a more granular basis,
> > 
> > Out of interest what is it exactly that you are doing in the
> > backend? 
> 
> Given that all of my IO is done as indidivual moves of scalars (with
> the
> exception of the color output, which is weird but is lowered by vc4
> code
> anyway), I'd like to see all the scalar ops for setting up
> undefined/unused scalar slots get dropped.  I don't see much change
> from
> this, because dead code is easy to eliminate, but I think there were
> small diffs.  It also makes the output more readable by cutting the
> pointless vector ops.
> 
> However, doing my IO as scalar has been a bit of a pain for other
> passes: The UCP and twoside lowering want a single load/store for the
> vector.  Because of this, I've also wondered if using the write_mask
> and
> extending nir_opt_dce() for per-channel liveness would be a better
> way
> to go.
> 
> > 
> > I was looking at brw_do_vector_splitting() and it seems to me that
> > moving that out of the Intel backend and making it also work on
> > varyings could be benefical to all drivers as we could extend it to
> > work across stages which would hopefully also improve varying
> > packing.
> > 
> > Currently it says: 
> > 
> > "This skips vectors in uniforms and varyings, which need to be
> > accessible as vectors for their access by the GL."
> > 
> > But that really only applies to vs inputs and the outward facing
> > stages
> > of SSOs.
> 
> Yeah, I think that comment is stale at this point.  But we have a lot
> of
> that pass in NIR already (ALU, const, io), and instead of extending
> the
> GLSL IR pass I'd rather see a NIR cross-linking pass.

I've been looking at this recently and I think to do this properly we
want to be able to start disabling the GLSL IR passes and doing things
in NIR before adding cross-linking support. The big blocker I see for
this is that we need to do the optimisations and packing passes before
doing doing validation and assigning varying/uniform locations.

It seems we would need to a least have a nir version of the GLSL IR
packing pass, even more extrem but probably less hacky (e.g not having
to check NIR and remove varying/uniforms that have been eliminated)
would be to do the varying and uniform location/store assignments from
a NIR pass also.

I made some minor steps towards this with this series [1], but there is
still a while to go.


[1] https://lists.freedesktop.org/archives/mesa-dev/2016-July/124501.ht
ml  

> 
> On the topic of cross-linking: Back in the day, i965 would look at
> the
> VS outputs and propagate constants into the FS inputs.  This was
> really
> painful, slow code to maintain, and we eventually just dropped it.
> However, if we know that a VS/FS pair are non-SSO, it seems like with
> NIR we could do that propagation really easily at link time.


> ___
> 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 2/2] anv/clear: Clear E5B9G9R9 images as R32_UINT

[Jason Ekstrand]

On Mon, Aug 8, 2016 at 11:40 AM, Nanley Chery  wrote:

> On Wed, Aug 03, 2016 at 01:06:10PM -0700, Jason Ekstrand wrote:
> > We can't actually clear these images normally because we can't render to
> > them.  Instead, we have to manually unpack the rgb9e5 color value on the
> > CPU and clear it as R32_UINT.  We still have a bit of work to do to clear
> > non-power-of-two images, but this should get all of the power-of-two
> clears
> > working on at least Haswell.
>
> Could you mention which CTS tests this fixes? That would help me to test
> the correctness of this change.
>

The vulkan-cts-1.0-dev branch of the CTS has a bunch of tests to test
clearing.  This fixes 3 of the
dEQP-VK.api.image_clearing.clear_color_image.* tests


>
> >
> > Cc: "12.0" 
> > ---
> >  src/intel/vulkan/anv_meta_clear.c | 16 ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_meta_clear.c
> b/src/intel/vulkan/anv_meta_clear.c
> > index fa07ec1..d8b5ce0 100644
> > --- a/src/intel/vulkan/anv_meta_clear.c
> > +++ b/src/intel/vulkan/anv_meta_clear.c
> > @@ -25,6 +25,8 @@
> >  #include "anv_private.h"
> >  #include "nir/nir_builder.h"
> >
> > +#include "gallium/auxiliary/util/u_format_rgb9e5.h"
> > +
> >  /** Vertex attributes for color clears.  */
> >  struct color_clear_vattrs {
> > struct anv_vue_header vue_header;
> > @@ -760,6 +762,16 @@ anv_cmd_clear_image(struct anv_cmd_buffer
> *cmd_buffer,
> >  {
> > VkDevice device_h = anv_device_to_handle(cmd_buffer->device);
> >
> > +   VkFormat vk_format = image->vk_format;
> > +   if (vk_format == VK_FORMAT_E5B9G9R9_UFLOAT_PACK32) {
> > +  /* We can't actually render to this format so we have to work
> around it
> > +   * by manualy unpacking and using R32_UINT.
>
> s/manualy/manually/
>
> > +   */
> > +  clear_value.color.uint32[0] =
> > + float3_to_rgb9e5(clear_value.color.float32);
> > +  vk_format = VK_FORMAT_R32_UINT;
> > +   }
> > +
> > for (uint32_t r = 0; r < range_count; r++) {
> >const VkImageSubresourceRange *range = [r];
> >for (uint32_t l = 0; l < anv_get_levelCount(image, range); ++l) {
> > @@ -773,7 +785,7 @@ anv_cmd_clear_image(struct anv_cmd_buffer
> *cmd_buffer,
> >.sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
> >.image = anv_image_to_handle(image),
> >.viewType = anv_meta_get_view_type(image),
> > -  .format = image->vk_format,
> > +  .format = vk_format,
> >.subresourceRange = {
> >   .aspectMask = range->aspectMask,
> >   .baseMipLevel = range->baseMipLevel + l,
> > @@ -800,7 +812,7 @@ anv_cmd_clear_image(struct anv_cmd_buffer
> *cmd_buffer,
> > );
> >
> >  VkAttachmentDescription att_desc = {
> > -   .format = iview.vk_format,
> > +   .format = vk_format,
> > .loadOp = VK_ATTACHMENT_LOAD_OP_LOAD,
> > .storeOp = VK_ATTACHMENT_STORE_OP_STORE,
> > .stencilLoadOp = VK_ATTACHMENT_LOAD_OP_LOAD,
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] anv/gen7_pipeline: Set multisample state using shared function

[Jason Ekstrand]

Does this fix any tests?  If so, we should say so in the commit message.
With that updated,

Reviewed-by: Jason Ekstrand 

On Mon, Aug 8, 2016 at 2:57 PM, Anuj Phogat  wrote:

> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 16 +---
>  1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_
> pipeline.c
> index 5395e79..17d7ccc 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -81,21 +81,7 @@ genX(graphics_pipeline_create)(
>   pCreateInfo->pRasterizationState, extra);
> emit_3dstate_streamout(pipeline, pCreateInfo->pRasterizationState);
>
> -   if (pCreateInfo->pMultisampleState &&
> -   pCreateInfo->pMultisampleState->rasterizationSamples > 1)
> -  anv_finishme("VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_
> STATE_CREATE_INFO");
> -
> -   uint32_t samples = 1;
> -   uint32_t log2_samples = __builtin_ffs(samples) - 1;
> -
> -   anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
> -  ms.PixelLocation= PIXLOC_CENTER;
> -  ms.NumberofMultisamples = log2_samples;
> -   }
> -
> -   anv_batch_emit(>batch, GENX(3DSTATE_SAMPLE_MASK), sm) {
> -  sm.SampleMask = 0xff;
> -   }
> +   emit_ms_state(pipeline, pCreateInfo->pMultisampleState);
>
> const struct brw_vs_prog_data *vs_prog_data =
> get_vs_prog_data(pipeline);
>
> --
> 2.5.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 2/3] anv/pipeline: Add sample locations for gen7-7.5

[Jason Ekstrand]

I wish we could come up with some clever way to not have to repeat the
multisample positions all over the place.  Unfortunately, I don't have any
particularly fastastic ideas on how.  We can figure that out later.
Patches 1 and 2 are

Reviewed-by: Jason Ekstrand 

On Mon, Aug 8, 2016 at 2:57 PM, Anuj Phogat  wrote:

> V1: Add multisample positions (Nanley)
> V2: Fix 8x sample positions (Anuj)
>
> Signed-off-by: Anuj Phogat 
> ---
>  src/intel/vulkan/genX_pipeline_util.h | 47 ++
> +
>  1 file changed, 47 insertions(+)
>
> diff --git a/src/intel/vulkan/genX_pipeline_util.h
> b/src/intel/vulkan/genX_pipeline_util.h
> index 52d386a..621edef 100644
> --- a/src/intel/vulkan/genX_pipeline_util.h
> +++ b/src/intel/vulkan/genX_pipeline_util.h
> @@ -470,6 +470,7 @@ emit_ms_state(struct anv_pipeline *pipeline,
> anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
>ms.NumberofMultisamples   = log2_samples;
>
> +#if GEN_GEN >= 8
>/* The PRM says that this bit is valid only for DX9:
> *
> *SW can choose to set this bit only for DX9 API. DX10/OGL API's
> @@ -477,6 +478,52 @@ emit_ms_state(struct anv_pipeline *pipeline,
> */
>ms.PixelPositionOffsetEnable  = false;
>ms.PixelLocation  = CENTER;
> +#else
> +  ms.PixelLocation  = PIXLOC_CENTER;
> +
> +  switch (samples) {
> +  case 1:
> + ms.Sample0XOffset  = 0.5;
> + ms.Sample0YOffset  = 0.5;
> + break;
> +  case 2:
> + ms.Sample0XOffset  = 0.25;
> + ms.Sample0YOffset  = 0.25;
> + ms.Sample1XOffset  = 0.75;
> + ms.Sample1YOffset  = 0.75;
> + break;
> +  case 4:
> + ms.Sample0XOffset  = 0.375;
> + ms.Sample0YOffset  = 0.125;
> + ms.Sample1XOffset  = 0.875;
> + ms.Sample1YOffset  = 0.375;
> + ms.Sample2XOffset  = 0.125;
> + ms.Sample2YOffset  = 0.625;
> + ms.Sample3XOffset  = 0.625;
> + ms.Sample3YOffset  = 0.875;
> + break;
> +  case 8:
> + ms.Sample0XOffset  = 0.4375;
> + ms.Sample0YOffset  = 0.5625;
> + ms.Sample1XOffset  = 0.5625;
> + ms.Sample1YOffset  = 0.8125;
> + ms.Sample2XOffset  = 0.6875;
> + ms.Sample2YOffset  = 0.1875;
> + ms.Sample3XOffset  = 0.8125;
> + ms.Sample3YOffset  = 0.6875;
> + ms.Sample4XOffset  = 0.0625;
> + ms.Sample4YOffset  = 0.4375;
> + ms.Sample5XOffset  = 0.3125;
> + ms.Sample5YOffset  = 0.0625;
> + ms.Sample6XOffset  = 0.9375;
> + ms.Sample6YOffset  = 0.3125;
> + ms.Sample7XOffset  = 0.1875;
> + ms.Sample7YOffset  = 0.9375;
> + break;
> +  default:
> + break;
> +  }
> +#endif
> }
>
> anv_batch_emit(>batch, GENX(3DSTATE_SAMPLE_MASK), sm) {
> --
> 2.5.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/3] gallium: add render_condition_enable param to clear_render_target/depth_stencil

[Roland Scheidegger]

Am 09.08.2016 um 00:59 schrieb Marek Olšák:
> From: Marek Olšák 
> 
> ---
>  src/gallium/auxiliary/util/u_clear.h|  5 +++--
>  src/gallium/auxiliary/vl/vl_bicubic_filter.c|  2 +-
>  src/gallium/auxiliary/vl/vl_compositor.c|  2 +-
>  src/gallium/docs/source/context.rst |  7 ---
>  src/gallium/drivers/ddebug/dd_draw.c| 12 
>  src/gallium/drivers/freedreno/freedreno_draw.c  |  6 --
>  src/gallium/drivers/i915/i915_surface.c | 12 
>  src/gallium/drivers/ilo/ilo_blit.c  |  6 --
>  src/gallium/drivers/llvmpipe/lp_surface.c   |  6 --
>  src/gallium/drivers/noop/noop_pipe.c|  6 --
>  src/gallium/drivers/nouveau/nv30/nv30_clear.c   |  6 --
>  src/gallium/drivers/nouveau/nv50/nv50_surface.c | 10 ++
>  src/gallium/drivers/nouveau/nv50/nv84_video.c   |  6 +++---
>  src/gallium/drivers/nouveau/nvc0/nvc0_surface.c |  6 --
>  src/gallium/drivers/r300/r300_blit.c|  6 --
>  src/gallium/drivers/r600/r600_blit.c|  6 --
>  src/gallium/drivers/radeonsi/si_blit.c  |  6 --
>  src/gallium/drivers/rbug/rbug_context.c | 12 
>  src/gallium/drivers/softpipe/sp_surface.c   |  6 --
>  src/gallium/drivers/swr/swr_clear.cpp   |  6 --
>  src/gallium/drivers/trace/tr_context.c  | 14 ++
>  src/gallium/drivers/vc4/vc4_draw.c  |  6 --
>  src/gallium/include/pipe/p_context.h|  6 --
>  src/gallium/state_trackers/nine/device9.c   |  6 +++---
>  src/gallium/state_trackers/nine/surface9.c  |  2 +-
>  src/gallium/state_trackers/vdpau/surface.c  |  2 +-
>  26 files changed, 109 insertions(+), 61 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_clear.h 
> b/src/gallium/auxiliary/util/u_clear.h
> index 864d130..6413530 100644
> --- a/src/gallium/auxiliary/util/u_clear.h
> +++ b/src/gallium/auxiliary/util/u_clear.h
> @@ -42,22 +42,23 @@ util_clear(struct pipe_context *pipe,
> struct pipe_framebuffer_state *framebuffer, unsigned buffers,
> const union pipe_color_union *color, double depth, unsigned 
> stencil)
>  {
> unsigned i;
>  
> for (i = 0; i < framebuffer->nr_cbufs; i++) {
>if (buffers & (PIPE_CLEAR_COLOR0 << i)) {
>   struct pipe_surface *ps = framebuffer->cbufs[i];
>  
>   if (ps) {
> -pipe->clear_render_target(pipe, ps, color, 0, 0, ps->width, 
> ps->height);
> +pipe->clear_render_target(pipe, ps, color, 0, 0, ps->width,
> +  ps->height, true);
>   }
>}
> }
>  
> if (buffers & PIPE_CLEAR_DEPTHSTENCIL) {
>struct pipe_surface *ps = framebuffer->zsbuf;
>pipe->clear_depth_stencil(pipe, ps, buffers & PIPE_CLEAR_DEPTHSTENCIL,
>  depth, stencil,
> -0, 0, ps->width, ps->height);
> +0, 0, ps->width, ps->height, true);
> }
>  }
> diff --git a/src/gallium/auxiliary/vl/vl_bicubic_filter.c 
> b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
> index 51a0019..0364d43 100644
> --- a/src/gallium/auxiliary/vl/vl_bicubic_filter.c
> +++ b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
> @@ -433,21 +433,21 @@ vl_bicubic_filter_render(struct vl_bicubic_filter 
> *filter,
> pipe_buffer_unmap(filter->pipe, buf_transfer);
>  
> memset(_state, 0, sizeof(fb_state));
> fb_state.width = dst->width;
> fb_state.height = dst->height;
> fb_state.nr_cbufs = 1;
> fb_state.cbufs[0] = dst;
>  
> filter->pipe->set_scissor_states(filter->pipe, 0, 1, );
> filter->pipe->clear_render_target(filter->pipe, dst, _color,
> - 0, 0, dst->width, dst->height);
> + 0, 0, dst->width, dst->height, false);
> pipe_set_constant_buffer(filter->pipe, PIPE_SHADER_FRAGMENT, 0, 
> surface_size);
> filter->pipe->bind_rasterizer_state(filter->pipe, filter->rs_state);
> filter->pipe->bind_blend_state(filter->pipe, filter->blend);
> filter->pipe->bind_sampler_states(filter->pipe, PIPE_SHADER_FRAGMENT,
>   0, 1, >sampler);
> filter->pipe->set_sampler_views(filter->pipe, PIPE_SHADER_FRAGMENT,
> 0, 1, );
> filter->pipe->bind_vs_state(filter->pipe, filter->vs);
> filter->pipe->bind_fs_state(filter->pipe, filter->fs);
> filter->pipe->set_framebuffer_state(filter->pipe, _state);
> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
> b/src/gallium/auxiliary/vl/vl_compositor.c
> index f7517f3..03a0a64 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor.c
> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
> @@ -1161,21 +1161,21 @@ vl_compositor_render(struct vl_compositor_state *s,
>s->scissor.maxy = dst_surface->height;
> }
> 

[Mesa-dev] [PATCH] anv/device: Enable sample shading on gen7+

[Anuj Phogat]

Passes all 30 min_sample_shading tests in vulkan cts.

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/anv_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index c2c5153..b0b48ea 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -375,7 +375,7 @@ void anv_GetPhysicalDeviceFeatures(
   .independentBlend = true,
   .geometryShader   = true,
   .tessellationShader   = false,
-  .sampleRateShading= pdevice->info->gen >= 8,
+  .sampleRateShading= pdevice->info->gen >= 7,
   .dualSrcBlend = true,
   .logicOp  = true,
   .multiDrawIndirect= false,
-- 
2.5.5

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

Re: [Mesa-dev] [PATCH] st/mesa: define ST_NEW_ flags as uint64_t values, not enums

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, Aug 9, 2016 at 12:41 AM, Brian Paul  wrote:
> MSVC doesn't support 64-bit enum values, at least not with C code.
> The compiler was warning:
>
> c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(43) : 
> warning
>  C4309: 'initializing' : truncation of constant value
> c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(44) : 
> warning
>  C4309: 'initializing' : truncation of constant value
> ...
>
> And at runtime we crashed since the high 32-bits of the 'dirty' bitmask
> was always 0x and the 32+u_bit_scan() index went out of bounds of
> the atoms[] array.
> ---
>  src/mesa/state_tracker/st_atom.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom.h 
> b/src/mesa/state_tracker/st_atom.h
> index febd7ce..971ea35 100644
> --- a/src/mesa/state_tracker/st_atom.h
> +++ b/src/mesa/state_tracker/st_atom.h
> @@ -68,12 +68,12 @@ enum {
>  #undef ST_STATE
>  };
>
> -/* Define ST_NEW_xxx */
> -enum {
> -#define ST_STATE(FLAG, st_update) FLAG = 1llu << FLAG##_INDEX,
> +/* Define ST_NEW_xxx values as static const uint64_t values.
> + * We can't use an enum type because MSVC doesn't allow 64-bit enum values.
> + */
> +#define ST_STATE(FLAG, st_update) static const uint64_t FLAG = 1llu << 
> FLAG##_INDEX;
>  #include "st_atom_list.h"
>  #undef ST_STATE
> -};
>
>  /* Add extern struct declarations. */
>  #define ST_STATE(FLAG, st_update) extern const struct st_tracked_state 
> st_update;
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] gallium: Add c99_compat.h to u_bitcast.h

[Brian Paul]

On 08/08/2016 08:37 AM, Mathias Fröhlich wrote:

Brian,

On Monday, 8 August 2016 08:27:40 CEST Brian Paul wrote:

 > On 08/06/2016 12:42 AM, mathias.froehl...@gmx.net wrote:

 > > From: Mathias Fröhlich 

 > >

 > > We need this for 'inline'.

 > >

 > > Signed-off-by: Mathias Fröhlich 

 > > ---

 > > src/gallium/auxiliary/util/u_bitcast.h | 2 ++

 > > 1 file changed, 2 insertions(+)

 > >

 > > diff --git a/src/gallium/auxiliary/util/u_bitcast.h
b/src/gallium/auxiliary/util/u_bitcast.h

 > > index b1f9938..e8fb0fe 100644

 > > --- a/src/gallium/auxiliary/util/u_bitcast.h

 > > +++ b/src/gallium/auxiliary/util/u_bitcast.h

 > > @@ -30,6 +30,8 @@

 > >

 > > #include 

 > >

 > > +#include "c99_compat.h"

 > > +

 > > #ifdef __cplusplus

 > > extern "C" {

 > > #endif

 > >

 >

 > Shouldn't this get squashed into patch 1?

No, i don't think so.

Patch 1 is about src/util/bitscan.h.


You're right.  I was hasty.  I had applied your patch series, tried to 
compile it and then hit the issue.  It turns out that I actually have 
this issue even without any of your patches applied (I didn't check that 
before).


I don't know why my local build is failing while appveyor and our 
in-house automated build seem OK.  But applying your patch 3 alone fixes 
things for me.





The series did so far *not* touch

src/gallium/auxiliary/util/u_bitcast.h at all.

I just put that there since you seem to have stepped onto

that. And it appeared to me that I kindly asked for testing

that seems to be hold back by that unrelated compile failure.

And if in the end your compile is fixed with my pending push

both will be happy then. Right?


Yeah, I applied your whole series and the MSVC build seems OK.  However, 
I'm hitting a new runtime crash (even after fixing the unrelated issue 
from Marek's rewrite of the state tracker validation code).  It looks 
like patch 2/3 is the problem.  I'll try to dig deeper tomorrow...


-Brian

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

Re: [Mesa-dev] [PATCH 43/95] i965/disasm: print NibCtrl for instructions with execsize 4

[Francisco Jerez]

Iago Toral Quiroga  writes:

> ---
>  src/mesa/drivers/dri/i965/brw_disasm.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c 
> b/src/mesa/drivers/dri/i965/brw_disasm.c
> index c8bdeab..d5e9916 100644
> --- a/src/mesa/drivers/dri/i965/brw_disasm.c
> +++ b/src/mesa/drivers/dri/i965/brw_disasm.c
> @@ -1169,7 +1169,13 @@ qtr_ctrl(FILE *file, const struct brw_device_info 
> *devinfo, brw_inst *inst)
> int qtr_ctl = brw_inst_qtr_control(devinfo, inst);
> int exec_size = 1 << brw_inst_exec_size(devinfo, inst);
>  
> -   if (exec_size == 8) {
> +   if (exec_size == 4) {

I guess it wouldn't hurt to show this for exec_size < 4 too even though
it will typically be 1N.

> +  int nib_ctl = brw_inst_nib_control(devinfo, inst);

This may cause an assertion failure on SNB and earlier because the
NibCtrl field doesn't exist.  You could do something along the lines of:

| const unsigned nib_ctl = devinfo->gen < 7 ? 0 :
|  brw_inst_nib_control(devinfo, inst);

> +  if (nib_ctl == 0)
> + string(file, " 1N");
> +  else
> + string(file, " 2N");

The usual qtr_ctl field is still taken into account by the hardware
regardless of whether you use NibCtrl, this should probably be:

| format(file, " %dN", qtr_ctl * 2 + nib_ctl + 1);

> +   } else if (exec_size == 8) {
>switch (qtr_ctl) {
>case 0:
>   string(file, " 1Q");
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH 1/3] gallium: add render_condition_enable param to clear_render_target/depth_stencil

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/auxiliary/util/u_clear.h|  5 +++--
 src/gallium/auxiliary/vl/vl_bicubic_filter.c|  2 +-
 src/gallium/auxiliary/vl/vl_compositor.c|  2 +-
 src/gallium/docs/source/context.rst |  7 ---
 src/gallium/drivers/ddebug/dd_draw.c| 12 
 src/gallium/drivers/freedreno/freedreno_draw.c  |  6 --
 src/gallium/drivers/i915/i915_surface.c | 12 
 src/gallium/drivers/ilo/ilo_blit.c  |  6 --
 src/gallium/drivers/llvmpipe/lp_surface.c   |  6 --
 src/gallium/drivers/noop/noop_pipe.c|  6 --
 src/gallium/drivers/nouveau/nv30/nv30_clear.c   |  6 --
 src/gallium/drivers/nouveau/nv50/nv50_surface.c | 10 ++
 src/gallium/drivers/nouveau/nv50/nv84_video.c   |  6 +++---
 src/gallium/drivers/nouveau/nvc0/nvc0_surface.c |  6 --
 src/gallium/drivers/r300/r300_blit.c|  6 --
 src/gallium/drivers/r600/r600_blit.c|  6 --
 src/gallium/drivers/radeonsi/si_blit.c  |  6 --
 src/gallium/drivers/rbug/rbug_context.c | 12 
 src/gallium/drivers/softpipe/sp_surface.c   |  6 --
 src/gallium/drivers/swr/swr_clear.cpp   |  6 --
 src/gallium/drivers/trace/tr_context.c  | 14 ++
 src/gallium/drivers/vc4/vc4_draw.c  |  6 --
 src/gallium/include/pipe/p_context.h|  6 --
 src/gallium/state_trackers/nine/device9.c   |  6 +++---
 src/gallium/state_trackers/nine/surface9.c  |  2 +-
 src/gallium/state_trackers/vdpau/surface.c  |  2 +-
 26 files changed, 109 insertions(+), 61 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_clear.h 
b/src/gallium/auxiliary/util/u_clear.h
index 864d130..6413530 100644
--- a/src/gallium/auxiliary/util/u_clear.h
+++ b/src/gallium/auxiliary/util/u_clear.h
@@ -42,22 +42,23 @@ util_clear(struct pipe_context *pipe,
struct pipe_framebuffer_state *framebuffer, unsigned buffers,
const union pipe_color_union *color, double depth, unsigned stencil)
 {
unsigned i;
 
for (i = 0; i < framebuffer->nr_cbufs; i++) {
   if (buffers & (PIPE_CLEAR_COLOR0 << i)) {
  struct pipe_surface *ps = framebuffer->cbufs[i];
 
  if (ps) {
-pipe->clear_render_target(pipe, ps, color, 0, 0, ps->width, 
ps->height);
+pipe->clear_render_target(pipe, ps, color, 0, 0, ps->width,
+  ps->height, true);
  }
   }
}
 
if (buffers & PIPE_CLEAR_DEPTHSTENCIL) {
   struct pipe_surface *ps = framebuffer->zsbuf;
   pipe->clear_depth_stencil(pipe, ps, buffers & PIPE_CLEAR_DEPTHSTENCIL,
 depth, stencil,
-0, 0, ps->width, ps->height);
+0, 0, ps->width, ps->height, true);
}
 }
diff --git a/src/gallium/auxiliary/vl/vl_bicubic_filter.c 
b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
index 51a0019..0364d43 100644
--- a/src/gallium/auxiliary/vl/vl_bicubic_filter.c
+++ b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
@@ -433,21 +433,21 @@ vl_bicubic_filter_render(struct vl_bicubic_filter *filter,
pipe_buffer_unmap(filter->pipe, buf_transfer);
 
memset(_state, 0, sizeof(fb_state));
fb_state.width = dst->width;
fb_state.height = dst->height;
fb_state.nr_cbufs = 1;
fb_state.cbufs[0] = dst;
 
filter->pipe->set_scissor_states(filter->pipe, 0, 1, );
filter->pipe->clear_render_target(filter->pipe, dst, _color,
- 0, 0, dst->width, dst->height);
+ 0, 0, dst->width, dst->height, false);
pipe_set_constant_buffer(filter->pipe, PIPE_SHADER_FRAGMENT, 0, 
surface_size);
filter->pipe->bind_rasterizer_state(filter->pipe, filter->rs_state);
filter->pipe->bind_blend_state(filter->pipe, filter->blend);
filter->pipe->bind_sampler_states(filter->pipe, PIPE_SHADER_FRAGMENT,
  0, 1, >sampler);
filter->pipe->set_sampler_views(filter->pipe, PIPE_SHADER_FRAGMENT,
0, 1, );
filter->pipe->bind_vs_state(filter->pipe, filter->vs);
filter->pipe->bind_fs_state(filter->pipe, filter->fs);
filter->pipe->set_framebuffer_state(filter->pipe, _state);
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index f7517f3..03a0a64 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -1161,21 +1161,21 @@ vl_compositor_render(struct vl_compositor_state *s,
   s->scissor.maxy = dst_surface->height;
}
c->pipe->set_scissor_states(c->pipe, 0, 1, >scissor);
 
gen_vertex_data(c, s, dirty_area);
 
if (clear_dirty && dirty_area &&
(dirty_area->x0 < dirty_area->x1 || dirty_area->y0 < dirty_area->y1)) {
 
   

[Mesa-dev] [PATCH 3/3] gallium/radeon: implement ARB_clear_texture (v3)

[Marek Olšák]

From: Marek Olšák 

Some ideas copied from Jakob Sinclair's implementation, but the color
clearing is completely different.

v2: remove leftover code, disable conditional rendering
disable render condition cleanly
---
 docs/GL3.txt  |  2 +-
 docs/relnotes/12.1.0.html |  1 +
 src/gallium/drivers/r600/r600_pipe.c  |  2 +-
 src/gallium/drivers/radeon/r600_texture.c | 67 +++
 src/gallium/drivers/radeonsi/si_pipe.c|  2 +-
 5 files changed, 71 insertions(+), 3 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index c185c69..5dcfc31 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -185,21 +185,21 @@ GL 4.3, GLSL 4.30 -- all DONE: nvc0, radeonsi
   GL_ARB_texture_query_levels   DONE (all drivers that 
support GLSL 1.30)
   GL_ARB_texture_storage_multisampleDONE (all drivers that 
support GL_ARB_texture_multisample)
   GL_ARB_texture_view   DONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_attrib_binding  DONE (all drivers)
 
 
 GL 4.4, GLSL 4.40:
 
   GL_MAX_VERTEX_ATTRIB_STRIDE   DONE (all drivers)
   GL_ARB_buffer_storage DONE (i965, nv50, 
nvc0, r600, radeonsi)
-  GL_ARB_clear_texture  DONE (i965, nv50, nvc0)
+  GL_ARB_clear_texture  DONE (i965, nv50, 
nvc0, r600, radeonsi)
   GL_ARB_enhanced_layouts   DONE (i965)
   - compile-time constant expressions   DONE
   - explicit byte offsets for blocksDONE
   - forced alignment within blocks  DONE
   - specified vec4-slot component numbers   DONE (i965)
   - specified transform/feedback layout DONE
   - input/output block locationsDONE
   GL_ARB_multi_bind DONE (all drivers)
   GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0)
   GL_ARB_texture_mirror_clamp_to_edge   DONE (i965, nv50, 
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html
index 3935bb0..ed98d13 100644
--- a/docs/relnotes/12.1.0.html
+++ b/docs/relnotes/12.1.0.html
@@ -37,20 +37,21 @@ TBD.
 
 
 
 New features
 
 
 Note: some of the new features are only available with certain drivers.
 
 
 
+GL_ARB_clear_texture on r600, radeonsi
 GL_ARB_enhanced_layouts on i965
 GL_ARB_shader_group_vote on nvc0
 GL_ARB_ES3_1_compatibility on i965
 GL_EXT_window_rectangles on nv50, nvc0
 GL_KHR_texture_compression_astc_sliced_3d on i965
 
 
 Bug fixes
 
 TBD.
diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index 39a310a..5f69a5d 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -276,20 +276,21 @@ static int r600_get_param(struct pipe_screen* pscreen, 
enum pipe_cap param)
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR:
case PIPE_CAP_TGSI_TXQS:
case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
case PIPE_CAP_INVALIDATE_BUFFER:
case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
case PIPE_CAP_QUERY_MEMORY_INFO:
case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
+   case PIPE_CAP_CLEAR_TEXTURE:
return 1;
 
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
return rscreen->b.info.drm_major == 2 && 
rscreen->b.info.drm_minor >= 43;
 
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
return !R600_BIG_ENDIAN && rscreen->b.info.has_userptr;
 
case PIPE_CAP_COMPUTE:
return rscreen->b.chip_class > R700;
@@ -348,21 +349,20 @@ static int r600_get_param(struct pipe_screen* pscreen, 
enum pipe_cap param)
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
case PIPE_CAP_VERTEX_COLOR_CLAMPED:
case PIPE_CAP_USER_VERTEX_BUFFERS:
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
case PIPE_CAP_VERTEXID_NOBASE:
case PIPE_CAP_DEPTH_BOUNDS_TEST:
case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
case PIPE_CAP_SHAREABLE_SHADERS:
-   case PIPE_CAP_CLEAR_TEXTURE:
case PIPE_CAP_DRAW_PARAMETERS:
case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
case PIPE_CAP_MULTI_DRAW_INDIRECT:
case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
case PIPE_CAP_GENERATE_MIPMAP:
case 

[Mesa-dev] [PATCH 2/3] gallium/radeon: handle render_condition_enable for clear_rt/ds

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/r300/r300_blit.c   | 6 --
 src/gallium/drivers/r600/r600_blit.c   | 6 --
 src/gallium/drivers/radeonsi/si_blit.c | 6 --
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/r300/r300_blit.c 
b/src/gallium/drivers/r300/r300_blit.c
index cfb3f6d..b5c3ae5 100644
--- a/src/gallium/drivers/r300/r300_blit.c
+++ b/src/gallium/drivers/r300/r300_blit.c
@@ -428,21 +428,22 @@ static void r300_clear(struct pipe_context* pipe,
 /* Clear a region of a color surface to a constant value. */
 static void r300_clear_render_target(struct pipe_context *pipe,
  struct pipe_surface *dst,
  const union pipe_color_union *color,
  unsigned dstx, unsigned dsty,
  unsigned width, unsigned height,
  bool render_condition_enabled)
 {
 struct r300_context *r300 = r300_context(pipe);
 
-r300_blitter_begin(r300, R300_CLEAR_SURFACE);
+r300_blitter_begin(r300, R300_CLEAR_SURFACE |
+   (render_condition_enabled ? 0 : 
R300_IGNORE_RENDER_COND));
 util_blitter_clear_render_target(r300->blitter, dst, color,
  dstx, dsty, width, height);
 r300_blitter_end(r300);
 }
 
 /* Clear a region of a depth stencil surface. */
 static void r300_clear_depth_stencil(struct pipe_context *pipe,
  struct pipe_surface *dst,
  unsigned clear_flags,
  double depth,
@@ -455,21 +456,22 @@ static void r300_clear_depth_stencil(struct pipe_context 
*pipe,
 struct pipe_framebuffer_state *fb =
 (struct pipe_framebuffer_state*)r300->fb_state.state;
 
 if (r300->zmask_in_use && !r300->locked_zbuffer) {
 if (fb->zsbuf->texture == dst->texture) {
 r300_decompress_zmask(r300);
 }
 }
 
 /* XXX Do not decompress ZMask of the currently-set zbuffer. */
-r300_blitter_begin(r300, R300_CLEAR_SURFACE);
+r300_blitter_begin(r300, R300_CLEAR_SURFACE |
+   (render_condition_enabled ? 0 : 
R300_IGNORE_RENDER_COND));
 util_blitter_clear_depth_stencil(r300->blitter, dst, clear_flags, depth, 
stencil,
  dstx, dsty, width, height);
 r300_blitter_end(r300);
 }
 
 void r300_decompress_zmask(struct r300_context *r300)
 {
 struct pipe_framebuffer_state *fb =
 (struct pipe_framebuffer_state*)r300->fb_state.state;
 
diff --git a/src/gallium/drivers/r600/r600_blit.c 
b/src/gallium/drivers/r600/r600_blit.c
index 327efc2..adf616e 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -471,38 +471,40 @@ static void r600_clear(struct pipe_context *ctx, unsigned 
buffers,
 
 static void r600_clear_render_target(struct pipe_context *ctx,
 struct pipe_surface *dst,
 const union pipe_color_union *color,
 unsigned dstx, unsigned dsty,
 unsigned width, unsigned height,
 bool render_condition_enabled)
 {
struct r600_context *rctx = (struct r600_context *)ctx;
 
-   r600_blitter_begin(ctx, R600_CLEAR_SURFACE);
+   r600_blitter_begin(ctx, R600_CLEAR_SURFACE |
+  (render_condition_enabled ? 0 : 
R600_DISABLE_RENDER_COND));
util_blitter_clear_render_target(rctx->blitter, dst, color,
 dstx, dsty, width, height);
r600_blitter_end(ctx);
 }
 
 static void r600_clear_depth_stencil(struct pipe_context *ctx,
 struct pipe_surface *dst,
 unsigned clear_flags,
 double depth,
 unsigned stencil,
 unsigned dstx, unsigned dsty,
 unsigned width, unsigned height,
 bool render_condition_enabled)
 {
struct r600_context *rctx = (struct r600_context *)ctx;
 
-   r600_blitter_begin(ctx, R600_CLEAR_SURFACE);
+   r600_blitter_begin(ctx, R600_CLEAR_SURFACE |
+  (render_condition_enabled ? 0 : 
R600_DISABLE_RENDER_COND));
util_blitter_clear_depth_stencil(rctx->blitter, dst, clear_flags, 
depth, stencil,
 dstx, dsty, width, height);
r600_blitter_end(ctx);
 }
 
 static void r600_copy_buffer(struct pipe_context *ctx, struct pipe_resource 
*dst, unsigned dstx,
 struct pipe_resource *src, const struct pipe_box 
*src_box)
 {
struct r600_context *rctx = 

[Mesa-dev] [PATCH] st/mesa: define ST_NEW_ flags as uint64_t values, not enums

[Brian Paul]

MSVC doesn't support 64-bit enum values, at least not with C code.
The compiler was warning:

c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(43) : warning
 C4309: 'initializing' : truncation of constant value
c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(44) : warning
 C4309: 'initializing' : truncation of constant value
...

And at runtime we crashed since the high 32-bits of the 'dirty' bitmask
was always 0x and the 32+u_bit_scan() index went out of bounds of
the atoms[] array.
---
 src/mesa/state_tracker/st_atom.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_atom.h b/src/mesa/state_tracker/st_atom.h
index febd7ce..971ea35 100644
--- a/src/mesa/state_tracker/st_atom.h
+++ b/src/mesa/state_tracker/st_atom.h
@@ -68,12 +68,12 @@ enum {
 #undef ST_STATE
 };
 
-/* Define ST_NEW_xxx */
-enum {
-#define ST_STATE(FLAG, st_update) FLAG = 1llu << FLAG##_INDEX,
+/* Define ST_NEW_xxx values as static const uint64_t values.
+ * We can't use an enum type because MSVC doesn't allow 64-bit enum values.
+ */
+#define ST_STATE(FLAG, st_update) static const uint64_t FLAG = 1llu << 
FLAG##_INDEX;
 #include "st_atom_list.h"
 #undef ST_STATE
-};
 
 /* Add extern struct declarations. */
 #define ST_STATE(FLAG, st_update) extern const struct st_tracked_state 
st_update;
-- 
1.9.1

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

Re: [Mesa-dev] Mesa (master): st/mesa: completely rewrite state atoms

[Brian Paul]

Marek,

I just found a problem with this patch series with MSVC.

The new enum type which defines the ST_NEW_ values uses bitshifts of 
more than 32 bits.  It looks like this overflows the 32-bit size of the 
enum datatype:


c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(43) : 
warning

 C4309: 'initializing' : truncation of constant value
c:\users\brian\projects\mesa\src\mesa\state_tracker\st_atom_list.h(44) : 
warning

 C4309: 'initializing' : truncation of constant value
...

I don't know of a way to specify a 64-bit enum.  stackoverflow.com 
offers a few ideas for C++, but they don't work for C.


My work-around is to create a 'static const uint64_t ST_NEW_foo = 1llu 
<< ST_NEW_foo_INDEX;' for each flag, rather than an enum value.


I'll post a patch for this soon.

-Brian


On 07/30/2016 07:04 AM, Marek Olšák wrote:

Module: Mesa
Branch: master
Commit: c8fe3b9dca73e3b91979d92ba4136b302001b3bb
URL:
https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_mesa_mesa_commit_-3Fid-3Dc8fe3b9dca73e3b91979d92ba4136b302001b3bb=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=lFYqYu7WLZRIthDamMpIHOysN7nmCAUk1RdZwZC7E44=a157hpIVAAqEFvga55qDUIH6SprwqXZ4BCoGVPCWfa4=

Author: Marek Olšák 
Date:   Sun Jul 17 18:38:38 2016 +0200

st/mesa: completely rewrite state atoms

The goal is to do this in st_validate_state:
while (dirty)
   atoms[u_bit_scan()]->update(st);

That implies that atoms can't specify which flags they consume.
There is exactly one ST_NEW_* flag for each atom. (58 flags in total)

There are macros that combine multiple flags into one for easier use.

All _NEW_* flags are translated into ST_NEW_* flags in st_invalidate_state.
st/mesa doesn't keep the _NEW_* flags after that.

torcs is 2% faster between the previous patch and the end of this series.

v2: - add st_atom_list.h to Makefile.sources

Reviewed-by: Nicolai Hähnle 

---

  src/mesa/Makefile.sources  |   1 +
  src/mesa/state_tracker/st_atom.c   | 156 +-
  src/mesa/state_tracker/st_atom.h   | 210 +
  src/mesa/state_tracker/st_atom_array.c |   4 -
  src/mesa/state_tracker/st_atom_atomicbuf.c |  24 ---
  src/mesa/state_tracker/st_atom_blend.c |   4 -
  src/mesa/state_tracker/st_atom_clip.c  |   4 -
  src/mesa/state_tracker/st_atom_constbuf.c  |  48 --
  src/mesa/state_tracker/st_atom_depth.c |   4 -
  src/mesa/state_tracker/st_atom_framebuffer.c   |   4 -
  src/mesa/state_tracker/st_atom_image.c |  24 ---
  src/mesa/state_tracker/st_atom_list.h  |  75 +
  src/mesa/state_tracker/st_atom_msaa.c  |   8 -
  src/mesa/state_tracker/st_atom_pixeltransfer.c |   4 -
  src/mesa/state_tracker/st_atom_rasterizer.c|  16 --
  src/mesa/state_tracker/st_atom_sampler.c   |   4 -
  src/mesa/state_tracker/st_atom_scissor.c   |   8 -
  src/mesa/state_tracker/st_atom_shader.c|  24 ---
  src/mesa/state_tracker/st_atom_stipple.c   |   5 -
  src/mesa/state_tracker/st_atom_storagebuf.c|  24 ---
  src/mesa/state_tracker/st_atom_tess.c  |   4 -
  src/mesa/state_tracker/st_atom_texture.c   |  24 ---
  src/mesa/state_tracker/st_atom_viewport.c  |   4 -
  src/mesa/state_tracker/st_cb_bitmap.c  |  10 +-
  src/mesa/state_tracker/st_cb_bufferobjects.c   |  10 +-
  src/mesa/state_tracker/st_cb_compute.c |   2 +-
  src/mesa/state_tracker/st_cb_feedback.c|   2 +-
  src/mesa/state_tracker/st_cb_program.c |  38 ++---
  src/mesa/state_tracker/st_cb_texture.c |   2 +-
  src/mesa/state_tracker/st_context.c| 100 ++--
  src/mesa/state_tracker/st_context.h|  42 +
  src/mesa/state_tracker/st_draw.c   |   4 +-
  src/mesa/state_tracker/st_manager.c|   4 +-
  33 files changed, 381 insertions(+), 516 deletions(-)

Diff:   
https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_mesa_mesa_diff_-3Fid-3Dc8fe3b9dca73e3b91979d92ba4136b302001b3bb=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=lFYqYu7WLZRIthDamMpIHOysN7nmCAUk1RdZwZC7E44=LOlK4ENHEaa1JBlA0wq8I6GQWpROFYYDFo_2gyzhego=
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Dcommit=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=lFYqYu7WLZRIthDamMpIHOysN7nmCAUk1RdZwZC7E44=S1tyA97XsiodjH7EOJ1M5vfEd5yiU4qcDicS1fayqdE=



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

Re: [Mesa-dev] [PATCH 42/95] i965/vec4: dump NibCtrl for instructions with execsize 4

[Francisco Jerez]

Iago Toral Quiroga  writes:

> ---
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 829b7d3..88bf895 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -1580,6 +1580,9 @@ vec4_visitor::dump_instruction(backend_instruction 
> *be_inst, FILE *file)
> if (inst->force_writemask_all)
>fprintf(file, " NoMask");
>  
> +   if (inst->exec_size == 4)
> +  fprintf(file, "%s", inst->group == 0 ? " 1N" : " 2N");
> +

In the FS back-end we do:

|   if (inst->exec_size != dispatch_width)
| fprintf(file, "group%d ", inst->group);

Would it make sense to have the vec4 back-end behave the same way for
consistency? (with dispatch_width equal to 8)

> fprintf(file, "\n");
>  }
>  
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 41/95] i965/vec4: make the generator set correct NibCtrl for SIMD4 DF instructions

[Francisco Jerez]

Iago Toral Quiroga  writes:

> From the HSW PRM, Command Reference, QtrCtrl:
>
>"NibCtrl is only allowed for SIMD4 instructions with a DF (Double Float)
> source or destination type."
>
> v2 (Samuel): Assert that the type is DF.
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> index c6e040e..dc4f6db 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> @@ -1494,6 +1494,7 @@ generate_code(struct brw_codegen *p,
>brw_set_default_saturate(p, inst->saturate);
>brw_set_default_mask_control(p, inst->force_writemask_all);
>brw_set_default_acc_write_control(p, inst->writes_accumulator);
> +  brw_set_default_group(p, 0);
>
>assert(inst->base_mrf + inst->mlen <= BRW_MAX_MRF(devinfo->gen));
>assert(inst->mlen <= BRW_MAX_MSG_LENGTH);
> @@ -1529,6 +1530,14 @@ generate_code(struct brw_codegen *p,
>} else {
>   assert(inst->exec_size == 8 || inst->exec_size == 4);
>   brw_set_default_exec_size(p, cvt(inst->exec_size) - 1);
> + if (inst->exec_size == 4 && !inst->force_writemask_all) {
> +assert(inst->dst.type == BRW_REGISTER_TYPE_DF ||
> +   inst->src[0].type == BRW_REGISTER_TYPE_DF ||
> +   inst->src[1].type == BRW_REGISTER_TYPE_DF ||
> +   inst->src[2].type == BRW_REGISTER_TYPE_DF);
> +assert(inst->group == 0 || inst->group == 4);
> +brw_inst_set_group(p->devinfo, p->current, inst->group);

I think this should be unconditional (e.g. if somebody tries to set
group == 4 on an instruction with exec_size == 8 it would be nice to get
an assertion failure instead of the group value being silently
ignored).  How about you replace the 'brw_set_default_group(p, 0)' line
above with:

|
|   assert(inst->group % inst->exec_size == 0);
|   assert(inst->group % 8 == 0 ||
|  inst->dst.type == BRW_REGISTER_TYPE_DF ||
|  inst->src[0].type == BRW_REGISTER_TYPE_DF ||
|  inst->src[1].type == BRW_REGISTER_TYPE_DF ||
|  inst->src[2].type == BRW_REGISTER_TYPE_DF);
|   brw_set_default_group(p, inst->group);

and then drop this hunk?

>}
>  
>switch (inst->opcode) {
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH] mesa: simplify ff fs generator a bit

[Miklós Máté]

On 08/08/2016 04:15 PM, Brian Paul wrote:

On 08/06/2016 03:34 PM, Miklós Máté wrote:

Literally.

Signed-off-by: Miklós Máté 
---
  src/mesa/main/ff_fragment_shader.cpp | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/ff_fragment_shader.cpp 
b/src/mesa/main/ff_fragment_shader.cpp

index b0ce8c4..ad3d666 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -102,7 +102,6 @@ struct state_key {
 GLuint nr_enabled_units:8;
 GLuint enabled_units:8;
 GLuint separate_specular:1;
-   GLuint fog_enabled:1;
 GLuint fog_mode:2;  /**< FOG_x */
 GLuint inputs_available:12;
 GLuint num_draw_buffers:4;
@@ -126,10 +125,10 @@ struct state_key {
 } unit[MAX_TEXTURE_UNITS];
  };

-#define FOG_LINEAR  0
-#define FOG_EXP 1
-#define FOG_EXP22
-#define FOG_UNKNOWN 3
+#define FOG_NONE0
+#define FOG_LINEAR  1
+#define FOG_EXP 2
+#define FOG_EXP23

  static GLuint translate_fog_mode( GLenum mode )
  {
@@ -137,7 +136,7 @@ static GLuint translate_fog_mode( GLenum mode )
 case GL_LINEAR: return FOG_LINEAR;
 case GL_EXP: return FOG_EXP;
 case GL_EXP2: return FOG_EXP2;
-   default: return FOG_UNKNOWN;
+   default: return FOG_NONE;
 }
  }

@@ -459,7 +458,6 @@ static GLuint make_state_key( struct gl_context 
*ctx,  struct state_key *key )


 /* _NEW_FOG */
 if (ctx->Fog.Enabled) {
-  key->fog_enabled = 1;
key->fog_mode = translate_fog_mode(ctx->Fog.Mode);
inputs_referenced |= VARYING_BIT_FOGC; /* maybe */
 }
@@ -1178,7 +1176,7 @@ emit_instructions(texenv_fragment_program *p)
cf = new(p->mem_ctx) ir_dereference_variable(spec_result);
 }

-   if (key->fog_enabled) {
+   if (key->fog_mode) {
cf = emit_fog_instructions(p, cf);
 }




Reviewed-by: Brian Paul 



Thanks for the review. I also need somebody to commit this for me, as I 
don't have commit access.


MM

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

[Mesa-dev] [PATCH] ddebug: dump driver states and shaders for apitrace calls

[Marek Olšák]

From: Marek Olšák 

I think this was an oversight when the PIPE_DUMP flags were added.
---
 src/gallium/drivers/ddebug/dd_draw.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/ddebug/dd_draw.c 
b/src/gallium/drivers/ddebug/dd_draw.c
index 97325e4..4ea3129 100644
--- a/src/gallium/drivers/ddebug/dd_draw.c
+++ b/src/gallium/drivers/ddebug/dd_draw.c
@@ -1084,21 +1084,24 @@ dd_after_draw(struct dd_context *dctx, struct dd_call 
*call)
  dd_pipelined_process_draw(dctx, call);
  break;
   case DD_DUMP_ALL_CALLS:
  if (!dscreen->no_flush)
 pipe->flush(pipe, NULL, 0);
  dd_write_report(dctx, call, 0, false);
  break;
   case DD_DUMP_APITRACE_CALL:
  if (dscreen->apitrace_dump_call ==
  dctx->draw_state.apitrace_call_number) {
-dd_write_report(dctx, call, 0, false);
+dd_write_report(dctx, call,
+PIPE_DUMP_CURRENT_STATES |
+PIPE_DUMP_CURRENT_SHADERS,
+false);
 /* No need to continue. */
 exit(0);
  }
  break;
   default:
  assert(0);
   }
}
 
++dctx->num_draw_calls;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 8/8] radeonsi: enable multi-draw related pipe caps

[Marek Olšák]

If release notes are updated as well, the series is:

Reviewed-by: Marek Olšák 

Marek

On Mon, Aug 8, 2016 at 5:55 PM, Nicolai Hähnle  wrote:
> From: Nicolai Hähnle 
>
> This enables GL_shader_draw_parameters and GL_ARB_indirect_parameters as well
> as a properly accelerated implementation of GL_ARB_multi_draw_indirect.
>
> Enabling the feature requires a sufficiently uptodate firmware -- those have
> already been released a long time ago, although this does mean that the
> feature only works with the amdgpu kernel module, since the radeon module
> doesn't have a way to query the firmware version.
> ---
>  docs/GL3.txt   | 4 ++--
>  src/gallium/drivers/radeonsi/si_pipe.c | 8 +---
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index c185c69..0ba5a25 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -283,7 +283,7 @@ Khronos, ARB, and OES extensions that are not part of any 
> OpenGL or OpenGL ES ve
>GL_ARB_ES3_2_compatibilitynot started
>GL_ARB_fragment_shader_interlock  not started
>GL_ARB_gpu_shader_int64   started (airlied for 
> core and Gallium, idr for i965)
> -  GL_ARB_indirect_parametersDONE (nvc0)
> +  GL_ARB_indirect_parametersDONE (nvc0, radeonsi)
>GL_ARB_parallel_shader_compilenot started, but 
> Chia-I Wu did some related work in 2014
>GL_ARB_pipeline_statistics_query  DONE (i965, nvc0, 
> radeonsi, softpipe, swr)
>GL_ARB_post_depth_coveragenot started
> @@ -293,7 +293,7 @@ Khronos, ARB, and OES extensions that are not part of any 
> OpenGL or OpenGL ES ve
>GL_ARB_shader_atomic_counter_ops  DONE (nvc0, 
> radeonsi, softpipe)
>GL_ARB_shader_ballot  not started
>GL_ARB_shader_clock   DONE (i965/gen7+)
> -  GL_ARB_shader_draw_parameters DONE (i965, nvc0)
> +  GL_ARB_shader_draw_parameters DONE (i965, nvc0, 
> radeonsi)
>GL_ARB_shader_group_vote  DONE (nvc0)
>GL_ARB_shader_stencil_export  DONE (i965/gen9+, 
> radeonsi, softpipe, llvmpipe, swr)
>GL_ARB_shader_viewport_layer_arraynot started
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index ffeeda3..86d7632 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -435,9 +435,6 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
> case PIPE_CAP_VERTEXID_NOBASE:
> case PIPE_CAP_CLEAR_TEXTURE:
> -   case PIPE_CAP_DRAW_PARAMETERS:
> -   case PIPE_CAP_MULTI_DRAW_INDIRECT:
> -   case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
> case PIPE_CAP_QUERY_BUFFER_OBJECT:
> case PIPE_CAP_CULL_DISTANCE:
> case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
> @@ -445,6 +442,11 @@ static int si_get_param(struct pipe_screen* pscreen, 
> enum pipe_cap param)
> case PIPE_CAP_MAX_WINDOW_RECTANGLES:
> return 0;
>
> +   case PIPE_CAP_DRAW_PARAMETERS:
> +   case PIPE_CAP_MULTI_DRAW_INDIRECT:
> +   case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
> +   return sscreen->has_draw_indirect_multi;
> +
> case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
> return 30;
>
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

[bugzilla-daemon]

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

Sander Eikelenboom  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)

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

[Mesa-dev] [PATCH 3/3] anv/gen7_pipeline: Set multisample state using shared function

[Anuj Phogat]

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen7_pipeline.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 5395e79..17d7ccc 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -81,21 +81,7 @@ genX(graphics_pipeline_create)(
  pCreateInfo->pRasterizationState, extra);
emit_3dstate_streamout(pipeline, pCreateInfo->pRasterizationState);
 
-   if (pCreateInfo->pMultisampleState &&
-   pCreateInfo->pMultisampleState->rasterizationSamples > 1)
-  anv_finishme("VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO");
-
-   uint32_t samples = 1;
-   uint32_t log2_samples = __builtin_ffs(samples) - 1;
-
-   anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
-  ms.PixelLocation= PIXLOC_CENTER;
-  ms.NumberofMultisamples = log2_samples;
-   }
-
-   anv_batch_emit(>batch, GENX(3DSTATE_SAMPLE_MASK), sm) {
-  sm.SampleMask = 0xff;
-   }
+   emit_ms_state(pipeline, pCreateInfo->pMultisampleState);
 
const struct brw_vs_prog_data *vs_prog_data = get_vs_prog_data(pipeline);
 
-- 
2.5.5

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

[Mesa-dev] [PATCH 2/3] anv/pipeline: Add sample locations for gen7-7.5

[Anuj Phogat]

V1: Add multisample positions (Nanley)
V2: Fix 8x sample positions (Anuj)

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/genX_pipeline_util.h | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/src/intel/vulkan/genX_pipeline_util.h 
b/src/intel/vulkan/genX_pipeline_util.h
index 52d386a..621edef 100644
--- a/src/intel/vulkan/genX_pipeline_util.h
+++ b/src/intel/vulkan/genX_pipeline_util.h
@@ -470,6 +470,7 @@ emit_ms_state(struct anv_pipeline *pipeline,
anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
   ms.NumberofMultisamples   = log2_samples;
 
+#if GEN_GEN >= 8
   /* The PRM says that this bit is valid only for DX9:
*
*SW can choose to set this bit only for DX9 API. DX10/OGL API's
@@ -477,6 +478,52 @@ emit_ms_state(struct anv_pipeline *pipeline,
*/
   ms.PixelPositionOffsetEnable  = false;
   ms.PixelLocation  = CENTER;
+#else
+  ms.PixelLocation  = PIXLOC_CENTER;
+
+  switch (samples) {
+  case 1:
+ ms.Sample0XOffset  = 0.5;
+ ms.Sample0YOffset  = 0.5;
+ break;
+  case 2:
+ ms.Sample0XOffset  = 0.25;
+ ms.Sample0YOffset  = 0.25;
+ ms.Sample1XOffset  = 0.75;
+ ms.Sample1YOffset  = 0.75;
+ break;
+  case 4:
+ ms.Sample0XOffset  = 0.375;
+ ms.Sample0YOffset  = 0.125;
+ ms.Sample1XOffset  = 0.875;
+ ms.Sample1YOffset  = 0.375;
+ ms.Sample2XOffset  = 0.125;
+ ms.Sample2YOffset  = 0.625;
+ ms.Sample3XOffset  = 0.625;
+ ms.Sample3YOffset  = 0.875;
+ break;
+  case 8:
+ ms.Sample0XOffset  = 0.4375;
+ ms.Sample0YOffset  = 0.5625;
+ ms.Sample1XOffset  = 0.5625;
+ ms.Sample1YOffset  = 0.8125;
+ ms.Sample2XOffset  = 0.6875;
+ ms.Sample2YOffset  = 0.1875;
+ ms.Sample3XOffset  = 0.8125;
+ ms.Sample3YOffset  = 0.6875;
+ ms.Sample4XOffset  = 0.0625;
+ ms.Sample4YOffset  = 0.4375;
+ ms.Sample5XOffset  = 0.3125;
+ ms.Sample5YOffset  = 0.0625;
+ ms.Sample6XOffset  = 0.9375;
+ ms.Sample6YOffset  = 0.3125;
+ ms.Sample7XOffset  = 0.1875;
+ ms.Sample7YOffset  = 0.9375;
+ break;
+  default:
+ break;
+  }
+#endif
}
 
anv_batch_emit(>batch, GENX(3DSTATE_SAMPLE_MASK), sm) {
-- 
2.5.5

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

[Mesa-dev] [Bug 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

[bugzilla-daemon]

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

--- Comment #4 from Sander Eikelenboom  ---
Created attachment 125619
  --> https://bugs.freedesktop.org/attachment.cgi?id=125619=edit
mesa-vanilla-opencv-vanilla.txt

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

[Mesa-dev] [Bug 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

[bugzilla-daemon]

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

--- Comment #5 from Sander Eikelenboom  ---
Created attachment 125620
  --> https://bugs.freedesktop.org/attachment.cgi?id=125620=edit
opencv-patch.diff

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

[Mesa-dev] [PATCH 1/3] anv/pipeline: Move emit_ms_state() to genX_pipeline_util.h

[Anuj Phogat]

This will help sharing multisample state setting code.

Signed-off-by: Anuj Phogat 
---
 src/intel/vulkan/gen8_pipeline.c  | 40 ---
 src/intel/vulkan/genX_pipeline_util.h | 40 +++
 2 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_pipeline.c
index d16ce7b..949a854 100644
--- a/src/intel/vulkan/gen8_pipeline.c
+++ b/src/intel/vulkan/gen8_pipeline.c
@@ -44,46 +44,6 @@ emit_ia_state(struct anv_pipeline *pipeline,
}
 }
 
-static void
-emit_ms_state(struct anv_pipeline *pipeline,
-  const VkPipelineMultisampleStateCreateInfo *info)
-{
-   uint32_t samples = 1;
-   uint32_t log2_samples = 0;
-
-   /* From the Vulkan 1.0 spec:
-*If pSampleMask is NULL, it is treated as if the mask has all bits
-*enabled, i.e. no coverage is removed from fragments.
-*
-* 3DSTATE_SAMPLE_MASK.SampleMask is 16 bits.
-*/
-   uint32_t sample_mask = 0x;
-
-   if (info) {
-  samples = info->rasterizationSamples;
-  log2_samples = __builtin_ffs(samples) - 1;
-   }
-
-   if (info && info->pSampleMask)
-  sample_mask &= info->pSampleMask[0];
-
-   anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
-  /* The PRM says that this bit is valid only for DX9:
-   *
-   *SW can choose to set this bit only for DX9 API. DX10/OGL API's
-   *should not have any effect by setting or not setting this bit.
-   */
-  ms.PixelPositionOffsetEnable = false;
-
-  ms.PixelLocation = CENTER;
-  ms.NumberofMultisamples = log2_samples;
-   }
-
-   anv_batch_emit(>batch, GENX(3DSTATE_SAMPLE_MASK), sm) {
-  sm.SampleMask = sample_mask;
-   }
-}
-
 VkResult
 genX(graphics_pipeline_create)(
 VkDevice_device,
diff --git a/src/intel/vulkan/genX_pipeline_util.h 
b/src/intel/vulkan/genX_pipeline_util.h
index 6184c87..52d386a 100644
--- a/src/intel/vulkan/genX_pipeline_util.h
+++ b/src/intel/vulkan/genX_pipeline_util.h
@@ -444,6 +444,46 @@ emit_rs_state(struct anv_pipeline *pipeline,
 #endif
 }
 
+static void
+emit_ms_state(struct anv_pipeline *pipeline,
+  const VkPipelineMultisampleStateCreateInfo *info)
+{
+   uint32_t samples = 1;
+   uint32_t log2_samples = 0;
+
+   /* From the Vulkan 1.0 spec:
+*If pSampleMask is NULL, it is treated as if the mask has all bits
+*enabled, i.e. no coverage is removed from fragments.
+*
+* 3DSTATE_SAMPLE_MASK.SampleMask is 16 bits.
+*/
+   uint32_t sample_mask = 0x;
+
+   if (info) {
+  samples = info->rasterizationSamples;
+  log2_samples = __builtin_ffs(samples) - 1;
+   }
+
+   if (info && info->pSampleMask)
+  sample_mask &= info->pSampleMask[0];
+
+   anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
+  ms.NumberofMultisamples   = log2_samples;
+
+  /* The PRM says that this bit is valid only for DX9:
+   *
+   *SW can choose to set this bit only for DX9 API. DX10/OGL API's
+   *should not have any effect by setting or not setting this bit.
+   */
+  ms.PixelPositionOffsetEnable  = false;
+  ms.PixelLocation  = CENTER;
+   }
+
+   anv_batch_emit(>batch, GENX(3DSTATE_SAMPLE_MASK), sm) {
+  sm.SampleMask = sample_mask;
+   }
+}
+
 static const uint32_t vk_to_gen_logic_op[] = {
[VK_LOGIC_OP_COPY]= LOGICOP_COPY,
[VK_LOGIC_OP_CLEAR]   = LOGICOP_CLEAR,
-- 
2.5.5

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

[Mesa-dev] [Bug 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

[bugzilla-daemon]

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

--- Comment #3 from Sander Eikelenboom  ---
Created attachment 125618
  --> https://bugs.freedesktop.org/attachment.cgi?id=125618=edit
mesa-vanilla-opencv-patched.txt

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

[Mesa-dev] [Bug 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

[bugzilla-daemon]

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

--- Comment #2 from Sander Eikelenboom  ---
Created attachment 125617
  --> https://bugs.freedesktop.org/attachment.cgi?id=125617=edit
mesa-patched-opencv-vanilla.txt

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

[Mesa-dev] [Bug 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

[bugzilla-daemon]

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

--- Comment #1 from Sander Eikelenboom  ---
Created attachment 125616
  --> https://bugs.freedesktop.org/attachment.cgi?id=125616=edit
mesa-patch.diff

-- 
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 97250] Mesa/Clover: openCV library bugs on CL_MEM_USE_HOST_PTR

[bugzilla-daemon]

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

Bug ID: 97250
   Summary: Mesa/Clover: openCV library bugs  on
CL_MEM_USE_HOST_PTR
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: li...@eikelenboom.it
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 125615
  --> https://bugs.freedesktop.org/attachment.cgi?id=125615=edit
only printk's added to openCV, fglrx is closed source so can't do anything
about that

At the moment I'm trying to get the openCV library to work with openCL (and
there T-API).

At first i would like to state that I'm don't have much knowledge about the
opencl specs, so please indicate when my
interpretations are correct.

A setup with the proprietary AMD fgrlx driver works fine with openCV, but it's
a PITA to setup and update.
So i am trying to get it to work with Mesa/Clover, but i seem to have a few
(related) issues:

The way OpenCV uses clCreateBuffer is as follows (
https://github.com/opencv/opencv/blob/master/modules/core/src/ocl.cpp#L4455 )

if (u->origdata == cv::alignPtr(u->origdata, 4)) // There are OpenCL
runtime issues for less aligned data
{
handle = clCreateBuffer(ctx_handle,
CL_MEM_USE_HOST_PTR|createFlags,
u->size, u->origdata, );
}
if((!handle || retval < 0) && !(accessFlags & ACCESS_FAST))
{
handle = clCreateBuffer(ctx_handle,
CL_MEM_COPY_HOST_PTR|CL_MEM_READ_WRITE|createFlags,
   u->size, u->origdata, );
tempUMatFlags |= UMatData::TEMP_COPIED_UMAT;
}

So it first tries with the flag CL_MEM_USE_HOST_PTR and only if that fails will
use CL_MEM_COPY_HOST_PTR.

What i have observed and am wondering about is:
1) Removing the CL_MEM_USE_HOST_PTR flag from the first invocation in openCV
makes things work with current upstream Mesa/Clover.
   Instead of carrying on it will now throw a "CL_INVALID_HOST_PTR" exception
and openCV will now try with
"CL_MEM_COPY_HOST_PTR|CL_MEM_READ_WRITE|createFlags" flags. This succeeds and
all is well.
   (so it's related to this part of the code and this specific flag)
2) With the CL_MEM_USE_HOST_PTR flag still in place, openCV bails out with the
following error:


3) I'm using a discrete graphics card (radeon HD7950) and not a APU, nor a card
with hybrid memory.
   So I'm wondering if in that situation, shouldn't Mesa/Clover throw an
exception when the CL_MEM_USE_HOST_PTR flag is specified in
   combination with a device which doesn't support "Host unified memory", or
has this nothing to do with "Host unified memory" ?

   Here i see a few things i can't place, the openCV code dumps some stats
about the openCL device:
   A) These values differ between the AMD fglrx driver and using Mesa/Clover:
  AMD fglrx:
Current OpenCL device:
Type = dGPU
Name = Tahiti
Version = OpenCL 1.2 AMD-APP (1702.3)
Compute units = 28
Max work group size = 256
Local memory size = 32 kB
Max memory allocation size = 2 GB 49 MB
Double support = Yes
Host unified memory = No
Has AMD Blas = No
Has AMD Fft = No
Preferred vector width char = 4
Preferred vector width short = 2
Preferred vector width int = 1
Preferred vector width long = 1
Preferred vector width float = 1
Preferred vector width double = 1


  Mesa/Clover:
Current OpenCL device:
Type = iGPU
Name = AMD TAHITI (DRM 2.43.0 / 4.6.0-1-amd64, LLVM 3.8.1)
Version = OpenCL 1.1 Mesa 12.1.0-devel (git-3e5db9a)
Compute units = 28
Max work group size = 256
Local memory size = 32 kB
Max memory allocation size = 3 GB
Double support = Yes
Host unified memory = Yes
Has AMD Blas = No
Has AMD Fft = No
Preferred vector width char = 16
Preferred vector width short = 8
Preferred vector width int = 4
Preferred vector width long = 2
Preferred vector width float = 4
Preferred vector width double = 2

   A1) Where do OpenCV and Mesa/Clover derive these values from ?
   A2) Is this an issue with the Linux kernel radeon firmware?

   B) I have added a lot of printk's to both openCV and Mesa/Clover, i have
attached logs for all four scenario's
  (note that the opencv and clover printk output is not in sync, clover
printk's seems to arrive later at stderr)

  From these i noticed some things and have some questions:

  B1) In the run with AMD fglrx 

Re: [Mesa-dev] [PATCH 2/2] anv: gen7/75: Set multisample modes

[Jason Ekstrand]

On Mon, Aug 8, 2016 at 12:30 PM, Lionel Landwerlin 
wrote:

> Fixes the following failures :
>
> dEQP-VK.api.copy_and_blit.resolve_image.whole_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.whole_8_bit
> dEQP-VK.api.copy_and_blit.resolve_image.partial_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.partial_8_bit
> dEQP-VK.api.copy_and_blit.resolve_image.with_regions_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.with_regions_8_bit
>
> Tested on IVB/HSW
>
> v2: Check pMultisampleState is not NULL
>
> v3: Drop rasterization state rename (Anuj)
> Fix value of MultisampleRasterizationMode in 3DSTATE_SF
>
> v4: rebase on master
>
> Signed-off-by: Lionel Landwerlin 
> Cc: Jason Ekstrand 
> ---
>  src/intel/vulkan/gen7_pipeline.c  | 10 --
>  src/intel/vulkan/gen8_pipeline.c  |  2 +-
>  src/intel/vulkan/genX_pipeline_util.h |  4 
>  3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_
> pipeline.c
> index 1da28c0..135281d 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -68,7 +68,7 @@ genX(graphics_pipeline_create)(
>
> assert(pCreateInfo->pRasterizationState);
> emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
> - pass, subpass, extra);
> + pCreateInfo->pMultisampleState, pass, subpass, extra);
>
> emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass,
> subpass);
>
> @@ -85,7 +85,8 @@ genX(graphics_pipeline_create)(
> pCreateInfo->pMultisampleState->rasterizationSamples > 1)
>anv_finishme("VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_
> STATE_CREATE_INFO");
>
> -   uint32_t samples = 1;
> +   uint32_t samples = pCreateInfo->pMultisampleState ?
> +  pCreateInfo->pMultisampleState->rasterizationSamples
> : 1;
> uint32_t log2_samples = __builtin_ffs(samples) - 1;
>
> anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
> @@ -273,6 +274,11 @@ genX(graphics_pipeline_create)(
>   }
>
>   wm.BarycentricInterpolationMode=
> wm_prog_data->barycentric_interp_modes;
> +
> + wm.MultisampleRasterizationMode= samples > 1 ?
> +  MSRASTMODE_ON_PATTERN :
> MSRASTMODE_OFF_PIXEL;
> + wm.MultisampleDispatchMode = 
> wm_prog_data->persample_dispatch
> ?
> +  MSDISPMODE_PERSAMPLE :
> MSDISPMODE_PERPIXEL;
>}
> }
>
> diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_
> pipeline.c
> index d16ce7b..1840ce2 100644
> --- a/src/intel/vulkan/gen8_pipeline.c
> +++ b/src/intel/vulkan/gen8_pipeline.c
> @@ -120,7 +120,7 @@ genX(graphics_pipeline_create)(
> emit_ia_state(pipeline, pCreateInfo->pInputAssemblyState, extra);
> assert(pCreateInfo->pRasterizationState);
> emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
> - pass, subpass, extra);
> + pCreateInfo->pMultisampleState, pass, subpass, extra);
> emit_ms_state(pipeline, pCreateInfo->pMultisampleState);
> emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass,
> subpass);
> emit_cb_state(pipeline, pCreateInfo->pColorBlendState,
> diff --git a/src/intel/vulkan/genX_pipeline_util.h
> b/src/intel/vulkan/genX_pipeline_util.h
> index 0aa85ba..3d0ab9a 100644
> --- a/src/intel/vulkan/genX_pipeline_util.h
> +++ b/src/intel/vulkan/genX_pipeline_util.h
> @@ -365,6 +365,7 @@ static const uint32_t vk_to_gen_front_face[] = {
>  static void
>  emit_rs_state(struct anv_pipeline *pipeline,
>const VkPipelineRasterizationStateCreateInfo *rs_info,
> +  const VkPipelineMultisampleStateCreateInfo *ms_info,
>const struct anv_render_pass *pass,
>const struct anv_subpass *subpass,
>const struct anv_graphics_pipeline_create_info *extra)
> @@ -433,6 +434,9 @@ emit_rs_state(struct anv_pipeline *pipeline,
>  isl_format_get_depth_format(isl_format, false);
>}
> }
> +
> +   sf.MultisampleRasterizationMode = (ms_info &&
> ms_info->rasterizationSamples > 1) ?
> + MSRASTMODE_ON_PATTERN :
> MSRASTMODE_OFF_PIXEL;
>

I moved this up a little to put it near the multisample stuff for gen8 and
pushed the patches with my and Anuj's reviews.  Thanks!

--Jason


>  #endif
>
>  #if GEN_GEN >= 8
> --
> 2.8.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 38/95] i965/vec4: allow the vec4 IR to indicate the execution size of instructions

[Francisco Jerez]

Iago Toral Quiroga  writes:

> In the vec4 backend the generator sets the execution size for all
> instructions to 8, however, we will have to split certain DF instructions
> to have an execution size of 4, so we need to indicate this explicitly in the
> IR for the generator to set the right execution size for them.
>
> We will use this in a later patch when we implement a SIMD splitting pass.
> ---
>  src/mesa/drivers/dri/i965/brw_ir_vec4.h  | 2 ++
>  src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 3 +++
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp   | 1 +
>  3 files changed, 6 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_ir_vec4.h 
> b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> index 81b6a13..721772e 100644
> --- a/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> +++ b/src/mesa/drivers/dri/i965/brw_ir_vec4.h
> @@ -166,6 +166,8 @@ public:
> bool sol_final_write; /**< gen6: send commit message */
> unsigned sol_vertex; /**< gen6: used for setting dst index in SVB header 
> */
>  
> +   uint8_t exec_size;
> +

How about we move this up into backend_instruction instead?  It has the
same semantics as the FS back-end's so it would make sense to share it.

> bool is_send_from_grf();
> unsigned regs_read(unsigned arg) const;
> bool can_reswizzle(const struct brw_device_info *devinfo, int 
> dst_writemask,
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> index d7e6e2d..c6e040e 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
> @@ -1526,6 +1526,9 @@ generate_code(struct brw_codegen *p,
>   }
>   brw_set_default_exec_size(p, BRW_EXECUTE_4);
>   fix_exec_size = true;

Ugh, the above seems like a nasty hack (which seems to have caused
trouble with double-precision you had to work around in PATCH 14) to
sidestep the missing support for arbitrary execution sizes in the vec4
back-end.  I'd rather drop the hack above and set
vec4_instruction::exec_size to the right size from the visitor when
an execution size other than the default is intended.

> +  } else {
> + assert(inst->exec_size == 8 || inst->exec_size == 4);

Execution sizes other than these can be valid and potentially useful, I
think I'd drop this assertion.

> + brw_set_default_exec_size(p, cvt(inst->exec_size) - 1);
>}
>  
>switch (inst->opcode) {
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index 652b453..265bb17 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -55,6 +55,7 @@ vec4_instruction::vec4_instruction(enum opcode opcode, 
> const dst_reg ,
> this->mlen = 0;
> this->base_mrf = 0;
> this->offset = 0;
> +   this->exec_size = 8;
> this->annotation = NULL;
>  }
>  
> -- 
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [Bug 97140] dd_draw.c:949:11: error: implicit declaration of function 'fmemopen' is invalid in C99 [-Werror, -Wimplicit-function-declaration]

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

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

--- Comment #1 from Vinson Lee  ---
commit 840353059a35453e8a960673474e8a37d6f1a97a
Author: Marek Olšák 
Date:   Sat Jul 30 23:54:06 2016 +0200

ddebug: don't use fmemopen on non-Linux OS

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

Reviewed-by: Nicolai Hähnle 

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

Re: [Mesa-dev] [PATCH v2 6/7] egl/android: Add support for YV12 pixel format (v2)

[Chad Versace]

On 08/08/2016 01:58 PM, Rob Herring wrote:

On Mon, Aug 8, 2016 at 1:39 PM, Chad Versace  wrote:

On 08/02/2016 04:07 AM, Tomasz Figa wrote:


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

v2: Use const array defined just for YV12 instead of trying to be overly
generic.

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






@@ -512,22 +518,60 @@ static _EGLImage *
 droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx,
  struct ANativeWindowBuffer *buf, int fd)
 {
+   unsigned int offsets[3] = { 0, 0, 0 };
+   unsigned int pitches[3] = { 0, 0, 0 };
+
const int fourcc = get_fourcc(buf->format);
-   const int pitch = buf->stride * get_format_bpp(buf->format);
+   if (fourcc == -1) {
+  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
+  return NULL;
+   }

-   const EGLint attr_list[14] = {
+   pitches[0] = buf->stride * get_format_bpp(buf->format);
+   if (pitches[0] == 0) {
+  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
+  return NULL;
+   }
+
+   switch (buf->format) {
+   case HAL_PIXEL_FORMAT_YV12:
+  /* Y plane is assumed to be at offset 0. */
+  /* Cr plane is located after Y plane */
+  offsets[1] = offsets[0] + pitches[0] * buf->height;
+  pitches[1] = ALIGN(pitches[0] / 2, 16);
+  /* Cb plane is located after Cr plane */
+  offsets[2] = offsets[1] + pitches[1] * buf->height / 2;



I believe the above should be
   offsets[2] = offsets[1] + pitches[1] * ALIGN(buf->height, 2) / 2;
to accommodate buffers with odd height.


Android defines this format is even height and width with a stride
multiple of 16 pixels:

/*
 * Android YUV format:
 *
 * This format is exposed outside of the HAL to software decoders and
 * applications.  EGLImageKHR must support it in conjunction with the
 * OES_EGL_image_external extension.
 *
 * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed
 * by (W/2) x (H/2) Cr and Cb planes.
 *
 * This format assumes
 * - an even width
 * - an even height
 * - a horizontal stride multiple of 16 pixels
 * - a vertical stride equal to the height
 *
 *   y_size = stride * height
 *   c_stride = ALIGN(stride/2, 16)
 *   c_size = c_stride * height/2
 *   size = y_size + c_size * 2
 *   cr_offset = y_size
 *   cb_offset = y_size + c_size
 *
 * When used with ANativeWindow, the dataSpace field describes the color
 * space of the buffer.
 */


Thanks for clarifying.

Reviewed-by: Chad Versace 

And pushed to master.

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

[Mesa-dev] [Bug 97231] GL_DEPTH_CLAMP doesn't clamp to the far plane

[bugzilla-daemon]

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

--- Comment #9 from Jules Blok  ---
(In reply to Roland Scheidegger from comment #8)
> So I think you're doing something unusual. With my earlier quick look, it
> seemed like maybe you're relying on getting the clamped values already as
> fragcoord.z in the shader?

We don't rely on that, we explicitly do our own clamping on gl_FragCoord.z in
the pixel shader.

(In reply to Roland Scheidegger from comment #8)
> If you're using (2^24 - 1) / (2^24) maybe there could also be precision
> issues, albeit I would think it should survive the viewport scaling bits
> (should be right at lsb of the float mantissa).

The reason we're using that specific depth range is so we can prevent round
trip errors by dividing/multiplying all our depth values by a power-of-two
factor. However, we still need to make sure we don't go outside of the 24-bit
integer range hence the strange far value.

What's happening in this specific example is that the game renders a mesh to
clear the screen at depth 2^24 - 1 and then it renders the background at 2^24.
Now, on the system we're trying to emulate the background depth would be
clamped to 2^24 - 1 and thus it will pass an less-equals depth test.

The nvidia blob driver handles this correctly:
https://fifoci.dolphin-emu.org/result/1931730/

The llvmpipe does not: https://fifoci.dolphin-emu.org/compare/1931541-1924723/

And the Intel driver has never been able to pass this test:
https://fifoci.dolphin-emu.org/result/1931392/

On Windows both Nvidia and Intel drivers pass this test.

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

Re: [Mesa-dev] [PATCH] dri: use 'bool' instead 'int' for boolean variables

[⚛]

On Mon, Aug 8, 2016 at 7:14 PM, Ian Romanick  wrote:
> On 08/08/2016 09:38 AM, ⚛ wrote:
>> On Mon, Aug 8, 2016 at 6:22 PM, Ian Romanick  wrote:
>>> I'm pretty sure this breaks ABI.  Did you try using an unpatched libGL
>>> with a patched *_dri.so (and vice-versa)?
>>
>> Can you be more specific?
>
> Eh... build Mesa.  Save the libGL and *_dri.so.  Apply patch.  Build
> again.  Run applications with LD_PRELOAD and LIBGL_DRIVERS_PATH (or
> EGL_DRIVERS_PATH) set to mix the old and new.

- The changes to the data structures in the patch do not necessarily
imply that mixing-unpatched-patched libs will fail because the
alignment of fields might stay the same.

- I looked into it a bit, but more time is required before I can send
the next version of the patch (if required). I marked the patch as
"deferred" at patchwork.freedesktop.org for now.

PS: Patches 10474 10427 10418 at patchwork aren't controversial so it
should be possible to review+merge them relatively quickly. It will
allow me to move on.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 6/7] egl/android: Add support for YV12 pixel format (v2)

[Rob Herring]

On Mon, Aug 8, 2016 at 1:39 PM, Chad Versace  wrote:
> On 08/02/2016 04:07 AM, Tomasz Figa wrote:
>>
>> This patch adds support for YV12 pixel format to the Android platform
>> backend. Only creating EGL images is supported, it is not added to the
>> list of available visuals.
>>
>> v2: Use const array defined just for YV12 instead of trying to be overly
>> generic.
>>
>> Signed-off-by: Tomasz Figa 
>> Signed-off-by: Kalyan Kondapally 
>> ---
>>  src/egl/drivers/dri2/platform_android.c | 56
>> +
>>  1 file changed, 50 insertions(+), 6 deletions(-)
>
>
>
>
>> @@ -512,22 +518,60 @@ static _EGLImage *
>>  droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx,
>>   struct ANativeWindowBuffer *buf, int fd)
>>  {
>> +   unsigned int offsets[3] = { 0, 0, 0 };
>> +   unsigned int pitches[3] = { 0, 0, 0 };
>> +
>> const int fourcc = get_fourcc(buf->format);
>> -   const int pitch = buf->stride * get_format_bpp(buf->format);
>> +   if (fourcc == -1) {
>> +  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
>> +  return NULL;
>> +   }
>>
>> -   const EGLint attr_list[14] = {
>> +   pitches[0] = buf->stride * get_format_bpp(buf->format);
>> +   if (pitches[0] == 0) {
>> +  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
>> +  return NULL;
>> +   }
>> +
>> +   switch (buf->format) {
>> +   case HAL_PIXEL_FORMAT_YV12:
>> +  /* Y plane is assumed to be at offset 0. */
>> +  /* Cr plane is located after Y plane */
>> +  offsets[1] = offsets[0] + pitches[0] * buf->height;
>> +  pitches[1] = ALIGN(pitches[0] / 2, 16);
>> +  /* Cb plane is located after Cr plane */
>> +  offsets[2] = offsets[1] + pitches[1] * buf->height / 2;
>
>
> I believe the above should be
>offsets[2] = offsets[1] + pitches[1] * ALIGN(buf->height, 2) / 2;
> to accommodate buffers with odd height.

Android defines this format is even height and width with a stride
multiple of 16 pixels:

/*
 * Android YUV format:
 *
 * This format is exposed outside of the HAL to software decoders and
 * applications.  EGLImageKHR must support it in conjunction with the
 * OES_EGL_image_external extension.
 *
 * YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed
 * by (W/2) x (H/2) Cr and Cb planes.
 *
 * This format assumes
 * - an even width
 * - an even height
 * - a horizontal stride multiple of 16 pixels
 * - a vertical stride equal to the height
 *
 *   y_size = stride * height
 *   c_stride = ALIGN(stride/2, 16)
 *   c_size = c_stride * height/2
 *   size = y_size + c_size * 2
 *   cr_offset = y_size
 *   cb_offset = y_size + c_size
 *
 * When used with ANativeWindow, the dataSpace field describes the color
 * space of the buffer.
 */

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

Re: [Mesa-dev] [PATCH v2] egl/dri2: Add reference count for dri2_egl_display

[⚛]

Hello

https://patchwork.freedesktop.org/series/10079/ has been merged to
master but it is still marked as "new" at patchwork.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97231] GL_DEPTH_CLAMP doesn't clamp to the far plane

[bugzilla-daemon]

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

--- Comment #8 from Roland Scheidegger  ---
(In reply to Jules Blok from comment #7)
> It seems you misunderstood me, it doesn't work with either reversed depth or
> normal depth on Mesa. So reverse depth has nothing to do with the issue, it
> was just a small thing I changed for reasons unrelated to this issue. I can
> reproduce the problem either way.

No I understood that just fine. What I'm saying is I'm pretty sure it is
totally busted if you do reverse depth range.
But if you don't do that, this feature is generally known to work with
llvmpipe. There's tests for this both on the gl (piglit) and d3d10 side (albeit
piglit doesn't seem to catch it won't work with reversed depth even though the
test does that...).
So I think you're doing something unusual. With my earlier quick look, it
seemed like maybe you're relying on getting the clamped values already as
fragcoord.z in the shader? That's not going to happen (and I can't see why it
should, with d3d10 the language is explicit this happens when the depth values
arrive at the output merger stage, gl language is way more confusing but still
says it happens at depth test time, and you cannot force early depth tests with
llvmpipe).
If you're using (2^24 - 1) / (2^24) maybe there could also be precision issues,
albeit I would think it should survive the viewport scaling bits (should be
right at lsb of the float mantissa).

-- 
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] vl/rbsp: add a check for emulation prevention three byte

[Leo Liu]

This is the case when the "00 00 03" is very close to the beginning of 
nal unit header 

Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/vl/vl_rbsp.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/vl/vl_rbsp.h 
b/src/gallium/auxiliary/vl/vl_rbsp.h
index 7867238..c134d31 100644
--- a/src/gallium/auxiliary/vl/vl_rbsp.h
+++ b/src/gallium/auxiliary/vl/vl_rbsp.h
@@ -77,8 +77,16 @@ static inline void vl_rbsp_fillbits(struct vl_rbsp *rbsp)
unsigned i, bits;
 
/* abort if we still have enough bits */
-   if (valid >= 32)
+   if (valid >= 32) {
+  /* search for the emulation prevention three byte */
+  for (i = 24; i <= valid; i += 8) {
+ if ((vl_vlc_peekbits(>nal, i) & 0xff) == 0x3) {
+vl_vlc_removebits(>nal, i - 8, 8);
+i += 8;
+ }
+  }
   return;
+   }
 
vl_vlc_fillbits(>nal);
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/2] anv: gen7/75: Set multisample modes

[Anuj Phogat]

On Mon, Aug 8, 2016 at 12:30 PM, Lionel Landwerlin 
wrote:

> Fixes the following failures :
>
> dEQP-VK.api.copy_and_blit.resolve_image.whole_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.whole_8_bit
> dEQP-VK.api.copy_and_blit.resolve_image.partial_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.partial_8_bit
> dEQP-VK.api.copy_and_blit.resolve_image.with_regions_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.with_regions_8_bit
>
> Tested on IVB/HSW
>
> v2: Check pMultisampleState is not NULL
>
> v3: Drop rasterization state rename (Anuj)
> Fix value of MultisampleRasterizationMode in 3DSTATE_SF
>
> v4: rebase on master
>
> Signed-off-by: Lionel Landwerlin 
> Cc: Jason Ekstrand 
> ---
>  src/intel/vulkan/gen7_pipeline.c  | 10 --
>  src/intel/vulkan/gen8_pipeline.c  |  2 +-
>  src/intel/vulkan/genX_pipeline_util.h |  4 
>  3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_
> pipeline.c
> index 1da28c0..135281d 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -68,7 +68,7 @@ genX(graphics_pipeline_create)(
>
> assert(pCreateInfo->pRasterizationState);
> emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
> - pass, subpass, extra);
> + pCreateInfo->pMultisampleState, pass, subpass, extra);
>
> emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass,
> subpass);
>
> @@ -85,7 +85,8 @@ genX(graphics_pipeline_create)(
> pCreateInfo->pMultisampleState->rasterizationSamples > 1)
>anv_finishme("VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_
> STATE_CREATE_INFO");
>
> -   uint32_t samples = 1;
> +   uint32_t samples = pCreateInfo->pMultisampleState ?
> +  pCreateInfo->pMultisampleState->rasterizationSamples
> : 1;
> uint32_t log2_samples = __builtin_ffs(samples) - 1;
>
> anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
> @@ -273,6 +274,11 @@ genX(graphics_pipeline_create)(
>   }
>
>   wm.BarycentricInterpolationMode=
> wm_prog_data->barycentric_interp_modes;
> +
> + wm.MultisampleRasterizationMode= samples > 1 ?
> +  MSRASTMODE_ON_PATTERN :
> MSRASTMODE_OFF_PIXEL;
> + wm.MultisampleDispatchMode = 
> wm_prog_data->persample_dispatch
> ?
> +  MSDISPMODE_PERSAMPLE :
> MSDISPMODE_PERPIXEL;
>}
> }
>
> diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_
> pipeline.c
> index d16ce7b..1840ce2 100644
> --- a/src/intel/vulkan/gen8_pipeline.c
> +++ b/src/intel/vulkan/gen8_pipeline.c
> @@ -120,7 +120,7 @@ genX(graphics_pipeline_create)(
> emit_ia_state(pipeline, pCreateInfo->pInputAssemblyState, extra);
> assert(pCreateInfo->pRasterizationState);
> emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
> - pass, subpass, extra);
> + pCreateInfo->pMultisampleState, pass, subpass, extra);
> emit_ms_state(pipeline, pCreateInfo->pMultisampleState);
> emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass,
> subpass);
> emit_cb_state(pipeline, pCreateInfo->pColorBlendState,
> diff --git a/src/intel/vulkan/genX_pipeline_util.h
> b/src/intel/vulkan/genX_pipeline_util.h
> index 0aa85ba..3d0ab9a 100644
> --- a/src/intel/vulkan/genX_pipeline_util.h
> +++ b/src/intel/vulkan/genX_pipeline_util.h
> @@ -365,6 +365,7 @@ static const uint32_t vk_to_gen_front_face[] = {
>  static void
>  emit_rs_state(struct anv_pipeline *pipeline,
>const VkPipelineRasterizationStateCreateInfo *rs_info,
> +  const VkPipelineMultisampleStateCreateInfo *ms_info,
>const struct anv_render_pass *pass,
>const struct anv_subpass *subpass,
>const struct anv_graphics_pipeline_create_info *extra)
> @@ -433,6 +434,9 @@ emit_rs_state(struct anv_pipeline *pipeline,
>  isl_format_get_depth_format(isl_format, false);
>}
> }
> +
> +   sf.MultisampleRasterizationMode = (ms_info &&
> ms_info->rasterizationSamples > 1) ?
> + MSRASTMODE_ON_PATTERN :
> MSRASTMODE_OFF_PIXEL;
>  #endif
>
>  #if GEN_GEN >= 8
> --
> 2.8.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

​Both patches are:
​Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] anv: gen7/75: Set multisample modes

[Lionel Landwerlin]

Fixes the following failures :

dEQP-VK.api.copy_and_blit.resolve_image.whole_4_bit
dEQP-VK.api.copy_and_blit.resolve_image.whole_8_bit
dEQP-VK.api.copy_and_blit.resolve_image.partial_4_bit
dEQP-VK.api.copy_and_blit.resolve_image.partial_8_bit
dEQP-VK.api.copy_and_blit.resolve_image.with_regions_4_bit
dEQP-VK.api.copy_and_blit.resolve_image.with_regions_8_bit

Tested on IVB/HSW

v2: Check pMultisampleState is not NULL

v3: Drop rasterization state rename (Anuj)
Fix value of MultisampleRasterizationMode in 3DSTATE_SF

v4: rebase on master

Signed-off-by: Lionel Landwerlin 
Cc: Jason Ekstrand 
---
 src/intel/vulkan/gen7_pipeline.c  | 10 --
 src/intel/vulkan/gen8_pipeline.c  |  2 +-
 src/intel/vulkan/genX_pipeline_util.h |  4 
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 1da28c0..135281d 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen7_pipeline.c
@@ -68,7 +68,7 @@ genX(graphics_pipeline_create)(
 
assert(pCreateInfo->pRasterizationState);
emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
- pass, subpass, extra);
+ pCreateInfo->pMultisampleState, pass, subpass, extra);
 
emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass, subpass);
 
@@ -85,7 +85,8 @@ genX(graphics_pipeline_create)(
pCreateInfo->pMultisampleState->rasterizationSamples > 1)
   anv_finishme("VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO");
 
-   uint32_t samples = 1;
+   uint32_t samples = pCreateInfo->pMultisampleState ?
+  pCreateInfo->pMultisampleState->rasterizationSamples : 1;
uint32_t log2_samples = __builtin_ffs(samples) - 1;
 
anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
@@ -273,6 +274,11 @@ genX(graphics_pipeline_create)(
  }
 
  wm.BarycentricInterpolationMode= 
wm_prog_data->barycentric_interp_modes;
+
+ wm.MultisampleRasterizationMode= samples > 1 ?
+  MSRASTMODE_ON_PATTERN : 
MSRASTMODE_OFF_PIXEL;
+ wm.MultisampleDispatchMode = 
wm_prog_data->persample_dispatch ?
+  MSDISPMODE_PERSAMPLE : 
MSDISPMODE_PERPIXEL;
   }
}
 
diff --git a/src/intel/vulkan/gen8_pipeline.c b/src/intel/vulkan/gen8_pipeline.c
index d16ce7b..1840ce2 100644
--- a/src/intel/vulkan/gen8_pipeline.c
+++ b/src/intel/vulkan/gen8_pipeline.c
@@ -120,7 +120,7 @@ genX(graphics_pipeline_create)(
emit_ia_state(pipeline, pCreateInfo->pInputAssemblyState, extra);
assert(pCreateInfo->pRasterizationState);
emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
- pass, subpass, extra);
+ pCreateInfo->pMultisampleState, pass, subpass, extra);
emit_ms_state(pipeline, pCreateInfo->pMultisampleState);
emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass, subpass);
emit_cb_state(pipeline, pCreateInfo->pColorBlendState,
diff --git a/src/intel/vulkan/genX_pipeline_util.h 
b/src/intel/vulkan/genX_pipeline_util.h
index 0aa85ba..3d0ab9a 100644
--- a/src/intel/vulkan/genX_pipeline_util.h
+++ b/src/intel/vulkan/genX_pipeline_util.h
@@ -365,6 +365,7 @@ static const uint32_t vk_to_gen_front_face[] = {
 static void
 emit_rs_state(struct anv_pipeline *pipeline,
   const VkPipelineRasterizationStateCreateInfo *rs_info,
+  const VkPipelineMultisampleStateCreateInfo *ms_info,
   const struct anv_render_pass *pass,
   const struct anv_subpass *subpass,
   const struct anv_graphics_pipeline_create_info *extra)
@@ -433,6 +434,9 @@ emit_rs_state(struct anv_pipeline *pipeline,
 isl_format_get_depth_format(isl_format, false);
   }
}
+
+   sf.MultisampleRasterizationMode = (ms_info && ms_info->rasterizationSamples 
> 1) ?
+ MSRASTMODE_ON_PATTERN : 
MSRASTMODE_OFF_PIXEL;
 #endif
 
 #if GEN_GEN >= 8
-- 
2.8.1

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

[Mesa-dev] [PATCH 0/2] Program multisampling modes on gen7/75

[Lionel Landwerlin]

Some of the new CTS tests are failing basic image resolve operations on gen7/75.
Turns out we're missing some bits there.

Cheers,

Lionel Landwerlin (2):
  anv: genX_pipeline: rename info to rs_info
  anv: gen7/75: Set multisample modes

 src/intel/vulkan/gen7_pipeline.c  | 10 --
 src/intel/vulkan/gen8_pipeline.c  |  2 +-
 src/intel/vulkan/genX_pipeline_util.h | 20 
 3 files changed, 21 insertions(+), 11 deletions(-)

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

[Mesa-dev] [PATCH 1/2] anv: genX_pipeline: rename info to rs_info

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
Cc: Jason Ekstrand 
---
 src/intel/vulkan/genX_pipeline_util.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/intel/vulkan/genX_pipeline_util.h 
b/src/intel/vulkan/genX_pipeline_util.h
index c17d930..0aa85ba 100644
--- a/src/intel/vulkan/genX_pipeline_util.h
+++ b/src/intel/vulkan/genX_pipeline_util.h
@@ -364,7 +364,7 @@ static const uint32_t vk_to_gen_front_face[] = {
 
 static void
 emit_rs_state(struct anv_pipeline *pipeline,
-  const VkPipelineRasterizationStateCreateInfo *info,
+  const VkPipelineRasterizationStateCreateInfo *rs_info,
   const struct anv_render_pass *pass,
   const struct anv_subpass *subpass,
   const struct anv_graphics_pipeline_create_info *extra)
@@ -398,10 +398,10 @@ emit_rs_state(struct anv_pipeline *pipeline,
raster.ForceMultisampling = false;
 #endif
 
-   raster.FrontWinding = vk_to_gen_front_face[info->frontFace];
-   raster.CullMode = vk_to_gen_cullmode[info->cullMode];
-   raster.FrontFaceFillMode = vk_to_gen_fillmode[info->polygonMode];
-   raster.BackFaceFillMode = vk_to_gen_fillmode[info->polygonMode];
+   raster.FrontWinding = vk_to_gen_front_face[rs_info->frontFace];
+   raster.CullMode = vk_to_gen_cullmode[rs_info->cullMode];
+   raster.FrontFaceFillMode = vk_to_gen_fillmode[rs_info->polygonMode];
+   raster.BackFaceFillMode = vk_to_gen_fillmode[rs_info->polygonMode];
raster.ScissorRectangleEnable = !(extra && extra->use_rectlist);
 
 #if GEN_GEN >= 9
@@ -412,9 +412,9 @@ emit_rs_state(struct anv_pipeline *pipeline,
raster.ViewportZClipTestEnable = !pipeline->depth_clamp_enable;
 #endif
 
-   raster.GlobalDepthOffsetEnableSolid = info->depthBiasEnable;
-   raster.GlobalDepthOffsetEnableWireframe = info->depthBiasEnable;
-   raster.GlobalDepthOffsetEnablePoint = info->depthBiasEnable;
+   raster.GlobalDepthOffsetEnableSolid = rs_info->depthBiasEnable;
+   raster.GlobalDepthOffsetEnableWireframe = rs_info->depthBiasEnable;
+   raster.GlobalDepthOffsetEnablePoint = rs_info->depthBiasEnable;
 
 #if GEN_GEN == 7
/* Gen7 requires that we provide the depth format in 3DSTATE_SF so that it
-- 
2.8.1

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

Re: [Mesa-dev] [PATCH v2 0/7] egl/android: Improve the Android EGL backend

[Chad Versace]

On 08/02/2016 04:07 AM, Tomasz Figa wrote:


Nicolas Boichat (1):
  egl/android: Fix support for pbuffers

Tomasz Figa (6):
  egl/android: Remove unused variables in
droid_get_buffers_with_format()
  egl/android: Respect buffer mask in droid_image_get_buffers
  egl/android: Refactor image creation to separate flink and prime paths
  egl/android: Make get_fourcc() accept HAL formats
  egl/android: Add support for YV12 pixel format
  egl/android: Make drm_gralloc headers optional



+ egl/android: Remove unused variables in droid_get_buffers_with_format()
+ egl/android: Respect buffer mask in droid_image_get_buffers
- egl/android: Fix support for pbuffers
+ egl/android: Refactor image creation to separate flink and prime paths
+ egl/android: Make get_fourcc() accept HAL formats
- egl/android: Add support for YV12 pixel format
- egl/android: Make drm_gralloc headers optional

Patches marked '+' I pushed to master, since they had reviewed-by's and
tested-by's. Patches marked '-' I didn't push, as they still have
outstanding review comments.

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

Re: [Mesa-dev] Switching to the GL 4.4 sRGB rules for glBlitFramebuffer().

[Ian Romanick]

Patches 1 through 5 and 7 through 9 are

Reviewed-by: Ian Romanick 

I sent one trivial comment on patch 9.

On 08/04/2016 04:14 PM, Kenneth Graunke wrote:
> Hello,
> 
> This combined patch series updates both Piglit and Mesa to implement
> the modern GL 4.4+ rules for sRGB encoding/decoding in BlitFramebuffer().
> 
> The new GL 4.4 rules make it possible to match the behavior of ES 3.x
> (always encode and decode), and the old behavior (never encode or decode).
> If GL_FRAMEBUFFER_SRGB is enabled, encode and decode happen.  If not,
> no conversions apply.  This is a change in behavior, which could break
> applications.
> 
> Paul Berry wrote Piglit tests in 2012 which matched the NVIDIA driver
> behavior at the time, which was to never apply conversions.  It appears
> that NVIDIA has changed their behavior, and now implements the GL 4.4
> rules.  They fail the Piglit tests, but begin passing after my patches.
> I'm told that AMD/Catalyst follows the 4.4+ rules too, but I haven't
> tested that personally.
> 
> Left 4 Dead 2 used to require the old behavior, but I retested with
> these patches, and it seems to be working fine.  I'm assuming they
> updated their application when the closed drivers changed behavior.
> 
> I've updated Gallium, Meta, and i965/blorp.  Please review - this
> will impact everyone.  I highly recommend reading patch 3, as it
> summarizes the changes in all GL 4.x specs.
> 
> Because working on sRGB drives people insane, here's an ode to
> non-linear colorspaces:
> 
> sRGB rules, GL broke
> some rendering glistened brightly
> some rendering grew bleak
> spec reformulations greatly bewilder
> surprisingly reasonable GL became
> 
> should review go badly,
> submitter's rationality goes b'bye
> 
> Thanks,
> --Ken
> 
> ___
> 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 09/10] meta: Make Meta's BlitFramebuffer() follow the GL 4.4 sRGB rules.

[Ian Romanick]

On 08/04/2016 04:14 PM, Kenneth Graunke wrote:
> Just avoid whacking GL_FRAMEBUFFER_SRGB altogether, so we respect
> the application's setting.  This appears to work.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/common/meta_blit.c | 80 
> +
>  1 file changed, 28 insertions(+), 52 deletions(-)
> 
> Metaaa!!!
> 
> diff --git a/src/mesa/drivers/common/meta_blit.c 
> b/src/mesa/drivers/common/meta_blit.c
> index d6d3a42..8a79725 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -606,7 +606,6 @@ blitframebuffer_texture(struct gl_context *ctx,
>  GLenum filter, GLint flipX, GLint flipY,
>  GLboolean glsl_version, GLboolean do_depth)
>  {
> -   struct save_state *save = >Meta->Save[ctx->Meta->SaveStackDepth - 1];
> int att_index = do_depth ? BUFFER_DEPTH : readFb->_ColorReadBufferIndex;
> const struct gl_renderbuffer_attachment *readAtt =
>>Attachment[att_index];
> @@ -719,57 +718,32 @@ blitframebuffer_texture(struct gl_context *ctx,
> fb_tex_blit.samp_obj = _mesa_meta_setup_sampler(ctx, texObj, target, 
> filter,
> srcLevel);
>  
> -   /* For desktop GL, we do our blits with no net sRGB decode or encode.
> -*
> -* However, if both the src and dst can be srgb decode/encoded, enable 
> them
> -* so that we do any blending (from scaling or from MSAA resolves) in the
> -* right colorspace.
> -*
> -* Our choice of not doing any net encode/decode is from the GL 3.0
> -* specification:
> -*
> -* "Blit operations bypass the fragment pipeline. The only fragment
> -*  operations which affect a blit are the pixel ownership test and 
> the
> -*  scissor test."
> -*
> -* The GL 4.4 specification disagrees and says that the sRGB part of the
> -* fragment pipeline applies, but this was found to break applications
> -* (such as Left 4 Dead 2).
> -*
> -* However, for ES 3.0, we follow the specification and perform sRGB
> -* decoding and encoding.  The specification has always been clear in
> -* the ES world, and hasn't changed over time.
> -*/
> if (ctx->Extensions.EXT_texture_sRGB_decode) {
> -  bool src_srgb = _mesa_get_format_color_encoding(rb->Format) == GL_SRGB;
> -  if (save->API == API_OPENGLES2 && ctx->Version >= 30) {
> - /* From the ES 3.0.4 specification, page 198:
> -  * "When values are taken from the read buffer, if the value of
> -  *  FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
> -  *  attachment corresponding to the read buffer is SRGB (see section
> -  *  6.1.13), the red, green, and blue components are converted from
> -  *  the non-linear sRGB color space according to equation 3.24.
> -  *
> -  *  When values are written to the draw buffers, blit operations
> -  *  bypass the fragment pipeline. The only fragment operations which
> -  *  affect a blit are the pixel ownership test, the scissor test,
> -  *  and sRGB conversion (see section 4.1.8)."
> -  */
> - _mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
> -   src_srgb ? GL_DECODE_EXT
> -: GL_SKIP_DECODE_EXT);
> - _mesa_set_framebuffer_srgb(ctx, drawFb->Visual.sRGBCapable);
> -  } else {
> - if (src_srgb && drawFb->Visual.sRGBCapable) {
> -_mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
> -  GL_DECODE_EXT);
> -_mesa_set_framebuffer_srgb(ctx, GL_TRUE);
> - } else {
> -_mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
> -  GL_SKIP_DECODE_EXT);
> -/* set_framebuffer_srgb was set by _mesa_meta_begin(). */
> - }
> -  }
> +  /* The GL 4.4 spec, section 18.3.1 ("Blitting Pixel Rectangles") says:
> +   *
> +   *"When values are taken from the read buffer, if FRAMEBUFFER_SRGB
> +   * is enabled and the value of 
> FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
> +   * for the framebuffer attachment corresponding to the read buffer
> +   * is SRGB (see section 9.2.3), the red, green, and blue components
> +   * are converted from the non-linear sRGB color space according to
> +   * equation 3.24.
> +   *
> +   * When values are written to the draw buffers, blit operations
> +   * bypass most of the fragment pipeline.  The only fragment
> +   * operations which affect a blit are the pixel ownership test,
> +   * the scissor test, and sRGB conversion (see section 17.3.9)."
> +   *
> +   * ES 3.0 contains nearly 

Re: [Mesa-dev] [PATCH 2/2] anv/clear: Clear E5B9G9R9 images as R32_UINT

[Nanley Chery]

On Wed, Aug 03, 2016 at 01:06:10PM -0700, Jason Ekstrand wrote:
> We can't actually clear these images normally because we can't render to
> them.  Instead, we have to manually unpack the rgb9e5 color value on the
> CPU and clear it as R32_UINT.  We still have a bit of work to do to clear
> non-power-of-two images, but this should get all of the power-of-two clears
> working on at least Haswell.

Could you mention which CTS tests this fixes? That would help me to test
the correctness of this change.

> 
> Cc: "12.0" 
> ---
>  src/intel/vulkan/anv_meta_clear.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_meta_clear.c 
> b/src/intel/vulkan/anv_meta_clear.c
> index fa07ec1..d8b5ce0 100644
> --- a/src/intel/vulkan/anv_meta_clear.c
> +++ b/src/intel/vulkan/anv_meta_clear.c
> @@ -25,6 +25,8 @@
>  #include "anv_private.h"
>  #include "nir/nir_builder.h"
>  
> +#include "gallium/auxiliary/util/u_format_rgb9e5.h"
> +
>  /** Vertex attributes for color clears.  */
>  struct color_clear_vattrs {
> struct anv_vue_header vue_header;
> @@ -760,6 +762,16 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
>  {
> VkDevice device_h = anv_device_to_handle(cmd_buffer->device);
>  
> +   VkFormat vk_format = image->vk_format;
> +   if (vk_format == VK_FORMAT_E5B9G9R9_UFLOAT_PACK32) {
> +  /* We can't actually render to this format so we have to work around it
> +   * by manualy unpacking and using R32_UINT.

s/manualy/manually/

> +   */
> +  clear_value.color.uint32[0] =
> + float3_to_rgb9e5(clear_value.color.float32);
> +  vk_format = VK_FORMAT_R32_UINT;
> +   }
> +
> for (uint32_t r = 0; r < range_count; r++) {
>const VkImageSubresourceRange *range = [r];
>for (uint32_t l = 0; l < anv_get_levelCount(image, range); ++l) {
> @@ -773,7 +785,7 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
>.sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
>.image = anv_image_to_handle(image),
>.viewType = anv_meta_get_view_type(image),
> -  .format = image->vk_format,
> +  .format = vk_format,
>.subresourceRange = {
>   .aspectMask = range->aspectMask,
>   .baseMipLevel = range->baseMipLevel + l,
> @@ -800,7 +812,7 @@ anv_cmd_clear_image(struct anv_cmd_buffer *cmd_buffer,
> );
>  
>  VkAttachmentDescription att_desc = {
> -   .format = iview.vk_format,
> +   .format = vk_format,
> .loadOp = VK_ATTACHMENT_LOAD_OP_LOAD,
> .storeOp = VK_ATTACHMENT_STORE_OP_STORE,
> .stencilLoadOp = VK_ATTACHMENT_LOAD_OP_LOAD,
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 6/7] egl/android: Add support for YV12 pixel format (v2)

[Chad Versace]

On 08/02/2016 04:07 AM, Tomasz Figa wrote:

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

v2: Use const array defined just for YV12 instead of trying to be overly
generic.

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





@@ -512,22 +518,60 @@ static _EGLImage *
 droid_create_image_from_prime_fd(_EGLDisplay *disp, _EGLContext *ctx,
  struct ANativeWindowBuffer *buf, int fd)
 {
+   unsigned int offsets[3] = { 0, 0, 0 };
+   unsigned int pitches[3] = { 0, 0, 0 };
+
const int fourcc = get_fourcc(buf->format);
-   const int pitch = buf->stride * get_format_bpp(buf->format);
+   if (fourcc == -1) {
+  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
+  return NULL;
+   }

-   const EGLint attr_list[14] = {
+   pitches[0] = buf->stride * get_format_bpp(buf->format);
+   if (pitches[0] == 0) {
+  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
+  return NULL;
+   }
+
+   switch (buf->format) {
+   case HAL_PIXEL_FORMAT_YV12:
+  /* Y plane is assumed to be at offset 0. */
+  /* Cr plane is located after Y plane */
+  offsets[1] = offsets[0] + pitches[0] * buf->height;
+  pitches[1] = ALIGN(pitches[0] / 2, 16);
+  /* Cb plane is located after Cr plane */
+  offsets[2] = offsets[1] + pitches[1] * buf->height / 2;


I believe the above should be
   offsets[2] = offsets[1] + pitches[1] * ALIGN(buf->height, 2) / 2;
to accommodate buffers with odd height.

That's the only issue I found in this patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/95] i965/vec4: handle 32 and 64 bit channels in liveness analysis

[Francisco Jerez]

"Juan A. Suarez Romero"  writes:

> On Mon, 2016-08-08 at 16:12 +0200, Juan A. Suarez Romero wrote:
>> Hmm... what about the case of exec_size == 4 and writing just a
>> float? 
>> 
>> I understand in this case we only should mark one word, so the loop
>> should  not be 2*inst->regs_written.
>> 
>> Note that in the original patch that was the case for using offs ==
>> 0.
>> So I guess we should compute if we should use 1 or 2 times
>> regs_written.
>
>
> Thinking more carefully, I think it is fine using 2*regs_written/read
> in this case.
>

The fundamental problem is that regs_written is expressed in units of
whole GRFs, but SIMD4 single-precision instructions typically write less
than one GRF, which will cause you to overestimate the number of dwords
written or read by the instruction (that's exactly what I was referring
to earlier with losing accuracy with sub-GRF writes).

I wouldn't worry too much about this right now, because it will only
cause you to calculate slightly pessimistic live intervals for the
variables used in such instructions, and shouldn't ever lead to program
miscompilation.  Overriding the dwords-per-vec4-component factor
depending on the SIMD width of the instruction seems like a hack that
could potentially hurt more than it would help (What if a
single-precision SIMD4 instruction actually reads or writes the whole
GRF register because it has multiple output phases?  How do you know?).

The right solution would be to represent regs_written in units that give
you sufficient accuracy, but I think there is enough going on in this
series that I wouldn't bother to fix that in addition.  We hadn't been
using SIMD4 instructions in the vec4 back-end until now, which means
that this inaccuracy shouldn't affect existing code or lead to
performance regressions, and the FS back-end has exactly the same
problem so you could potentially fix both at the same time. ;)

> So forget about my comment!
>
>
>   J.A.


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

Re: [Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

[Matt Turner]

On Mon, Aug 8, 2016 at 9:52 AM, Jan Vesely  wrote:
> On Mon, 2016-08-08 at 08:54 -0700, Ian Romanick wrote:
>> On 08/05/2016 07:05 PM, ⚛ wrote:
>> >
>> > On Sat, Aug 6, 2016 at 3:37 AM, Jan Vesely 
>> > wrote:
>> > >
>> > > On Sat, 2016-08-06 at 02:42 +0200, Jan Ziak wrote:
>> > > >
>> > > > Mesa source code prior to this patch uses both RTLD_NOW and
>> > > > RTLD_LAZY.
>> > > > This patch removes all RTLD_NOW in favor of RTLD_LAZY.
>> > > >
>> > > > In comparison to early binding, lazy binding reduces CPU
>> > > > instruction
>> > > > count
>> > > > of small GL apps (e.g: glxinfo) by 6 million instructions.
>> > > > Larger apps won't notice the difference.
>> > >
>> > > this is IMO micro-optimization in the wrong place. RTLD_NOW also
>> > > guarantees that symbols were successfully resolved. Changing it
>> > > to lazy
>> > > may hide bugs by deferring failure to future point in the
>> > > execution.
>> >
>> > Question 1: Are you suggesting to replace current RTLD_LAZY in all
>> > locations with RTLD_NOW?
>> >
>> > Question 2: Exists there a reason for _not_ linking
>> > radeonsi_dri.so,
>> > swrastg_dri.so, etc, directly to Mesa's libGL.so? The Gallium
>> > *_dri.so libraries are the same inode on the filesystem.
>>
>> This is an intentional feature.  This allows libGL and *_dri.so to be
>> installed from different versions.  It also allows the possibility
>> for a
>> *_dri.so from outside the Mesa source tree.
>
> Just out of curiosity, what is the motivation for using different _dri
> and mesa version?
> Are there license restrictions that prevent distributing mesa with
> custom _dri binaries?

No idea if anyone actually does this, but in theory it allows the
usage of the old DRI drivers (i810, mach64, mga, r128, savage, sis,
tdfx, and unichrome) with a newer libGL.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: gen7/75: enable multisampling (v3)

[Jason Ekstrand]

On Fri, Aug 5, 2016 at 11:37 PM, Jason Ekstrand 
wrote:

> I am going to try and give this a proper look on Monday.  Given how
> sketchy the multisampling support is on gen7 at the moment, I am a but
> concerned that it doesn't fix more tests.  What's left to fix for MSAA?
>
I just pushed the patches to rework emit_rs_state to be the same on gen8
and gen7, so you'll have to rebase but I think things are much cleaner now.

For this patch in particular, we should probably rename it to something
more like "anv/pipeline/gen7: Set multisample modes"  because it doesn't
really "enable" multisampling.  In some sense, multisampling was already
enabled, just badly.

The other obvious thing that we need to do for MSAA on gen7 is to actually
advertise sampleRateShading.  Everything else should be there with this
patch, we just need to enable it and make sure we're passing the tests.


>
> On Aug 5, 2016 4:55 PM, "Lionel Landwerlin"  wrote:
>
> Fixes the following failures :
>
> dEQP-VK.api.copy_and_blit.resolve_image.whole_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.whole_8_bit
> dEQP-VK.api.copy_and_blit.resolve_image.partial_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.partial_8_bit
> dEQP-VK.api.copy_and_blit.resolve_image.with_regions_4_bit
> dEQP-VK.api.copy_and_blit.resolve_image.with_regions_8_bit
>
> Tested on IVB/HSW
>
> v2: Check pMultisampleState is not NULL
>
> v3: Drop rasterization state rename (Anuj)
> Fix value of MultisampleRasterizationMode in 3DSTATE_SF
>
> Signed-off-by: Lionel Landwerlin 
> Cc: Anuj Phogat 
> ---
>  src/intel/vulkan/gen7_pipeline.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/src/intel/vulkan/gen7_pipeline.c
> b/src/intel/vulkan/gen7_pipeline.c
> index 6acdd85..5ddb922 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -37,6 +37,7 @@
>  static void
>  gen7_emit_rs_state(struct anv_pipeline *pipeline,
> const VkPipelineRasterizationStateCreateInfo *info,
> +   uint32_t samples,
> const struct anv_graphics_pipeline_create_info *extra)
>  {
> struct GENX(3DSTATE_SF) sf = {
> @@ -56,7 +57,8 @@ gen7_emit_rs_state(struct anv_pipeline *pipeline,
>/* uint32_t
> LineEndCapAntialiasingRegionWidth; */
>.ScissorRectangleEnable   =  !(extra &&
> extra->use_rectlist),
>
> -  /* uint32_t
>  MultisampleRasterizationMode; */
> +  .MultisampleRasterizationMode = samples > 1 ?
> +  MSRASTMODE_ON_PATTERN :
> MSRASTMODE_OFF_PIXEL,
>/* bool LastPixelEnable; */
>
>.TriangleStripListProvokingVertexSelect   = 0,
> @@ -107,8 +109,16 @@ genX(graphics_pipeline_create)(
> assert(pCreateInfo->pVertexInputState);
> emit_vertex_input(pipeline, pCreateInfo->pVertexInputState, extra);
>
> +   if (pCreateInfo->pMultisampleState &&
> +   pCreateInfo->pMultisampleState->rasterizationSamples > 1)
> +  anv_finishme("VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_
> CREATE_INFO");
> +
> +   uint32_t samples = pCreateInfo->pMultisampleState ?
> +  pCreateInfo->pMultisampleState->rasterizationSamples
> : 1;
> +
> assert(pCreateInfo->pRasterizationState);
> -   gen7_emit_rs_state(pipeline, pCreateInfo->pRasterizationState, extra);
> +   gen7_emit_rs_state(pipeline, pCreateInfo->pRasterizationState,
> +  samples, extra);
>
>
I think I marginally prefer passing pMultisampleState in, but I'm ok with
samples since that's all we actually need.  Meh


>
> emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass,
> subpass);
>
> @@ -121,11 +131,6 @@ genX(graphics_pipeline_create)(
>   pCreateInfo->pRasterizationState, extra);
> emit_3dstate_streamout(pipeline, pCreateInfo->pRasterizationState);
>
> -   if (pCreateInfo->pMultisampleState &&
> -   pCreateInfo->pMultisampleState->rasterizationSamples > 1)
> -  anv_finishme("VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_
> CREATE_INFO");
> -
> -   uint32_t samples = 1;
> uint32_t log2_samples = __builtin_ffs(samples) - 1;
>
> anv_batch_emit(>batch, GENX(3DSTATE_MULTISAMPLE), ms) {
> @@ -312,6 +317,11 @@ genX(graphics_pipeline_create)(
>   }
>
>   wm.BarycentricInterpolationMode=
> wm_prog_data->barycentric_interp_modes;
> +
> + wm.MultisampleRasterizationMode= samples > 1 ?
> +  MSRASTMODE_ON_PATTERN :
> MSRASTMODE_OFF_PIXEL;
> + wm.MultisampleDispatchMode =
> wm_prog_data->persample_dispatch ?
> +  MSDISPMODE_PERSAMPLE :
> MSDISPMODE_PERPIXEL;
>}
> }
>
> --
> 2.8.1
>
> 

[Mesa-dev] [Bug 97231] GL_DEPTH_CLAMP doesn't clamp to the far plane

[bugzilla-daemon]

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

--- Comment #7 from Jules Blok  ---
Created attachment 125603
  --> https://bugs.freedesktop.org/attachment.cgi?id=125603=edit
FIFO log for Dolphin Emulator

(In reply to Roland Scheidegger from comment #6)
> The replays don't work with llvmpipe since they require glsl 400 and I
> couldn't make them work with version overrides neither.

It probably uses some extensions llvmpipe doesn't support, I'll try and get you
an apitrace from llvmpipe. You can also try and compile the Dolphin Emulator,
I've attached a replay file (FIFO log) you can drag into the emulator.

(In reply to Roland Scheidegger from comment #6)
> Not sure though why it wouldn't work without reversed depth, I know this
> feature generally works (with d3d10 in particular, which forbids reversing
> depth hence the bug there going unnoticed).

It seems you misunderstood me, it doesn't work with either reversed depth or
normal depth on Mesa. So reverse depth has nothing to do with the issue, it was
just a small thing I changed for reasons unrelated to this issue. I can
reproduce the problem either way.

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

Re: [Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

[Ian Romanick]

On 08/08/2016 09:52 AM, Jan Vesely wrote:
> On Mon, 2016-08-08 at 08:54 -0700, Ian Romanick wrote:
>> On 08/05/2016 07:05 PM, ⚛ wrote:
>>>
>>> On Sat, Aug 6, 2016 at 3:37 AM, Jan Vesely 
>>> wrote:

 On Sat, 2016-08-06 at 02:42 +0200, Jan Ziak wrote:
>
> Mesa source code prior to this patch uses both RTLD_NOW and
> RTLD_LAZY.
> This patch removes all RTLD_NOW in favor of RTLD_LAZY.
>
> In comparison to early binding, lazy binding reduces CPU
> instruction
> count
> of small GL apps (e.g: glxinfo) by 6 million instructions.
> Larger apps won't notice the difference.

 this is IMO micro-optimization in the wrong place. RTLD_NOW also
 guarantees that symbols were successfully resolved. Changing it
 to lazy
 may hide bugs by deferring failure to future point in the
 execution.
>>>
>>> Question 1: Are you suggesting to replace current RTLD_LAZY in all
>>> locations with RTLD_NOW?
>>>
>>> Question 2: Exists there a reason for _not_ linking
>>> radeonsi_dri.so,
>>> swrastg_dri.so, etc, directly to Mesa's libGL.so? The Gallium
>>> *_dri.so libraries are the same inode on the filesystem.
>>
>> This is an intentional feature.  This allows libGL and *_dri.so to be
>> installed from different versions.  It also allows the possibility
>> for a
>> *_dri.so from outside the Mesa source tree.
> 
> Just out of curiosity, what is the motivation for using different _dri
> and mesa version?
> Are there license restrictions that prevent distributing mesa with
> custom _dri binaries?

So that you can update one without changing the other.  It's also useful
as a developer... I can have one libGL that I point at a variety of
i965_dri.so builds for comparison testing, etc.  We (I) originally
implemented this feature so that non-Mesa drivers could use a single
libGL.  A couple (very uncommon) drivers used this feature, but it
didn't gain much traction.

Once glvnd is more widely deployed and has had more practical
experience, it may be worth reevaluating how some of this is
implemented.  There's quite a bit of mechanism involved in, for example,
the remap table stuff.  Removing that would at least allow some code
simplification / removal.

> I know that virtualbox uses this approach, it breaks when guest distro
> updates mesa packages (until vbox-additions catch up).
> 
> regards,
> Jan
> 




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

Re: [Mesa-dev] [PATCH 6/7] isl: Add a helper for getting a depth format from an isl_format

[Kenneth Graunke]

Patches 6 and 7 are
Reviewed-by: Kenneth Graunke 


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri: use 'bool' instead 'int' for boolean variables

[Ian Romanick]

On 08/08/2016 10:20 AM, Rob Clark wrote:
> how strict are we on that actually?  I think whenever we add new gl
> entry points (ie. implementing new extension, etc) we kinda sorta
> break ABI, don't we?  I thought mixing/matching libGL vs *_dri.so was
> at least not recommended..

No... we go to great lengths to make *_dri.so query libGL to know where
a new function goes in the dispatch table.  If libGL doesn't know a
location for the new function, it dynamically assigns one.  That's what
all the remap table stuff is.

> BR,
> -R
> 
> On Mon, Aug 8, 2016 at 12:22 PM, Ian Romanick  wrote:
>> I'm pretty sure this breaks ABI.  Did you try using an unpatched libGL
>> with a patched *_dri.so (and vice-versa)?
>>
>> On 08/01/2016 06:21 AM, Jan Ziak wrote:
>>> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
>>> ---
>>>  src/egl/drivers/dri2/egl_dri2.h   | 19 ++-
>>>  src/gallium/auxiliary/vl/vl_winsys_dri3.c |  3 ++-
>>>  src/glx/dri3_priv.h   |  5 +++--
>>>  src/loader/loader.c   |  7 ---
>>>  src/loader/loader.h   |  4 +++-
>>>  5 files changed, 22 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/src/egl/drivers/dri2/egl_dri2.h 
>>> b/src/egl/drivers/dri2/egl_dri2.h
>>> index 4577875..e406443 100644
>>> --- a/src/egl/drivers/dri2/egl_dri2.h
>>> +++ b/src/egl/drivers/dri2/egl_dri2.h
>>> @@ -28,6 +28,7 @@
>>>  #ifndef EGL_DRI2_INCLUDED
>>>  #define EGL_DRI2_INCLUDED
>>>
>>> +#include 
>>>  #include 
>>>
>>>  #ifdef HAVE_X11_PLATFORM
>>> @@ -160,7 +161,7 @@ struct dri2_egl_display
>>> int   dri2_major;
>>> int   dri2_minor;
>>> __DRIscreen  *dri_screen;
>>> -   int   own_dri_screen;
>>> +   bool  own_dri_screen;
>>> const __DRIconfig   **driver_configs;
>>> void *driver;
>>> const __DRIcoreExtension   *core;
>>> @@ -181,8 +182,8 @@ struct dri2_egl_display
>>>  * dri2_make_current (tracks if there are active contexts/surfaces). */
>>> int   ref_count;
>>>
>>> -   int   own_device;
>>> -   int   invalidate_available;
>>> +   bool  own_device;
>>> +   bool  invalidate_available;
>>> int   min_swap_interval;
>>> int   max_swap_interval;
>>> int   default_swap_interval;
>>> @@ -201,7 +202,7 @@ struct dri2_egl_display
>>>  #ifdef HAVE_X11_PLATFORM
>>> xcb_connection_t *conn;
>>> int  screen;
>>> -   int  swap_available;
>>> +   bool swap_available;
>>>  #ifdef HAVE_DRI3
>>> struct loader_dri3_extensions loader_dri3_ext;
>>>  #endif
>>> @@ -214,13 +215,13 @@ struct dri2_egl_display
>>> struct wl_drm*wl_drm;
>>> struct wl_shm*wl_shm;
>>> struct wl_event_queue*wl_queue;
>>> -   intauthenticated;
>>> +   bool  authenticated;
>>> intformats;
>>> uint32_t  capabilities;
>>>  #endif
>>>
>>> -   int  is_render_node;
>>> -   intis_different_gpu;
>>> +   bool is_render_node;
>>> +   bool is_different_gpu;
>>>  };
>>>
>>>  struct dri2_egl_context
>>> @@ -244,7 +245,7 @@ struct dri2_egl_surface
>>> __DRIdrawable   *dri_drawable;
>>> __DRIbuffer  buffers[5];
>>> int  buffer_count;
>>> -   int  have_fake_front;
>>> +   bool have_fake_front;
>>>
>>>  #ifdef HAVE_X11_PLATFORM
>>> xcb_drawable_t   drawable;
>>> @@ -282,7 +283,7 @@ struct dri2_egl_surface
>>>  #ifdef HAVE_DRM_PLATFORM
>>>struct gbm_bo   *bo;
>>>  #endif
>>> -  int locked;
>>> +  boollocked;
>>>int age;
>>> } color_buffers[4], *back, *current;
>>>  #endif
>>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
>>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>> index 493e645..7cb6c18 100644
>>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>>> @@ -25,6 +25,7 @@
>>>   *
>>>   
>>> **/
>>>
>>> +#include 
>>>  #include 
>>>
>>>  #include 
>>> @@ -627,7 +628,7 @@ vl_dri3_screen_create(Display *display, int screen)
>>> xcb_dri3_open_reply_t *open_reply;
>>> xcb_get_geometry_cookie_t geom_cookie;
>>> xcb_get_geometry_reply_t *geom_reply;
>>> -   int is_different_gpu;
>>> +   bool is_different_gpu;
>>> int fd;
>>>
>>> assert(display);
>>> diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
>>> index 0822377..bfb0786 100644
>>> --- a/src/glx/dri3_priv.h
>>> +++ 

Re: [Mesa-dev] [PATCH 5/7] anv/pipeline: Unify 3DSTATE_RASTER and 3DSTATE_SF setup between gen7 and gen8

[Kenneth Graunke]

On Saturday, August 6, 2016 10:31:20 AM PDT Jason Ekstrand wrote:
> ---
>  src/intel/vulkan/gen7_pipeline.c  | 43 +
>  src/intel/vulkan/gen8_pipeline.c  | 48 
>  src/intel/vulkan/genX_pipeline_util.h | 60 
> +++
>  3 files changed, 61 insertions(+), 90 deletions(-)
> 
> diff --git a/src/intel/vulkan/gen7_pipeline.c 
> b/src/intel/vulkan/gen7_pipeline.c
> index 5a6158e..01b2793 100644
> --- a/src/intel/vulkan/gen7_pipeline.c
> +++ b/src/intel/vulkan/gen7_pipeline.c
> @@ -34,47 +34,6 @@
>  
>  #include "genX_pipeline_util.h"
>  
> -static void
> -gen7_emit_rs_state(struct anv_pipeline *pipeline,
> -   const VkPipelineRasterizationStateCreateInfo *info,
> -   const struct anv_graphics_pipeline_create_info *extra)
> -{
> -   struct GENX(3DSTATE_SF) sf = {
> -  GENX(3DSTATE_SF_header),
> -
> -  /* LegacyGlobalDepthBiasEnable */
> -
> -  .StatisticsEnable = true,

You've dropped StatisticsEnable - anv was setting it on Gen7 but not
Gen8+.  Now it's not setting it at all.  Apparently brw sets it on Gen6+.

This controls CL_PRIMITIVES_COUNT, which is necessary for the
VK_QUERY_PIPELINE_STATISTIC_CLIPPING_PRIMITIVES_BIT pipeline statistics
query.

Whichever way you decide to set it, it's probably worth changing in a
separate patch prior to this.

> -  .FrontFaceFillMode= 
> vk_to_gen_fillmode[info->polygonMode],
> -  .BackFaceFillMode = 
> vk_to_gen_fillmode[info->polygonMode],
> -  .ViewportTransformEnable  = !(extra && 
> extra->use_rectlist),
> -  .FrontWinding = 
> vk_to_gen_front_face[info->frontFace],
> -  /* bool AntiAliasingEnable; */
> -
> -  .CullMode = 
> vk_to_gen_cullmode[info->cullMode],
> -
> -  /* uint32_t 
> LineEndCapAntialiasingRegionWidth; */
> -  .ScissorRectangleEnable   =  !(extra && 
> extra->use_rectlist),
> -
> -  /* uint32_t 
> MultisampleRasterizationMode; */
> -  /* bool LastPixelEnable; */
> -
> -  .TriangleStripListProvokingVertexSelect   = 0,
> -  .LineStripListProvokingVertexSelect   = 0,
> -  .TriangleFanProvokingVertexSelect = 1,
> -
> -  /* uint32_t AALineDistanceMode; */
> -  /* uint32_t 
> VertexSubPixelPrecisionSelect; */
> -  .PointWidthSource = Vertex,
> -  .PointWidth   = 1.0,
> -  .GlobalDepthOffsetEnableSolid = info->depthBiasEnable,
> -  .GlobalDepthOffsetEnableWireframe = info->depthBiasEnable,
> -  .GlobalDepthOffsetEnablePoint = info->depthBiasEnable,
> -   };
> -
> -   GENX(3DSTATE_SF_pack)(NULL, >gen7.sf, );
> -}
> -
>  VkResult
>  genX(graphics_pipeline_create)(
>  VkDevice_device,
> @@ -108,7 +67,7 @@ genX(graphics_pipeline_create)(
> emit_vertex_input(pipeline, pCreateInfo->pVertexInputState, extra);
>  
> assert(pCreateInfo->pRasterizationState);
> -   gen7_emit_rs_state(pipeline, pCreateInfo->pRasterizationState, extra);
> +   emit_rs_state(pipeline, pCreateInfo->pRasterizationState, extra);
>  
> emit_ds_state(pipeline, pCreateInfo->pDepthStencilState, pass, subpass);
>  
> diff --git a/src/intel/vulkan/gen8_pipeline.c 
> b/src/intel/vulkan/gen8_pipeline.c
> index ad8a643..94b0c48 100644
> --- a/src/intel/vulkan/gen8_pipeline.c
> +++ b/src/intel/vulkan/gen8_pipeline.c
> @@ -45,54 +45,6 @@ emit_ia_state(struct anv_pipeline *pipeline,
>  }
>  
>  static void
> -emit_rs_state(struct anv_pipeline *pipeline,
> -  const VkPipelineRasterizationStateCreateInfo *info,
> -  const struct anv_graphics_pipeline_create_info *extra)
> -{
> -   struct GENX(3DSTATE_SF) sf = {
> -  GENX(3DSTATE_SF_header),
> -   };
> -
> -   sf.ViewportTransformEnable = !(extra && extra->use_rectlist);
> -   sf.TriangleStripListProvokingVertexSelect = 0;
> -   sf.LineStripListProvokingVertexSelect = 0;
> -   sf.TriangleFanProvokingVertexSelect = 1;
> -   sf.PointWidthSource = Vertex;
> -   sf.PointWidth = 1.0;
> -
> -   GENX(3DSTATE_SF_pack)(NULL, pipeline->gen8.sf, );
> -
> -   struct GENX(3DSTATE_RASTER) raster = {
> -  GENX(3DSTATE_RASTER_header),
> -   };
> -
> -   /* For details on 3DSTATE_RASTER multisample state, see the BSpec table
> -* "Multisample Modes State".
> -*/
> -   raster.DXMultisampleRasterizationEnable = true;
> -   raster.ForcedSampleCount = FSC_NUMRASTSAMPLES_0;
> -   raster.ForceMultisampling = false;
> -
> -   raster.FrontWinding = vk_to_gen_front_face[info->frontFace];
> -   raster.CullMode = 

Re: [Mesa-dev] [PATCH] dri: use 'bool' instead 'int' for boolean variables

[Ian Romanick]

On 08/08/2016 09:38 AM, ⚛ wrote:
> On Mon, Aug 8, 2016 at 6:22 PM, Ian Romanick  wrote:
>> I'm pretty sure this breaks ABI.  Did you try using an unpatched libGL
>> with a patched *_dri.so (and vice-versa)?
> 
> Can you be more specific?

Eh... build Mesa.  Save the libGL and *_dri.so.  Apply patch.  Build
again.  Run applications with LD_PRELOAD and LIBGL_DRIVERS_PATH (or
EGL_DRIVERS_PATH) set to mix the old and new.

> Where is the ABI documented?

I don't know this particular code that well, so this may be a non-issue.
 Generally, any structures that represent data that is accessed in both
libGL (or libEGL) and *_dri.so are ABI.  Usually these structures are
versioned so that fields can be added... you just don't ever get to
change or remove fields.  The .h file is the documentation.
include/GL/internal/dri_interface.h is the prime example
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri: use 'bool' instead 'int' for boolean variables

[Rob Clark]

how strict are we on that actually?  I think whenever we add new gl
entry points (ie. implementing new extension, etc) we kinda sorta
break ABI, don't we?  I thought mixing/matching libGL vs *_dri.so was
at least not recommended..

BR,
-R

On Mon, Aug 8, 2016 at 12:22 PM, Ian Romanick  wrote:
> I'm pretty sure this breaks ABI.  Did you try using an unpatched libGL
> with a patched *_dri.so (and vice-versa)?
>
> On 08/01/2016 06:21 AM, Jan Ziak wrote:
>> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
>> ---
>>  src/egl/drivers/dri2/egl_dri2.h   | 19 ++-
>>  src/gallium/auxiliary/vl/vl_winsys_dri3.c |  3 ++-
>>  src/glx/dri3_priv.h   |  5 +++--
>>  src/loader/loader.c   |  7 ---
>>  src/loader/loader.h   |  4 +++-
>>  5 files changed, 22 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/egl_dri2.h 
>> b/src/egl/drivers/dri2/egl_dri2.h
>> index 4577875..e406443 100644
>> --- a/src/egl/drivers/dri2/egl_dri2.h
>> +++ b/src/egl/drivers/dri2/egl_dri2.h
>> @@ -28,6 +28,7 @@
>>  #ifndef EGL_DRI2_INCLUDED
>>  #define EGL_DRI2_INCLUDED
>>
>> +#include 
>>  #include 
>>
>>  #ifdef HAVE_X11_PLATFORM
>> @@ -160,7 +161,7 @@ struct dri2_egl_display
>> int   dri2_major;
>> int   dri2_minor;
>> __DRIscreen  *dri_screen;
>> -   int   own_dri_screen;
>> +   bool  own_dri_screen;
>> const __DRIconfig   **driver_configs;
>> void *driver;
>> const __DRIcoreExtension   *core;
>> @@ -181,8 +182,8 @@ struct dri2_egl_display
>>  * dri2_make_current (tracks if there are active contexts/surfaces). */
>> int   ref_count;
>>
>> -   int   own_device;
>> -   int   invalidate_available;
>> +   bool  own_device;
>> +   bool  invalidate_available;
>> int   min_swap_interval;
>> int   max_swap_interval;
>> int   default_swap_interval;
>> @@ -201,7 +202,7 @@ struct dri2_egl_display
>>  #ifdef HAVE_X11_PLATFORM
>> xcb_connection_t *conn;
>> int  screen;
>> -   int  swap_available;
>> +   bool swap_available;
>>  #ifdef HAVE_DRI3
>> struct loader_dri3_extensions loader_dri3_ext;
>>  #endif
>> @@ -214,13 +215,13 @@ struct dri2_egl_display
>> struct wl_drm*wl_drm;
>> struct wl_shm*wl_shm;
>> struct wl_event_queue*wl_queue;
>> -   intauthenticated;
>> +   bool  authenticated;
>> intformats;
>> uint32_t  capabilities;
>>  #endif
>>
>> -   int  is_render_node;
>> -   intis_different_gpu;
>> +   bool is_render_node;
>> +   bool is_different_gpu;
>>  };
>>
>>  struct dri2_egl_context
>> @@ -244,7 +245,7 @@ struct dri2_egl_surface
>> __DRIdrawable   *dri_drawable;
>> __DRIbuffer  buffers[5];
>> int  buffer_count;
>> -   int  have_fake_front;
>> +   bool have_fake_front;
>>
>>  #ifdef HAVE_X11_PLATFORM
>> xcb_drawable_t   drawable;
>> @@ -282,7 +283,7 @@ struct dri2_egl_surface
>>  #ifdef HAVE_DRM_PLATFORM
>>struct gbm_bo   *bo;
>>  #endif
>> -  int locked;
>> +  boollocked;
>>int age;
>> } color_buffers[4], *back, *current;
>>  #endif
>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> index 493e645..7cb6c18 100644
>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> @@ -25,6 +25,7 @@
>>   *
>>   **/
>>
>> +#include 
>>  #include 
>>
>>  #include 
>> @@ -627,7 +628,7 @@ vl_dri3_screen_create(Display *display, int screen)
>> xcb_dri3_open_reply_t *open_reply;
>> xcb_get_geometry_cookie_t geom_cookie;
>> xcb_get_geometry_reply_t *geom_reply;
>> -   int is_different_gpu;
>> +   bool is_different_gpu;
>> int fd;
>>
>> assert(display);
>> diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
>> index 0822377..bfb0786 100644
>> --- a/src/glx/dri3_priv.h
>> +++ b/src/glx/dri3_priv.h
>> @@ -54,6 +54,7 @@
>>   *   Kristian Høgsberg (k...@redhat.com)
>>   */
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -78,7 +79,7 @@ struct dri3_display
>> int dri3Minor;
>>
>> /* Present bits */
>> -   int hasPresent;
>> +   bool hasPresent;
>> int presentMajor;
>> int presentMinor;
>>  };
>> @@ -101,7 +102,7 @@ struct dri3_screen {
>>
>> void *driver;
>> 

Re: [Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

[Jan Vesely]

On Mon, 2016-08-08 at 08:54 -0700, Ian Romanick wrote:
> On 08/05/2016 07:05 PM, ⚛ wrote:
> > 
> > On Sat, Aug 6, 2016 at 3:37 AM, Jan Vesely 
> > wrote:
> > > 
> > > On Sat, 2016-08-06 at 02:42 +0200, Jan Ziak wrote:
> > > > 
> > > > Mesa source code prior to this patch uses both RTLD_NOW and
> > > > RTLD_LAZY.
> > > > This patch removes all RTLD_NOW in favor of RTLD_LAZY.
> > > > 
> > > > In comparison to early binding, lazy binding reduces CPU
> > > > instruction
> > > > count
> > > > of small GL apps (e.g: glxinfo) by 6 million instructions.
> > > > Larger apps won't notice the difference.
> > > 
> > > this is IMO micro-optimization in the wrong place. RTLD_NOW also
> > > guarantees that symbols were successfully resolved. Changing it
> > > to lazy
> > > may hide bugs by deferring failure to future point in the
> > > execution.
> > 
> > Question 1: Are you suggesting to replace current RTLD_LAZY in all
> > locations with RTLD_NOW?
> > 
> > Question 2: Exists there a reason for _not_ linking
> > radeonsi_dri.so,
> > swrastg_dri.so, etc, directly to Mesa's libGL.so? The Gallium
> > *_dri.so libraries are the same inode on the filesystem.
> 
> This is an intentional feature.  This allows libGL and *_dri.so to be
> installed from different versions.  It also allows the possibility
> for a
> *_dri.so from outside the Mesa source tree.

Just out of curiosity, what is the motivation for using different _dri
and mesa version?
Are there license restrictions that prevent distributing mesa with
custom _dri binaries?

I know that virtualbox uses this approach, it breaks when guest distro
updates mesa packages (until vbox-additions catch up).

regards,
Jan

> 
> > 
> > Question 3: Isn't the current status quo (i.e: not linking
> > radeonsi_dri.so directly to libGL.so) also a micro-optimization
> > that
> > can hide certain bugs?
> > 
> > Question 4: Is it planned for *_dri.so belonging to Gallium/DRI
> > _not_
> > to be mapped to the same inode on the filesystem in the future? If
> > there is no such plan, what was the original point of having
> > multiple
> > _dri.so files mapped to the same inode?
> > 
> > Thanks.
> > 
> 
-- 
Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri: use 'bool' instead 'int' for boolean variables

[⚛]

On Mon, Aug 8, 2016 at 6:22 PM, Ian Romanick  wrote:
> I'm pretty sure this breaks ABI.  Did you try using an unpatched libGL
> with a patched *_dri.so (and vice-versa)?

Can you be more specific?

Where is the ABI documented?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: Add an IO scalarizing pass using the intrinsic's first_component.

[Jason Ekstrand]

On Aug 8, 2016 9:18 AM, "Eric Anholt"  wrote:
>
> Timothy Arceri  writes:
>
> > On Sat, 2016-08-06 at 10:15 +1000, Timothy Arceri wrote:
> >> On Fri, 2016-08-05 at 16:27 -0700, Eric Anholt wrote:
> >> > vc4 wants to have per-scalar IO load/stores so that dead code
> >> > elimination
> >> > can happen on a more granular basis,
> >
> > Out of interest what is it exactly that you are doing in the backend?
>
> Given that all of my IO is done as indidivual moves of scalars (with the
> exception of the color output, which is weird but is lowered by vc4 code
> anyway), I'd like to see all the scalar ops for setting up
> undefined/unused scalar slots get dropped.  I don't see much change from
> this, because dead code is easy to eliminate, but I think there were
> small diffs.  It also makes the output more readable by cutting the
> pointless vector ops.
>
> However, doing my IO as scalar has been a bit of a pain for other
> passes: The UCP and twoside lowering want a single load/store for the
> vector.  Because of this, I've also wondered if using the write_mask and
> extending nir_opt_dce() for per-channel liveness would be a better way
> to go.

I would very much like to see dead code extended to channels anyway. :-)

> > I was looking at brw_do_vector_splitting() and it seems to me that
> > moving that out of the Intel backend and making it also work on
> > varyings could be benefical to all drivers as we could extend it to
> > work across stages which would hopefully also improve varying packing.
> >
> > Currently it says:
> >
> > "This skips vectors in uniforms and varyings, which need to be
> > accessible as vectors for their access by the GL."
> >
> > But that really only applies to vs inputs and the outward facing stages
> > of SSOs.
>
> Yeah, I think that comment is stale at this point.  But we have a lot of
> that pass in NIR already (ALU, const, io), and instead of extending the
> GLSL IR pass I'd rather see a NIR cross-linking pass.
>
> On the topic of cross-linking: Back in the day, i965 would look at the
> VS outputs and propagate constants into the FS inputs.  This was really
> painful, slow code to maintain, and we eventually just dropped it.
> However, if we know that a VS/FS pair are non-SSO, it seems like with
> NIR we could do that propagation really easily at link time.
>
> ___
> 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 12/18] mesa: Skip ES 3.0/3.1 transform feedback primitive counting error.

[Ian Romanick]

On 08/01/2016 10:29 AM, Kenneth Graunke wrote:
> This error condition is not implementable when using tessellation or
> geometry shaders.  The text was also removed from the ES 3.2 spec.
> I believe the intended behavior is to remove the error condition
> when either OES_geometry_shader or OES_tessellation_shader are
> exposed.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/main/api_validate.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 2ee2cd8..68f55b6 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -546,8 +546,20 @@ validate_draw_arrays(struct gl_context *ctx, const char 
> *func,
>  *
>  * This is in contrast to the behaviour of desktop GL, where the extra
>  * primitives are silently dropped from the transform feedback buffer.
> +*
> +* This text is removed in ES 3.2, presumably because it's not really
> +* implementable with geometry and tessellation shaders.  In fact,
> +* issue 13 of the OES_geometry_shader spec says:
> +*
> +* "Since we no longer require being able to predict how much geometry 
> will
> +*  be generated [...]"
> +*
> +* It isn't speaking about this condition specifically, but speaks of
> +* lifting similar transform feedback drawing restrictions.
>  */

This is the spec text that I quoted in my similar patch:

+*
+* The OES_geometry_shader spec says:
+*
+*Issues:
+*
+*(13) Does this extension change how transform feedback operates
+*compared to unextended OpenGL ES 3.0 or 3.1?
+*
+*RESOLVED: Yes. Because dynamic geometry amplification in a geometry
+*shader can make it difficult if not impossible to predict the amount
+*of geometry that may be generated in advance of executing the shader,
+*the draw-time error for transform feedback buffer overflow conditions
+*is removed and replaced with the GL behavior (primitives are not
+*written and the corresponding counter is not updated)...

> -   if (_mesa_is_gles3(ctx) && _mesa_is_xfb_active_and_unpaused(ctx)) {
> +   if (_mesa_is_gles3(ctx) && _mesa_is_xfb_active_and_unpaused(ctx) &&
> +   !_mesa_has_OES_geometry_shader(ctx) &&
> +   !_mesa_has_OES_tessellation_shader(ctx)) {
>size_t prim_count = vbo_count_tessellated_primitives(mode, count, 1);
>if (xfb_obj->GlesRemainingPrims < prim_count) {
>   _mesa_error(ctx, GL_INVALID_OPERATION,
> 

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

Re: [Mesa-dev] [PATCH] dri: use 'bool' instead 'int' for boolean variables

[Ian Romanick]

I'm pretty sure this breaks ABI.  Did you try using an unpatched libGL
with a patched *_dri.so (and vice-versa)?

On 08/01/2016 06:21 AM, Jan Ziak wrote:
> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
> ---
>  src/egl/drivers/dri2/egl_dri2.h   | 19 ++-
>  src/gallium/auxiliary/vl/vl_winsys_dri3.c |  3 ++-
>  src/glx/dri3_priv.h   |  5 +++--
>  src/loader/loader.c   |  7 ---
>  src/loader/loader.h   |  4 +++-
>  5 files changed, 22 insertions(+), 16 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index 4577875..e406443 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -28,6 +28,7 @@
>  #ifndef EGL_DRI2_INCLUDED
>  #define EGL_DRI2_INCLUDED
>  
> +#include 
>  #include 
>  
>  #ifdef HAVE_X11_PLATFORM
> @@ -160,7 +161,7 @@ struct dri2_egl_display
> int   dri2_major;
> int   dri2_minor;
> __DRIscreen  *dri_screen;
> -   int   own_dri_screen;
> +   bool  own_dri_screen;
> const __DRIconfig   **driver_configs;
> void *driver;
> const __DRIcoreExtension   *core;
> @@ -181,8 +182,8 @@ struct dri2_egl_display
>  * dri2_make_current (tracks if there are active contexts/surfaces). */
> int   ref_count;
>  
> -   int   own_device;
> -   int   invalidate_available;
> +   bool  own_device;
> +   bool  invalidate_available;
> int   min_swap_interval;
> int   max_swap_interval;
> int   default_swap_interval;
> @@ -201,7 +202,7 @@ struct dri2_egl_display
>  #ifdef HAVE_X11_PLATFORM
> xcb_connection_t *conn;
> int  screen;
> -   int  swap_available;
> +   bool swap_available;
>  #ifdef HAVE_DRI3
> struct loader_dri3_extensions loader_dri3_ext;
>  #endif
> @@ -214,13 +215,13 @@ struct dri2_egl_display
> struct wl_drm*wl_drm;
> struct wl_shm*wl_shm;
> struct wl_event_queue*wl_queue;
> -   intauthenticated;
> +   bool  authenticated;
> intformats;
> uint32_t  capabilities;
>  #endif
>  
> -   int  is_render_node;
> -   intis_different_gpu;
> +   bool is_render_node;
> +   bool is_different_gpu;
>  };
>  
>  struct dri2_egl_context
> @@ -244,7 +245,7 @@ struct dri2_egl_surface
> __DRIdrawable   *dri_drawable;
> __DRIbuffer  buffers[5];
> int  buffer_count;
> -   int  have_fake_front;
> +   bool have_fake_front;
>  
>  #ifdef HAVE_X11_PLATFORM
> xcb_drawable_t   drawable;
> @@ -282,7 +283,7 @@ struct dri2_egl_surface
>  #ifdef HAVE_DRM_PLATFORM
>struct gbm_bo   *bo;
>  #endif
> -  int locked;
> +  boollocked;
>int age;
> } color_buffers[4], *back, *current;
>  #endif
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 493e645..7cb6c18 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -25,6 +25,7 @@
>   *
>   **/
>  
> +#include 
>  #include 
>  
>  #include 
> @@ -627,7 +628,7 @@ vl_dri3_screen_create(Display *display, int screen)
> xcb_dri3_open_reply_t *open_reply;
> xcb_get_geometry_cookie_t geom_cookie;
> xcb_get_geometry_reply_t *geom_reply;
> -   int is_different_gpu;
> +   bool is_different_gpu;
> int fd;
>  
> assert(display);
> diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
> index 0822377..bfb0786 100644
> --- a/src/glx/dri3_priv.h
> +++ b/src/glx/dri3_priv.h
> @@ -54,6 +54,7 @@
>   *   Kristian Høgsberg (k...@redhat.com)
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -78,7 +79,7 @@ struct dri3_display
> int dri3Minor;
>  
> /* Present bits */
> -   int hasPresent;
> +   bool hasPresent;
> int presentMajor;
> int presentMinor;
>  };
> @@ -101,7 +102,7 @@ struct dri3_screen {
>  
> void *driver;
> int fd;
> -   int is_different_gpu;
> +   bool is_different_gpu;
>  
> int show_fps_interval;
>  
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 56ffc5d..a3b75c7 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -356,7 +356,7 @@ DRI_CONF_BEGIN
>  DRI_CONF_END;
>  #endif
>  
> -int loader_get_user_preferred_fd(int default_fd, int *different_device)
> +int loader_get_user_preferred_fd(int 

Re: [Mesa-dev] [PATCH 10/95] i965/vec4: handle 32 and 64 bit channels in liveness analysis

[Juan A. Suarez Romero]

On Mon, 2016-08-08 at 16:12 +0200, Juan A. Suarez Romero wrote:
> Hmm... what about the case of exec_size == 4 and writing just a
> float? 
> 
> I understand in this case we only should mark one word, so the loop
> should  not be 2*inst->regs_written.
> 
> Note that in the original patch that was the case for using offs ==
> 0.
> So I guess we should compute if we should use 1 or 2 times
> regs_written.


Thinking more carefully, I think it is fine using 2*regs_written/read
in this case.

So forget about my comment!


J.A.


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: Add an IO scalarizing pass using the intrinsic's first_component.

[Eric Anholt]

Timothy Arceri  writes:

> On Sat, 2016-08-06 at 10:15 +1000, Timothy Arceri wrote:
>> On Fri, 2016-08-05 at 16:27 -0700, Eric Anholt wrote:
>> > vc4 wants to have per-scalar IO load/stores so that dead code
>> > elimination
>> > can happen on a more granular basis,
>
> Out of interest what is it exactly that you are doing in the backend? 

Given that all of my IO is done as indidivual moves of scalars (with the
exception of the color output, which is weird but is lowered by vc4 code
anyway), I'd like to see all the scalar ops for setting up
undefined/unused scalar slots get dropped.  I don't see much change from
this, because dead code is easy to eliminate, but I think there were
small diffs.  It also makes the output more readable by cutting the
pointless vector ops.

However, doing my IO as scalar has been a bit of a pain for other
passes: The UCP and twoside lowering want a single load/store for the
vector.  Because of this, I've also wondered if using the write_mask and
extending nir_opt_dce() for per-channel liveness would be a better way
to go.

> I was looking at brw_do_vector_splitting() and it seems to me that
> moving that out of the Intel backend and making it also work on
> varyings could be benefical to all drivers as we could extend it to
> work across stages which would hopefully also improve varying packing.
>
> Currently it says: 
>
> "This skips vectors in uniforms and varyings, which need to be
> accessible as vectors for their access by the GL."
>
> But that really only applies to vs inputs and the outward facing stages
> of SSOs.

Yeah, I think that comment is stale at this point.  But we have a lot of
that pass in NIR already (ALU, const, io), and instead of extending the
GLSL IR pass I'd rather see a NIR cross-linking pass.

On the topic of cross-linking: Back in the day, i965 would look at the
VS outputs and propagate constants into the FS inputs.  This was really
painful, slow code to maintain, and we eventually just dropped it.
However, if we know that a VS/FS pair are non-SSO, it seems like with
NIR we could do that propagation really easily at link time.


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

Re: [Mesa-dev] [PATCH 0/8] radeonsi: implement missing indirect draw features

[Bas Nieuwenhuizen]

For patch 1-7:

Reviewed-by: Bas Nieuwenhuizen 

For patch 8, you probably also want to add the extensions to the
release notes. With that added, it looks good to me too.

- Bas

On Mon, Aug 8, 2016 at 5:55 PM, Nicolai Hähnle  wrote:
> Hi,
>
> this series adds some bug fixes and small extensions related to indirect
> draws that we can now use. As with the recent changes, it only applies
> with sufficiently new firmware, which means that it only works with amdgpu
> (due to a lack of firmware version query in the radeon kernel module).
> Please review!
>
> Thanks,
> Nicolai
> --
>  docs/GL3.txt |  4 +-
>  .../drivers/radeonsi/si_descriptors.c|  8 ++--
>  src/gallium/drivers/radeonsi/si_pipe.c   |  8 ++--
>  src/gallium/drivers/radeonsi/si_pipe.h   |  3 +-
>  src/gallium/drivers/radeonsi/si_shader.c | 13 +-
>  src/gallium/drivers/radeonsi/si_shader.h |  4 +-
>  src/gallium/drivers/radeonsi/si_state_draw.c | 43 ++
>  src/gallium/drivers/radeonsi/sid.h   |  3 ++
>  8 files changed, 65 insertions(+), 21 deletions(-)
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nvc0: advertise 8 bits subpixel precision for viewport bounds

[Józef Kucia]

Based on subpixel precision returned by the blob.

Signed-off-by: Józef Kucia 
---

I've checked that the blob returns 8 for the following GPUs:
GeForce GTX 460 (GF104), GeForce GTX 760 (GK104), GeForce GTX 970 (GM204).
Generally, I expect that 8 bits precision should be supported
by any D3D11-capable GPU.

---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index fb0a9c8..836ee23 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -156,6 +156,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
   return NOUVEAU_MIN_BUFFER_MAP_ALIGN;
case PIPE_CAP_MAX_VIEWPORTS:
   return NVC0_MAX_VIEWPORTS;
+   case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
+  return 8;
case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
   return 4;
case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
@@ -272,7 +274,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_PCI_BUS:
case PIPE_CAP_PCI_DEVICE:
case PIPE_CAP_PCI_FUNCTION:
-   case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
   return 0;
 
case PIPE_CAP_VENDOR_ID:
-- 
2.7.3

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

Re: [Mesa-dev] [PATCH 01/18] mapi: Add PatchParameteriOES and PatchParameteriEXT.

[Ian Romanick]

It looks like only part of this series has landed?

Patches 1 through 7 and 9 through 12 are

Reviewed-by: Ian Romanick 

On 08/01/2016 10:29 AM, Kenneth Graunke wrote:
> The OES_tessellation_shader and EXT_tessellation_shader specifications
> have suffixed names.  These are identical to the core function, so just
> alias them.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mapi/glapi/gen/ARB_tessellation_shader.xml | 10 ++
>  src/mesa/main/tests/dispatch_sanity.cpp|  3 +++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/src/mapi/glapi/gen/ARB_tessellation_shader.xml 
> b/src/mapi/glapi/gen/ARB_tessellation_shader.xml
> index cc55f9b..e26f227 100644
> --- a/src/mapi/glapi/gen/ARB_tessellation_shader.xml
> +++ b/src/mapi/glapi/gen/ARB_tessellation_shader.xml
> @@ -58,6 +58,16 @@
>  
>  
>  
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>  
>  
>  
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index ee3c3d4..cfbf70d 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -2594,5 +2594,8 @@ const struct function gles31_functions_possible[] = {
> /* GL_OES_geometry_shader */
> { "glFramebufferTextureOES", 31, -1},
>  
> +   /* GL_OES_tessellation_shader */
> +   { "glPatchParameteriOES", 31, -1 },
> +
> { NULL, 0, -1 },
>   };
> 

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

Re: [Mesa-dev] [PATCH 09/18] glsl: Handle patch qualifier on interface blocks.

[Ian Romanick]

This is also a problem for desktop, yeah?  Cc stable?

On 08/01/2016 10:29 AM, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke 
> ---
>  src/compiler/glsl/ast_to_hir.cpp |  4 
>  src/compiler/glsl/glsl_parser.yy | 11 +++
>  src/compiler/glsl/glsl_parser_extras.cpp |  3 +++
>  3 files changed, 18 insertions(+)
> 
> diff --git a/src/compiler/glsl/ast_to_hir.cpp 
> b/src/compiler/glsl/ast_to_hir.cpp
> index d246745..6273528 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -7436,10 +7436,12 @@ ast_interface_block::hir(exec_list *instructions,
>_mesa_glsl_error(, state, "geometry shader inputs must be arrays");
> } else if ((state->stage == MESA_SHADER_TESS_CTRL ||
> state->stage == MESA_SHADER_TESS_EVAL) &&
> +  !this->layout.flags.q.patch &&
>this->array_specifier == NULL &&
>var_mode == ir_var_shader_in) {
>_mesa_glsl_error(, state, "per-vertex tessellation shader inputs 
> must be arrays");
> } else if (state->stage == MESA_SHADER_TESS_CTRL &&
> +  !this->layout.flags.q.patch &&
>this->array_specifier == NULL &&
>var_mode == ir_var_shader_out) {
>_mesa_glsl_error(, state, "tessellation control shader outputs 
> must be arrays");
> @@ -7555,6 +7557,8 @@ ast_interface_block::hir(exec_list *instructions,
>if (var_mode == ir_var_shader_in || var_mode == ir_var_uniform)
>   var->data.read_only = true;
>  
> +  var->data.patch = this->layout.flags.q.patch;
> +
>if (state->stage == MESA_SHADER_GEOMETRY && var_mode == 
> ir_var_shader_in)
>   handle_geometry_shader_input_decl(state, loc, var);
>else if ((state->stage == MESA_SHADER_TESS_CTRL ||
> diff --git a/src/compiler/glsl/glsl_parser.yy 
> b/src/compiler/glsl/glsl_parser.yy
> index 4ab9e14..d90418e 100644
> --- a/src/compiler/glsl/glsl_parser.yy
> +++ b/src/compiler/glsl/glsl_parser.yy
> @@ -2697,6 +2697,17 @@ interface_qualifier:
>memset(& $$, 0, sizeof($$));
>$$.flags.q.buffer = 1;
> }
> +   | auxiliary_storage_qualifier interface_qualifier
> +   {
> +  if (!$1.flags.q.patch) {
> + _mesa_glsl_error(&@1, state, "invalid interface qualifier");
> +  }
> +  if ($2.has_auxiliary_storage()) {
> + _mesa_glsl_error(&@1, state, "duplicate patch qualifier");
> +  }
> +  $$ = $2;
> +  $$.flags.q.patch = 1;
> +   }
> ;
>  
>  instance_name_opt:
> diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
> b/src/compiler/glsl/glsl_parser_extras.cpp
> index 14a5540..2211d97 100644
> --- a/src/compiler/glsl/glsl_parser_extras.cpp
> +++ b/src/compiler/glsl/glsl_parser_extras.cpp
> @@ -929,6 +929,8 @@ _mesa_ast_process_interface_block(YYLTYPE *locp,
> "a fragment shader");
> }
>  
> +   /* error checking for patch qualifier? */
> +
> /* Since block arrays require names, and both features are added in
>  * the same language versions, we don't have to explicitly
>  * version-check both things.
> @@ -950,6 +952,7 @@ _mesa_ast_process_interface_block(YYLTYPE *locp,
> temp_type_qualifier.flags.q.in = true;
> temp_type_qualifier.flags.q.out = true;
> temp_type_qualifier.flags.q.buffer = true;
> +   temp_type_qualifier.flags.q.patch = true;
> interface_type_mask = temp_type_qualifier.flags.i;
>  
> /* Get the block's interface qualifier.  The interface_qualifier
> 

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

Re: [Mesa-dev] [PATCH 07/18] glsl: Implicitly enable OES_shader_io_blocks if geom/tess are enabled.

[Ian Romanick]

On 08/01/2016 10:29 AM, Kenneth Graunke wrote:
> Signed-off-by: Kenneth Graunke 
> ---
>  src/compiler/glsl/glsl_parser_extras.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/src/compiler/glsl/glsl_parser_extras.h 
> b/src/compiler/glsl/glsl_parser_extras.h
> index 991cfc6..0294ef7 100644
> --- a/src/compiler/glsl/glsl_parser_extras.h
> +++ b/src/compiler/glsl/glsl_parser_extras.h
> @@ -267,8 +267,19 @@ struct _mesa_glsl_parse_state {
>  
> bool has_shader_io_blocks() const
> {
> +  /* The OES_geometry_shader_specification says:
> +   *
> +   *"If the OES_geometry_shader extension is enabled, the
> +   * OES_shader_io_blocks extension is also implicitly enabled."
> +   *
> +   * The OES_tessellation_shader extension has similar wording.
> +   */

Ah!  I missed that text when I wrote a very similar patch. :)

>return OES_shader_io_blocks_enable ||
>   EXT_shader_io_blocks_enable ||
> + OES_geometry_shader_enable ||
> + OES_tessellation_shader_enable ||
> + EXT_tessellation_shader_enable ||
> +
>   is_version(150, 320);
> }
>  
> 

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

Re: [Mesa-dev] [PATCH 02/18] mesa: Add {OES, EXT}_tessellation_shader to the extensions table.

[Ian Romanick]

On 08/01/2016 07:52 PM, Kenneth Graunke wrote:
> On Monday, August 1, 2016 7:06:14 PM PDT Ilia Mirkin wrote:
>> I'm looking at these on my phone, so perhaps I missed it - do you ever end
>> up turning them on, or is that left to  later series?
> 
> No...not yet.  This series gets almost all of dEQP passing, except for a
> couple program interface query bugs (at least some of which are probably
> in dEQP), but the Khronos CTS has a bunch of additional tests that still
> fail, and I haven't looked into why yet.

There are a couple legit dEQP tests failing in my OES_geometry_shader
series too.  I suspect that these are related.

> I figured I'd send out this much at least.
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev




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

[Mesa-dev] [PATCH 5/8] radeonsi: add DRAWID parameter to vertex shaders

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_shader.c | 8 +++-
 src/gallium/drivers/radeonsi/si_shader.h | 4 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 2c00f56..2de20cb 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1668,6 +1668,11 @@ static void declare_system_value(
 SI_PARAM_START_INSTANCE);
break;
 
+   case TGSI_SEMANTIC_DRAWID:
+   value = LLVMGetParam(radeon_bld->main_fn,
+SI_PARAM_DRAWID);
+   break;
+
case TGSI_SEMANTIC_INVOCATIONID:
if (ctx->type == PIPE_SHADER_TESS_CTRL)
value = unpack_param(ctx, SI_PARAM_REL_IDS, 8, 5);
@@ -5460,7 +5465,8 @@ static void create_function(struct si_shader_context *ctx)
params[SI_PARAM_VERTEX_BUFFERS] = const_array(ctx->v16i8, 
SI_NUM_VERTEX_BUFFERS);
params[SI_PARAM_BASE_VERTEX] = ctx->i32;
params[SI_PARAM_START_INSTANCE] = ctx->i32;
-   num_params = SI_PARAM_START_INSTANCE+1;
+   params[SI_PARAM_DRAWID] = ctx->i32;
+   num_params = SI_PARAM_DRAWID+1;
 
if (shader->key.vs.as_es) {
params[ctx->param_es2gs_offset = num_params++] = 
ctx->i32;
diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index e856049..fc1b22d 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -96,6 +96,7 @@ enum {
SI_SGPR_VERTEX_BUFFERS_HI,
SI_SGPR_BASE_VERTEX,
SI_SGPR_START_INSTANCE,
+   SI_SGPR_DRAWID,
SI_ES_NUM_USER_SGPR,
 
/* hw VS only */
@@ -142,10 +143,11 @@ enum {
SI_PARAM_VERTEX_BUFFERS = SI_NUM_RESOURCE_PARAMS,
SI_PARAM_BASE_VERTEX,
SI_PARAM_START_INSTANCE,
+   SI_PARAM_DRAWID,
/* [0] = clamp vertex color, VS as VS only */
SI_PARAM_VS_STATE_BITS,
/* same value as TCS_IN_LAYOUT, VS as LS only */
-   SI_PARAM_LS_OUT_LAYOUT = SI_PARAM_START_INSTANCE + 1,
+   SI_PARAM_LS_OUT_LAYOUT = SI_PARAM_DRAWID + 1,
/* the other VS parameters are assigned dynamically */
 
/* Layout of TCS outputs in the offchip buffer
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/8] radeonsi/sid: add additional bits for the DRAW_(INDEX)_INDIRECT_MULTI packets

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/sid.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/sid.h 
b/src/gallium/drivers/radeonsi/sid.h
index 0d2ac37..9c74a6a 100644
--- a/src/gallium/drivers/radeonsi/sid.h
+++ b/src/gallium/drivers/radeonsi/sid.h
@@ -93,6 +93,9 @@
 #define CONTEXT_CONTROL_SHADOW_ENABLE(x)   (((unsigned)(x) & 0x1) << 31)
 #define PKT3_INDEX_TYPE0x2A
 #define PKT3_DRAW_INDIRECT_MULTI   0x2C
+#define   R_2C3_DRAW_INDEX_LOC  0x2C3
+#define S_2C3_COUNT_INDIRECT_ENABLE(x)  (((unsigned)(x) & 0x1) << 30)
+#define S_2C3_DRAW_INDEX_ENABLE(x)  (((unsigned)(x) & 0x1) << 31)
 #define PKT3_DRAW_INDEX_AUTO   0x2D
 #define PKT3_DRAW_INDEX_IMMD   0x2E /* not on CIK */
 #define PKT3_NUM_INSTANCES 0x2F
-- 
2.7.4

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

[Mesa-dev] [PATCH 8/8] radeonsi: enable multi-draw related pipe caps

[Nicolai Hähnle]

From: Nicolai Hähnle 

This enables GL_shader_draw_parameters and GL_ARB_indirect_parameters as well
as a properly accelerated implementation of GL_ARB_multi_draw_indirect.

Enabling the feature requires a sufficiently uptodate firmware -- those have
already been released a long time ago, although this does mean that the
feature only works with the amdgpu kernel module, since the radeon module
doesn't have a way to query the firmware version.
---
 docs/GL3.txt   | 4 ++--
 src/gallium/drivers/radeonsi/si_pipe.c | 8 +---
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index c185c69..0ba5a25 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -283,7 +283,7 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
   GL_ARB_ES3_2_compatibilitynot started
   GL_ARB_fragment_shader_interlock  not started
   GL_ARB_gpu_shader_int64   started (airlied for 
core and Gallium, idr for i965)
-  GL_ARB_indirect_parametersDONE (nvc0)
+  GL_ARB_indirect_parametersDONE (nvc0, radeonsi)
   GL_ARB_parallel_shader_compilenot started, but 
Chia-I Wu did some related work in 2014
   GL_ARB_pipeline_statistics_query  DONE (i965, nvc0, 
radeonsi, softpipe, swr)
   GL_ARB_post_depth_coveragenot started
@@ -293,7 +293,7 @@ Khronos, ARB, and OES extensions that are not part of any 
OpenGL or OpenGL ES ve
   GL_ARB_shader_atomic_counter_ops  DONE (nvc0, radeonsi, 
softpipe)
   GL_ARB_shader_ballot  not started
   GL_ARB_shader_clock   DONE (i965/gen7+)
-  GL_ARB_shader_draw_parameters DONE (i965, nvc0)
+  GL_ARB_shader_draw_parameters DONE (i965, nvc0, 
radeonsi)
   GL_ARB_shader_group_vote  DONE (nvc0)
   GL_ARB_shader_stencil_export  DONE (i965/gen9+, 
radeonsi, softpipe, llvmpipe, swr)
   GL_ARB_shader_viewport_layer_arraynot started
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index ffeeda3..86d7632 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -435,9 +435,6 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
case PIPE_CAP_VERTEXID_NOBASE:
case PIPE_CAP_CLEAR_TEXTURE:
-   case PIPE_CAP_DRAW_PARAMETERS:
-   case PIPE_CAP_MULTI_DRAW_INDIRECT:
-   case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
case PIPE_CAP_QUERY_BUFFER_OBJECT:
case PIPE_CAP_CULL_DISTANCE:
case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
@@ -445,6 +442,11 @@ static int si_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_MAX_WINDOW_RECTANGLES:
return 0;
 
+   case PIPE_CAP_DRAW_PARAMETERS:
+   case PIPE_CAP_MULTI_DRAW_INDIRECT:
+   case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
+   return sscreen->has_draw_indirect_multi;
+
case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
return 30;
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 6/8] radeonsi: program the DRAWID SGPR

[Nicolai Hähnle]

From: Nicolai Hähnle 

Note that for indirect draws, the new MULTI firmware packets are required.

There's also no need to reset last_{start_instance,sh_base_reg}, since
resetting last_base_vertex is sufficient.
---
 src/gallium/drivers/radeonsi/si_pipe.h   | 3 +--
 src/gallium/drivers/radeonsi/si_state_draw.c | 8 ++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.h 
b/src/gallium/drivers/radeonsi/si_pipe.h
index 9e6bd78..f6535cf 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -308,6 +308,7 @@ struct si_context {
/* Emitted draw state. */
int last_base_vertex;
int last_start_instance;
+   int last_drawid;
int last_sh_base_reg;
int last_primitive_restart_en;
int last_restart_index;
@@ -414,8 +415,6 @@ static inline void
 si_invalidate_draw_sh_constants(struct si_context *sctx)
 {
sctx->last_base_vertex = SI_BASE_VERTEX_UNKNOWN;
-   sctx->last_start_instance = -1; /* reset to an unknown value */
-   sctx->last_sh_base_reg = -1; /* reset to an unknown value */
 }
 
 static inline void
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 3147311..d518d42 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -591,13 +591,16 @@ static void si_emit_draw_packets(struct si_context *sctx,
if (base_vertex != sctx->last_base_vertex ||
sctx->last_base_vertex == SI_BASE_VERTEX_UNKNOWN ||
info->start_instance != sctx->last_start_instance ||
+   info->drawid != sctx->last_drawid ||
sh_base_reg != sctx->last_sh_base_reg) {
-   radeon_set_sh_reg_seq(cs, sh_base_reg + 
SI_SGPR_BASE_VERTEX * 4, 2);
+   radeon_set_sh_reg_seq(cs, sh_base_reg + 
SI_SGPR_BASE_VERTEX * 4, 3);
radeon_emit(cs, base_vertex);
radeon_emit(cs, info->start_instance);
+   radeon_emit(cs, info->drawid);
 
sctx->last_base_vertex = base_vertex;
sctx->last_start_instance = info->start_instance;
+   sctx->last_drawid = info->drawid;
sctx->last_sh_base_reg = sh_base_reg;
}
} else {
@@ -647,7 +650,8 @@ static void si_emit_draw_packets(struct si_context *sctx,
radeon_emit(cs, info->indirect_offset);
radeon_emit(cs, (sh_base_reg + SI_SGPR_BASE_VERTEX * 4 
- SI_SH_REG_OFFSET) >> 2);
radeon_emit(cs, (sh_base_reg + SI_SGPR_START_INSTANCE * 
4 - SI_SH_REG_OFFSET) >> 2);
-   radeon_emit(cs, 0); /* draw_index */
+   radeon_emit(cs, ((sh_base_reg + SI_SGPR_DRAWID * 4 - 
SI_SH_REG_OFFSET) >> 2) |
+   S_2C3_DRAW_INDEX_ENABLE(1));
radeon_emit(cs, 1); /* count */
radeon_emit(cs, 0); /* count_addr -- disabled */
radeon_emit(cs, 0);
-- 
2.7.4

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

[Mesa-dev] [PATCH 4/8] radeonsi: wire up TGSI_SEMANTIC_BASEINSTANCE

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_shader.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 64c367e..2c00f56 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1663,6 +1663,11 @@ static void declare_system_value(
 SI_PARAM_BASE_VERTEX);
break;
 
+   case TGSI_SEMANTIC_BASEINSTANCE:
+   value = LLVMGetParam(radeon_bld->main_fn,
+SI_PARAM_START_INSTANCE);
+   break;
+
case TGSI_SEMANTIC_INVOCATIONID:
if (ctx->type == PIPE_SHADER_TESS_CTRL)
value = unpack_param(ctx, SI_PARAM_REL_IDS, 8, 5);
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/8] radeonsi: remove an incorrect assertion

[Nicolai Hähnle]

From: Nicolai Hähnle 

Byte indices don't need any alignment, so remove this assertion (it got moved
into a path where a piglit test hit it during the refactoring of
commit 64ff23a58c).
---
 src/gallium/drivers/radeonsi/si_state_draw.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index b559306..3147311 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -574,8 +574,6 @@ static void si_emit_draw_packets(struct si_context *sctx,
  ib->index_size;
index_va = r600_resource(ib->buffer)->gpu_address + ib->offset;
 
-   assert(index_va % 2 == 0);
-
radeon_add_to_buffer_list(>b, >b.gfx,
  (struct r600_resource *)ib->buffer,
  RADEON_USAGE_READ, 
RADEON_PRIO_INDEX_BUFFER);
-- 
2.7.4

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

[Mesa-dev] [PATCH 0/8] radeonsi: implement missing indirect draw features

[Nicolai Hähnle]

Hi,

this series adds some bug fixes and small extensions related to indirect
draws that we can now use. As with the recent changes, it only applies
with sufficiently new firmware, which means that it only works with amdgpu
(due to a lack of firmware version query in the radeon kernel module).
Please review!

Thanks,
Nicolai
--
 docs/GL3.txt |  4 +-
 .../drivers/radeonsi/si_descriptors.c|  8 ++--
 src/gallium/drivers/radeonsi/si_pipe.c   |  8 ++--
 src/gallium/drivers/radeonsi/si_pipe.h   |  3 +-
 src/gallium/drivers/radeonsi/si_shader.c | 13 +-
 src/gallium/drivers/radeonsi/si_shader.h |  4 +-
 src/gallium/drivers/radeonsi/si_state_draw.c | 43 ++
 src/gallium/drivers/radeonsi/sid.h   |  3 ++
 8 files changed, 65 insertions(+), 21 deletions(-)

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

[Mesa-dev] [PATCH 2/8] radeonsi: flush TC L2 cache for indirect draw data

[Nicolai Hähnle]

From: Nicolai Hähnle 

This fixes a bug when indirect draw data is generated by transform
feedback.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/drivers/radeonsi/si_descriptors.c | 8 
 src/gallium/drivers/radeonsi/si_state_draw.c  | 5 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 224cf35..7600671 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -1242,10 +1242,10 @@ static void si_set_streamout_targets(struct 
pipe_context *ctx,
 * and most other clients can use TC L2 as well, we don't need
 * to flush it.
 *
-* The only case which requires flushing it is VGT DMA index
-* fetching, which is a rare case. Thus, flag the TC L2
-* dirtiness in the resource and handle it when index fetching
-* is used.
+* The only cases which requires flushing it is VGT DMA index
+* fetching (on <= CIK) and indirect draw data, which are rare
+* cases. Thus, flag the TC L2 dirtiness in the resource and
+* handle it at draw call time.
 */
for (i = 0; i < sctx->b.streamout.num_targets; i++)
if (sctx->b.streamout.targets[i])
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index a60723d..b559306 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -967,6 +967,11 @@ void si_draw_vbo(struct pipe_context *ctx, const struct 
pipe_draw_info *info)
r600_resource(ib.buffer)->TC_L2_dirty = false;
}
 
+   if (info->indirect && r600_resource(info->indirect)->TC_L2_dirty) {
+   sctx->b.flags |= SI_CONTEXT_INV_GLOBAL_L2;
+   r600_resource(info->indirect)->TC_L2_dirty = false;
+   }
+
/* Check flush flags. */
if (sctx->b.flags)
si_mark_atom_dirty(sctx, sctx->atoms.s.cache_flush);
-- 
2.7.4

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

[Mesa-dev] [PATCH 7/8] radeonsi: program additional multi draw parameters

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/drivers/radeonsi/si_state_draw.c | 30 +++-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index d518d42..bcf1104 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -644,6 +644,19 @@ static void si_emit_draw_packets(struct si_context *sctx,
radeon_emit(cs, (sh_base_reg + SI_SGPR_START_INSTANCE * 
4 - SI_SH_REG_OFFSET) >> 2);
radeon_emit(cs, di_src_sel);
} else {
+   uint64_t count_va = 0;
+
+   if (info->indirect_params) {
+   struct r600_resource *params_buf =
+   (struct r600_resource 
*)info->indirect_params;
+
+   radeon_add_to_buffer_list(
+   >b, >b.gfx, params_buf,
+   RADEON_USAGE_READ, 
RADEON_PRIO_DRAW_INDIRECT);
+
+   count_va = params_buf->gpu_address + 
info->indirect_params_offset;
+   }
+
radeon_emit(cs, PKT3(info->indexed ? 
PKT3_DRAW_INDEX_INDIRECT_MULTI :
 
PKT3_DRAW_INDIRECT_MULTI,
 8, render_cond_bit));
@@ -651,11 +664,12 @@ static void si_emit_draw_packets(struct si_context *sctx,
radeon_emit(cs, (sh_base_reg + SI_SGPR_BASE_VERTEX * 4 
- SI_SH_REG_OFFSET) >> 2);
radeon_emit(cs, (sh_base_reg + SI_SGPR_START_INSTANCE * 
4 - SI_SH_REG_OFFSET) >> 2);
radeon_emit(cs, ((sh_base_reg + SI_SGPR_DRAWID * 4 - 
SI_SH_REG_OFFSET) >> 2) |
-   S_2C3_DRAW_INDEX_ENABLE(1));
-   radeon_emit(cs, 1); /* count */
-   radeon_emit(cs, 0); /* count_addr -- disabled */
-   radeon_emit(cs, 0);
-   radeon_emit(cs, 16); /* stride */
+   S_2C3_DRAW_INDEX_ENABLE(1) |
+   
S_2C3_COUNT_INDIRECT_ENABLE(!!info->indirect_params));
+   radeon_emit(cs, info->indirect_count);
+   radeon_emit(cs, count_va);
+   radeon_emit(cs, count_va >> 32);
+   radeon_emit(cs, info->indirect_stride);
radeon_emit(cs, di_src_sel);
}
} else {
@@ -974,6 +988,12 @@ void si_draw_vbo(struct pipe_context *ctx, const struct 
pipe_draw_info *info)
r600_resource(info->indirect)->TC_L2_dirty = false;
}
 
+   if (info->indirect_params &&
+   r600_resource(info->indirect_params)->TC_L2_dirty) {
+   sctx->b.flags |= SI_CONTEXT_INV_GLOBAL_L2;
+   r600_resource(info->indirect_params)->TC_L2_dirty = false;
+   }
+
/* Check flush flags. */
if (sctx->b.flags)
si_mark_atom_dirty(sctx, sctx->atoms.s.cache_flush);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] src: replace RTLD_NOW with RTLD_LAZY

[Ian Romanick]

On 08/05/2016 07:05 PM, ⚛ wrote:
> On Sat, Aug 6, 2016 at 3:37 AM, Jan Vesely  wrote:
>> On Sat, 2016-08-06 at 02:42 +0200, Jan Ziak wrote:
>>> Mesa source code prior to this patch uses both RTLD_NOW and
>>> RTLD_LAZY.
>>> This patch removes all RTLD_NOW in favor of RTLD_LAZY.
>>>
>>> In comparison to early binding, lazy binding reduces CPU instruction
>>> count
>>> of small GL apps (e.g: glxinfo) by 6 million instructions.
>>> Larger apps won't notice the difference.
>>
>> this is IMO micro-optimization in the wrong place. RTLD_NOW also
>> guarantees that symbols were successfully resolved. Changing it to lazy
>> may hide bugs by deferring failure to future point in the execution.
> 
> Question 1: Are you suggesting to replace current RTLD_LAZY in all
> locations with RTLD_NOW?
> 
> Question 2: Exists there a reason for _not_ linking radeonsi_dri.so,
> swrastg_dri.so, etc, directly to Mesa's libGL.so? The Gallium
> *_dri.so libraries are the same inode on the filesystem.

This is an intentional feature.  This allows libGL and *_dri.so to be
installed from different versions.  It also allows the possibility for a
*_dri.so from outside the Mesa source tree.

> Question 3: Isn't the current status quo (i.e: not linking
> radeonsi_dri.so directly to libGL.so) also a micro-optimization that
> can hide certain bugs?
> 
> Question 4: Is it planned for *_dri.so belonging to Gallium/DRI _not_
> to be mapped to the same inode on the filesystem in the future? If
> there is no such plan, what was the original point of having multiple
> _dri.so files mapped to the same inode?
> 
> Thanks.
> 

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

[Mesa-dev] [Bug 97231] GL_DEPTH_CLAMP doesn't clamp to the far plane

[bugzilla-daemon]

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

--- Comment #6 from Roland Scheidegger  ---
(In reply to Jules Blok from comment #5)
> (In reply to Roland Scheidegger from comment #4)
> > Oh I could see why it might not work with llvmpipe if you do reverse depth
> > range.
> 
> We already had this problem before we reversed the depth range, refer to the
> obsolete apitrace to see the same sample without the reversed depth range.

The replays don't work with llvmpipe since they require glsl 400 and I couldn't
make them work with version overrides neither.
Not sure though why it wouldn't work without reversed depth, I know this
feature generally works (with d3d10 in particular, which forbids reversing
depth hence the bug there going unnoticed).

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

Re: [Mesa-dev] [PATCH 1/6] gallium/radeon: change the vendor string to Advanced Micro Devices, Inc.

[Alex Deucher]

On Sat, Aug 6, 2016 at 2:04 PM, Marek Olšák  wrote:
> From: Marek Olšák 

If we want to display the marking names for each asic, we could add
the marketing name api from libdrm_amdgpu that the closed driver uses.
It would also reduce the delta between open and pro.

Alex

>
> ---
>  src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c 
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index 1c56e6e..8a9ab94 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -598,21 +598,21 @@ static const struct debug_named_value 
> common_debug_options[] = {
> { "mono", DBG_MONOLITHIC_SHADERS, "Use old-style monolithic shaders 
> compiled on demand" },
> { "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";
> +   return "Advanced Micro Devices, Inc.";
>  }
>
>  static const char* r600_get_device_vendor(struct pipe_screen* pscreen)
>  {
> return "AMD";
>  }
>
>  static const char* r600_get_chip_name(struct r600_common_screen *rscreen)
>  {
> switch (rscreen->info.family) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] gallium: Add c99_compat.h to u_bitcast.h

[Mathias Fröhlich]

Brian,

On Monday, 8 August 2016 08:27:40 CEST Brian Paul wrote:
> On 08/06/2016 12:42 AM, mathias.froehl...@gmx.net wrote:
> > From: Mathias Fröhlich 
> >
> > We need this for 'inline'.
> >
> > Signed-off-by: Mathias Fröhlich 
> > ---
> >   src/gallium/auxiliary/util/u_bitcast.h | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/src/gallium/auxiliary/util/u_bitcast.h 
> > b/src/gallium/auxiliary/util/
u_bitcast.h
> > index b1f9938..e8fb0fe 100644
> > --- a/src/gallium/auxiliary/util/u_bitcast.h
> > +++ b/src/gallium/auxiliary/util/u_bitcast.h
> > @@ -30,6 +30,8 @@
> >
> >   #include 
> >
> > +#include "c99_compat.h"
> > +
> >   #ifdef __cplusplus
> >   extern "C" {
> >   #endif
> >
> 
> Shouldn't this get squashed into patch 1?

No, i don't think so.
Patch 1 is about src/util/bitscan.h.
The series did so far *not* touch
src/gallium/auxiliary/util/u_bitcast.h at all.

I just put that there since you seem to have stepped onto
that. And it appeared to me that I kindly asked for testing
that seems to be hold back by that unrelated compile failure.
And if in the end your compile is fixed with my pending push
both will be happy then. Right?

Regards

Mathias


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

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Christian,

I am more than happy to solve these problems, the Lanczos filtering was
getting a little stale
anyway because I was not able to reproduce the problems Andy was facing.

On Mon, Aug 8, 2016 at 6:24 PM, Christian König 
wrote:

> Hi Nayan,
>
> ok let's take a step back and put the lanczos filtering aside for a
> moment. I have another task for you which is more urgent right now.
>
> The order we do things in vlVdpVideoMixerRender() was never 100% correct,
> so we have at least three problems here which needs fixing:
>
> 1) The noise reduction and sharpness filter read and write to the same
> surface at the same time. That only works because we use a linear layout.
>
> Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I need to
use maybe a couple of surfaces alternatively to read and write with the
filters. This approach should work I guess.

2) We apply the noise reduction and sharpness filter after the composition.
> That is rather odd and should be fixed so that we apply those filters on
> the original video frame instead.
>
>  So we need to apply the filter before the CSC conversion.

> 3) We use delayed rendering to render into output surfaces directly. We
> should rather use the DRI3 capabilities to allocate multiple output
> surfaces instead.
>
> Could you take care of some of those issues? Especially #1 has become a
> problem recently.
>
> Surely, I will start working on the first 2 problem for now and look at
the third problem a little later.

Regards,
Nayan.


> Regards,
> Christian.
>
>
> Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:
>
> Hi Andy,
>
>
> On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss  wrote:
>
>> Nayan Deshmukh wrote:
>>
>>> Hi Andy,
>>>
>>> Thanks for testing my patches.
>>>
>>
>> NP
>>
>>
>> The scaling happens after CSC.

>>>
>> OK, thanks.
>>
>>
>> I believe there is some misunderstanding here, I was able to see the
>>> artifacts in the video that you sent me previously. But I was not
>>> able to replicate them
>>>
>>
>> Yea, I got that - just thought you may want to see how they had changed.
>>
>> with the pendulum video on my system. Same case this time the
>>> pendulum video plays fine this time too. I am attacing a video of it
>>> here
>>>
>>> https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E
>>> /view?usp=sharing
>>>
>>
>> Hmm, that's interesting for a few reasons.
>>
>> Though my monitor won't do 1366x768 I can replicate the same scale
>> factor windowed with mplayer ... -xy 768/576 ...
>>
>> At first glance only level 2 is obviously artifacted (though very close
>> inspection shows others are slightly).
>>
>> Levels: for some reason your vid has the black bars at 0 but the content
>> isn't scaled - like your mplayer didn't expand tv to pc on playback.
>> This shouldn't happen by default. Do you have some extra config
>> somewhere like in $HOME/.mplayer, if so maybe better to test without.
>>
>> Most important - though the vp9 compression may be to blame I can't
>> really see any difference between the levels in that vid.
>>
>> In fact closely comparing just your level 1 to my (admittedly
>> uncompressed) level 1 and 0 output scaled the same plus unstretched
>> levels wise it looks to me like you are getting level 0 on this test.
>>
>
> You are right it I am getting level 0 only. I have a PRIME configuration
> and I forgot to set DRI_PRIME to 1. But for some reason, I am not able to
> create
> a screen recording when I use my AMD card. So, for now, I can't reproduce
> the artifacts
> you are having so can't debug them too :(
>
> Regards,
> Nayan.
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Christian König]

Hi Nayan,

ok let's take a step back and put the lanczos filtering aside for a 
moment. I have another task for you which is more urgent right now.


The order we do things in vlVdpVideoMixerRender() was never 100% 
correct, so we have at least three problems here which needs fixing:


1) The noise reduction and sharpness filter read and write to the same 
surface at the same time. That only works because we use a linear layout.


2) We apply the noise reduction and sharpness filter after the 
composition. That is rather odd and should be fixed so that we apply 
those filters on the original video frame instead.


3) We use delayed rendering to render into output surfaces directly. We 
should rather use the DRI3 capabilities to allocate multiple output 
surfaces instead.


Could you take care of some of those issues? Especially #1 has become a 
problem recently.


Regards,
Christian.

Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:

Hi Andy,


On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss > wrote:


Nayan Deshmukh wrote:

Hi Andy,

Thanks for testing my patches.


NP


The scaling happens after CSC.


OK, thanks.


I believe there is some misunderstanding here, I was able to
see the
artifacts in the video that you sent me previously. But I was not
able to replicate them


Yea, I got that - just thought you may want to see how they had
changed.

with the pendulum video on my system. Same case this time the
pendulum video plays fine this time too. I am attacing a video
of it
here


https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing




Hmm, that's interesting for a few reasons.

Though my monitor won't do 1366x768 I can replicate the same scale
factor windowed with mplayer ... -xy 768/576 ...

At first glance only level 2 is obviously artifacted (though very
close
inspection shows others are slightly).

Levels: for some reason your vid has the black bars at 0 but the
content
isn't scaled - like your mplayer didn't expand tv to pc on playback.
This shouldn't happen by default. Do you have some extra config
somewhere like in $HOME/.mplayer, if so maybe better to test without.

Most important - though the vp9 compression may be to blame I can't
really see any difference between the levels in that vid.

In fact closely comparing just your level 1 to my (admittedly
uncompressed) level 1 and 0 output scaled the same plus unstretched
levels wise it looks to me like you are getting level 0 on this test.


You are right it I am getting level 0 only. I have a PRIME configuration
and I forgot to set DRI_PRIME to 1. But for some reason, I am not able 
to create
a screen recording when I use my AMD card. So, for now, I can't 
reproduce the artifacts

you are having so can't debug them too :(

Regards,
Nayan.



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

Re: [Mesa-dev] [PATCH 3/3] gallium: Add c99_compat.h to u_bitcast.h

[Brian Paul]

On 08/06/2016 12:42 AM, mathias.froehl...@gmx.net wrote:

From: Mathias Fröhlich 

We need this for 'inline'.

Signed-off-by: Mathias Fröhlich 
---
  src/gallium/auxiliary/util/u_bitcast.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_bitcast.h 
b/src/gallium/auxiliary/util/u_bitcast.h
index b1f9938..e8fb0fe 100644
--- a/src/gallium/auxiliary/util/u_bitcast.h
+++ b/src/gallium/auxiliary/util/u_bitcast.h
@@ -30,6 +30,8 @@

  #include 

+#include "c99_compat.h"
+
  #ifdef __cplusplus
  extern "C" {
  #endif



Shouldn't this get squashed into patch 1?

-Brian

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

Re: [Mesa-dev] [PATCH] mesa: simplify ff fs generator a bit

[Brian Paul]

On 08/06/2016 03:34 PM, Miklós Máté wrote:

Literally.

Signed-off-by: Miklós Máté 
---
  src/mesa/main/ff_fragment_shader.cpp | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/ff_fragment_shader.cpp 
b/src/mesa/main/ff_fragment_shader.cpp
index b0ce8c4..ad3d666 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -102,7 +102,6 @@ struct state_key {
 GLuint nr_enabled_units:8;
 GLuint enabled_units:8;
 GLuint separate_specular:1;
-   GLuint fog_enabled:1;
 GLuint fog_mode:2;  /**< FOG_x */
 GLuint inputs_available:12;
 GLuint num_draw_buffers:4;
@@ -126,10 +125,10 @@ struct state_key {
 } unit[MAX_TEXTURE_UNITS];
  };

-#define FOG_LINEAR  0
-#define FOG_EXP 1
-#define FOG_EXP22
-#define FOG_UNKNOWN 3
+#define FOG_NONE0
+#define FOG_LINEAR  1
+#define FOG_EXP 2
+#define FOG_EXP23

  static GLuint translate_fog_mode( GLenum mode )
  {
@@ -137,7 +136,7 @@ static GLuint translate_fog_mode( GLenum mode )
 case GL_LINEAR: return FOG_LINEAR;
 case GL_EXP: return FOG_EXP;
 case GL_EXP2: return FOG_EXP2;
-   default: return FOG_UNKNOWN;
+   default: return FOG_NONE;
 }
  }

@@ -459,7 +458,6 @@ static GLuint make_state_key( struct gl_context *ctx,  
struct state_key *key )

 /* _NEW_FOG */
 if (ctx->Fog.Enabled) {
-  key->fog_enabled = 1;
key->fog_mode = translate_fog_mode(ctx->Fog.Mode);
inputs_referenced |= VARYING_BIT_FOGC; /* maybe */
 }
@@ -1178,7 +1176,7 @@ emit_instructions(texenv_fragment_program *p)
cf = new(p->mem_ctx) ir_dereference_variable(spec_result);
 }

-   if (key->fog_enabled) {
+   if (key->fog_mode) {
cf = emit_fog_instructions(p, cf);
 }




Reviewed-by: Brian Paul 



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

Re: [Mesa-dev] [PATCH 10/95] i965/vec4: handle 32 and 64 bit channels in liveness analysis

[Juan A. Suarez Romero]

On Fri, 2016-07-29 at 12:59 -0700, Francisco Jerez wrote:
> |   for (unsigned i = 0; i < 2 * inst->regs_written; i++)
> {
> |  for (int c = 0; c < 4; c++)
> | result_live[c] |= BITSET_TEST(
> |    live, var_from_reg(alloc, inst->dst, c, i));
> |   }
> 
> Note that the offset call goes away.  The factor of two makes sense
> because you need to check 4 * 2 * regs_written bits in total, since
> you're keeping track of 8 bits per GRF.  It would likely make sense
> to

Hmm... what about the case of exec_size == 4 and writing just a float? 

I understand in this case we only should mark one word, so the loop
should  not be 2*inst->regs_written.

Note that in the original patch that was the case for using offs == 0.
So I guess we should compute if we should use 1 or 2 times
regs_written.


J.A.


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 97231] GL_DEPTH_CLAMP doesn't clamp to the far plane

[bugzilla-daemon]

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

--- Comment #5 from Jules Blok  ---
(In reply to Roland Scheidegger from comment #4)
> Oh I could see why it might not work with llvmpipe if you do reverse depth
> range.

We already had this problem before we reversed the depth range, refer to the
obsolete apitrace to see the same sample without the reversed depth range.

-- 
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 97231] GL_DEPTH_CLAMP doesn't clamp to the far plane

[bugzilla-daemon]

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

--- Comment #4 from Roland Scheidegger  ---
(In reply to Jules Blok from comment #3)
> Created attachment 125589 [details]
> apitrace file version 2
> 
> That's a rounding error, 16777215 / 16777216 is being rounded to 1 in the
> apitrace GUI.
> 
> I've attached another apitrace that's more representative of the current PR.
> The difference being that we've reversed the depth range to gain more depth
> precision.

Oh I could see why it might not work with llvmpipe if you do reverse depth
range.
lp_setup_set_viewports() will set the min/max depth (they actually get
"reverse-calculated" from viewport), but it will not take the potential
reversing into account, so assuming near <= far. These values are then later
used for clamping (in generate_fs_loop). Thus with min = 1.0, max = 0.0 it will
first do the min against max (so the value will end up negative or 0.0) and
then the max against min from the result (therefore, any value would end up as
1.0).
Just a theory though...

-- 
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 - Mesa 06/10] Revert "st/mesa: use sRGB formats for MSAA resolving if destination is sRGB"

[Nicolai Hähnle]

Reviewed-by: Nicolai Hähnle 

On 05.08.2016 01:14, Kenneth Graunke wrote:

This reverts commit 4e549ddb500cf677b6fa16d9ebdfa67cc23da097,
dropping the hack from Gallium that I just deleted from i965.

See the previous commit for rationale.
---
 src/mesa/state_tracker/st_cb_blit.c | 32 
 1 file changed, 32 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_blit.c 
b/src/mesa/state_tracker/st_cb_blit.c
index 826152d..5e7c34c 100644
--- a/src/mesa/state_tracker/st_cb_blit.c
+++ b/src/mesa/state_tracker/st_cb_blit.c
@@ -46,34 +46,6 @@


 static void
-st_adjust_blit_for_msaa_resolve(struct pipe_blit_info *blit)
-{
-   /* Even though we do multisample resolves at the time of the blit, OpenGL
-* specification defines them as if they happen at the time of rendering,
-* which means that the type of averaging we do during the resolve should
-* only depend on the source format; the destination format should be
-* ignored. But, specification doesn't seem to be strict about it.
-*
-* It has been observed that mulitisample resolves produce slightly better
-* looking images when averaging is done using destination format. NVIDIA's
-* proprietary OpenGL driver also follows this approach.
-*
-* When multisampling, if the source and destination formats are equal
-* (aside from the color space), we choose to blit in sRGB space to get
-* this higher quality image.
-*/
-   if (blit->src.resource->nr_samples > 1 &&
-   blit->dst.resource->nr_samples <= 1) {
-  blit->dst.format = blit->dst.resource->format;
-
-  if (util_format_is_srgb(blit->dst.resource->format))
- blit->src.format = util_format_srgb(blit->src.resource->format);
-  else
- blit->src.format = util_format_linear(blit->src.resource->format);
-   }
-}
-
-static void
 st_BlitFramebuffer(struct gl_context *ctx,
struct gl_framebuffer *readFB,
struct gl_framebuffer *drawFB,
@@ -232,8 +204,6 @@ st_BlitFramebuffer(struct gl_context *ctx,
   blit.src.box.z = srcAtt->Zoffset + srcAtt->CubeMapFace;
   blit.src.format = util_format_linear(srcObj->pt->format);

-  st_adjust_blit_for_msaa_resolve();
-
   st->pipe->blit(st->pipe, );
   dstRb->defined = true; /* front buffer tracking */
}
@@ -270,8 +240,6 @@ st_BlitFramebuffer(struct gl_context *ctx,
   blit.src.box.z = srcSurf->u.tex.first_layer;
   blit.src.format = util_format_linear(srcSurf->format);

-  st_adjust_blit_for_msaa_resolve();
-
   st->pipe->blit(st->pipe, );
   dstRb->defined = true; /* front buffer tracking */
}


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

Re: [Mesa-dev] [PATCH - Mesa 10/10] st/mesa: Make Gallium's BlitFramebuffer follow the GL 4.4 sRGB rules.

[Nicolai Hähnle]

I'm glad your sanity is still hanging on :) I particularly like the "Yes 
& No" in the comparison table.


Anyway, this patch and the piglit patches are

Reviewed-by: Nicolai Hähnle 

On 05.08.2016 01:14, Kenneth Graunke wrote:

OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled.  This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.

The NVIDIA 367.35 drivers appear to follow this behavior.

For the awful spec analysis, please read Piglit's
tests/spec/arb_framebuffer_srgb/blit.c, which explains the differences
between GL 4.1, 4.2, 4.3 (2012), 4.3 (2013), and 4.4, and why this
is the right rule to implement.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/state_tracker/st_cb_blit.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

Whoever designed this interface did a very nice job.  Making this change
was really simple.  I wrote the obvious code, tested it with llvmpipe,
and it appears to be working.

diff --git a/src/mesa/state_tracker/st_cb_blit.c 
b/src/mesa/state_tracker/st_cb_blit.c
index 5e7c34c..cfcf3f7 100644
--- a/src/mesa/state_tracker/st_cb_blit.c
+++ b/src/mesa/state_tracker/st_cb_blit.c
@@ -44,6 +44,14 @@

 #include "util/u_format.h"

+static void
+st_adjust_blit_for_srgb(struct pipe_blit_info *blit, bool framebuffer_srgb)
+{
+   if (!framebuffer_srgb) {
+  blit->dst.format = util_format_linear(blit->dst.format);
+  blit->src.format = util_format_linear(blit->src.format);
+   }
+}

 static void
 st_BlitFramebuffer(struct gl_context *ctx,
@@ -197,12 +205,14 @@ st_BlitFramebuffer(struct gl_context *ctx,
   blit.dst.resource = dstSurf->texture;
   blit.dst.level = dstSurf->u.tex.level;
   blit.dst.box.z = dstSurf->u.tex.first_layer;
-  blit.dst.format = util_format_linear(dstSurf->format);
+  blit.dst.format = dstSurf->format;

   blit.src.resource = srcObj->pt;
   blit.src.level = srcAtt->TextureLevel;
   blit.src.box.z = srcAtt->Zoffset + srcAtt->CubeMapFace;
-  blit.src.format = util_format_linear(srcObj->pt->format);
+  blit.src.format = srcObj->pt->format;
+
+  st_adjust_blit_for_srgb(, ctx->Color.sRGBEnabled);

   st->pipe->blit(st->pipe, );
   dstRb->defined = true; /* front buffer tracking */
@@ -233,12 +243,14 @@ st_BlitFramebuffer(struct gl_context *ctx,
   blit.dst.resource = dstSurf->texture;
   blit.dst.level = dstSurf->u.tex.level;
   blit.dst.box.z = dstSurf->u.tex.first_layer;
-  blit.dst.format = util_format_linear(dstSurf->format);
+  blit.dst.format = dstSurf->format;

   blit.src.resource = srcSurf->texture;
   blit.src.level = srcSurf->u.tex.level;
   blit.src.box.z = srcSurf->u.tex.first_layer;
-  blit.src.format = util_format_linear(srcSurf->format);
+  blit.src.format = srcSurf->format;
+
+  st_adjust_blit_for_srgb(, ctx->Color.sRGBEnabled);

   st->pipe->blit(st->pipe, );
   dstRb->defined = true; /* front buffer tracking */


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