[Mesa-dev] [Bug 79629] [Dri3 bisected] piglit glx_GLX_ARB_create_context_current_with_no_framebuffer fail

[bugzilla-daemon]

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

--- Comment #14 from Eero Tamminen  ---
(In reply to XiongZhang from comment #13)
> Yes, I test with DRI3. When I compile xf86-video-intel and mesa, I add
> --enable-dri3 option.
> Without the proposed patch, I could easily reproduce this issue. And adding
> "DRI 2" option to Xorg.conf, this issue disappear.

I assume you refer to the original bug and versions of SW at that time.

In the meanwhile X intel driver defaulted back to DRI2 from DRI3.  I think you
need now to set DRI to version 3 specifically in xorg.conf.  Chris?

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

[Mesa-dev] [Bug 79629] [Dri3 bisected] piglit glx_GLX_ARB_create_context_current_with_no_framebuffer fail

[bugzilla-daemon]

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

--- Comment #13 from XiongZhang  ---
(In reply to Chris Wilson from comment #12)
> Do you mind reconfirming that you actually tested with DRI3 since the
> proposed patch is not yet included?

Yes, I test with DRI3. When I compile xf86-video-intel and mesa, I add
--enable-dri3 option.
Without the proposed patch, I could easily reproduce this issue. And adding
"DRI 2" option to Xorg.conf, this issue disappear.

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

[Mesa-dev] [Bug 88962] [osmesa] Crash on postprocessing if z buffer is NULL

[bugzilla-daemon]

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

--- Comment #1 from Park, Jeongmin  ---
Created attachment 113147
  --> https://bugs.freedesktop.org/attachment.cgi?id=113147&action=edit
patch #1

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88962] [osmesa] Crash on postprocessing if z buffer is NULL

[bugzilla-daemon]

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

--- Comment #2 from Park, Jeongmin  ---
Created attachment 113148
  --> https://bugs.freedesktop.org/attachment.cgi?id=113148&action=edit
patch #2

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88962] [osmesa] Crash on postprocessing if z buffer is NULL

[bugzilla-daemon]

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

Bug ID: 88962
   Summary: [osmesa] Crash on postprocessing if z buffer is NULL
   Product: Mesa
   Version: git
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: pjm0...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

It seems that z buffer is not optional to pp_run looking at other codes
but it is not checked in osmesa_st_framebuffer_flush_front().

It crashes if zsbuf is NULL with pp_jimenezmlaa. With pp_nored it doesn't
crash,
but if pipe_sampler_view.reference is not the first member in
struct pipe_sampler_view, it would crash in pipe_sampler_view_reference at
>   if (pipe_reference_described(&(*ptr)->reference, &view->reference,
>
> (debug_reference_descriptor)debug_describe_sampler_view))

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] i965/fs: Implement the WaCMPInstFlagDepClearedEarly work-around.

[Matt Turner]

Prevents piglit regressions from the next patch.
---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 37 +-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 77d4908..8cd36f8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1734,7 +1734,42 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
  brw_F16TO32(p, dst, src[0]);
  break;
   case BRW_OPCODE_CMP:
-brw_CMP(p, dst, inst->conditional_mod, src[0], src[1]);
+ /* The Ivybridge/BayTrail WaCMPInstFlagDepClearedEarly workaround says
+  * that when the destination is a GRF that the dependency-clear bit on
+  * the flag register is cleared early.
+  *
+  * Suggested workarounds are to disable coissuing CMP instructions
+  * or to split CMP(16) instructions into two CMP(8) instructions.
+  *
+  * We choose to split into CMP(8) instructions since disabling
+  * coissuing would affect CMP instructions not otherwise affected by
+  * the errata.
+  */
+ if (dispatch_width == 16 && brw->gen == 7 && !brw->is_haswell) {
+if (dst.file == BRW_GENERAL_REGISTER_FILE) {
+   brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
+   brw_CMP(p, firsthalf(dst), inst->conditional_mod,
+  firsthalf(src[0]), firsthalf(src[1]));
+   brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
+   brw_CMP(p, sechalf(dst), inst->conditional_mod,
+  sechalf(src[0]), sechalf(src[1]));
+   brw_set_default_compression_control(p, 
BRW_COMPRESSION_COMPRESSED);
+
+   multiple_instructions_emitted = true;
+} else if (dst.file == BRW_ARCHITECTURE_REGISTER_FILE) {
+   /* For unknown reasons, the aforementioned workaround is not
+* sufficient. Overriding the type when the destination is the
+* null register is necessary but not sufficient by itself.
+*/
+   assert(dst.nr == BRW_ARF_NULL);
+   dst.type = BRW_REGISTER_TYPE_D;
+   brw_CMP(p, dst, inst->conditional_mod, src[0], src[1]);
+} else {
+   unreachable("not reached");
+}
+ } else {
+brw_CMP(p, dst, inst->conditional_mod, src[0], src[1]);
+ }
 break;
   case BRW_OPCODE_SEL:
 brw_SEL(p, dst, src[0], src[1]);
-- 
2.0.4

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

[Mesa-dev] [PATCH 2/3] i965: Set CMP's destination type to src0's type.

[Matt Turner]

Allows CMP instructions with float sources to be compacted and coissued.
---
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 16 ++--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 20 
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0ada583..2046eba 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -339,17 +339,13 @@ fs_visitor::CMP(fs_reg dst, fs_reg src0, fs_reg src1,
 *
 * Original gen4 does type conversion to the destination type before
 * comparison, producing garbage results for floating point comparisons.
-* gen5 does the comparison on the execution type (resolved source types),
-* so dst type doesn't matter.  gen6 does comparison and then uses the
-* result as if it was the dst type with no conversion, which happens to
-* mostly work out for float-interpreted-as-int since our comparisons are
-* for >0, =0, <0.
+*
+* The destination type doesn't matter on newer generations, so we set the
+* type to match src0 so we can compact the instruction.
 */
-   if (brw->gen == 4) {
-  dst.type = src0.type;
-  if (dst.file == HW_REG)
-dst.fixed_hw_reg.type = dst.type;
-   }
+   dst.type = src0.type;
+   if (dst.file == HW_REG)
+  dst.fixed_hw_reg.type = dst.type;
 
resolve_ud_negate(&src0);
resolve_ud_negate(&src1);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 8129118..e6a7ed0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -222,15 +222,19 @@ vec4_visitor::CMP(dst_reg dst, src_reg src0, src_reg src1,
 {
vec4_instruction *inst;
 
-   /* original gen4 does type conversion to the destination type
-* before before comparison, producing garbage results for floating
-* point comparisons.
+   /* Take the instruction:
+*
+* CMP null src0 src1
+*
+* Original gen4 does type conversion to the destination type before
+* comparison, producing garbage results for floating point comparisons.
+*
+* The destination type doesn't matter on newer generations, so we set the
+* type to match src0 so we can compact the instruction.
 */
-   if (brw->gen == 4) {
-  dst.type = src0.type;
-  if (dst.file == HW_REG)
-dst.fixed_hw_reg.type = dst.type;
-   }
+   dst.type = src0.type;
+   if (dst.file == HW_REG)
+  dst.fixed_hw_reg.type = dst.type;
 
resolve_ud_negate(&src0);
resolve_ud_negate(&src1);
-- 
2.0.4

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

[Mesa-dev] [PATCH 3/3] i965: Remove now unnecessary Gen8 CMP destination type override.

[Matt Turner]

---
 src/mesa/drivers/dri/i965/brw_eu_emit.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 57161e2..308b305 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -1849,14 +1849,6 @@ void brw_CMP(struct brw_compile *p,
struct brw_context *brw = p->brw;
brw_inst *insn = next_insn(p, BRW_OPCODE_CMP);
 
-   if (brw->gen >= 8) {
-  /* The CMP instruction appears to behave erratically for floating point
-   * sources unless the destination type is also float.  Overriding it to
-   * match src0 makes it work in all cases.
-   */
-  dest.type = src0.type;
-   }
-
brw_inst_set_cond_modifier(brw, insn, conditional);
brw_set_dest(p, insn, dest);
brw_set_src0(p, insn, src0);
-- 
2.0.4

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

Re: [Mesa-dev] [PATCH 10/10] radeonsi: implement polygon stippling

[Michel Dänzer]

On 03.02.2015 22:43, Marek Olšák wrote:
> On Mon, Feb 2, 2015 at 10:05 AM, Michel Dänzer  wrote:
>> On 02.02.2015 02:37, Marek Olšák wrote:
>>> From: Marek Olšák 
>>>
>>> The stipple texture is bound to slot 16, so there are 17 sampler states and
>>> 34 sampler views now (17 normal slots + 17 fmask slots).
>>
>> [...]
>>
>>> @@ -2742,16 +2743,26 @@ static int si_generate_gs_copy_shader(struct 
>>> si_screen *sscreen,
>>>  int si_shader_create(struct si_screen *sscreen, struct si_shader *shader)
>>>  {
>>>   struct si_shader_selector *sel = shader->selector;
>>> + struct tgsi_token *tokens = sel->tokens;
>>>   struct si_shader_context si_shader_ctx;
>>>   struct lp_build_tgsi_context * bld_base;
>>> + struct tgsi_shader_info stipple_shader_info;
>>>   LLVMModuleRef mod;
>>>   int r = 0;
>>> + bool poly_stipple = sel->type == PIPE_SHADER_FRAGMENT &&
>>> + shader->key.ps.poly_stipple;
>>>   bool dump = r600_can_dump_shader(&sscreen->b, sel->tokens);
>>>
>>> + if (poly_stipple) {
>>> + tokens = util_pstipple_create_fragment_shader(tokens, NULL,
>>> + SI_POLY_STIPPLE_SAMPLER);
>>> + tgsi_scan_shader(tokens, &stipple_shader_info);
>>> +}
>>
>> The indentation of the closing curly brace is wrong.
> 
> Updated patches are attached.

Both

Reviewed-by: Michel Dänzer 


>>> @@ -109,14 +110,16 @@ union si_state {
>>>   struct si_pm4_state *array[0];
>>>  };
>>>
>>> -#define SI_NUM_USER_SAMPLERS 16 /* AKA OpenGL textures units per shader */
>>> +#define SI_NUM_USER_SAMPLERS 16 /* AKA OpenGL textures units per 
>>> shader */
>>
>> SI_NUM_USER_SAMPLERS could be bumped in or after patch 8, right?
> 
> Did you mean SI_NUM_SAMPLES? I split that into a separate patch.
> 
> SI_NUM_USER_SAMPLERS could be bumped, but I don't see a point yet.

The intel driver bumped it to 32 in
d8c7740ddabeb456243e40dc3cf0e86c7fca09d0, but the only justification was
'the Windows driver did so'.

I also saw in the meantime that it would require bumping something in
the TGSI(?) code as well.

I guess we can wait until we get reports of apps which want to use more
than 16.


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

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

[bugzilla-daemon]

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

--- Comment #9 from Michel Dänzer  ---
(In reply to Lorenzo Bona from comment #7)
> I'm experiencing the same problem here.
> 
> Computer suddently hangs and I have to reboot.

I doubt those hangs are directly related to these messages.

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

Re: [Mesa-dev] [PATCH v2] c11/threads: Use PTHREAD_MUTEX_RECURSIVE by default

[Felix Janda]

Emil Velikov wrote:
> On 3 February 2015 at 02:53, Emil Velikov  wrote:
> > Hi Felix,
> >

Thanks for the review.

> > On 2 February 2015 at 19:04, Felix Janda  wrote:
> >> Previously PTHREAD_MUTEX_RECURSIVE_NP had been used on linux for
> >> compatibility with old glibc. Since mesa defines __GNU_SOURCE__
> >> on linux PTHREAD_MUTEX_RECURSIVE is also available since at least
> >> 1998. So we can unconditionally use the portable version
> >> PTHREAD_MUTEX_RECURSIVE.
> >> ---
> >> Previous patch didn't work as intended since on glibc these are
> >> part of an enum and not defines.
> >>
> > From a quick look at {e,}glibc sources [1]
> >
> >PTHREAD_MUTEX_RECURSIVE_NP,
> >...
> >#if defined __USE_UNIX98 || defined __USE_XOPEN2K8
> >...
> >PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
> >...
> >
> > Which does not seem to have relation with _GNU_SOURCE_ as the commit
> > mentions. Note I don't even pretend to know the convoluted web of
> > macros, so I could be a bit off :-)
> >

_GNU_SOURCE basically stands for "enable everything". I've checked that
for glibc 2.1 it defined _XOPEN_SOURCE=500 which in turn defines
__USE_UNIX98.

> Upon closer look things could be fine, as
> 
>   linux/gnu: _GNU_SOURCE sets _POSIX_C_SOURCE 200809L.
> With the latter of which guarding the __USE_XOPEN2K8  definition.
> 
>   cygwin: (hmm does it even set __linux*) we set _XOPEN_SOURCE=700.
> Which is the guard for __USE_XOPEN2K8.

http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system

seems to indicate that it doesn't. I don't think that anything but
glibc has PTHREAD_MUTEX_RECURSIVE_NP.

> If one wants to be extra careful we can change
>   #if defined(__linux__) || defined(__linux)
> to check for the said old versions of glibc, but I believe we should be safe.

#if defined(__GLIBC__) is fine, too. Unless you care about hurd:
https://bugzilla.gnome.org/show_bug.cgi?id=377066

Something along this line is necessary (and sufficient) to compile
mesa unmodified with musl libc.

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

Re: [Mesa-dev] [PATCH 7/9] gallium/u_tests: test a NULL texture sampler view

[Marek Olšák]

Interesting. On radeonsi, the default value of an unbound texture can
be chosen but is the same for "load", "sample", and "gather"
instructions. We can't return (0,0,0,0) for "load" and (0,0,0,1) for
"sample".

I'll just modify the test to accept both return values.

Marek

On Mon, Feb 2, 2015 at 5:19 PM, Roland Scheidegger  wrote:
> Actually, since ARB_robust_buffer_access_behavior, GL requires some
> specfic values, but it's - odd...
> "In all the above cases, if the context was created with robust buffer
> access enabled then instead of undefined behavior the result of the
> texel fetch is zero. For the case of a texel fetch on an incomplete
> texture the result is a texture source color of (0, 0, 0, 1)."
> So, it seems if the texture was incomplete, then 0/0/0/1 has to be
> returned, but if it was unbound, then all zeros is the right answer.
> However, this is only true for textures _fetches_, not ordinary sampling
> (it is described in the vertex shader functionality). I would assume
> this to be the case for ordinary sampling too, but there the spec only
> describes the 0/0/0/1 behavior for incomplete textures, not the behavior
> for unbound ones...
>
> Roland
>
>
>
> Am 02.02.2015 um 16:51 schrieb Roland Scheidegger:
>> I don't think this is really correct. llvmpipe will return all zeros on
>> purpose, because this is d3d10 behavior (and dummy textures cannot work
>> correctly with d3d10). Traditionally both d3d9 and gl state trackers
>> used dummy textures, though I'm unsure what values they required (if
>> any). (For d3d9 though 0/0/0/1 would be somewhat odd since it would be
>> different to what bound textures but unused channels have to return, but
>> d3d9 is sometimes odd so it's possible. Well in that way d3d10 is odd
>> too...)
>> I certainly do agree though with the "don't crash" part.
>>
>> Am 01.02.2015 um 18:15 schrieb Marek Olšák:
>>> From: Marek Olšák 
>>>
>>> It shouldn't crash the GPU and it should return (0, 0, 0, 1).
>>>
>>> This is r300 behavior, so I assume it's also DX9 behavior.
>>> Radeonsi can support this easily.
>>> ---
>>>  src/gallium/auxiliary/util/u_tests.c | 39 
>>> 
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/src/gallium/auxiliary/util/u_tests.c 
>>> b/src/gallium/auxiliary/util/u_tests.c
>>> index 89ae840..9c8514c 100644
>>> --- a/src/gallium/auxiliary/util/u_tests.c
>>> +++ b/src/gallium/auxiliary/util/u_tests.c
>>> @@ -304,6 +304,44 @@ tgsi_vs_window_space_position(struct pipe_context *ctx)
>>> util_report_result(pass);
>>>  }
>>>
>>> +static void
>>> +null_sampler_view(struct pipe_context *ctx)
>>> +{
>>> +   struct cso_context *cso;
>>> +   struct pipe_resource *cb;
>>> +   void *fs, *vs;
>>> +   bool pass = true;
>>> +   static const float expected[] = {0, 0, 0, 1};
>>> +
>>> +   cso = cso_create_context(ctx);
>>> +   cb = util_create_texture2d(ctx->screen, 256, 256,
>>> +  PIPE_FORMAT_R8G8B8A8_UNORM);
>>> +   util_set_common_states_and_clear(cso, ctx, cb);
>>> +
>>> +   ctx->set_sampler_views(ctx, PIPE_SHADER_FRAGMENT, 0, 1, NULL);
>>> +
>>> +   /* Fragment shader. */
>>> +   fs = util_make_fragment_tex_shader(ctx, TGSI_TEXTURE_2D,
>>> +  TGSI_INTERPOLATE_LINEAR);
>>> +   cso_set_fragment_shader_handle(cso, fs);
>>> +
>>> +   /* Vertex shader. */
>>> +   vs = util_set_passthrough_vertex_shader(cso, ctx, false);
>>> +   util_draw_fullscreen_quad(cso);
>>> +
>>> +   /* Probe pixels. */
>>> +   pass = pass && util_probe_rect_rgba(ctx, cb, 0, 0,
>>> +   cb->width0, cb->height0, expected);
>>> +
>>> +   /* Cleanup. */
>>> +   cso_destroy_context(cso);
>>> +   ctx->delete_vs_state(ctx, vs);
>>> +   ctx->delete_fs_state(ctx, fs);
>>> +   pipe_resource_reference(&cb, NULL);
>>> +
>>> +   util_report_result(pass);
>>> +}
>>> +
>>>  /**
>>>   * Run all tests. This should be run with a clean context after
>>>   * context_create.
>>> @@ -314,6 +352,7 @@ util_run_tests(struct pipe_screen *screen)
>>> struct pipe_context *ctx = screen->context_create(screen, NULL);
>>>
>>> tgsi_vs_window_space_position(ctx);
>>> +   null_sampler_view(ctx);
>>>
>>> ctx->destroy(ctx);
>>>
>>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=XOQSHQnIu1sXl65rM4KSLIO5-Zej5H2L9o1CVQNkXvQ&s=uBbprkG3Qul-bWCqNmg5fX-4b9csQamQpx5wWJZmWcU&e=
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] drirc: add workarounds for Unigine Sanctuary v2

[Matt Turner]

On Tue, Feb 3, 2015 at 7:41 AM, Martin Peres
 wrote:
> v2:
> - rename mesa_extension-override to extension_override
> - improve the comment by telling we disable GL_ARB_gpu_shader5 (Ilia)
> - fix the name ARB_GL_gpu_shader5 to GL_ARB_gpu_shader5 (Ilia)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82897
> Signed-off-by: Martin Peres 
> ---
>  src/mesa/drivers/dri/common/drirc | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/drirc 
> b/src/mesa/drivers/dri/common/drirc
> index 10c60d5..8d59e61 100644
> --- a/src/mesa/drivers/dri/common/drirc
> +++ b/src/mesa/drivers/dri/common/drirc
> @@ -10,6 +10,12 @@ Application bugs worked around in this file:
>Enabling all extensions for Unigine fixes most issues, but the GLSL version
>is still 1.10.
>
> +* Unigine Sanctuary 2.3 makes use of the "sample" keyword which is reserved
> +  with GL_ARB_gpu_shader5 which got enabled by force_glsl_extensions_warn.

It doesn't make use of the sample keyword, it just has a variable
named "sample" which has now become a keyword, right?

How about

 uses "sample" as a variable name which is a keyword as
of GL_ARB_gpu_shader5. GL_ARB_gpu_shader5 is enabled by
force_glsl_extensions_warn.

The same comment applies to 3/4.

With the comment updated, 3 and 4 are

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/9] nir: Add a flag for lowering fneg/ineg.

[Connor Abbott]

On Tue, Feb 3, 2015 at 5:20 PM, Eric Anholt  wrote:
> Connor Abbott  writes:
>
>> I think this logic should be flipped around... you should have a flag
>> 'lower_sub' which is false for vc4 but true for i965, and then if the
>> flag is true we lower sub to add+neg and if false we try and
>> reconstruct sub (and do other things like pulling neg's out of
>> multiplies). That way, eventually we can turn off the lowering in GLSL
>> IR and in the future pass a subtract in the GLSL source all the way
>> down to the driver without lowering it and then un-lowering it.
>
> I think given that vc4 is pretty much alone in wanting SUBs instead of
> src modifiers, we should probably be the non-default flag value, but I
> don't feel too strongly.

Well, I think that the other way is more consistent with stuff like
lower_pow where some hardware can do the more complicated thing
directly and some can't, plus this is the way it already works in GLSL
IR. But yeah, it's not terribly important and now that I think about
it it could go either way.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

[bugzilla-daemon]

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

--- Comment #8 from Lorenzo Bona  ---
Created attachment 113141
  --> https://bugs.freedesktop.org/attachment.cgi?id=113141&action=edit
Xorg.log

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

[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

[bugzilla-daemon]

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

--- Comment #7 from Lorenzo Bona  ---
I'm experiencing the same problem here.

Computer suddently hangs and I have to reboot.
In Xorg.0.log I have the same warnings.
Dmesg has no issue.

Running on drm-fixes-3.19 (rc6), mesa/ddx/xorg/drm from git, LLVM 3.6 rc2 from
Debian Sid.

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

Re: [Mesa-dev] [PATCH] torus.c: Lighting effect is distorted when object is scaled up/down

[Brian Paul]

On 02/03/2015 03:48 PM, Dongwon Kim wrote:

When torus object is scaled up/down via glScalef call the lighting
effect is incorrectly expressed on render target because normals'
length is also changed when vertices are scaled up/down.

This patch enables "automatic normalization" of normals, which
is one of well-known ways to avoid this kind of distortion.

Reference:
www.opengl.org/sdk/docs/man2/xhtml/glScale.xml

Notes

  If scale factors other than 1 are applied to the modelview matrix
  and lighting is enabled, lighting often appears wrong.
  In that case, enable automatic normalization of normals by
  calling glEnable with the argument GL_NORMALIZE.

Signed-off-by: Dongwon Kim 
---
  src/egl/opengles1/torus.c |4 
  1 file changed, 4 insertions(+)

diff --git a/src/egl/opengles1/torus.c b/src/egl/opengles1/torus.c
index 8f262b5..bb20670 100644
--- a/src/egl/opengles1/torus.c
+++ b/src/egl/opengles1/torus.c
@@ -358,6 +358,10 @@ init(void)

 make_texture();
 glEnable(GL_TEXTURE_2D);
+
+   /* Enabling automatic normalizing to prevent wrong expression of lighting
+  when torus is scaled down via glScalef */
+   glEnable(GL_NORMALIZE);
  }



Reviewed-by: Brian Paul 

I'll commit this for you.

-Brian

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

[Mesa-dev] [PATCH] egl, wayland: RGB565 format support on Back-buffer

[Dongwon Kim]

In current code, color format is always hardcoded to __DRI_IMAGE_FORMAT_ARGB
when buffer or DRI image is allocated in function calls, get_back_bo and 
dri2_get_buffers,
regardless of current target's color format. This problem may leads to 
incorrect render
pitch calculation, which eventually ends up with wrong offset of pixels in the 
frame buffer
when the image is in different color format from dri surf's, especially with 
different bpp.
(e.g. 16bpp)

Attached code patch simply adds RGB565 case to two functions noted above to 
resolve
the issue.

Signed-off-by: Vivek Kasireddy 
Signed-off-by: Dongwon Kim 
---
 src/egl/drivers/dri2/platform_wayland.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 3c34e07..78761e2 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -293,6 +293,11 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
   dri2_egl_display(dri2_surf->base.Resource.Display);
int i;
 
+   /* currently supports two DRI image formats, __DRI_IMAGE_FORMAT_RGB565 or 
__DRI_IMAGE_FORMAT_ARGB,
+* one of which is selected depending on dri surface format */
+   const unsigned int dri_image_format =
+(dri2_surf->format == WL_DRM_FORMAT_RGB565) ? 
__DRI_IMAGE_FORMAT_RGB565 : __DRI_IMAGE_FORMAT_ARGB;
+
/* We always want to throttle to some event (either a frame callback or
 * a sync request) after the commit so that we can be sure the
 * compositor has had a chance to handle it and send us a release event
@@ -322,7 +327,7 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
  dri2_dpy->image->createImage(dri2_dpy->dri_screen,
   dri2_surf->base.Width,
   dri2_surf->base.Height,
-  __DRI_IMAGE_FORMAT_ARGB,
+  dri_image_format,
   __DRI_IMAGE_USE_SHARE,
   NULL);
   dri2_surf->back->age = 0;
@@ -462,9 +467,10 @@ dri2_wl_get_buffers(__DRIdrawable * driDrawable,
 unsigned int *attachments, int count,
 int *out_count, void *loaderPrivate)
 {
+   struct dri2_egl_surface *dri2_surf = loaderPrivate;
unsigned int *attachments_with_format;
__DRIbuffer *buffer;
-   const unsigned int format = 32;
+   const unsigned int format = (dri2_surf->format == WL_DRM_FORMAT_RGB565) ? 
16 : 32;
int i;
 
attachments_with_format = calloc(count, 2 * sizeof(unsigned int));
-- 
1.7.9.5

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

[Mesa-dev] [Bug 88930] [osmesa] osbuffer->textures should be indexed by attachment type

[bugzilla-daemon]

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

Brian Paul  changed:

   What|Removed |Added

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

--- Comment #2 from Brian Paul  ---
Patch pushed.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] torus.c: Lighting effect is distorted when object is scaled up/down

[Dongwon Kim]

When torus object is scaled up/down via glScalef call the lighting
effect is incorrectly expressed on render target because normals'
length is also changed when vertices are scaled up/down.

This patch enables "automatic normalization" of normals, which
is one of well-known ways to avoid this kind of distortion.

Reference:
www.opengl.org/sdk/docs/man2/xhtml/glScale.xml

Notes

 If scale factors other than 1 are applied to the modelview matrix
 and lighting is enabled, lighting often appears wrong.
 In that case, enable automatic normalization of normals by
 calling glEnable with the argument GL_NORMALIZE.

Signed-off-by: Dongwon Kim 
---
 src/egl/opengles1/torus.c |4 
 1 file changed, 4 insertions(+)

diff --git a/src/egl/opengles1/torus.c b/src/egl/opengles1/torus.c
index 8f262b5..bb20670 100644
--- a/src/egl/opengles1/torus.c
+++ b/src/egl/opengles1/torus.c
@@ -358,6 +358,10 @@ init(void)
 
make_texture();
glEnable(GL_TEXTURE_2D);
+
+   /* Enabling automatic normalizing to prevent wrong expression of lighting
+  when torus is scaled down via glScalef */
+   glEnable(GL_NORMALIZE);
 }
 
 
-- 
1.7.9.5

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

[Mesa-dev] [PATCH] st/osmesa: simplify osmesa_st_framebuffer_flush_front()

[Brian Paul]

The osmesa->textures[] array is indexed by ST_ATTACHMENT_* so
there's no need to search the array to find the depth/stencil buffer.
This is a follow-on improvement after bug 88930.
---
 src/gallium/state_trackers/osmesa/osmesa.c | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/src/gallium/state_trackers/osmesa/osmesa.c 
b/src/gallium/state_trackers/osmesa/osmesa.c
index 4e2b2e0..cbda267 100644
--- a/src/gallium/state_trackers/osmesa/osmesa.c
+++ b/src/gallium/state_trackers/osmesa/osmesa.c
@@ -319,21 +319,11 @@ osmesa_st_framebuffer_flush_front(struct st_context_iface 
*stctx,
int dst_stride;
 
if (osmesa->pp) {
-  struct pipe_resource *zsbuf = NULL;
-  unsigned i;
-
-  /* Find the z/stencil buffer if there is one */
-  for (i = 0; i < Elements(osbuffer->textures); i++) {
- struct pipe_resource *res = osbuffer->textures[i];
- if (res) {
-const struct util_format_description *desc =
-   util_format_description(res->format);
-
-if (util_format_has_depth(desc)) {
-   zsbuf = res;
-   break;
-}
- }
+  /* Get the z/stencil buffer if there is one */
+  struct pipe_resource *zsbuf =
+ osbuffer->textures[ST_ATTACHMENT_DEPTH_STENCIL];
+  if (zsbuf) {
+ assert(util_format_has_depth(util_format_description(zsbuf->format)));
   }
 
   /* run the postprocess stage(s) */
-- 
1.9.1

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

[Mesa-dev] [Bug 88930] [osmesa] osbuffer->textures should be indexed by attachment type

[bugzilla-daemon]

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

--- Comment #1 from Brian Paul  ---
Thanks.  Your patch looks correct.  I believe we can also simply some code in
osmesa_st_framebuffer_flush_front() as a follow-on.

I'll apply your patch to master and the 10.4 branch.

-- 
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
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/9] nir: Add a flag for lowering fneg/ineg.

[Eric Anholt]

Connor Abbott  writes:

> I think this logic should be flipped around... you should have a flag
> 'lower_sub' which is false for vc4 but true for i965, and then if the
> flag is true we lower sub to add+neg and if false we try and
> reconstruct sub (and do other things like pulling neg's out of
> multiplies). That way, eventually we can turn off the lowering in GLSL
> IR and in the future pass a subtract in the GLSL source all the way
> down to the driver without lowering it and then un-lowering it.

I think given that vc4 is pretty much alone in wanting SUBs instead of
src modifiers, we should probably be the non-default flag value, but I
don't feel too strongly.


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

Re: [Mesa-dev] [PATCH 2/2] nir/validate: Validate that only float ALU outputs are saturated

[Erik Faye-Lund]

On Feb 3, 2015 10:39 PM, "Jason Ekstrand"  wrote:
>
>
>
> On Tue, Feb 3, 2015 at 1:08 PM, Erik Faye-Lund 
wrote:
>>
>> On Tue, Feb 3, 2015 at 9:43 PM, Jason Ekstrand 
wrote:
>> > ---
>> >  src/glsl/nir/nir_validate.c | 8 
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
>> > index 7c801b2..89dfdf8 100644
>> > --- a/src/glsl/nir/nir_validate.c
>> > +++ b/src/glsl/nir/nir_validate.c
>> > @@ -239,6 +239,14 @@ validate_alu_dest(nir_alu_dest *dest,
validate_state *state)
>> >  * register/SSA value
>> >  */
>> > assert(is_packed || !(dest->write_mask & ~((1 << dest_size) - 1)));
>> > +
>> > +   /* validate that saturate is only ever used on instructions with
>> > +* destinations of type float
>> > +*/
>> > +   nir_alu_instr *alu = nir_instr_as_alu(state->instr);
>> > +   assert(nir_op_infos[alu->op].output_type == nir_type_float ||
>> > +  !dest->saturate);
>>
>> I think this can end up generating a warning on builds with asserts
>> disabled due to "alu" being written but never read. Perhaps just do
>> "nir_instr_as_alu(state->instr)->op" directly in the expression? It's
>> a tad less readable, though :/
>
>
> It doesn't even get compiled if we have no asserts.  There's a giant
#ifdef DEBUG surrounding the entire file.

Right, my bad.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] nir/validate: Validate that only float ALU outputs are saturated

[Jason Ekstrand]

On Tue, Feb 3, 2015 at 1:08 PM, Erik Faye-Lund  wrote:

> On Tue, Feb 3, 2015 at 9:43 PM, Jason Ekstrand 
> wrote:
> > ---
> >  src/glsl/nir/nir_validate.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
> > index 7c801b2..89dfdf8 100644
> > --- a/src/glsl/nir/nir_validate.c
> > +++ b/src/glsl/nir/nir_validate.c
> > @@ -239,6 +239,14 @@ validate_alu_dest(nir_alu_dest *dest,
> validate_state *state)
> >  * register/SSA value
> >  */
> > assert(is_packed || !(dest->write_mask & ~((1 << dest_size) - 1)));
> > +
> > +   /* validate that saturate is only ever used on instructions with
> > +* destinations of type float
> > +*/
> > +   nir_alu_instr *alu = nir_instr_as_alu(state->instr);
> > +   assert(nir_op_infos[alu->op].output_type == nir_type_float ||
> > +  !dest->saturate);
>
> I think this can end up generating a warning on builds with asserts
> disabled due to "alu" being written but never read. Perhaps just do
> "nir_instr_as_alu(state->instr)->op" directly in the expression? It's
> a tad less readable, though :/
>

It doesn't even get compiled if we have no asserts.  There's a giant #ifdef
DEBUG surrounding the entire file.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] nir/validate: Validate that only float ALU outputs are saturated

[Erik Faye-Lund]

On Tue, Feb 3, 2015 at 9:43 PM, Jason Ekstrand  wrote:
> ---
>  src/glsl/nir/nir_validate.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
> index 7c801b2..89dfdf8 100644
> --- a/src/glsl/nir/nir_validate.c
> +++ b/src/glsl/nir/nir_validate.c
> @@ -239,6 +239,14 @@ validate_alu_dest(nir_alu_dest *dest, validate_state 
> *state)
>  * register/SSA value
>  */
> assert(is_packed || !(dest->write_mask & ~((1 << dest_size) - 1)));
> +
> +   /* validate that saturate is only ever used on instructions with
> +* destinations of type float
> +*/
> +   nir_alu_instr *alu = nir_instr_as_alu(state->instr);
> +   assert(nir_op_infos[alu->op].output_type == nir_type_float ||
> +  !dest->saturate);

I think this can end up generating a warning on builds with asserts
disabled due to "alu" being written but never read. Perhaps just do
"nir_instr_as_alu(state->instr)->op" directly in the expression? It's
a tad less readable, though :/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] nir: add an optimization to remove useless phi nodes

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 
Tested-by: Jason Ekstrand 

And here's the shader-db stats for the commit message:

total NIR instructions in shared programs: 2045293 -> 2041209 (-0.20%)
NIR instructions in affected programs: 126564 -> 122480 (-3.23%)
helped:615
HURT:  0

total FS instructions in shared programs: 4321840 -> 4320392 (-0.03%)
FS instructions in affected programs: 24622 -> 23174 (-5.88%)
helped:138
HURT:  0



On Mon, Feb 2, 2015 at 10:59 PM, Connor Abbott  wrote:

> On Tue, Feb 3, 2015 at 1:54 AM, Connor Abbott  wrote:
> > This removes phi nodes whose sources all point to the same thing.
> >
> > Only compile tested.
> >
> > Signed-off-by: Connor Abbott 
> > ---
> >  src/glsl/Makefile.sources  |   1 +
> >  src/glsl/nir/nir.h |   2 +
> >  src/glsl/nir/nir_opt_remove_phis.c | 111
> +
> >  3 files changed, 114 insertions(+)
> >  create mode 100644 src/glsl/nir/nir_opt_remove_phis.c
> >
> > diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> > index face22e..6d51c71 100644
> > --- a/src/glsl/Makefile.sources
> > +++ b/src/glsl/Makefile.sources
> > @@ -44,6 +44,7 @@ NIR_FILES = \
> > nir/nir_opt_dce.c \
> > nir/nir_opt_global_to_local.c \
> > nir/nir_opt_peephole_select.c \
> > +   nir/nir_opt_remove_phis.c \
> > nir/nir_print.c \
> > nir/nir_remove_dead_variables.c \
> > nir/nir_search.c \
> > diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> > index 98d2689..d1860d4 100644
> > --- a/src/glsl/nir/nir.h
> > +++ b/src/glsl/nir/nir.h
> > @@ -1559,6 +1559,8 @@ bool nir_opt_dce(nir_shader *shader);
> >  bool nir_opt_peephole_select(nir_shader *shader);
> >  bool nir_opt_peephole_ffma(nir_shader *shader);
> >
> > +bool nir_opt_remove_phis(nir_shader *shader);
> > +
> >  #ifdef __cplusplus
> >  } /* extern "C" */
> >  #endif
> > diff --git a/src/glsl/nir/nir_opt_remove_phis.c
> b/src/glsl/nir/nir_opt_remove_phis.c
> > new file mode 100644
> > index 000..aec5dc01
> > --- /dev/null
> > +++ b/src/glsl/nir/nir_opt_remove_phis.c
> > @@ -0,0 +1,111 @@
> > +/*
> > + * Copyright © 2015 Connor Abbott
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> obtaining a
> > + * copy of this software and associated documentation files (the
> "Software"),
> > + * to deal in the Software without restriction, including without
> limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the
> next
> > + * paragraph) shall be included in all copies or substantial portions
> of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + * Authors:
> > + *Connor Abbott (cwabbo...@gmail.com)
> > + *
> > + */
> > +
> > +#include "nir.h"
> > +
> > +/*
> > + * This is a pass for removing phi nodes that look like:
> > + * a = phi(b, b, b, ...)
> > + *
> > + * Note that we can't ignore undef sources here, or else we may create a
> > + * situation where the definition of b isn't dominated by its uses.
> We're
> > + * allowed to do this since the definition of b must dominate all of the
> > + * phi node's predecessors, which means it must dominate the phi node
> as well
> > + * as all of the phi node's uses. In essence, the phi node acts as a
> copy
> > + * instruction. b can't be another phi node in the same block, since
> the only
> > + * time when phi nodes can source other phi nodes defined in the same
> block is
> > + * at the loop header, and in that case one of the sources of the phi
> has to
> > + * be from before the loop and that source can't be b.
> > + */
> > +
> > +/* returns true if any progress was made */
>
> Gah, this shouldn't be there. Fixed locally.
>
> > +
> > +static bool
> > +remove_phis_block(nir_block *block, void *state)
> > +{
> > +   bool *progress = state;
> > +
> > +   void *mem_ctx = ralloc_parent(block);
> > +
> > +   nir_foreach_instr_safe(block, instr) {
> > +  if (instr->type != nir_instr_type_phi)
> > + break;
> > +
> > +  nir_phi_instr *phi = nir_instr_as_phi(instr);
> > +
> > +  nir_ssa_def *def = NULL;
> > +   

Re: [Mesa-dev] [PATCH 2/2] nir/validate: Validate that only float ALU outputs are saturated

[Connor Abbott]

Reviewed-by: Connor Abbott 

Funny, I thought we already did this... whoops.

On Tue, Feb 3, 2015 at 3:43 PM, Jason Ekstrand  wrote:
> ---
>  src/glsl/nir/nir_validate.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
> index 7c801b2..89dfdf8 100644
> --- a/src/glsl/nir/nir_validate.c
> +++ b/src/glsl/nir/nir_validate.c
> @@ -239,6 +239,14 @@ validate_alu_dest(nir_alu_dest *dest, validate_state 
> *state)
>  * register/SSA value
>  */
> assert(is_packed || !(dest->write_mask & ~((1 << dest_size) - 1)));
> +
> +   /* validate that saturate is only ever used on instructions with
> +* destinations of type float
> +*/
> +   nir_alu_instr *alu = nir_instr_as_alu(state->instr);
> +   assert(nir_op_infos[alu->op].output_type == nir_type_float ||
> +  !dest->saturate);
> +
> validate_dest(&dest->dest, state);
>  }
>
> --
> 2.2.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/fs: Fix saturate for nir_opcode_bcsel.

[Jason Ekstrand]

On Tue, Feb 3, 2015 at 12:42 PM, Connor Abbott  wrote:

> On Tue, Feb 3, 2015 at 3:27 PM, Kenneth Graunke 
> wrote:
> > On Tuesday, February 03, 2015 07:10:20 AM you wrote:
> >> On Feb 3, 2015 2:35 AM, "Kenneth Graunke" 
> wrote:
> >> > Caught by lit_sat.shader_test.
> >> >
> >> > Signed-off-by: Kenneth Graunke 
> >> > ---
> >> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> >> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> >> > index 153a1be..3c611af 100644
> >> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> >> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> >> > @@ -1084,6 +1084,7 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
> >> >emit(CMP(reg_null_d, op[0], fs_reg(0), BRW_CONDITIONAL_NZ));
> >> >inst = emit(SEL(result, op[1], op[2]));
> >> >inst->predicate = BRW_PREDICATE_NORMAL;
> >> > +  inst->saturate = instr->dest.saturate;
> >> >break;
> >> >
> >> > default:
> >> > --
> >> > 2.2.2
> >>
> >> Hrm... I thought bcsel worked on integers.  You shouldn't be able to
> sat it
> >> anyway... This seems strange.
> >>
> >> As a side-note, this is one of the downsides to typeless that we should
> >> figure out how to solve.  Not 100% sure how at the moment.
> >
> > For LIT's Z component, I generate different code based on whether
> > drivers support native integers/prefer real booleans:
> >
> >bcsel(fge(0.0f, src.x), 0.0f, pow(...))
> >
> > or
> >
> >fcsel(sge(0.0f, src.x), 0.0f, pow(...))
> >
> > My thinking was that bcsel uses a real boolean condition, whereas fcsel
> > has to do condition != 0.0f...and that the type of the sources being
> > selected shouldn't really matter.  But I suppose it does if we're doing
> > saturate.
>
> Yes, fcsel is supposed to be for emulating csel for HW that doesn't
> natively support integers... that being said, if you think about it,
> testing if condition != 0.0f is basically the same as testing if
> condition != 0, so maybe it would be better if we just used both fcsel
> and bcsel interchangably (except the modifiers mean different things),
> similar to imov and fmov now, and when we lower to modifiers we can
> change one to the other if it allows us to inline a modifier. HW
> without integers wouldn't have NIR with ineg and iabs instructions,
> and we would still always emit fcsel in that case, so it would never
> see a bcsel anyways.
>

Not quite.  There's always -0.0 which is not integer 0.  *sigh*


>
> >
> > Incidentally, making an "fsat" ALU operation would solve that ambiguity,
> > wouldn't require special handling all over the place, could be optimized
> > in nir_opt_algebraic, and would probably be better for nouveau...
> >
> > Plus, I think we can probably just emit MOV.sat in the i965 backend, and
> > Matt's saturation propagation pass should clean it up for us.
>
> As Jason explained, we already have a fsat instruction but we lower it
> to . As an aside, are you running your code through the validator? It
> should assert fail on a bcsel with a saturate modifier, since integer
> destinations can't have the saturate modifier set, so we shouldn't be
> having this problem with GLSL IR.
>

The validator didn't check that.  I just sent a patch to make it check it
and also to not fold saturate into instructions that can't handle it.  That
should fix things up.

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

Re: [Mesa-dev] [PATCH 1/2] nir/lower_source_mods: Don't lower saturate for non-float outputs

[Connor Abbott]

Reviewed-by: Connor Abbott 

On Tue, Feb 3, 2015 at 3:43 PM, Jason Ekstrand  wrote:
> ---
>  src/glsl/nir/nir_lower_to_source_mods.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/glsl/nir/nir_lower_to_source_mods.c 
> b/src/glsl/nir/nir_lower_to_source_mods.c
> index c3f39bc..d6bf77f 100644
> --- a/src/glsl/nir/nir_lower_to_source_mods.c
> +++ b/src/glsl/nir/nir_lower_to_source_mods.c
> @@ -120,6 +120,10 @@ nir_lower_to_source_mods_block(nir_block *block, void 
> *state)
>if (!alu->dest.dest.is_ssa)
>   continue;
>
> +  /* We can only saturate float destinations */
> +  if (nir_op_infos[alu->op].output_type != nir_type_float)
> + continue;
> +
>if (alu->dest.dest.ssa.if_uses->entries != 0)
>   continue;
>
> --
> 2.2.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] nir/lower_source_mods: Don't lower saturate for non-float outputs

[Jason Ekstrand]

---
 src/glsl/nir/nir_lower_to_source_mods.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/glsl/nir/nir_lower_to_source_mods.c 
b/src/glsl/nir/nir_lower_to_source_mods.c
index c3f39bc..d6bf77f 100644
--- a/src/glsl/nir/nir_lower_to_source_mods.c
+++ b/src/glsl/nir/nir_lower_to_source_mods.c
@@ -120,6 +120,10 @@ nir_lower_to_source_mods_block(nir_block *block, void 
*state)
   if (!alu->dest.dest.is_ssa)
  continue;
 
+  /* We can only saturate float destinations */
+  if (nir_op_infos[alu->op].output_type != nir_type_float)
+ continue;
+
   if (alu->dest.dest.ssa.if_uses->entries != 0)
  continue;
 
-- 
2.2.2

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

[Mesa-dev] [PATCH 2/2] nir/validate: Validate that only float ALU outputs are saturated

[Jason Ekstrand]

---
 src/glsl/nir/nir_validate.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index 7c801b2..89dfdf8 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -239,6 +239,14 @@ validate_alu_dest(nir_alu_dest *dest, validate_state 
*state)
 * register/SSA value
 */
assert(is_packed || !(dest->write_mask & ~((1 << dest_size) - 1)));
+
+   /* validate that saturate is only ever used on instructions with
+* destinations of type float
+*/
+   nir_alu_instr *alu = nir_instr_as_alu(state->instr);
+   assert(nir_op_infos[alu->op].output_type == nir_type_float ||
+  !dest->saturate);
+
validate_dest(&dest->dest, state);
 }
 
-- 
2.2.2

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

Re: [Mesa-dev] [PATCH] i965/fs: Fix saturate for nir_opcode_bcsel.

[Connor Abbott]

On Tue, Feb 3, 2015 at 3:27 PM, Kenneth Graunke  wrote:
> On Tuesday, February 03, 2015 07:10:20 AM you wrote:
>> On Feb 3, 2015 2:35 AM, "Kenneth Graunke"  wrote:
>> > Caught by lit_sat.shader_test.
>> >
>> > Signed-off-by: Kenneth Graunke 
>> > ---
>> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> > index 153a1be..3c611af 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> > @@ -1084,6 +1084,7 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
>> >emit(CMP(reg_null_d, op[0], fs_reg(0), BRW_CONDITIONAL_NZ));
>> >inst = emit(SEL(result, op[1], op[2]));
>> >inst->predicate = BRW_PREDICATE_NORMAL;
>> > +  inst->saturate = instr->dest.saturate;
>> >break;
>> >
>> > default:
>> > --
>> > 2.2.2
>>
>> Hrm... I thought bcsel worked on integers.  You shouldn't be able to sat it
>> anyway... This seems strange.
>>
>> As a side-note, this is one of the downsides to typeless that we should
>> figure out how to solve.  Not 100% sure how at the moment.
>
> For LIT's Z component, I generate different code based on whether
> drivers support native integers/prefer real booleans:
>
>bcsel(fge(0.0f, src.x), 0.0f, pow(...))
>
> or
>
>fcsel(sge(0.0f, src.x), 0.0f, pow(...))
>
> My thinking was that bcsel uses a real boolean condition, whereas fcsel
> has to do condition != 0.0f...and that the type of the sources being
> selected shouldn't really matter.  But I suppose it does if we're doing
> saturate.

Yes, fcsel is supposed to be for emulating csel for HW that doesn't
natively support integers... that being said, if you think about it,
testing if condition != 0.0f is basically the same as testing if
condition != 0, so maybe it would be better if we just used both fcsel
and bcsel interchangably (except the modifiers mean different things),
similar to imov and fmov now, and when we lower to modifiers we can
change one to the other if it allows us to inline a modifier. HW
without integers wouldn't have NIR with ineg and iabs instructions,
and we would still always emit fcsel in that case, so it would never
see a bcsel anyways.

>
> Incidentally, making an "fsat" ALU operation would solve that ambiguity,
> wouldn't require special handling all over the place, could be optimized
> in nir_opt_algebraic, and would probably be better for nouveau...
>
> Plus, I think we can probably just emit MOV.sat in the i965 backend, and
> Matt's saturation propagation pass should clean it up for us.

As Jason explained, we already have a fsat instruction but we lower it
to . As an aside, are you running your code through the validator? It
should assert fail on a bcsel with a saturate modifier, since integer
destinations can't have the saturate modifier set, so we shouldn't be
having this problem with GLSL IR.

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

Re: [Mesa-dev] [PATCH] i965/fs: Fix saturate for nir_opcode_bcsel.

[Jason Ekstrand]

On Tue, Feb 3, 2015 at 12:27 PM, Kenneth Graunke 
wrote:

> On Tuesday, February 03, 2015 07:10:20 AM you wrote:
> > On Feb 3, 2015 2:35 AM, "Kenneth Graunke"  wrote:
> > > Caught by lit_sat.shader_test.
> > >
> > > Signed-off-by: Kenneth Graunke 
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > index 153a1be..3c611af 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > > @@ -1084,6 +1084,7 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
> > >emit(CMP(reg_null_d, op[0], fs_reg(0), BRW_CONDITIONAL_NZ));
> > >inst = emit(SEL(result, op[1], op[2]));
> > >inst->predicate = BRW_PREDICATE_NORMAL;
> > > +  inst->saturate = instr->dest.saturate;
> > >break;
> > >
> > > default:
> > > --
> > > 2.2.2
> >
> > Hrm... I thought bcsel worked on integers.  You shouldn't be able to sat
> it
> > anyway... This seems strange.
> >
> > As a side-note, this is one of the downsides to typeless that we should
> > figure out how to solve.  Not 100% sure how at the moment.
>
> For LIT's Z component, I generate different code based on whether
> drivers support native integers/prefer real booleans:
>
>bcsel(fge(0.0f, src.x), 0.0f, pow(...))
>
> or
>
>fcsel(sge(0.0f, src.x), 0.0f, pow(...))
>
> My thinking was that bcsel uses a real boolean condition, whereas fcsel
> has to do condition != 0.0f...and that the type of the sources being
> selected shouldn't really matter.  But I suppose it does if we're doing
> saturate.
>

Exactly.


> Incidentally, making an "fsat" ALU operation would solve that ambiguity,
> wouldn't require special handling all over the place, could be optimized
> in nir_opt_algebraic, and would probably be better for nouveau...
>

We have one.  It just gets lowered to a dest modifier before you see it.
That said, maybe it was getting lowered wrong here...


> Plus, I think we can probably just emit MOV.sat in the i965 backend, and
> Matt's saturation propagation pass should clean it up for us.
>

Yeah, it should most of the time.  However, lowering the sat in SSA has its
advantages.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/fs: Fix saturate for nir_opcode_bcsel.

[Kenneth Graunke]

On Tuesday, February 03, 2015 07:10:20 AM you wrote:
> On Feb 3, 2015 2:35 AM, "Kenneth Graunke"  wrote:
> > Caught by lit_sat.shader_test.
> >
> > Signed-off-by: Kenneth Graunke 
> > ---
> >  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > index 153a1be..3c611af 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> > @@ -1084,6 +1084,7 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
> >emit(CMP(reg_null_d, op[0], fs_reg(0), BRW_CONDITIONAL_NZ));
> >inst = emit(SEL(result, op[1], op[2]));
> >inst->predicate = BRW_PREDICATE_NORMAL;
> > +  inst->saturate = instr->dest.saturate;
> >break;
> >
> > default:
> > --
> > 2.2.2
>
> Hrm... I thought bcsel worked on integers.  You shouldn't be able to sat it
> anyway... This seems strange.
> 
> As a side-note, this is one of the downsides to typeless that we should
> figure out how to solve.  Not 100% sure how at the moment.

For LIT's Z component, I generate different code based on whether
drivers support native integers/prefer real booleans:

   bcsel(fge(0.0f, src.x), 0.0f, pow(...))

or

   fcsel(sge(0.0f, src.x), 0.0f, pow(...))

My thinking was that bcsel uses a real boolean condition, whereas fcsel
has to do condition != 0.0f...and that the type of the sources being
selected shouldn't really matter.  But I suppose it does if we're doing
saturate.

Incidentally, making an "fsat" ALU operation would solve that ambiguity,
wouldn't require special handling all over the place, could be optimized
in nir_opt_algebraic, and would probably be better for nouveau...

Plus, I think we can probably just emit MOV.sat in the i965 backend, and 
Matt's saturation propagation pass should clean it up for us.


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

Re: [Mesa-dev] [PATCH] nir/validate: Ensure that phi sources are SSA-only

[Connor Abbott]

On Tue, Feb 3, 2015 at 1:49 PM, Jason Ekstrand  wrote:
> For whatever reason, I thought we might have non-ssa phi sources.  However,
> I looked again and I don't think it's possible.  Also, this patch applies
> with no piglit regressions.

Yeah, the only reason I made it so that phi instructions could have
non-SSA sources is for the old to-SSA pass -- it's pretty convenient
there. With the stuff about inserting new definitions for range
analysis, I may end up making it use a new to-SSA helper (that the
variable-to-SSA pass and range analysis would also use) that doesn't
rely on this, so after that it should be possible to make phi sources
(and destinations) SSA-only like what we did with load_const.

>
> On Tue, Feb 3, 2015 at 10:49 AM, Jason Ekstrand 
> wrote:
>>
>> ---
>>  src/glsl/nir/nir_validate.c | 13 +++--
>>  1 file changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
>> index 7c801b2..5b47f1a 100644
>> --- a/src/glsl/nir/nir_validate.c
>> +++ b/src/glsl/nir/nir_validate.c
>> @@ -488,16 +488,9 @@ validate_phi_src(nir_phi_instr *instr, nir_block
>> *pred, validate_state *state)
>> exec_list_validate(&instr->srcs);
>> nir_foreach_phi_src(instr, src) {
>>if (src->pred == pred) {
>> - unsigned num_components;
>> - if (src->src.is_ssa)
>> -num_components = src->src.ssa->num_components;
>> - else {
>> -if (src->src.reg.reg->is_packed)
>> -   num_components = 4; /* can't check anything */
>> -else
>> -   num_components = src->src.reg.reg->num_components;
>> - }
>> - assert(num_components == instr->dest.ssa.num_components);
>> + assert(src->src.is_ssa);
>> + assert(src->src.ssa->num_components ==
>> +instr->dest.ssa.num_components);
>>
>>   validate_src(&src->src, state);
>>   return;
>> --
>> 2.2.2
>>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: Don't use __builtin_clrsb in util_last_bit().

[Matt Turner]

On Tue, Feb 3, 2015 at 5:37 AM, Roland Scheidegger  wrote:
> Am 03.02.2015 um 02:28 schrieb Matt Turner:
>> Unclear circumstances lead to undefined symbols on x86.
>>
>> Bugzilla: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.gentoo.org_show-5Fbug.cgi-3Fid-3D536916&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=MGEUCqG6f2VdOqZHSyX6LIUPo4REk4_ehZWPRWGSuQI&s=faytCFpyY97_7ti4xOHK34hphsVRE0YwSdvqU3DYl2k&e=
>> ---
>>  src/gallium/auxiliary/util/u_math.h | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_math.h 
>> b/src/gallium/auxiliary/util/u_math.h
>> index 19c7343..ca6d0f1 100644
>> --- a/src/gallium/auxiliary/util/u_math.h
>> +++ b/src/gallium/auxiliary/util/u_math.h
>> @@ -561,14 +561,10 @@ util_last_bit(unsigned u)
>>  static INLINE unsigned
>>  util_last_bit_signed(int i)
>>  {
>> -#if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 407) && 
>> !defined(__INTEL_COMPILER)
>> -   return 31 - __builtin_clrsb(i);
>> -#else
>> if (i >= 0)
>>return util_last_bit(i);
>> else
>>return util_last_bit(~(unsigned)i);
>> -#endif
>>  }
>>
>>  /* Destructively loop over all of the bits in a mask as in:
>>
>
> This looks like a gcc bug to me, right?
> If so it should probably be reported there.

Not clear, since no one but the original reporter has been able to reproduce it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] main: make the intel driver obey drirc's force_glsl_version

[Kenneth Graunke]

On Tuesday, February 03, 2015 03:50:58 PM Martin Peres wrote:
> 
> On 30/01/15 23:44, Kenneth Graunke wrote:
> > On Friday, January 30, 2015 04:19:47 PM Martin Peres wrote:
> >> Reviewed-by: Kenneth Graunke 
> >> Signed-off-by: Martin Peres 
> >> ---
> >>   src/mesa/drivers/dri/i915/intel_screen.c | 1 +
> >>   src/mesa/drivers/dri/i965/brw_context.c  | 3 +++
> >>   src/mesa/drivers/dri/i965/intel_screen.c | 1 +
> >>   3 files changed, 5 insertions(+)
> >>
> >> diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
> >> b/src/mesa/drivers/dri/i915/intel_screen.c
> >> index 00d8580..e728979 100644
> >> --- a/src/mesa/drivers/dri/i915/intel_screen.c
> >> +++ b/src/mesa/drivers/dri/i915/intel_screen.c
> >> @@ -71,6 +71,7 @@ DRI_CONF_BEGIN
> >> DRI_CONF_ALWAYS_FLUSH_BATCH("false")
> >> DRI_CONF_ALWAYS_FLUSH_CACHE("false")
> >> DRI_CONF_DISABLE_THROTTLING("false")
> >> +  DRI_CONF_FORCE_GLSL_VERSION(0)
> >> DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
> >> DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
> >> DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
> >> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> >> b/src/mesa/drivers/dri/i965/brw_context.c
> >> index e20da0b..7a61496 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_context.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> >> @@ -641,6 +641,9 @@ brw_process_driconf_options(struct brw_context *brw)
> >>   
> >>  brw->precompile = driQueryOptionb(&brw->optionCache, 
> >> "shader_precompile");
> >>   
> >> +   ctx->Const.ForceGLSLVersion =
> >> +  driQueryOptioni(options, "force_glsl_version");
> >> +
> >>  ctx->Const.ForceGLSLExtensionsWarn =
> >> driQueryOptionb(options, "force_glsl_extensions_warn");
> >>   
> >> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> >> b/src/mesa/drivers/dri/i965/intel_screen.c
> >> index cea7ddf..ee22fe7 100644
> >> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> >> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> >> @@ -77,6 +77,7 @@ DRI_CONF_BEGIN
> >> DRI_CONF_ALWAYS_FLUSH_BATCH("false")
> >> DRI_CONF_ALWAYS_FLUSH_CACHE("false")
> >> DRI_CONF_DISABLE_THROTTLING("false")
> >> +  DRI_CONF_FORCE_GLSL_VERSION(0)
> >> DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
> >> DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
> >> DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
> > This won't actually make i915 obey it, since you only have one of the two
> > hunks in the i915 driver.
> 
> Indeed. I should have remembered that it was not complete.
> 
> > It technically does support GLSL 1.10 and 1.20.
> Will the compiler backend complain about unknown instructions?

I believe it supports everything needed for GLSL 1.20.  It often falls
back to swrast when exceeding limits.

> I'm more than OK if games with workarounds do not run on such outdated hw.
> What are you suggesting we should do?

I'd either not touch i915 at all or add the

   ctx->Const.ForceGLSLVersion = driQueryOptioni(...)

hunk to i915 as well.  I don't really care that much - it's i915.


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

Re: [Mesa-dev] [PATCH] i965/fs: Fix saturate on MAD and LRP with the NIR backend.

[Matt Turner]

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: Don't use __builtin_clrsb in util_last_bit().

[Erik Faye-Lund]

On Tue, Feb 3, 2015 at 7:58 PM, Matt Turner  wrote:
> On Tue, Feb 3, 2015 at 6:13 AM, Erik Faye-Lund  wrote:
>> On Tue, Feb 3, 2015 at 2:28 AM, Matt Turner  wrote:
>>> Unclear circumstances lead to undefined symbols on x86.
>>>
>>> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=536916
>>
>> A comment[1] on the gentoo bug-tracker suggest doing something along
>> these lines instead (untested)...
>>
>> [1]: https://bugs.gentoo.org/show_bug.cgi?id=536916#c5
>
> That was me, and it didn't seem to solve his problem.

Wow, I should have checked that, sorry for the noise :P
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: Don't use __builtin_clrsb in util_last_bit().

[Matt Turner]

On Tue, Feb 3, 2015 at 6:13 AM, Erik Faye-Lund  wrote:
> On Tue, Feb 3, 2015 at 2:28 AM, Matt Turner  wrote:
>> Unclear circumstances lead to undefined symbols on x86.
>>
>> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=536916
>
> A comment[1] on the gentoo bug-tracker suggest doing something along
> these lines instead (untested)...
>
> [1]: https://bugs.gentoo.org/show_bug.cgi?id=536916#c5

That was me, and it didn't seem to solve his problem.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir/validate: Ensure that phi sources are SSA-only

[Jason Ekstrand]

For whatever reason, I thought we might have non-ssa phi sources.  However,
I looked again and I don't think it's possible.  Also, this patch applies
with no piglit regressions.

On Tue, Feb 3, 2015 at 10:49 AM, Jason Ekstrand 
wrote:

> ---
>  src/glsl/nir/nir_validate.c | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
> index 7c801b2..5b47f1a 100644
> --- a/src/glsl/nir/nir_validate.c
> +++ b/src/glsl/nir/nir_validate.c
> @@ -488,16 +488,9 @@ validate_phi_src(nir_phi_instr *instr, nir_block
> *pred, validate_state *state)
> exec_list_validate(&instr->srcs);
> nir_foreach_phi_src(instr, src) {
>if (src->pred == pred) {
> - unsigned num_components;
> - if (src->src.is_ssa)
> -num_components = src->src.ssa->num_components;
> - else {
> -if (src->src.reg.reg->is_packed)
> -   num_components = 4; /* can't check anything */
> -else
> -   num_components = src->src.reg.reg->num_components;
> - }
> - assert(num_components == instr->dest.ssa.num_components);
> + assert(src->src.is_ssa);
> + assert(src->src.ssa->num_components ==
> +instr->dest.ssa.num_components);
>
>   validate_src(&src->src, state);
>   return;
> --
> 2.2.2
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nir/validate: Ensure that phi sources are SSA-only

[Jason Ekstrand]

---
 src/glsl/nir/nir_validate.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/src/glsl/nir/nir_validate.c b/src/glsl/nir/nir_validate.c
index 7c801b2..5b47f1a 100644
--- a/src/glsl/nir/nir_validate.c
+++ b/src/glsl/nir/nir_validate.c
@@ -488,16 +488,9 @@ validate_phi_src(nir_phi_instr *instr, nir_block *pred, 
validate_state *state)
exec_list_validate(&instr->srcs);
nir_foreach_phi_src(instr, src) {
   if (src->pred == pred) {
- unsigned num_components;
- if (src->src.is_ssa)
-num_components = src->src.ssa->num_components;
- else {
-if (src->src.reg.reg->is_packed)
-   num_components = 4; /* can't check anything */
-else
-   num_components = src->src.reg.reg->num_components;
- }
- assert(num_components == instr->dest.ssa.num_components);
+ assert(src->src.is_ssa);
+ assert(src->src.ssa->num_components ==
+instr->dest.ssa.num_components);
 
  validate_src(&src->src, state);
  return;
-- 
2.2.2

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

Re: [Mesa-dev] Naming conventions, DSA, and meta

[Kristian Høgsberg]

On Mon, Feb 2, 2015 at 11:59 AM, Thomas Helland
 wrote:
> 2015-02-02 19:18 GMT+01:00 Jason Ekstrand :
>> Hi all,
>> I wanted to send out a quick message about naming conventions for mesa
>> entrypoints and dd table fallbacks.  There has been some confusion and
>> disagreement about this with some of the stuff Laura has been doing to
>> implement DSA.  Instead of side-track one of those patches for this
>> discussion, I thought it was worth its own e-mail.
>>
>> When Laura started working on DSA, I suggested that, since we're refactoring
>> everything anyway, we refactor the guts of the entrypoint into a DSA-style
>> "internal entrypoint".  This internal entrypoint takes a gl_context pointer,
>> does less error checking, and actual mesa object pointers instead of GLuint
>> names.  I'll get to why in a minute here.  However, that leaves us needing a
>> naming convention for three things:
>>
>>  1) The entrypoint itself (currently _mesa_EntryPoint)
>>  2) the internal entrypoint (Laura chose _mesa_entry_point)
>>  3) the software fallback for the DD table entry (Laura chose
>> _mesa_TableEntry_sw)
>>
>> I think we can all agree on not changing (1).  Previously we had something
>> of a convention of _mesa_entry_point for (3) but it wasn't perfectly
>> consistent.  Since we didn't have DSA, we didn't have anything for (2).
>> Personally, I'm OK with what Laura chose, but I understand that it's a
>> change of convention.  Another option, would be to do _mesa_main_TableEntry
>> or _mesa_main_table_entry for the standard DD fallback.  Or we can come up
>> with a different convention for the internal entry points.  I don't care
>> much.
>>
>> Why the internal entrypoints?
>>
>> The first reason is that we have to do the refactor anyway, and that seems
>> reasonable.  The more important reason is meta.  This is something that
>> Kristian, Ken and I have talked about a good bit lately.  I've done some
>> traces with meta lately and meta_begin/end show up a lot and what shows up
>> more is hash table lookups and, in particular, the mutex lock/unlock that's
>> involved.  Inside meta, we do all sorts of stupidity like
>
> Kind of off-topic, but since you're mentioning overhead of hash tables:
> I've been doing some work on util/hash_table that is yet to be sent to the 
> list.
> Thought I could share my experience if someone happens to be
> working on other improvements to the hash-tables.
>
> TLDR of approach:
> Power-of-two sized table instead of prime size.
> -> We can replace the modulo with bitmasking to fit keys in the table.
> -> Reduced overhead on insert, search, resize, etc.
> -> FNV-1a has good avalanche properties -> collisions is a no-issue.
>
> Changing to quadratic probing removes the rehash-stuff.
> -> Less code, simpler, seems to do a better job.
> -> Reduced memory usage and better cache locality?
>
> Preliminary oprofile results of a shader-db run with NIR:
>
> hash_table_insert:   4.13 %   -->   2.13 %
> hash_table_search: 4.12 %   -->   2.29 %
>
> To be done:
> Do the same for hash set.
> Change some hash table uses to the one in util.
> Similar treatment for the other tables.
> Test on something that is actually CPU bound.

Yeah, I was never convinced that the prime size hashtables provided
any benefit. Sounds good to me looking forward to seeing the patches.

Kristian

> -Thomas Helland
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/21] main: Add entry point for NamedBufferSubData.

[Laura Ekstrand]

Because of your comments, there will be a v2 patch series.  But I won't be
sending it for a week or so because I'm in the middle of implementing
BlitNamedFramebuffer, which has required a lot of concentration.

Laura

On Sat, Jan 31, 2015 at 11:46 PM, Ian Romanick  wrote:

> On 01/31/2015 02:21 AM, Laura Ekstrand wrote:
> >
> >
> > On Wed, Jan 21, 2015 at 6:42 PM, Ian Romanick  > > wrote:
> >
> > On 01/21/2015 05:40 PM, Laura Ekstrand wrote:
> > > ---
> > >  src/mapi/glapi/gen/ARB_direct_state_access.xml |   7 ++
> > >  src/mesa/main/bufferobj.c  | 150
> > -
> > >  src/mesa/main/bufferobj.h  |  13 ++-
> > >  src/mesa/main/tests/dispatch_sanity.cpp|   1 +
> > >  4 files changed, 113 insertions(+), 58 deletions(-)
> > >
> > > diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> > b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> > > index 4b1ef6f..8a5cebb 100644
> > > --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml
> > > +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml
> > > @@ -28,6 +28,13 @@
> > >
> > > 
> > >
> > > +   
> > > +  
> > > +  
> > > +  
> > > +  
> > > +   
> > > +
> > >
> > >
> > > 
> > > diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> > > index c77029f..20c2cdc 100644
> > > --- a/src/mesa/main/bufferobj.c
> > > +++ b/src/mesa/main/bufferobj.c
> > > @@ -227,67 +227,62 @@ bufferobj_range_mapped(const struct
> > gl_buffer_object *obj,
> > >   * \c glClearBufferSubData.
> > >   *
> > >   * \param ctx GL context.
> > > - * \param target  Buffer object target on which to operate.
> > > + * \param bufObj  The buffer object.
> > >   * \param offset  Offset of the first byte of the subdata range.
> > >   * \param sizeSize, in bytes, of the subdata range.
> > >   * \param mappedRange  If true, checks if an overlapping range is
> > mapped.
> > >   * If false, checks if buffer is mapped.
> > > - * \param errorNoBuffer  Error code if no buffer is bound to
> target.
> > > - * \param caller  Name of calling function for recording errors.
> > > - * \return   A pointer to the buffer object bound to \c target in
> the
> > > - *   specified context or \c NULL if any of the parameter
> > or state
> > > - *   conditions are invalid.
> > > + * \param func  Name of calling function for recording errors.
> > > + * \return   false if error, true otherwise
> > >   *
> > >   * \sa glBufferSubDataARB, glGetBufferSubDataARB,
> > glClearBufferSubData
> > >   */
> > > -static struct gl_buffer_object *
> > > -buffer_object_subdata_range_good(struct gl_context * ctx, GLenum
> > target,
> > > - GLintptrARB offset,
> > GLsizeiptrARB size,
> > > - bool mappedRange, GLenum
> > errorNoBuffer,
> > > - const char *caller)
> > > +static bool
> > > +buffer_object_subdata_range_good(struct gl_context *ctx,
> > > + struct gl_buffer_object *bufObj,
> > > + GLintptr offset, GLsizeiptr size,
> > > + bool mappedRange, const char
> *func)
> >
> > Many places in Mesa use 'caller'.  This feels like a spurious change
> in
> > this patch.  If we want to unify on a single name, there should be a
> > patch that changes all the occurrences of 'func', 'caller', and
> > 'function' to that single name.
> >
> > >  {
> > > -   struct gl_buffer_object *bufObj;
> > > -
> > > if (size < 0) {
> > > -  _mesa_error(ctx, GL_INVALID_VALUE, "%s(size < 0)", caller);
> > > -  return NULL;
> > > +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(size < 0)", func);
> > > +  return false;
> > > }
> > >
> > > if (offset < 0) {
> > > -  _mesa_error(ctx, GL_INVALID_VALUE, "%s(offset < 0)",
> caller);
> > > -  return NULL;
> > > +  _mesa_error(ctx, GL_INVALID_VALUE, "%s(offset < 0)", func);
> > > +  return false;
> > > }
> > >
> > > -   bufObj = get_buffer(ctx, caller, target, errorNoBuffer);
> > > -   if (!bufObj)
> > > -  return NULL;
> > > -
> > > if (offset + size > bufObj->Size) {
> > >_mesa_error(ctx, GL_INVALID_VALUE,
> > > -  "%s(offset %lu + size %lu > buffer size %lu)",
> > caller,
> > > +  "%s(offset %lu + size %lu > buffer size %lu)",
> > func,
> > >(unsigned long) offset,
> > >(unsigned long) size,
> > >  

Re: [Mesa-dev] [PATCH] util: move etc shared code to util library

[Kai Wasserbäch]

Dave Airlie wrote on 03.02.2015 05:48:
> From: Dave Airlie 
> 
> Like the RGTC code sharing this could be done nicer in the util lib.
> 
> This slighty increase i965_dri.so size by ~100 bytes,
> but it decreases the combined gallium driver by over 1k,
> and its just nicer to avoid TAG().
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/auxiliary/util/u_format_etc.c |  22 ++--
>  src/mesa/Makefile.sources |   1 -
>  src/mesa/main/texcompress_etc.c   |  32 +++---
>  src/mesa/main/texcompress_etc_tmp.h   | 170 
> --
>  src/util/Makefile.sources |   2 +
>  src/util/format_etc.c | 136 
>  src/util/format_etc.h |  78 ++
>  7 files changed, 237 insertions(+), 204 deletions(-)
>  delete mode 100644 src/mesa/main/texcompress_etc_tmp.h
>  create mode 100644 src/util/format_etc.c
>  create mode 100644 src/util/format_etc.h
> 
> [...]
> diff --git a/src/util/format_etc.c b/src/util/format_etc.c
> new file mode 100644
> index 000..5676bbf
> --- /dev/null
> +++ b/src/util/format_etc.c
> @@ -0,0 +1,136 @@
> +/*
> + [...]
> +
> +#include "format_etc.h"
> +#define MIN2( A, B )   ( (A)<(B) ? (A) : (B) )


Shouldn't macros.h be included instead of defining MIN2 again?



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

Re: [Mesa-dev] [PATCH 2/4] mesa: introduce the equivalent of MESA_EXTENSION_OVERRIDE in drirc v2

[Ilia Mirkin]

On Tue, Feb 3, 2015 at 10:41 AM, Martin Peres
 wrote:
> When both MESA_EXTENSION_OVERRIDE and drirc's mesa_extension_override are
> set, the environment variable takes precedence.

Just a thought -- combine them instead of having one override the
other? (With the env var being processed second so that it can
override things in the drirc.)

OTOH drirc settings are also overridable via env var (as I recall), so
someone could use a mesa_extension_override env var (in addition to a
MESA_EXTENSION_OVERRIDE env var).

Anyways, just wanted to point out the possibility, in case you liked the idea.

Cheers,

  -ilia

>
> This will be used to fix Unigine Tropics and Sanctuary.
>
> v2:
> - change the name from mesa_extension_override to extension_override
> - make the presence of the environment variable enough to disable the
>   drirc-provided version
> - init all the constants in i915 before calling _mesa_initialize_context
> - make GLchar *ExtensionOverride in struct gl_constants constant
>
> Signed-off-by: Martin Peres 
> ---
>  src/gallium/include/state_tracker/st_api.h  |  1 +
>  src/gallium/state_trackers/dri/dri_screen.c |  3 +++
>  src/mesa/drivers/dri/common/xmlpool/t_options.h |  4 
>  src/mesa/drivers/dri/i915/intel_context.c   | 18 +++---
>  src/mesa/drivers/dri/i915/intel_screen.c|  1 +
>  src/mesa/drivers/dri/i965/brw_context.c |  6 +-
>  src/mesa/drivers/dri/i965/intel_screen.c|  1 +
>  src/mesa/main/context.c |  4 +++-
>  src/mesa/main/extensions.c  |  6 +-
>  src/mesa/main/extensions.h  |  2 +-
>  src/mesa/main/mtypes.h  |  5 +
>  11 files changed, 40 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/include/state_tracker/st_api.h 
> b/src/gallium/include/state_tracker/st_api.h
> index 86fdc69..99872ce 100644
> --- a/src/gallium/include/state_tracker/st_api.h
> +++ b/src/gallium/include/state_tracker/st_api.h
> @@ -246,6 +246,7 @@ struct st_config_options
> unsigned force_glsl_version;
> boolean force_s3tc_enable;
> boolean allow_glsl_extension_directive_midshader;
> +   char *extension_override;
>  };
>
>  /**
> diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
> b/src/gallium/state_trackers/dri/dri_screen.c
> index 9cdebf8..d1d1eb8 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/dri_screen.c
> @@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension gallium_config_options = {
>   DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
>   DRI_CONF_FORCE_GLSL_VERSION(0)
>   DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
> + DRI_CONF_EXTENSION_OVERRIDE()
>DRI_CONF_SECTION_END
>
>DRI_CONF_SECTION_MISCELLANEOUS
> @@ -98,6 +99,8 @@ dri_fill_st_options(struct st_config_options *options,
>driQueryOptionb(optionCache, "force_s3tc_enable");
> options->allow_glsl_extension_directive_midshader =
>driQueryOptionb(optionCache, 
> "allow_glsl_extension_directive_midshader");
> +   options->extension_override =
> +  driQueryOptionstr(optionCache, "extension_override");
>  }
>
>  static const __DRIconfig **
> diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h 
> b/src/mesa/drivers/dri/common/xmlpool/t_options.h
> index 4e5a721..0c2e7d6 100644
> --- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
> +++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
> @@ -110,6 +110,10 @@ 
> DRI_CONF_OPT_BEGIN_B(allow_glsl_extension_directive_midshader, def) \
>  DRI_CONF_DESC(en,gettext("Allow GLSL #extension directives in the 
> middle of shaders")) \
>  DRI_CONF_OPT_END
>
> +#define DRI_CONF_EXTENSION_OVERRIDE(def) \
> +DRI_CONF_OPT_BEGIN(extension_override, string, def) \
> +DRI_CONF_DESC(en,gettext("Allow enabling/disabling a list of GL 
> extensions")) \
> +DRI_CONF_OPT_END
>
>
>  /**
> diff --git a/src/mesa/drivers/dri/i915/intel_context.c 
> b/src/mesa/drivers/dri/i915/intel_context.c
> index 12a1d2b..6357621 100644
> --- a/src/mesa/drivers/dri/i915/intel_context.c
> +++ b/src/mesa/drivers/dri/i915/intel_context.c
> @@ -419,13 +419,6 @@ intelInitContext(struct intel_context *intel,
>
> intel->intelScreen = intelScreen;
>
> -   if (!_mesa_initialize_context(&intel->ctx, api, mesaVis, shareCtx,
> - functions)) {
> -  *dri_ctx_error = __DRI_CTX_ERROR_NO_MEMORY;
> -  printf("%s: failed to init mesa context\n", __FUNCTION__);
> -  return false;
> -   }
> -
> driContextPriv->driverPrivate = intel;
> intel->driContext = driContextPriv;
> intel->driFd = sPriv->fd;
> @@ -443,6 +436,10 @@ intelInitContext(struct intel_context *intel,
>
> driParseConfigFiles(&intel->optionCache, &intelScreen->optionCache,
> sPriv->myNum, "i915");
> +
> +   ctx->Const.ExtensionOverride =
> + driQueryOptionstr(&intel->optionCache, "e

Re: [Mesa-dev] [PATCH 3/6] main: Added entry point for glTransformFeedbackBufferRange

[Martin Peres]

On 02/02/15 23:51, Laura Ekstrand wrote:


On Mon, Feb 2, 2015 at 3:30 AM, Martin Peres 
mailto:martin.pe...@linux.intel.com>> 
wrote:


if (index >= ctx->Const.MaxTransformFeedbackBuffers) {
-  _mesa_error(ctx, GL_INVALID_VALUE,
"glBindBufferRange(index=%d "
-  "out of bounds)", index);
+  /* An INVALID_VALUE error is generated if index is greater
than or equal
+   * to the number of binding points for transform feedback,
as described
+   * in section 6.7.1.

Include the spec  (I presume OpenGL 4.5 core).


Done, thanks


+   */
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(index=%d out of
bounds)",
+  gl_methd_name, index);
   return;
}

if (size & 0x3) {
-  /* must a multiple of four */
-  _mesa_error(ctx, GL_INVALID_VALUE,
"glBindBufferRange(size=%d)",
-  (int) size);
+  /* must a be multiple of four */
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(size=%d must be a
multiple of "
+  "four)", gl_methd_name, (int) size);
   return;
}

if (offset & 0x3) {
   /* must be multiple of four */
-  _mesa_error(ctx, GL_INVALID_VALUE,
-  "glBindBufferRange(offset=%d)", (int) offset);
+  _mesa_error(ctx, GL_INVALID_VALUE, "gl%s(offset=%d must be
a multiple "
+  "of four)", gl_methd_name, (int) offset);
   return;
-   }
+   }
+
+   if (offset < 0) {
+  /* An INVALID_VALUE error is generated by BindBufferRange
if buffer is
+   * non-zero and size is less than or equal to zero.

They're still mixed up.^^  It says size instead of offset.


I'm so sorry! I fixed it properly now!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/6] main: Added entry point for glTransformFeedbackBufferBase

[Martin Peres]

On 02/02/15 16:09, Ilia Mirkin wrote:

On Mon, Feb 2, 2015 at 6:00 AM, Martin Peres
 wrote:

+static struct gl_transform_feedback_object *
+_mesa_lookup_transform_feedback_object_err(struct gl_context *ctx,
+   GLuint xfb, const char* func)
+{
+   struct gl_transform_feedback_object *obj;
+
+   obj = _mesa_lookup_transform_feedback_object(ctx, xfb);
+   if (!obj) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "%s(xfb=%u: non-generated object name)", func, xfb);
+   }
+
+   return obj;
+}
+
+/**
+ * Wrapper around _mesa_lookup_bufferobj that throws GL_INVALID_VALUE if id
+ * is not in the hash table. Specialised version for the
+ * transform-feedback-related functions. After calling _mesa_error, it
+ * returns NULL.
+ */
+static struct gl_buffer_object *
+_mesa_lookup_transform_feedback_bufferobj_err(struct gl_context *ctx,
+  GLuint buffer, const char* func)

The general convention in mesa is that "public" functions are called
_mesa_foo, while "private" (i.e. static) functions are just called
foo. In this case, lookup_transform_feedback_bufferobj_err.


Noted, thanks Ilia :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/6] main: Added entry point for glTransformFeedbackBufferBase

[Martin Peres]

On 02/02/15 23:46, Laura Ekstrand wrote:



On Mon, Feb 2, 2015 at 3:00 AM, Martin Peres 
mailto:martin.pe...@linux.intel.com>> 
wrote:



@@ -543,15 +545,12 @@ bind_buffer_range(struct gl_context *ctx,
GLuint index,
  */
 void
 _mesa_bind_buffer_range_transform_feedback(struct gl_context *ctx,
-  GLuint index,
-  struct gl_buffer_object
*bufObj,
-  GLintptr offset,
-  GLsizeiptr size)

These don't line up?  Check for tabs here.  (Mesa uses 3-space indents)


Another visualisation artefact? Everything seems fine on my side. No 
tabs here and everything is perfectly aligned. I'm pretty sure I set my 
editor correctly + I see some dots instead of spaces which is quite 
helpful to investigate this kind of issues.



+  struct gl_transform_feedback_object *obj,
+   GLuint index,
+   struct
gl_buffer_object *bufObj,
+   GLintptr offset,
+   GLsizeiptr size)
 {




It'd be nice to include the PDF page.


Sure! Included!


@@ -817,6 +889,10 @@ _mesa_GetTransformFeedbackVarying(GLuint
program, GLuint index,
 struct gl_transform_feedback_object *
 _mesa_lookup_transform_feedback_object(struct gl_context *ctx,
GLuint name)
 {

Again, a page number would be nice, but not necessary.


Done

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

Re: [Mesa-dev] [PATCH 1/6] main: Added entry point for glCreateTransformFeedbacks

[Martin Peres]

On 02/02/15 23:36, Laura Ekstrand wrote:
On Mon, Feb 2, 2015 at 2:58 AM, Martin Peres 
mailto:martin.pe...@linux.intel.com>> 
wrote:


  if (!obj) {
-_mesa_error(ctx, GL_OUT_OF_MEMORY,
"glGenTransformFeedbacks");
+_mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);

^^
This doesn't line up with ( above.  Mesa uses 3-space identation.
Seems like a visualisation problem as the indentation was good before 
the patch and is still good after it...


 return;
  }
- names[i] = first + i;
+ ids[i] = first + i;

Same thing


Same thing


_mesa_HashInsert(ctx->TransformFeedback.Objects, first + i, obj);
+ if (dsa) {
+/* this is normally done at bind time in the non-dsa
case */
+obj->EverBound = GL_TRUE;
+ }
   }
}
else {
-  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glGenTransformFeedbacks");
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, "%s", func);

Same thing.


Same thing.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] svga: fix sid corruption in vmw_drm_surface_from_handle()

[danielx . j . van . der . wath]

From: Daniel van der Wath 

The value stored in "handle" is trashed before being copied into the
surface's sid. Use the original value from "whandle->handle" instead.
This fixes a bug with Weston running on VMWare, where SVGA3D_SetRenderTarget()
would fail and prevent anything from being drawn on screen.

Reviewed-by: Satyeshwar Singh 
---
 src/gallium/winsys/svga/drm/vmw_screen_dri.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c 
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 79a1b3e..0f796c4 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -319,7 +319,7 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
 pipe_reference_init(&vsrf->refcnt, 1);
 p_atomic_set(&vsrf->validated, 0);
 vsrf->screen = vws;
-vsrf->sid = handle;
+vsrf->sid = whandle->handle;
 ssrf = svga_winsys_surface(vsrf);
 *format = rep->format;
 
-- 
1.7.11.7

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

[Mesa-dev] [PATCH 3/4] drirc: add workarounds for Unigine Tropics v2

[Martin Peres]

v2:
- rename mesa_extension-override to extension_override
- improve the comment by telling we disable GL_ARB_gpu_shader5
- fix the name ARB_GL_gpu_shader5 to GL_ARB_gpu_shader5 (Ilia)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82897
Signed-off-by: Martin Peres 
---
 src/mesa/drivers/dri/common/drirc | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/mesa/drivers/dri/common/drirc 
b/src/mesa/drivers/dri/common/drirc
index cecd6a9..10c60d5 100644
--- a/src/mesa/drivers/dri/common/drirc
+++ b/src/mesa/drivers/dri/common/drirc
@@ -10,6 +10,12 @@ Application bugs worked around in this file:
   Enabling all extensions for Unigine fixes most issues, but the GLSL version
   is still 1.10.
 
+* Unigine Tropics 1.3 makes use of the "sample" keyword which is reserved
+  with GL_ARB_gpu_shader5 which got enabled by force_glsl_extensions_warn.
+  Disable this extension using extension_override.
+  It also makes use of bitwise manipulation (when adding anistropic filtering)
+  which is illegal in GLSL 1.10. Adding "#version 130" fixes this.
+
 * Unigine Heaven 3.0 with ARB_texture_multisample uses a "ivec4 * vec4"
   expression, which is illegal in GLSL 1.10.
   Adding "#version 130" fixes this.
@@ -41,6 +47,8 @@ TODO: document the other workarounds.
 
 
 
+
+
 

 
-- 
2.2.2

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

[Mesa-dev] [PATCH 4/4] drirc: add workarounds for Unigine Sanctuary v2

[Martin Peres]

v2:
- rename mesa_extension-override to extension_override
- improve the comment by telling we disable GL_ARB_gpu_shader5 (Ilia)
- fix the name ARB_GL_gpu_shader5 to GL_ARB_gpu_shader5 (Ilia)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82897
Signed-off-by: Martin Peres 
---
 src/mesa/drivers/dri/common/drirc | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/mesa/drivers/dri/common/drirc 
b/src/mesa/drivers/dri/common/drirc
index 10c60d5..8d59e61 100644
--- a/src/mesa/drivers/dri/common/drirc
+++ b/src/mesa/drivers/dri/common/drirc
@@ -10,6 +10,12 @@ Application bugs worked around in this file:
   Enabling all extensions for Unigine fixes most issues, but the GLSL version
   is still 1.10.
 
+* Unigine Sanctuary 2.3 makes use of the "sample" keyword which is reserved
+  with GL_ARB_gpu_shader5 which got enabled by force_glsl_extensions_warn.
+  Disable this extension using extension_override.
+  It also makes use of bitwise manipulation (when adding anistropic filtering)
+  which is illegal in GLSL 1.10. Adding "#version 130" fixes this.
+
 * Unigine Tropics 1.3 makes use of the "sample" keyword which is reserved
   with GL_ARB_gpu_shader5 which got enabled by force_glsl_extensions_warn.
   Disable this extension using extension_override.
@@ -42,6 +48,8 @@ TODO: document the other workarounds.
 
 
 
+
+
 

 
-- 
2.2.2

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

[Mesa-dev] [PATCH 2/4] mesa: introduce the equivalent of MESA_EXTENSION_OVERRIDE in drirc v2

[Martin Peres]

When both MESA_EXTENSION_OVERRIDE and drirc's mesa_extension_override are
set, the environment variable takes precedence.

This will be used to fix Unigine Tropics and Sanctuary.

v2:
- change the name from mesa_extension_override to extension_override
- make the presence of the environment variable enough to disable the
  drirc-provided version
- init all the constants in i915 before calling _mesa_initialize_context
- make GLchar *ExtensionOverride in struct gl_constants constant

Signed-off-by: Martin Peres 
---
 src/gallium/include/state_tracker/st_api.h  |  1 +
 src/gallium/state_trackers/dri/dri_screen.c |  3 +++
 src/mesa/drivers/dri/common/xmlpool/t_options.h |  4 
 src/mesa/drivers/dri/i915/intel_context.c   | 18 +++---
 src/mesa/drivers/dri/i915/intel_screen.c|  1 +
 src/mesa/drivers/dri/i965/brw_context.c |  6 +-
 src/mesa/drivers/dri/i965/intel_screen.c|  1 +
 src/mesa/main/context.c |  4 +++-
 src/mesa/main/extensions.c  |  6 +-
 src/mesa/main/extensions.h  |  2 +-
 src/mesa/main/mtypes.h  |  5 +
 11 files changed, 40 insertions(+), 11 deletions(-)

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index 86fdc69..99872ce 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -246,6 +246,7 @@ struct st_config_options
unsigned force_glsl_version;
boolean force_s3tc_enable;
boolean allow_glsl_extension_directive_midshader;
+   char *extension_override;
 };
 
 /**
diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
b/src/gallium/state_trackers/dri/dri_screen.c
index 9cdebf8..d1d1eb8 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++ b/src/gallium/state_trackers/dri/dri_screen.c
@@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension gallium_config_options = {
  DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
  DRI_CONF_FORCE_GLSL_VERSION(0)
  DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
+ DRI_CONF_EXTENSION_OVERRIDE()
   DRI_CONF_SECTION_END
 
   DRI_CONF_SECTION_MISCELLANEOUS
@@ -98,6 +99,8 @@ dri_fill_st_options(struct st_config_options *options,
   driQueryOptionb(optionCache, "force_s3tc_enable");
options->allow_glsl_extension_directive_midshader =
   driQueryOptionb(optionCache, "allow_glsl_extension_directive_midshader");
+   options->extension_override =
+  driQueryOptionstr(optionCache, "extension_override");
 }
 
 static const __DRIconfig **
diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h 
b/src/mesa/drivers/dri/common/xmlpool/t_options.h
index 4e5a721..0c2e7d6 100644
--- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
+++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h
@@ -110,6 +110,10 @@ 
DRI_CONF_OPT_BEGIN_B(allow_glsl_extension_directive_midshader, def) \
 DRI_CONF_DESC(en,gettext("Allow GLSL #extension directives in the 
middle of shaders")) \
 DRI_CONF_OPT_END
 
+#define DRI_CONF_EXTENSION_OVERRIDE(def) \
+DRI_CONF_OPT_BEGIN(extension_override, string, def) \
+DRI_CONF_DESC(en,gettext("Allow enabling/disabling a list of GL 
extensions")) \
+DRI_CONF_OPT_END
 
 
 /**
diff --git a/src/mesa/drivers/dri/i915/intel_context.c 
b/src/mesa/drivers/dri/i915/intel_context.c
index 12a1d2b..6357621 100644
--- a/src/mesa/drivers/dri/i915/intel_context.c
+++ b/src/mesa/drivers/dri/i915/intel_context.c
@@ -419,13 +419,6 @@ intelInitContext(struct intel_context *intel,
 
intel->intelScreen = intelScreen;
 
-   if (!_mesa_initialize_context(&intel->ctx, api, mesaVis, shareCtx,
- functions)) {
-  *dri_ctx_error = __DRI_CTX_ERROR_NO_MEMORY;
-  printf("%s: failed to init mesa context\n", __FUNCTION__);
-  return false;
-   }
-
driContextPriv->driverPrivate = intel;
intel->driContext = driContextPriv;
intel->driFd = sPriv->fd;
@@ -443,6 +436,10 @@ intelInitContext(struct intel_context *intel,
 
driParseConfigFiles(&intel->optionCache, &intelScreen->optionCache,
sPriv->myNum, "i915");
+
+   ctx->Const.ExtensionOverride =
+ driQueryOptionstr(&intel->optionCache, "extension_override");
+
intel->maxBatchSize = 4096;
 
/* Estimate the size of the mappable aperture into the GTT.  There's an
@@ -487,6 +484,13 @@ intelInitContext(struct intel_context *intel,
 
ctx->Const.StripTextureBorder = GL_TRUE;
 
+   if (!_mesa_initialize_context(&intel->ctx, api, mesaVis, shareCtx,
+ functions)) {
+  *dri_ctx_error = __DRI_CTX_ERROR_NO_MEMORY;
+  printf("%s: failed to init mesa context\n", __FUNCTION__);
+  return false;
+   }
+
/* reinitialize the context point state.
 * It depend on constants in __struct gl_contextRec::Const
 */
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 

[Mesa-dev] [PATCH 1/4] intel: make the i830/i915/i965 drivers obey drirc's force_glsl_version v2

[Martin Peres]

v2:
- change the commit name as per Marek's comment
- make the i830/i915 drivers actually use the force_glsl_version

Reviewed-by: Kenneth Graunke  v1
Signed-off-by: Martin Peres 
---
 src/mesa/drivers/dri/i915/i830_context.c | 4 
 src/mesa/drivers/dri/i915/i915_context.c | 4 
 src/mesa/drivers/dri/i915/intel_screen.c | 1 +
 src/mesa/drivers/dri/i965/brw_context.c  | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 1 +
 5 files changed, 13 insertions(+)

diff --git a/src/mesa/drivers/dri/i915/i830_context.c 
b/src/mesa/drivers/dri/i915/i830_context.c
index 299e54d..cf9f511 100644
--- a/src/mesa/drivers/dri/i915/i830_context.c
+++ b/src/mesa/drivers/dri/i915/i830_context.c
@@ -114,6 +114,10 @@ i830CreateContext(int api,
ctx->Const.MaxDrawBuffers = 1;
ctx->Const.QueryCounterBits.SamplesPassed = 0;
 
+   ctx->Const.ForceGLSLVersion =
+ driQueryOptioni(&intel->intelScreen->optionCache,
+ "force_glsl_version");
+
_tnl_init_vertices(ctx, ctx->Const.MaxArrayLockSize + 12,
   18 * sizeof(GLfloat));
 
diff --git a/src/mesa/drivers/dri/i915/i915_context.c 
b/src/mesa/drivers/dri/i915/i915_context.c
index 42ea54e..352dc66 100644
--- a/src/mesa/drivers/dri/i915/i915_context.c
+++ b/src/mesa/drivers/dri/i915/i915_context.c
@@ -270,6 +270,10 @@ i915CreateContext(int api,
ctx->Const.MaxDrawBuffers = 1;
ctx->Const.QueryCounterBits.SamplesPassed = 0;
 
+   ctx->Const.ForceGLSLVersion =
+ driQueryOptioni(&intel->intelScreen->optionCache,
+ "force_glsl_version");
+
_tnl_init_vertices(ctx, ctx->Const.MaxArrayLockSize + 12,
   36 * sizeof(GLfloat));
 
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 00d8580..e728979 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -71,6 +71,7 @@ DRI_CONF_BEGIN
   DRI_CONF_ALWAYS_FLUSH_BATCH("false")
   DRI_CONF_ALWAYS_FLUSH_CACHE("false")
   DRI_CONF_DISABLE_THROTTLING("false")
+  DRI_CONF_FORCE_GLSL_VERSION(0)
   DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
   DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
   DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index e20da0b..7a61496 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -641,6 +641,9 @@ brw_process_driconf_options(struct brw_context *brw)
 
brw->precompile = driQueryOptionb(&brw->optionCache, "shader_precompile");
 
+   ctx->Const.ForceGLSLVersion =
+  driQueryOptioni(options, "force_glsl_version");
+
ctx->Const.ForceGLSLExtensionsWarn =
   driQueryOptionb(options, "force_glsl_extensions_warn");
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cea7ddf..ee22fe7 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -77,6 +77,7 @@ DRI_CONF_BEGIN
   DRI_CONF_ALWAYS_FLUSH_BATCH("false")
   DRI_CONF_ALWAYS_FLUSH_CACHE("false")
   DRI_CONF_DISABLE_THROTTLING("false")
+  DRI_CONF_FORCE_GLSL_VERSION(0)
   DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
   DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
   DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
-- 
2.2.2

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

Re: [Mesa-dev] [PATCH] i965/fs: Fix saturate for nir_opcode_bcsel.

[Jason Ekstrand]

Hrm... I thought bcsel worked on integers.  You shouldn't be able to sat it
anyway... This seems strange.

As a side-note, this is one of the downsides to typeless that we should
figure out how to solve.  Not 100% sure how at the moment.
On Feb 3, 2015 2:35 AM, "Kenneth Graunke"  wrote:

> Caught by lit_sat.shader_test.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index 153a1be..3c611af 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -1084,6 +1084,7 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
>emit(CMP(reg_null_d, op[0], fs_reg(0), BRW_CONDITIONAL_NZ));
>inst = emit(SEL(result, op[1], op[2]));
>inst->predicate = BRW_PREDICATE_NORMAL;
> +  inst->saturate = instr->dest.saturate;
>break;
>
> default:
> --
> 2.2.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/fs: Fix saturate on MAD and LRP with the NIR backend.

[Jason Ekstrand]

Ooh! I bet this fixes our rendering problems on some of those benchmarks
too!  I was wondering why generating made was causing problems.

Reviewed-by: Jason Ekstrand 
On Feb 3, 2015 1:18 AM, "Kenneth Graunke"  wrote:

> Fixes misrendering in "Witcher 2" with INTEL_USE_NIR=1, and probably
> many other programs.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> This depends on Jason's 3 patch series that removes emit_percomp.
> It's available in the 'nir-madfix' branch of my tree.
>
> This was caught by tests/spec/arb_fragment_program/lrp_sat.shader_test
> with my in-progress Mesa IR -> NIR converter code, so I don't think we
> need to write more Piglit tests.  We just don't have a GLSL based one.
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index fbb1622..153a1be 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -1070,12 +1070,14 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
>break;
>
> case nir_op_ffma:
> -  emit(MAD(result, op[2], op[1], op[0]));
> +  inst = emit(MAD(result, op[2], op[1], op[0]));
> +  inst->saturate = instr->dest.saturate;
>break;
>
> case nir_op_flrp:
>/* TODO emulate for gen < 6 */
> -  emit(LRP(result, op[2], op[1], op[0]));
> +  inst = emit(LRP(result, op[2], op[1], op[0]));
> +  inst->saturate = instr->dest.saturate;
>break;
>
> case nir_op_bcsel:
> --
> 2.2.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 1/3] nir: Add a pass to lower vector phi nodes to scalar phi nodes

[Jason Ekstrand]

On Feb 2, 2015 10:59 PM, "Kenneth Graunke"  wrote:
>
> On Monday, February 02, 2015 10:28:22 PM Jason Ekstrand wrote:
> > On Mon, Feb 2, 2015 at 9:08 PM, Kenneth Graunke 
> > wrote:
> >
> > > On Thursday, January 29, 2015 01:40:18 PM Jason Ekstrand wrote:
> [snip]
> > > > +static bool
> > > > +is_phi_src_scalarizable(nir_phi_src *src,
> > > > +struct lower_phis_to_scalar_state *state)
> > > > +{
> > > > +   /* Don't know what to do with non-ssa sources */
> > > > +   if (!src->src.is_ssa)
> > >
> > > Can phi nodes with non-SSA sources even exist?  That sounds crazy.
> > > Perhaps just assert(src->src.is_ssa)?
> > >
> >
> > It's possible.  We should probably disallow it as we can't coalesce them
> > anyway, but it can happen at the moment.
>
> Really?  That sounds scary - what does phi(non-SSA values) even mean?

Yeah, I'll look into that and get it disallowed. We shouldn't be getting
non-SSA phi sources.  I just seem to remember them happening for some
reason.

> [snip]
> > > Perhaps add:
> > >
> > >   case nir_intrinsic_load_uniform:
> > >   case nir_intrinsic_load_const:
> > >  return true;
> > >
> > > so that the pass could handle this same concept after nir_lower_io()?
> > >
> >
> > I have a patch floating arround that adds load_const and it helps by a
few
> > instructions.  We should probably do the same for inputs and uniforms
but I
> > thought I had some reason not to.  Can't remember what it is now.
>
> Huh.  I'm not sure why it'd break - you're already doing it for input
> and uniform /variables/...

Right... Sure, I'll add that.

> [snip]
> > >
> > > > +* won't automatically make us fail to scalarize.
> > > > +*/
> > > > +   entry = _mesa_hash_table_insert(state->phi_table, phi, (void
> > > *)(intptr_t)1);
> > >
> > > This is weird.  Why are you using a hash table and not a set?  It
sounds
> > > like you're trying to store a tri-state: unknown (no entry in hash
> > > table), known-not-scalarizable (entry in hash table, value of 0), and
> > > known-scalarizable (entry in hash table, value of 1).
> > >
> > > However, I don't see any code that actually inserts or updates a value
> > > to 0 - are you missing some code?
> > >
> > > Otherwise, this looks good to me...
> > >
> > > > +
> > > > +   bool scalarizable = true;
> > > > +
> > > > +   nir_foreach_phi_src(phi, src) {
> > > > +  scalarizable = is_phi_src_scalarizable(src, state);
> > > > +  if (!scalarizable)
> > > > + break;
> > > > +   }
> > > > +
> > > > +   entry->data = (void *)(intptr_t)scalarizable;
> > >
> >
> > It's updated right here ^^
>
> So it is!  I was expecting to see a search/remove/insert, and overlooked
> the fact that you're getting a hash_entry pointer (rather than the
> value) and editing the data.  That seems fine.
>
> This is:
> Reviewed-by: Kenneth Graunke 

Thanks!

> with the concern that non-SSA phi sources still sound bizarre.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: Don't use __builtin_clrsb in util_last_bit().

[Erik Faye-Lund]

On Tue, Feb 3, 2015 at 2:28 AM, Matt Turner  wrote:
> Unclear circumstances lead to undefined symbols on x86.
>
> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=536916

A comment[1] on the gentoo bug-tracker suggest doing something along
these lines instead (untested)...

[1]: https://bugs.gentoo.org/show_bug.cgi?id=536916#c5

diff --git a/configure.ac b/configure.ac
index c2d775e..e6daf40 100644
--- a/configure.ac
+++ b/configure.ac
@@ -175,6 +175,7 @@ fi
 dnl Check for compiler builtins
 AX_GCC_BUILTIN([__builtin_bswap32])
 AX_GCC_BUILTIN([__builtin_bswap64])
+AX_GCC_BUILTIN([__builtin_clrsb])
 AX_GCC_BUILTIN([__builtin_clz])
 AX_GCC_BUILTIN([__builtin_clzll])
 AX_GCC_BUILTIN([__builtin_ctz])
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 19c7343..4591830 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -561,7 +561,7 @@ util_last_bit(unsigned u)
 static INLINE unsigned
 util_last_bit_signed(int i)
 {
-#if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 407)
&& !defined(__INTEL_COMPILER)
+#if defined(HAVE___BUILTIN_CLRSB)
return 31 - __builtin_clrsb(i);
 #else
if (i >= 0)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] c11/threads: Use PTHREAD_MUTEX_RECURSIVE by default

[Emil Velikov]

On 3 February 2015 at 02:53, Emil Velikov  wrote:
> Hi Felix,
>
> On 2 February 2015 at 19:04, Felix Janda  wrote:
>> Previously PTHREAD_MUTEX_RECURSIVE_NP had been used on linux for
>> compatibility with old glibc. Since mesa defines __GNU_SOURCE__
>> on linux PTHREAD_MUTEX_RECURSIVE is also available since at least
>> 1998. So we can unconditionally use the portable version
>> PTHREAD_MUTEX_RECURSIVE.
>> ---
>> Previous patch didn't work as intended since on glibc these are
>> part of an enum and not defines.
>>
> From a quick look at {e,}glibc sources [1]
>
>PTHREAD_MUTEX_RECURSIVE_NP,
>...
>#if defined __USE_UNIX98 || defined __USE_XOPEN2K8
>...
>PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
>...
>
> Which does not seem to have relation with _GNU_SOURCE_ as the commit
> mentions. Note I don't even pretend to know the convoluted web of
> macros, so I could be a bit off :-)
>
Upon closer look things could be fine, as

  linux/gnu: _GNU_SOURCE sets _POSIX_C_SOURCE 200809L.
With the latter of which guarding the __USE_XOPEN2K8  definition.

  cygwin: (hmm does it even set __linux*) we set _XOPEN_SOURCE=700.
Which is the guard for __USE_XOPEN2K8.

If one wants to be extra careful we can change
  #if defined(__linux__) || defined(__linux)
to check for the said old versions of glibc, but I believe we should be safe.

Would anyone else have comments on this patch ?

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

Re: [Mesa-dev] [PATCH 1/4] main: make the intel driver obey drirc's force_glsl_version

[Martin Peres]

On 30/01/15 23:44, Kenneth Graunke wrote:

On Friday, January 30, 2015 04:19:47 PM Martin Peres wrote:

Reviewed-by: Kenneth Graunke 
Signed-off-by: Martin Peres 
---
  src/mesa/drivers/dri/i915/intel_screen.c | 1 +
  src/mesa/drivers/dri/i965/brw_context.c  | 3 +++
  src/mesa/drivers/dri/i965/intel_screen.c | 1 +
  3 files changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 00d8580..e728979 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -71,6 +71,7 @@ DRI_CONF_BEGIN
DRI_CONF_ALWAYS_FLUSH_BATCH("false")
DRI_CONF_ALWAYS_FLUSH_CACHE("false")
DRI_CONF_DISABLE_THROTTLING("false")
+  DRI_CONF_FORCE_GLSL_VERSION(0)
DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index e20da0b..7a61496 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -641,6 +641,9 @@ brw_process_driconf_options(struct brw_context *brw)
  
 brw->precompile = driQueryOptionb(&brw->optionCache, "shader_precompile");
  
+   ctx->Const.ForceGLSLVersion =

+  driQueryOptioni(options, "force_glsl_version");
+
 ctx->Const.ForceGLSLExtensionsWarn =
driQueryOptionb(options, "force_glsl_extensions_warn");
  
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c

index cea7ddf..ee22fe7 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -77,6 +77,7 @@ DRI_CONF_BEGIN
DRI_CONF_ALWAYS_FLUSH_BATCH("false")
DRI_CONF_ALWAYS_FLUSH_CACHE("false")
DRI_CONF_DISABLE_THROTTLING("false")
+  DRI_CONF_FORCE_GLSL_VERSION(0)
DRI_CONF_FORCE_GLSL_EXTENSIONS_WARN("false")
DRI_CONF_DISABLE_GLSL_LINE_CONTINUATIONS("false")
DRI_CONF_DISABLE_BLEND_FUNC_EXTENDED("false")

This won't actually make i915 obey it, since you only have one of the two
hunks in the i915 driver.


Indeed. I should have remembered that it was not complete.


It technically does support GLSL 1.10 and 1.20.
Will the compiler backend complain about unknown instructions? I'm more 
than OK if games with workarounds do not run on such outdated hw. What 
are you suggesting we should do?


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

Re: [Mesa-dev] [PATCH 10/10] radeonsi: implement polygon stippling

[Marek Olšák]

On Mon, Feb 2, 2015 at 10:05 AM, Michel Dänzer  wrote:
> On 02.02.2015 02:37, Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> The stipple texture is bound to slot 16, so there are 17 sampler states and
>> 34 sampler views now (17 normal slots + 17 fmask slots).
>
> [...]
>
>> @@ -2742,16 +2743,26 @@ static int si_generate_gs_copy_shader(struct 
>> si_screen *sscreen,
>>  int si_shader_create(struct si_screen *sscreen, struct si_shader *shader)
>>  {
>>   struct si_shader_selector *sel = shader->selector;
>> + struct tgsi_token *tokens = sel->tokens;
>>   struct si_shader_context si_shader_ctx;
>>   struct lp_build_tgsi_context * bld_base;
>> + struct tgsi_shader_info stipple_shader_info;
>>   LLVMModuleRef mod;
>>   int r = 0;
>> + bool poly_stipple = sel->type == PIPE_SHADER_FRAGMENT &&
>> + shader->key.ps.poly_stipple;
>>   bool dump = r600_can_dump_shader(&sscreen->b, sel->tokens);
>>
>> + if (poly_stipple) {
>> + tokens = util_pstipple_create_fragment_shader(tokens, NULL,
>> + SI_POLY_STIPPLE_SAMPLER);
>> + tgsi_scan_shader(tokens, &stipple_shader_info);
>> +}
>
> The indentation of the closing curly brace is wrong.

Updated patches are attached. The indentation looked wrong because
there were spaces instead of tabs.

>
>
>> @@ -109,14 +110,16 @@ union si_state {
>>   struct si_pm4_state *array[0];
>>  };
>>
>> -#define SI_NUM_USER_SAMPLERS 16 /* AKA OpenGL textures units per shader */
>> +#define SI_NUM_USER_SAMPLERS 16 /* AKA OpenGL textures units per 
>> shader */
>
> SI_NUM_USER_SAMPLERS could be bumped in or after patch 8, right?

Did you mean SI_NUM_SAMPLES? I split that into a separate patch.

SI_NUM_USER_SAMPLERS could be bumped, but I don't see a point yet.
Note that the limit is 31 due to the stipple texture and FMASK
consuming the other half of the slots.

Marek
From e31a5c85e1f59c4cd96a13213f0ce3e328f961cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Tue, 3 Feb 2015 12:49:19 +0100
Subject: [PATCH 1/2] radeonsi: add polygon stipple texture slot

---
 src/gallium/drivers/radeonsi/si_state.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.h b/src/gallium/drivers/radeonsi/si_state.h
index d2feb7d..2637289 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -109,14 +109,17 @@ union si_state {
 	struct si_pm4_state	*array[0];
 };
 
-#define SI_NUM_USER_SAMPLERS 16 /* AKA OpenGL textures units per shader */
+#define SI_NUM_USER_SAMPLERS16 /* AKA OpenGL textures units per shader */
+#define SI_POLY_STIPPLE_SAMPLER SI_NUM_USER_SAMPLERS
+#define SI_NUM_SAMPLERS (SI_POLY_STIPPLE_SAMPLER + 1)
 
 /* User sampler views:   0..15
- * FMASK sampler views: 16..31 (no sampler states)
+ * Polygon stipple tex:  16
+ * FMASK sampler views:  17..33 (no sampler states)
  */
-#define SI_FMASK_TEX_OFFSET		SI_NUM_USER_SAMPLERS
-#define SI_NUM_SAMPLER_VIEWS		(SI_FMASK_TEX_OFFSET + SI_NUM_USER_SAMPLERS)
-#define SI_NUM_SAMPLER_STATES		SI_NUM_USER_SAMPLERS
+#define SI_FMASK_TEX_OFFSET		SI_NUM_SAMPLERS
+#define SI_NUM_SAMPLER_VIEWS		(SI_FMASK_TEX_OFFSET + SI_NUM_SAMPLERS)
+#define SI_NUM_SAMPLER_STATES		SI_NUM_SAMPLERS
 
 /* User constant buffers:   0..15
  * Driver state constants:  16
-- 
2.1.0

From be750f7fd2eded7d25e89677ed1276ab020e8da2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?= 
Date: Sat, 31 Jan 2015 21:43:37 +0100
Subject: [PATCH 2/2] radeonsi: implement polygon stippling

---
 src/gallium/drivers/radeonsi/si_pipe.c  |  2 +
 src/gallium/drivers/radeonsi/si_pipe.h  |  1 +
 src/gallium/drivers/radeonsi/si_shader.c| 22 ---
 src/gallium/drivers/radeonsi/si_shader.h|  1 +
 src/gallium/drivers/radeonsi/si_state.c | 52 +
 src/gallium/drivers/radeonsi/si_state.h |  1 +
 src/gallium/drivers/radeonsi/si_state_shaders.c |  5 +++
 7 files changed, 79 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c b/src/gallium/drivers/radeonsi/si_pipe.c
index eb2b785..373df30 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -53,6 +53,8 @@ static void si_destroy_context(struct pipe_context *context)
 	si_pm4_delete_state(sctx, gs_onoff, sctx->gs_on);
 	si_pm4_delete_state(sctx, gs_onoff, sctx->gs_off);
 
+	if (sctx->pstipple_sampler_state)
+		sctx->b.b.delete_sampler_state(&sctx->b.b, sctx->pstipple_sampler_state);
 	if (sctx->dummy_pixel_shader) {
 		sctx->b.b.delete_fs_state(&sctx->b.b, sctx->dummy_pixel_shader);
 	}
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h b/src/gallium/drivers/radeonsi/si_pipe.h
index 02820a1..059fe0d 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/

Re: [Mesa-dev] [PATCH] gallium/util: Don't use __builtin_clrsb in util_last_bit().

[Roland Scheidegger]

Am 03.02.2015 um 02:28 schrieb Matt Turner:
> Unclear circumstances lead to undefined symbols on x86.
> 
> Bugzilla: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.gentoo.org_show-5Fbug.cgi-3Fid-3D536916&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=MGEUCqG6f2VdOqZHSyX6LIUPo4REk4_ehZWPRWGSuQI&s=faytCFpyY97_7ti4xOHK34hphsVRE0YwSdvqU3DYl2k&e=
>  
> ---
>  src/gallium/auxiliary/util/u_math.h | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_math.h 
> b/src/gallium/auxiliary/util/u_math.h
> index 19c7343..ca6d0f1 100644
> --- a/src/gallium/auxiliary/util/u_math.h
> +++ b/src/gallium/auxiliary/util/u_math.h
> @@ -561,14 +561,10 @@ util_last_bit(unsigned u)
>  static INLINE unsigned
>  util_last_bit_signed(int i)
>  {
> -#if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 407) && 
> !defined(__INTEL_COMPILER)
> -   return 31 - __builtin_clrsb(i);
> -#else
> if (i >= 0)
>return util_last_bit(i);
> else
>return util_last_bit(~(unsigned)i);
> -#endif
>  }
>  
>  /* Destructively loop over all of the bits in a mask as in:
> 

This looks like a gcc bug to me, right?
If so it should probably be reported there.
(I guess I can live with the patch since I have no idea if it could be
narrowed down further when the builtin doesn't work but I don't
especially like it.)

Roland

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

[Mesa-dev] [PATCH] i965/fs: Fix saturate for nir_opcode_bcsel.

[Kenneth Graunke]

Caught by lit_sat.shader_test.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 153a1be..3c611af 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -1084,6 +1084,7 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
   emit(CMP(reg_null_d, op[0], fs_reg(0), BRW_CONDITIONAL_NZ));
   inst = emit(SEL(result, op[1], op[2]));
   inst->predicate = BRW_PREDICATE_NORMAL;
+  inst->saturate = instr->dest.saturate;
   break;
 
default:
-- 
2.2.2

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

Re: [Mesa-dev] Fixes to build Mesa 10.4 against LLVM 3.5 on windows

[Jose Fonseca]

On 16/12/14 20:08, Rob Conde wrote:

I built Mesa 10.4 with LLVM 3.5 today and I had to make a couple of
fixes to get it to work:


 1. root\src\mesa\compiler.h

After:

#include "c99_compat.h" /* inline, __func__, etc. */

Add:

#ifdef _MSC_VER
#define __attribute__(a)
#endif

Otherwise you get a compile error in
root\build\windows-x86_64\mesa\program\program_parse.tab.c


This looks like a bug in the particular bison version you have.  I 
haven't seen this issue.


I'm using bison 2.4.1 and flex 2.5.35 on my MSVC builds.  And bison 
3.0.2 on Linux.  AFAICT, all generated program_parse.tab.c I've seen 
don't rely on __attribute__ for non-GNU compilers.


Which bison/flex version did you use?



 2. root\scons\llvm.py

Add 'LLVMBitReader' to libs list (i.e. 'LLVMBitWriter',
'LLVMBitReader', 'LLVMX86Disassembler', ...)

Otherwise you get a linker error on opengl32.dll


Thanks.  I pushed this change.

Jose

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

[Mesa-dev] [Bug 79629] [Dri3 bisected] piglit glx_GLX_ARB_create_context_current_with_no_framebuffer fail

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

 Status|VERIFIED|REOPENED
 Resolution|FIXED   |---

--- Comment #12 from Chris Wilson  ---
Do you mind reconfirming that you actually tested with DRI3 since the proposed
patch is not yet included?

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

Re: [Mesa-dev] [PATCH] glsl/list: Note that exec_lists may not be realloc'd.

[Kenneth Graunke]

On Monday, February 02, 2015 05:28:37 PM Matt Turner wrote:
> ---
>  src/glsl/list.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/glsl/list.h b/src/glsl/list.h
> index 85368a4..6f1a57b 100644
> --- a/src/glsl/list.h
> +++ b/src/glsl/list.h
> @@ -51,6 +51,10 @@
>   * Therefore, if \c head->next is \c NULL or \c tail_prev->prev is \c NULL,
>   * the list is empty.
>   *
> + * Do note that this means that the list nodes will contain pointers into the
> + * list structure itself and as a result you may not \c realloc() an  \c
> + * exec_list or any instructure in which an \c exec_list is embedded.
> + *
>   * To anyone familiar with "exec lists" on the Amiga, this structure should
>   * be immediately recognizable.  See the following link for the original 
> Amiga
>   * operating system documentation on the subject.
> 

Thanks for leaving a comment to try and warn people in the future.

Reviewed-by: Kenneth Graunke 


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

[Mesa-dev] [PATCH] i965/fs: Fix saturate on MAD and LRP with the NIR backend.

[Kenneth Graunke]

Fixes misrendering in "Witcher 2" with INTEL_USE_NIR=1, and probably
many other programs.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

This depends on Jason's 3 patch series that removes emit_percomp.
It's available in the 'nir-madfix' branch of my tree.

This was caught by tests/spec/arb_fragment_program/lrp_sat.shader_test
with my in-progress Mesa IR -> NIR converter code, so I don't think we
need to write more Piglit tests.  We just don't have a GLSL based one.

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index fbb1622..153a1be 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -1070,12 +1070,14 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
   break;
 
case nir_op_ffma:
-  emit(MAD(result, op[2], op[1], op[0]));
+  inst = emit(MAD(result, op[2], op[1], op[0]));
+  inst->saturate = instr->dest.saturate;
   break;
 
case nir_op_flrp:
   /* TODO emulate for gen < 6 */
-  emit(LRP(result, op[2], op[1], op[0]));
+  inst = emit(LRP(result, op[2], op[1], op[0]));
+  inst->saturate = instr->dest.saturate;
   break;
 
case nir_op_bcsel:
-- 
2.2.2

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