[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 91969, which changed state.

Bug 91969 Summary: [radeonsi][bonaire] Stalls with Borderlands 2
https://bugs.freedesktop.org/show_bug.cgi?id=91969

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |WORKSFORME

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

Re: [Mesa-dev] [PATCH v3] mesa: readpixels add support for GL_HALF_FLOAT

[Tapani Pälli]

Hi Eric;

On 03/30/2018 11:25 PM, Eric Anholt wrote:

Lin Johnson  writes:


Ext_color_buffer_half_float is using type GL_HALF_FLOAT
and data_type GL_FLOAT. This fix Android CTS test
android.view.cts.PixelCopyTest
v2: remove commtens of Ext_color_buffer_half_float.
As Ext_color_buffer__float can use type GL_HALF_FLOAT

Reviewed-by:   Palli, Tapani 
Signed-off-by: Lin Johnson 


I've been looking into CTS issues on VC5, and I think this patch should
be reverted.


After some inspection of the packed_pixels test I do agree, will revert 
this. It's too bad dEQP does not have similar test. It bothers me a bit 
though that 'reading pixels' section has hints that type could be 
GL_HALF_FLOAT but no spec seems to add this capability, maybe that is 
then only possible via IMPLEMENTATION_COLOR_READ_FORMAT?




The issue is that the text above that in the spec disallows this case.
 From GLES 3.0.2:

 Only two combinations of format and type are accepted in most
 cases. The first varies depending on the format of the currently
 bound rendering surface. For normalized fixed-point rendering
 surfaces, the combination format RGBA and type UNSIGNED_BYTE is
 accepted. For signed integer rendering surfaces, the combina- tion
 format RGBA_INTEGER and type INT is accepted. For unsigned integer
 rendering surfaces, the combination format RGBA_INTEGER and type
 UNSIGNED_INT is accepted.

 [...]

 ReadPixels generates an INVALID_OPERATION error if the combination
 of format and type is unsupported.

and this spec adds on to that first paragraph:

 For floating-point rendering surfaces, the combination
 format RGBA and type FLOAT is accepted.

The second allowed combo is:

 The second is an implementation-chosen format from among those
 defined in table 3.2, excluding formats DEPTH_COMPONENT and
 DEPTH_STENCIL . The values of format and type for this format may be
 determined by calling Get- Integerv with the symbolic constants
 IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_COLOR_READ_TYPE
 , respectively.

The failing cases are in the CTS's packed_pixels testsuite, such as:

KHR-GLES3.packed_pixels.pbo_rectangle.r11f_g11f_b10f




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

Re: [Mesa-dev] [PATCH] st/mesa: add missing GLSL_TYPE_[U]INT8 cases in st_glsl_type_dword_size()

[Timothy Arceri]

Thanks Brian.

Reviewed-by: Timothy Arceri 

On 31/03/18 01:40, Brian Paul wrote:

Silences a compiler warning about unhandled enum switch cases.
---
  src/mesa/state_tracker/st_glsl_types.cpp | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_types.cpp 
b/src/mesa/state_tracker/st_glsl_types.cpp
index baba2d4..42d4e9c 100644
--- a/src/mesa/state_tracker/st_glsl_types.cpp
+++ b/src/mesa/state_tracker/st_glsl_types.cpp
@@ -124,6 +124,9 @@ st_glsl_type_dword_size(const struct glsl_type *type)
 case GLSL_TYPE_INT16:
 case GLSL_TYPE_FLOAT16:
return DIV_ROUND_UP(type->components(), 2);
+   case GLSL_TYPE_UINT8:
+   case GLSL_TYPE_INT8:
+  return DIV_ROUND_UP(type->components(), 4);
 case GLSL_TYPE_DOUBLE:
 case GLSL_TYPE_UINT64:
 case GLSL_TYPE_INT64:


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

Re: [Mesa-dev] [PATCH 05/55] radeonsi: use num_cs_dw_queries_suspend

[Timothy Arceri]

This is the only patch that seems to have a functional change. I have no 
idea what this is doing from a glance, are you able to put a little 
comment on why this is needed in the commit message?


Other than that for the series:

Acked-by: Timothy Arceri 

On 02/04/18 14:07, Marek Olšák wrote:

From: Marek Olšák 

---
  src/gallium/drivers/radeonsi/si_hw_context.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_hw_context.c 
b/src/gallium/drivers/radeonsi/si_hw_context.c
index 6fc85ea..0f7fbc6 100644
--- a/src/gallium/drivers/radeonsi/si_hw_context.c
+++ b/src/gallium/drivers/radeonsi/si_hw_context.c
@@ -62,7 +62,8 @@ void si_need_cs_space(struct si_context *ctx)
/* If the CS is sufficiently large, don't count the space needed
 * and just flush if there is not enough space left.
 */
-   if (!ctx->b.ws->cs_check_space(cs, 2048))
+   unsigned need_dwords = 2048 + ctx->b.num_cs_dw_queries_suspend;
+   if (!ctx->b.ws->cs_check_space(cs, need_dwords))
si_flush_gfx_cs(ctx, PIPE_FLUSH_ASYNC, NULL);
  }
  


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

Re: [Mesa-dev] [PATCH] glsl: always call do_lower_jumps() after loop unrolling

[Matt Turner]

Seems reasonable.

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

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 95308, which changed state.

Bug 95308 Summary: [radeonsi] Hangs after some minutes on Team Fortress 2
https://bugs.freedesktop.org/show_bug.cgi?id=95308

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

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

[Mesa-dev] [PATCH] st/mesa: tex offsets can't be in a const or 2d-indexed

[Ilia Mirkin]

All consts are now implicitly 2d (they set .Dimension), so trigger
asserts. Also, the texture offset can't handle any sort of 2d indexing.
While this could be tacked on, this seems unnecessary, just move it off
into a separate temp.

Fixes assertion failure in
tests/spec/arb_gpu_shader5/compiler/builtin-functions/fs-gatherOffset-uniform-offset.frag

Note that this was an issue even before the const-always-2d thing, since
there was no detection of when even a proper second dimension was used,
e.g. for UBO or geom/tess inputs.

Signed-off-by: Ilia Mirkin 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 5f7a0dcd3e8..01a58d7d2c6 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4096,7 +4096,11 @@ glsl_to_tgsi_visitor::get_deref_offsets(ir_dereference 
*ir,
 st_src_reg
 glsl_to_tgsi_visitor::canonicalize_gather_offset(st_src_reg offset)
 {
-   if (offset.reladdr || offset.reladdr2) {
+   if (offset.reladdr || offset.reladdr2 ||
+   offset.has_index2 ||
+   offset.file == PROGRAM_UNIFORM ||
+   offset.file == PROGRAM_CONSTANT ||
+   offset.file == PROGRAM_STATE_VAR) {
   st_src_reg tmp = get_temp(glsl_type::ivec2_type);
   st_dst_reg tmp_dst = st_dst_reg(tmp);
   tmp_dst.writemask = WRITEMASK_XY;
-- 
2.16.1

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

[Mesa-dev] [PATCH] glsl: always call do_lower_jumps() after loop unrolling

[Timothy Arceri]

This fixes a bug in radeonsi where LLVM cannot handle the case where
a break exists but its not the last instruction in the block.

LLVM would fail with:
Terminator found in the middle of a basic block!
LLVM ERROR: Broken function found, compilation aborted!

Fixes: 96fe8834f539 "glsl_to_tgsi: do fewer optimizations with 
GLSLOptimizeConservatively"

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105317
---
 src/compiler/glsl/glsl_parser_extras.cpp | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 275c4d75711..0cc57f5a887 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -2242,6 +2242,24 @@ do_common_optimization(exec_list *ir, bool linked,
 loop_progress = false;
 loop_progress |= do_constant_propagation(ir);
 loop_progress |= do_if_simplification(ir);
+
+/* Some drivers only call do_common_optimization() once rather
+ * than in a loop. So we must call do_lower_jumps() after
+ * unrolling a loop because for drivers that use LLVM validation
+ * will fail if a jump is not the last instruction in the block.
+ * For example the following will fail LLVM validation:
+ *
+ *   (loop (
+ *  ...
+ *   break
+ *   (assign  (x) (var_ref v124)  (expression int + (var_ref v124)
+ *  (constant int (1)) ) )
+ *   ))
+ */
+loop_progress |= do_lower_jumps(ir, true, true,
+options->EmitNoMainReturn,
+options->EmitNoCont,
+options->EmitNoLoops);
  }
  progress |= loop_progress;
   }
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] mesa: ensure that variable is initialized

[Mark Janes]

Tested-by: Mark Janes 

Dylan Baker  writes:

> locally I've added:
> Fixes: 16f6634e7fb5ada308e55b852cd49251e7f3f8b1 
>("mesa/program: Link SPIR-V shaders using the SPIR-V code-path")
>
> Quoting Dylan Baker (2018-04-02 15:36:01)
>> Otherwise this variable will only be set if there are spirv shaders
>> present, but it's used regardless, resulting in undefined behavior.
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105820
>> CC: Alejandro Piñeiro 
>> CC: Mark Janes 
>> Signed-off-by: Dylan Baker 
>> ---
>>  src/mesa/program/ir_to_mesa.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/src/mesa/program/ir_to_mesa.cpp 
>> b/src/mesa/program/ir_to_mesa.cpp
>> index 49ef5ea52d8..60fb24bf664 100644
>> --- a/src/mesa/program/ir_to_mesa.cpp
>> +++ b/src/mesa/program/ir_to_mesa.cpp
>> @@ -3126,7 +3126,7 @@ void
>>  _mesa_glsl_link_shader(struct gl_context *ctx, struct gl_shader_program 
>> *prog)
>>  {
>> unsigned int i;
>> -   bool spirv;
>> +   bool spirv = false;
>>  
>> _mesa_clear_shader_program_data(ctx, prog);
>>  
>> -- 
>> 2.16.3
>> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hi Laura,

I haven't used any script.
I made all the HTML to rst translations by hand, file by file.

Kind Regards,
Jean Hertel

Em 2 de abril de 2018 19:09:34 BRT, Laura Ekstrand  
escreveu:
Hi Jean,

I'm going to play around with your patches to get them into a format that Mesa 
devs can review.  This will blow the history away.

The problem is that your workflow in 1 & 2 ruins the Git history for reviewers. 
 It makes the patch series hard to read.

Could you provide us with your script for translating HTML to rst?  Go ahead 
and commit it to your repo as a patch.

Thanks.

Laura

On Sun, Apr 1, 2018 at 6:12 AM, Jean Hertel 
> wrote:

Hi Laura,


The commits have the idea of being atomic, so it makes sense to have a lot of 
them.

Some of them are just fixes, and can be squashed.


Please keep in mind that no CSS file is supposed to live there, as we are using 
an existing template from readTheDocs.

The commits are doing mainly two things:

1 - Create a new file and translate the old HTML content into a rst format.

2 - Delete the old file


Kind Regards,

Jean Hertel


De: Laura Ekstrand >
Enviado: sábado, 31 de março de 2018 22:06
Para: Jean Hertel
Cc: Emil Velikov; Vedran Miletić; 
mesa-dev@lists.freedesktop.org; Jason 
Ekstrand
Assunto: Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

Jean,

I've taken at look at your sphinx-docs branch 
(https://github.com/jlHertel/mesa).

Oh my you have a lot of commits there!  It would be simpler for me to review if 
you could squash some of them together.

I am thinking a series on the order of 30 patches to start - just the pretty 
CSS stuff in Sphinx.

Once we get the page to look nicer, then we can start editing the content for 
readability!!!

Thanks.

Laura

On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand 
> wrote:
Hello Jean,

Has anyone reviewed your patch series yet?   I would like to get these website 
updates moving.

Thanks.

Laura

On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
> wrote:
Hello Emil,

I've updated the website with the new release notes template.

Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html


What about rebasing my current work on top of mesa-master?
(Remembering that github comments referencing directly the commit will be loss)


The repository: https://github.com/jlHertel/mesa
Demo site: http://mesa2.jeanhertel.com.br/

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




--
Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela brevidade.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: ensure that variable is initialized

[Dylan Baker]

locally I've added:
Fixes: 16f6634e7fb5ada308e55b852cd49251e7f3f8b1 
   ("mesa/program: Link SPIR-V shaders using the SPIR-V code-path")

Quoting Dylan Baker (2018-04-02 15:36:01)
> Otherwise this variable will only be set if there are spirv shaders
> present, but it's used regardless, resulting in undefined behavior.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105820
> CC: Alejandro Piñeiro 
> CC: Mark Janes 
> Signed-off-by: Dylan Baker 
> ---
>  src/mesa/program/ir_to_mesa.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
> index 49ef5ea52d8..60fb24bf664 100644
> --- a/src/mesa/program/ir_to_mesa.cpp
> +++ b/src/mesa/program/ir_to_mesa.cpp
> @@ -3126,7 +3126,7 @@ void
>  _mesa_glsl_link_shader(struct gl_context *ctx, struct gl_shader_program 
> *prog)
>  {
> unsigned int i;
> -   bool spirv;
> +   bool spirv = false;
>  
> _mesa_clear_shader_program_data(ctx, prog);
>  
> -- 
> 2.16.3
> 


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

[Mesa-dev] [PATCH] mesa: ensure that variable is initialized

[Dylan Baker]

Otherwise this variable will only be set if there are spirv shaders
present, but it's used regardless, resulting in undefined behavior.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105820
CC: Alejandro Piñeiro 
CC: Mark Janes 
Signed-off-by: Dylan Baker 
---
 src/mesa/program/ir_to_mesa.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 49ef5ea52d8..60fb24bf664 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -3126,7 +3126,7 @@ void
 _mesa_glsl_link_shader(struct gl_context *ctx, struct gl_shader_program *prog)
 {
unsigned int i;
-   bool spirv;
+   bool spirv = false;
 
_mesa_clear_shader_program_data(ctx, prog);
 
-- 
2.16.3

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

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Laura Ekstrand]

Hi Jean,

I'm going to play around with your patches to get them into a format that
Mesa devs can review.  This will blow the history away.

The problem is that your workflow in 1 & 2 ruins the Git history for
reviewers.  It makes the patch series hard to read.

Could you provide us with your script for translating HTML to rst?  Go
ahead and commit it to your repo as a patch.

Thanks.

Laura

On Sun, Apr 1, 2018 at 6:12 AM, Jean Hertel  wrote:

> Hi Laura,
>
>
> The commits have the idea of being atomic, so it makes sense to have a lot
> of them.
>
> Some of them are just fixes, and can be squashed.
>
>
> Please keep in mind that no CSS file is supposed to live there, as we are
> using an existing template from readTheDocs.
>
> The commits are doing mainly two things:
>
> 1 - Create a new file and translate the old HTML content into a rst format.
>
> 2 - Delete the old file
>
> Kind Regards,
>
> Jean Hertel
>
> --
> *De:* Laura Ekstrand 
> *Enviado:* sábado, 31 de março de 2018 22:06
> *Para:* Jean Hertel
> *Cc:* Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org; Jason
> Ekstrand
> *Assunto:* Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx
>
> Jean,
>
> I've taken at look at your sphinx-docs branch (
> https://github.com/jlHertel/mesa).
>
> Oh my you have a lot of commits there!  It would be simpler for me to
> review if you could squash some of them together.
>
> I am thinking a series on the order of 30 patches to start - just the
> pretty CSS stuff in Sphinx.
>
> Once we get the page to look nicer, then we can start editing the content
> for readability!!!
>
> Thanks.
>
> Laura
>
> On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand 
> wrote:
>
> Hello Jean,
>
> Has anyone reviewed your patch series yet?   I would like to get these
> website updates moving.
>
> Thanks.
>
> Laura
>
> On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
> wrote:
>
> Hello Emil,
>
> I've updated the website with the new release notes template.
>
> Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html
>
>
> What about rebasing my current work on top of mesa-master?
> (Remembering that github comments referencing directly the commit will be
> loss)
>
>
> The repository: https://github.com/jlHertel/mesa
> Demo site: http://mesa2.jeanhertel.com.br/
>
> Best regards,
> Jean Hertel
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Trevor Woerner]

Even without the patch, simply adding:

PACKAGECONFIG_append_pn-mesa = "dri3"

to my conf/local.conf has glmark2-es2 running, and chromium-x11 is running
accelerated out-of-the-box (i.e. I don't have to install the egl/gles
libraries it builds itself).

I'm re-building my rpi3-64 image to see if things are better there too under
vc4.

I guess the patch is to address some of the other things you were seeing?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Andreas Müller]

On Mon, Apr 2, 2018 at 3:05 PM, Andreas Müller  wrote:
> On Mon, Apr 2, 2018 at 2:42 PM, Daniel Stone  wrote:
>> Hi Andreas,
>>
>> On 31 March 2018 at 15:18, Andreas Müller  wrote:
>>> Thanks for prompt an VERY helpful support. I did:
>>>
>>> * Check my configure and found: --disable-dri3!
>>> * Tested your patch (with --disable-dri3) and as expected it fixes the issue
>>> * Found what causes --disable-dri3 - it came in by the Openembedded
>>> update mentioned in first email. FWIW: I use a fork for
>>> meta-raspberrypi - the original is not affected so I am the only one
>>> with this issue...
>>
>> Glad to hear it!
>>
>>> I have two questions related to dri2/your patch (sorry asking for more :)
>>>
>>> 1. Your patch fixes improper initialized variable. Do you think it is
>>> worth being applied?
>>
>> Yes, definitely: I've sent it in now. It's sadly missed 17.3.8
>> (scheduled to be released about an hour ago), but hopefully we can get
>> it in for a 17.3.9, if we have one. Else it'll be in 18.0.1.
>>
>>> 2. In the thread I mentioned in my first email Trevor mentioned that
>>> he has seen error message 'Modifier 0x0 vs. tiling(0x7001)
>>> mismatch' when trying to get chromium GLES accelerated. Maybe a stupid
>>> question but is it possible that applications running at X can ask for
>>> dri2 explicitly?
>>
>> He said that only happened when using the system (rather than bundled)
>> libraries, which would presumably be using DRI2 by default. I've
>> submitted a bug to OE to ask them to enable DRI3 by default, but in
>> the meantime this Mesa fix should hopefully work anyway.
> Thanks - I was thinking same. OE-Core enables DRI3 for x11 AND vulcan
> only - and vulcan is not in my distro features (and does not make much
> sense for VC4)
>
> Added yocto mailing list to merge both threads together and avoid cross-tak.
>
> Thanks again for taking care
>
Hi Daniel,

Just sent out patches to oe-core

* Apply your patch with dri2 modifier init
* Prefer dri3 over dri2 for x11/opengl distro features

See what happens...

Cheers

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

[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675

[bugzilla-daemon]

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

--- Comment #4 from l...@protonmail.ch ---
After some testing, it does not seem to happen when MESA_DEBUG=context and
MESA_VERBOSE=all.

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

Re: [Mesa-dev] 2018 Election voting OPEN

[Rob Clark]

To all X.Org Foundation Members:

Due to some technical difficulties, the earlier election notification
messages to memb...@x.org list did not go through (but also did not
trigger bounce/moderator notification).  We cross referenced the
members list to the subscriber lists for xorg-devel, xorg, mesa-dev,
and wayland-devel lists and concluded that there are a small
percentage of x.org foundation members who were not also subscribed to
one of the lists CC'd on the original notification about election
period.

For this reason, to ensure that all x.org foundation members have an
opportunity to vote, we are extending the voting period by one week.
The voting period will now remain open until 23:59 UTC on 12 April
2018.

Rob Clark,
on behalf of the X.Org elections committee

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> To all X.Org Foundation Members:
>
> The X.Org Foundation's annual election is now open and will remain
> open until 23:59 UTC on 5 April 2018.
>
> Four of the eight director seats are open during this election, with
> the four nominees receiving the highest vote totals serving as
> directors for two year terms.
>
> There were six candidates nominated. For a complete list of the
> candidates and their personal statements, please see the following:
>
>   https://www.x.org/wiki/BoardOfDirectors/Elections/2018/
>
> Here are some instructions on how to cast your vote:
>
> Login to the membership system at: https://members.x.org/
>
> If you do not remember your password, you can click on the "lost
> password" button and enter your user name. An e-mail will be sent to
> you with your password. If you have problems with the membership
> system, please e-mail members...@x.org.
>
> When you login you will see a row of buttons that will allow you to
> update your info, list the members, list the open ballots and logout.
> Below this you will see a list of open ballots, for which you can cast
> votes. At the bottom of this page you will see another row of buttons
> with the current privacy policy, the provisional By-laws, the
> provisional Membership Agreement and instructions on how to contact
> the admin.
>
> Note that if you click on the "Ballots" button at any time, you will
> see a list of the open ballots.
>
> To cast your vote in a ballot, click on the "Cast" button to the right
> of the ballot you wish to vote on. This will bring up another page
> with the list of the candidates, and a question of whether or not to
> approve the new By-laws.
>
> For the election: There is a pull-down selection box next to each
> candidate. For your top choice, select "1". For your second choice,
> select "2" and so forth. You should think of the numbers that you are
> selecting as the ranking of your preferences.
>
> Note that you are NOT required to select your preferences for all four
> positions. You can leave more than one blank. The only restriction is
> that you cannot duplicate any of your choices (i.e., you can only
> select one "1", one "2" and so forth).
>
> After you have completed your ballot, click the "Vote" button. Note
> that once you click this button, your votes will be cast and you will
> not be able to make further changes, so please make sure you are
> satisfied with your votes before clicking the "Vote" button.
>
> After you click the "Vote" button, the system will verify that you
> have completed a valid ballot. If your ballot is invalid (e.g., you
> duplicated a selection), it will return you to the previous voting
> page. If your ballot is valid, your votes will be recorded and the
> system will show you a notice that your votes were cast.
>
> Note that the election will close at 23:59 UTC on 5 April 2018. At
> that time, the election committee will count the votes and present the
> results to the current board for validation. After the current board
> validates the results, the election committee will present the results
> to the Members.
>
> Rob Clark,
> on behalf of the X.Org elections committee
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: skip DCC render feedback checking if color writes are disabled

[Marek Olšák]

On Mon, Apr 2, 2018 at 2:22 PM, Dieter Nützel  wrote:

> Hello Marek,
>
> this one do not longer apply after 'GL_KHR_blend_equation_advanced'
> landed.
>

The conflict can be resolved trivially. The patch is still open for review.

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

Re: [Mesa-dev] [PATCH] nir: Look into uniform structs for samplers when counting num_textures.

[Jason Ekstrand]

Doesn't st/mesa have a pass for getting rid if the structs?

On Mon, Apr 2, 2018 at 11:13 AM, Eric Anholt  wrote:

> mesa/st decides whether to update samplers after a program change based on
> whether num_textures is nonzero.  By not counting samplers in a uniform
> struct, we would segfault in
> KHR-GLES3.shaders.struct.uniform.sampler_vertex if it was run in the same
> context after a non-vertex-shader-uniform testcase (as is the case during
> a full conformance run).
> ---
>  src/compiler/nir/nir_gather_info.c | 32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/src/compiler/nir/nir_gather_info.c
> b/src/compiler/nir/nir_gather_info.c
> index 5530009255d7..63783f9bc6a2 100644
> --- a/src/compiler/nir/nir_gather_info.c
> +++ b/src/compiler/nir/nir_gather_info.c
> @@ -350,24 +350,32 @@ gather_info_block(nir_block *block, nir_shader
> *shader)
> }
>  }
>
> +static void
> +nir_gather_uniform_info(nir_shader *shader, const struct glsl_type *type,
> +int count)
>
+{
> +   if (glsl_type_is_array(type)) {
> +  nir_gather_uniform_info(shader, glsl_without_array(type),
> +  count * glsl_get_aoa_size(type));
> +   } else if (glsl_type_is_struct(type)) {
> +  for (int i = 0; i < glsl_get_length(type); i++) {
> + nir_gather_uniform_info(shader, glsl_get_struct_field(type, i),
> + count);
>

The interaction between in and out parameters is a bit weird here.  Why not
just have a simpler helper:

unsigned
glsl_type_get_image_count(const struct glsl_type *type)
{
   if (glsl_type_is_array(type)) {
  return glsl_type_get_image_count(glsl_without_array(type)) *
glsl_get_aoa_size(type);
   } else if (glsl_type_is_struct(type)) {
  unsigned count = 0;
  for (int i = 0; i < glsl_get_length(type); i++)
 count += glsl_type_get_image_count(glsl_get_struct_field(type, i));
  return count;
   } else if (glsl_type_is_image(type) {
  return 1;
   } else {
  return 0;
}

and another one for samplers.  Yes, it's a bit more code but the new
functions are pure which is nice.

--Jason


> +  }
> +   } else if (glsl_type_is_image(type)) {
> +  shader->info.num_images += count;
> +   } else if (glsl_type_is_sampler(type)) {
> +  shader->info.num_textures += count;
> +   }
> +}
> +
>  void
>  nir_shader_gather_info(nir_shader *shader, nir_function_impl *entrypoint)
>  {
> shader->info.num_textures = 0;
> shader->info.num_images = 0;
> nir_foreach_variable(var, >uniforms) {
> -  const struct glsl_type *type = var->type;
> -  unsigned count = 1;
> -  if (glsl_type_is_array(type)) {
> - count = glsl_get_aoa_size(type);
> - type = glsl_without_array(type);
> -  }
> -
> -  if (glsl_type_is_image(type)) {
> - shader->info.num_images += count;
> -  } else if (glsl_type_is_sampler(type)) {
> - shader->info.num_textures += count;
> -  }
> +  nir_gather_uniform_info(shader, var->type, 1);
> }
>
> shader->info.inputs_read = 0;
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: skip DCC render feedback checking if color writes are disabled

[Dieter Nützel]

Hello Marek,

this one do not longer apply after 'GL_KHR_blend_equation_advanced' 
landed.


Happy Easter!

Dieter

Am 02.04.2018 05:54, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_blit.c  |  5 +
 src/gallium/drivers/radeonsi/si_pipe.h  | 17 +
 src/gallium/drivers/radeonsi/si_state_shaders.c |  6 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index f1c4f6d..c34d677 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -706,20 +706,25 @@ static void
si_check_render_feedback_resident_images(struct si_context *sctx)
si_check_render_feedback_texture(sctx, tex,
 view->u.tex.level,
 view->u.tex.level,
 view->u.tex.first_layer,
 view->u.tex.last_layer);
}
 }

 static void si_check_render_feedback(struct si_context *sctx)
 {
+   /* There is no render feedback if color writes are disabled.
+* (e.g. a pixel shader with image stores)
+*/
+   if (!si_get_total_colormask(sctx))
+   return;

if (!sctx->need_check_render_feedback)
return;

for (int i = 0; i < SI_NUM_SHADERS; ++i) {
si_check_render_feedback_images(sctx, >images[i]);
si_check_render_feedback_textures(sctx, >samplers[i]);
}

si_check_render_feedback_resident_images(sctx);
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h
b/src/gallium/drivers/radeonsi/si_pipe.h
index 2053dcb..e75e6c1 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -923,11 +923,28 @@ si_htile_enabled(struct r600_texture *tex, 
unsigned level)

return tex->htile_offset && level == 0;
 }

 static inline bool
 vi_tc_compat_htile_enabled(struct r600_texture *tex, unsigned level)
 {
assert(!tex->tc_compatible_htile || tex->htile_offset);
return tex->tc_compatible_htile && level == 0;
 }

+static inline unsigned si_get_total_colormask(struct si_context *sctx)
+{
+   if (sctx->queued.named.rasterizer->rasterizer_discard)
+   return 0;
+
+   struct si_shader_selector *ps = sctx->ps_shader.cso;
+   unsigned colormask = sctx->framebuffer.colorbuf_enabled_4bit &
+sctx->queued.named.blend->cb_target_mask;
+
+   if (!ps->info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
+   colormask &= ps->colors_written_4bit;
+   else if (!ps->colors_written_4bit)
+   colormask = 0; /* color0 writes all cbufs, but it's not written 
*/
+
+   return colormask;
+}
+
 #endif
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 8fe4c04..45eded9 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1208,25 +1208,21 @@ static void
si_shader_selector_key_hw_vs(struct si_context *sctx,
bool ps_disabled = true;
if (ps) {
const struct si_state_blend *blend = sctx->queued.named.blend;
bool alpha_to_coverage = blend && blend->alpha_to_coverage;
bool ps_modifies_zs = ps->info.uses_kill ||
  ps->info.writes_z ||
  ps->info.writes_stencil ||
  ps->info.writes_samplemask ||
  alpha_to_coverage ||
  si_get_alpha_test_func(sctx) != 
PIPE_FUNC_ALWAYS;
-
-   unsigned ps_colormask = sctx->framebuffer.colorbuf_enabled_4bit 
&
-   
sctx->queued.named.blend->cb_target_mask;
-   if 
(!ps->info.properties[TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS])
-   ps_colormask &= ps->colors_written_4bit;
+   unsigned ps_colormask = si_get_total_colormask(sctx);

ps_disabled = sctx->queued.named.rasterizer->rasterizer_discard 
||
  (!ps_colormask &&
   !ps_modifies_zs &&
   !ps->info.writes_memory);
}

/* Find out which VS outputs aren't used by the PS. */
uint64_t outputs_written = vs->outputs_written;
uint64_t inputs_read = 0;

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

[Mesa-dev] [PATCH] nir: Look into uniform structs for samplers when counting num_textures.

[Eric Anholt]

mesa/st decides whether to update samplers after a program change based on
whether num_textures is nonzero.  By not counting samplers in a uniform
struct, we would segfault in
KHR-GLES3.shaders.struct.uniform.sampler_vertex if it was run in the same
context after a non-vertex-shader-uniform testcase (as is the case during
a full conformance run).
---
 src/compiler/nir/nir_gather_info.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/src/compiler/nir/nir_gather_info.c 
b/src/compiler/nir/nir_gather_info.c
index 5530009255d7..63783f9bc6a2 100644
--- a/src/compiler/nir/nir_gather_info.c
+++ b/src/compiler/nir/nir_gather_info.c
@@ -350,24 +350,32 @@ gather_info_block(nir_block *block, nir_shader *shader)
}
 }
 
+static void
+nir_gather_uniform_info(nir_shader *shader, const struct glsl_type *type,
+int count)
+{
+   if (glsl_type_is_array(type)) {
+  nir_gather_uniform_info(shader, glsl_without_array(type),
+  count * glsl_get_aoa_size(type));
+   } else if (glsl_type_is_struct(type)) {
+  for (int i = 0; i < glsl_get_length(type); i++) {
+ nir_gather_uniform_info(shader, glsl_get_struct_field(type, i),
+ count);
+  }
+   } else if (glsl_type_is_image(type)) {
+  shader->info.num_images += count;
+   } else if (glsl_type_is_sampler(type)) {
+  shader->info.num_textures += count;
+   }
+}
+
 void
 nir_shader_gather_info(nir_shader *shader, nir_function_impl *entrypoint)
 {
shader->info.num_textures = 0;
shader->info.num_images = 0;
nir_foreach_variable(var, >uniforms) {
-  const struct glsl_type *type = var->type;
-  unsigned count = 1;
-  if (glsl_type_is_array(type)) {
- count = glsl_get_aoa_size(type);
- type = glsl_without_array(type);
-  }
-
-  if (glsl_type_is_image(type)) {
- shader->info.num_images += count;
-  } else if (glsl_type_is_sampler(type)) {
- shader->info.num_textures += count;
-  }
+  nir_gather_uniform_info(shader, var->type, 1);
}
 
shader->info.inputs_read = 0;
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH] st/dri: Initialise modifier to INVALID for DRI2

[Daniel Stone]

On 2 April 2018 at 18:52, Eric Anholt  wrote:
> Daniel Stone  writes:
>> When allocating a buffer for DRI2, set the modifier to INVALID to inform
>> the backend that we have no supplied modifiers and it should do its own
>> thing. The missed initialisation forced linear, even if the
>> implementation had made other decisions.
>
> This makes sense.

Pushed now, thanks Eric!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/dri: Initialise modifier to INVALID for DRI2

[Eric Anholt]

Daniel Stone  writes:

> When allocating a buffer for DRI2, set the modifier to INVALID to inform
> the backend that we have no supplied modifiers and it should do its own
> thing. The missed initialisation forced linear, even if the
> implementation had made other decisions.

This makes sense.

Reviewed-by: Eric Anholt 


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

[Mesa-dev] [Bug 105442] Hang when running nine ff lighting shader with radeonsi

[bugzilla-daemon]

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

Axel Davy  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Other

--- Comment #3 from Axel Davy  ---
Patrick Rudolph bisected the radeonsi regression to:
2f4705afde707e8eb41b9414c25df91aa1ea2fb3

Checking the attached TGSI, it seems the lighting constants were not declared
properly (which is illegal), and in conjunction with the behaviour introduced
by this commit (which is legal), it caused the shader to never stop.

The bug was thus a nine bug. Patch sent to the mailing list:
https://lists.freedesktop.org/archives/mesa-dev/2018-April/190803.html

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

Re: [Mesa-dev] 2018 Election voting OPEN

[Rob Clark]

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> To all X.Org Foundation Members:
>
> The X.Org Foundation's annual election is now open and will remain
> open until 23:59 UTC on 5 April 2018.

Reminder that the elections are open until midnight on Thurs, so if
you have not already voted, please do.

> Four of the eight director seats are open during this election, with
> the four nominees receiving the highest vote totals serving as
> directors for two year terms.
>
> There were six candidates nominated. For a complete list of the
> candidates and their personal statements, please see the following:
>
>   https://www.x.org/wiki/BoardOfDirectors/Elections/2018/
>
> Here are some instructions on how to cast your vote:
>
> Login to the membership system at: https://members.x.org/
>
> If you do not remember your password, you can click on the "lost
> password" button and enter your user name. An e-mail will be sent to
> you with your password. If you have problems with the membership
> system, please e-mail members...@x.org.
>
> When you login you will see a row of buttons that will allow you to
> update your info, list the members, list the open ballots and logout.
> Below this you will see a list of open ballots, for which you can cast
> votes. At the bottom of this page you will see another row of buttons
> with the current privacy policy, the provisional By-laws, the
> provisional Membership Agreement and instructions on how to contact
> the admin.
>
> Note that if you click on the "Ballots" button at any time, you will
> see a list of the open ballots.
>
> To cast your vote in a ballot, click on the "Cast" button to the right
> of the ballot you wish to vote on. This will bring up another page
> with the list of the candidates, and a question of whether or not to
> approve the new By-laws.
>
> For the election: There is a pull-down selection box next to each
> candidate. For your top choice, select "1". For your second choice,
> select "2" and so forth. You should think of the numbers that you are
> selecting as the ranking of your preferences.
>
> Note that you are NOT required to select your preferences for all four
> positions. You can leave more than one blank. The only restriction is
> that you cannot duplicate any of your choices (i.e., you can only
> select one "1", one "2" and so forth).
>
> After you have completed your ballot, click the "Vote" button. Note
> that once you click this button, your votes will be cast and you will
> not be able to make further changes, so please make sure you are
> satisfied with your votes before clicking the "Vote" button.
>
> After you click the "Vote" button, the system will verify that you
> have completed a valid ballot. If your ballot is invalid (e.g., you
> duplicated a selection), it will return you to the previous voting
> page. If your ballot is valid, your votes will be recorded and the
> system will show you a notice that your votes were cast.
>
> Note that the election will close at 23:59 UTC on 5 April 2018. At
> that time, the election committee will count the votes and present the
> results to the current board for validation. After the current board
> validates the results, the election committee will present the results
> to the Members.
>
> Rob Clark,
> on behalf of the X.Org elections committee
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/nine: Declare lighting consts for ff shaders

[Axel Davy]

The lighting constants were not declared previously,
but were accessed with indirect addressing, which is
illegal.

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

Signed-off-by: Axel Davy 

CC: "17.3 18.0" 
---
 src/gallium/state_trackers/nine/nine_ff.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/state_trackers/nine/nine_ff.c 
b/src/gallium/state_trackers/nine/nine_ff.c
index d7b697caee..fabc1d3b88 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -810,6 +810,10 @@ nine_ff_build_vs(struct NineDevice9 *device, struct 
vs_build_ctx *vs)
 
 const unsigned loop_label = l++;
 
+/* Declare all light constants to allow indirect adressing */
+for (i = 32; i < 96; i++)
+ureg_DECL_constant(ureg, i);
+
 ureg_MOV(ureg, rCtr, ureg_imm1f(ureg, 32.0f)); /* (0) */
 ureg_MOV(ureg, rD, ureg_imm1f(ureg, 0.0f));
 ureg_MOV(ureg, rA, ureg_imm1f(ureg, 0.0f));
-- 
2.16.2

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

Re: [Mesa-dev] vmware change resolution mode

[Deepak Singh Rawat]

Hi,

What distro you are running ? Is open-vm-tools installed ? This package
is required for setting resolutions from user-space. Also what is the Linux
kernel version used ?

Regarding usage of kernel option I suspect there is a upper limit on that, I
will verify that. During bootup vmwgfx use fbdev driver and later it is switched
to screen object.

Thanks,
Deepak

> From: Vignesh Raman 
> To:   mesa-dev@lists.freedesktop.org
> 
> 
> 
> Hi,
> 
> I have a question how to change screen resolution. I'm running a image
> in vmplayer. From dmesg logs I see,
> [    2.947320] [drm] Screen Objects Display Unit initialized
> [    2.947346] [drm] width 1280
> [    2.947351] [drm] height 768
> [    2.947356] [drm] bpp 32
> 
> lsmod | grep vmwgfx
> vmwgfx    220505  2
> ttm    75481  1 vmwgfx
> drm_kms_helper    105053  1 vmwgfx
> drm   279913  6 vmwgfx,ttm,drm_kms_helper
> 
> The status of the connector is,
> cat /sys/class/drm/card0-Virtual-1/status
> connected
> 
> cat /sys/class/drm/card0-Virtual-1/modes
> preferred
> 2560x1600
> 1920x1440
> 1856x1392
> 1792x1344
> 1920x1200
> 1600x1200
> 1680x1050
> 1400x1050
> 1280x1024
> 1440x900
> 1280x960
> 1360x768
> 1280x800
> 1152x864
> 1280x768
> 1024x768
> 800x600
> 640x480
> 
> I tried the below to change the screen resolution to 1920x1200,
> - Passing video=Virtual-1:1920x1200 as kernel option
> - Setting below in vmx file  (https://kb.vmware.com/s/article/1003
> )
> svga.vramSize = 9216000
> svga.autodetect = "FALSE"
> svga.maxWidth = 1920
> svga.maxHeight = 1200
> 
> But the screen resolution doesn't change and in dmesg output I see width
> and height as (1280x768).
> 
> Any pointers will be helpful. Thanks.
> 
> Regards,
> Vignesh
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] compiler/spirv: set is_shadow for depth comparitor sampling opcodes

[Jason Ekstrand]

On April 2, 2018 04:04:49 Iago Toral Quiroga  wrote:

From the SPIR-V spec, OpTypeImage:

"Depth is whether or not this image is a depth image. (Note that
whether or not depth comparisons are actually done is a property of
the sampling opcode, not of this type declaration.)"

OpImageSample{Proj}Dref{Explicit,Implicit}Lod sampling opcodes always do
a depth comparison, regardless of the Depth property of the image type,
and as stated in the spec quote, this should be honored. For us, it means
that we always have to handle them as shadow sampling opcodes.

Fixes crashes in:
dEQP-VK.spirv_assembly.instruction.graphics.image_sampler.depth_property.*
---
src/compiler/spirv/spirv_to_nir.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c

index 72ab426e80..f968c4d387 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1908,7 +1908,22 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
const struct glsl_type *image_type = sampled.type->type;
const enum glsl_sampler_dim sampler_dim = glsl_get_sampler_dim(image_type);
const bool is_array = glsl_sampler_type_is_array(image_type);
-   const bool is_shadow = glsl_sampler_type_is_shadow(image_type);
+
+   bool is_shadow;
+   switch (opcode) {
+   /* These opcodes are always depth-comparitors regardless of the depth
+* property of the image
+*/
+   case SpvOpImageSampleDrefImplicitLod:
+   case SpvOpImageSampleProjDrefImplicitLod:
+   case SpvOpImageSampleDrefExplicitLod:
+   case SpvOpImageSampleProjDrefExplicitLod:
+  is_shadow = true;
+  break;
+   default:
+  is_shadow = glsl_sampler_type_is_shadow(image_type);

Given the sure quote above, should this just be false?  Also, don't we 
already have a switch for the Dref source that we can use instead of making 
a new one?



+  break;
+   }

/* Figure out the base texture operation */
nir_texop texop;
--
2.14.1



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

[Mesa-dev] [PATCH] radv: enable VK_EXT_shader_viewport_index_layer

[Samuel Pitoiset]

The driver already supports exporting the Layer and ViewportIndex
built-ins from vertex or tessellation shaders.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_extensions.py | 1 +
 src/amd/vulkan/radv_shader.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index cbb02f138a..8cb0b7aa7d 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -92,6 +92,7 @@ EXTENSIONS = [
 Extension('VK_EXT_external_memory_host',  1, 
'device->rad_info.has_userptr'),
 Extension('VK_EXT_global_priority',   1, 
'device->rad_info.has_ctx_priority'),
 Extension('VK_EXT_sampler_filter_minmax', 1, 
'device->rad_info.chip_class >= CIK'),
+Extension('VK_EXT_shader_viewport_index_layer',   1, True),
 Extension('VK_AMD_draw_indirect_count',   1, True),
 Extension('VK_AMD_gcn_shader',1, True),
 Extension('VK_AMD_rasterization_order',   1, 
'device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2'),
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index f150a20e3b..f46beab8c1 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -217,6 +217,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
.variable_pointers = true,
.gcn_shader = true,
.trinary_minmax = true,
+   .shader_viewport_index_layer = true,
},
};
entry_point = spirv_to_nir(spirv, module->size / 4,
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Kyriazis, George]

Please use LLVM defines consistent with the surrounding code.  Surrounding code 
uses LLVM_VERSION_MAJOR / LLVM_VERSION_MINOR.

This code should then be:

#if LLVM_VERSION_MAJOR >= 7
…
#endif

Thank you!

George

> On Apr 1, 2018, at 3:05 PM, Vinson Lee  wrote:
> 
> On Sun, Apr 1, 2018 at 1:10 AM, Mike Lothian  wrote:
>> Include llvm/Transforms/Utils.h with the newest LLVM 7
>> 
>> Signed-of-by: Mike Lothian 
>> ---
>> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
>> b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
>> index 031bced8a0..d726d4844e 100644
>> --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
>> +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
>> @@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
>> #include "llvm/Support/DynamicLibrary.h"
>> #include "llvm/Transforms/IPO.h"
>> #include "llvm/Transforms/Scalar.h"
>> +#if HAVE_LLVM >= 0x0700
>> +#include 
>> +#endif
>> #include "llvm/Support/Host.h"
>> #include "llvm/Support/DynamicLibrary.h"
>> 
>> --
>> 2.16.3
>> 
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
> The added include uses <> delimiters whereas the other includes use ""
> delimiters.
> 
> Tested-by: Vinson Lee 

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

[Mesa-dev] [PATCH 2/5] i965: replace calls to dup(2) with fcntl(F_DUPFD_CLOEXEC)

[Matt Whitlock]

Without this fix, duplicated file descriptors leak into child processes.
See commit aaac913e901229d11a1894f6aaf646de6b1a542c for one instance
where the same fix was employed.

Signed-off-by: Matt Whitlock 
---
 src/mesa/drivers/dri/i965/brw_sync.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_sync.c 
b/src/mesa/drivers/dri/i965/brw_sync.c
index 6391648879..98abab03b7 100644
--- a/src/mesa/drivers/dri/i965/brw_sync.c
+++ b/src/mesa/drivers/dri/i965/brw_sync.c
@@ -502,7 +502,7 @@ brw_dri_create_fence_fd(__DRIcontext *dri_ctx, int fd)
  goto fail;
} else {
   /* Import the sync fd as an in-fence. */
-  fence->sync_fd = dup(fd);
+  fence->sync_fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
}
 
assert(fence->sync_fd != -1);
@@ -519,7 +519,7 @@ static int
 brw_dri_get_fence_fd_locked(struct brw_fence *fence)
 {
assert(fence->type == BRW_FENCE_TYPE_SYNC_FD);
-   return dup(fence->sync_fd);
+   return fcntl(fence->sync_fd, F_DUPFD_CLOEXEC, 3);
 }
 
 static int
-- 
2.16.3

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

[Mesa-dev] [PATCH 1/5] egl/dri2: replace call to dup(2) with fcntl(F_DUPFD_CLOEXEC)

[Matt Whitlock]

Without this fix, duplicated file descriptors leak into child processes.
See commit aaac913e901229d11a1894f6aaf646de6b1a542c for one instance
where the same fix was employed.

Signed-off-by: Matt Whitlock 
---
 src/egl/drivers/dri2/egl_dri2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 45d0c7275c..f1919da3a0 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -3028,7 +3028,7 @@ dri2_dup_native_fence_fd(_EGLDriver *drv, _EGLDisplay 
*dpy, _EGLSync *sync)
   return EGL_NO_NATIVE_FENCE_FD_ANDROID;
}
 
-   return dup(sync->SyncFd);
+   return fcntl(sync->SyncFd, F_DUPFD_CLOEXEC, 3);
 }
 
 static void
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Stuart Young]

Hi Sergii,

I built this into mesa 17.3.7 and it seems to solve all the issues I've
seen that were mentioned in 101408.

This includes not just the issues with the Mortar, but the other visual
artefacts that I've noticed with the player models and with other weapons
in the game.

Many thanks for digging into this.


On 26 March 2018 at 23:22, Sergii Romantsov <
sergii.romant...@globallogic.com> wrote:

> Hello, Stuart.
> Could You, please, test this patch?
>
> On Mon, Mar 26, 2018 at 3:16 PM, Sergii Romantsov <
> sergii.romant...@gmail.com> wrote:
>
>> Negative deltas are used to fake a range in a large buffer.
>> See 900a5c91eeb3
>> "i965: Use negative relocation deltas to minimise vertex uploads"
>>
>> Gen8+ use 48-bit address relocations so need to extend the sign
>> to 64-bit return value. Without it we have higher bits zeroed
>> and missing the negavive values.
>> Haswell and older use 32-bit deltas so are unaffected by this issue.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
>> Signed-off-by: Sergii Romantsov 
>> Tested-by: Andriy Khulap 
>> ---
>>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> index d824ff2..128da77 100644
>> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
>> /* Using the old buffer offset, write in what the right data would
>> be, in
>>  * case the buffer doesn't move and we can short-circuit the
>> relocation
>>  * processing in the kernel
>> +*
>> +* Some target_offsets may be negative, so extend the sign to 64 bits.
>>  */
>> -   return entry->offset + target_offset;
>> +   return entry->offset + (int64_t)((int32_t)target_offset);
>>  }
>>
>>  uint64_t
>> --
>> 2.7.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
> --
> Sergii Romantsov
> GlobalLogic Inc.
> www.globallogic.com
>



-- 
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] freedreno: replace calls to dup(2) with fcntl(F_DUPFD_CLOEXEC)

[Matt Whitlock]

Without this fix, duplicated file descriptors leak into child processes.
See commit aaac913e901229d11a1894f6aaf646de6b1a542c for one instance
where the same fix was employed.

Signed-off-by: Matt Whitlock 
---
 src/gallium/drivers/freedreno/freedreno_fence.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_fence.c 
b/src/gallium/drivers/freedreno/freedreno_fence.c
index 1925f726a2..e49c276f29 100644
--- a/src/gallium/drivers/freedreno/freedreno_fence.c
+++ b/src/gallium/drivers/freedreno/freedreno_fence.c
@@ -124,7 +124,7 @@ void fd_create_fence_fd(struct pipe_context *pctx,
enum pipe_fd_type type)
 {
assert(type == PIPE_FD_TYPE_NATIVE_SYNC);
-   *pfence = fence_create(fd_context(pctx), NULL, 0, dup(fd));
+   *pfence = fence_create(fd_context(pctx), NULL, 0, fcntl(fd, 
F_DUPFD_CLOEXEC, 3));
 }
 
 void fd_fence_server_sync(struct pipe_context *pctx,
@@ -144,7 +144,7 @@ int fd_fence_get_fd(struct pipe_screen *pscreen,
struct pipe_fence_handle *fence)
 {
fence_flush(fence);
-   return dup(fence->fence_fd);
+   return fcntl(fence->fence_fd, F_DUPFD_CLOEXEC, 3);
 }
 
 struct pipe_fence_handle * fd_fence_create(struct fd_batch *batch)
-- 
2.16.3

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

[Mesa-dev] [PATCH 4/5] etnaviv: replace calls to dup(2) with fcntl(F_DUPFD_CLOEXEC)

[Matt Whitlock]

Without this fix, duplicated file descriptors leak into child processes.
See commit aaac913e901229d11a1894f6aaf646de6b1a542c for one instance
where the same fix was employed.

Signed-off-by: Matt Whitlock 
---
 src/gallium/drivers/etnaviv/etnaviv_fence.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_fence.c 
b/src/gallium/drivers/etnaviv/etnaviv_fence.c
index 22a964ad28..594fa7e76d 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_fence.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_fence.c
@@ -80,7 +80,7 @@ etna_create_fence_fd(struct pipe_context *pctx,
  enum pipe_fd_type type)
 {
assert(type == PIPE_FD_TYPE_NATIVE_SYNC);
-   *pfence = etna_fence_create(pctx, dup(fd));
+   *pfence = etna_fence_create(pctx, fcntl(fd, F_DUPFD_CLOEXEC, 3));
 }
 
 void
@@ -96,7 +96,7 @@ static int
 etna_screen_fence_get_fd(struct pipe_screen *pscreen,
  struct pipe_fence_handle *pfence)
 {
-   return dup(pfence->fence_fd);
+   return fcntl(pfence->fence_fd, F_DUPFD_CLOEXEC, 3);
 }
 
 struct pipe_fence_handle *
-- 
2.16.3

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

[Mesa-dev] [PATCH 3/5] winsys/svga/drm: replace calls to dup(2) with fcntl(F_DUPFD_CLOEXEC)

[Matt Whitlock]

Without this fix, duplicated file descriptors leak into child processes.
See commit aaac913e901229d11a1894f6aaf646de6b1a542c for one instance
where the same fix was employed.

Signed-off-by: Matt Whitlock 
---
 src/gallium/winsys/svga/drm/vmw_screen_svga.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_svga.c 
b/src/gallium/winsys/svga/drm/vmw_screen_svga.c
index 7c80642b37..d35cdf9d6a 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_svga.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_svga.c
@@ -139,7 +139,7 @@ vmw_svga_winsys_fence_get_fd(struct svga_winsys_screen *sws,
  boolean duplicate)
 {
if (duplicate)
-  return dup(vmw_fence_get_fd(fence));
+  return fcntl(vmw_fence_get_fd(fence), F_DUPFD_CLOEXEC, 3);
else
   return vmw_fence_get_fd(fence);
 }
@@ -150,7 +150,7 @@ vmw_svga_winsys_fence_create_fd(struct svga_winsys_screen 
*sws,
 struct pipe_fence_handle **fence,
 int32_t fd)
 {
-   *fence = vmw_fence_create(NULL, 0, 0, 0, dup(fd));
+   *fence = vmw_fence_create(NULL, 0, 0, 0, fcntl(fd, F_DUPFD_CLOEXEC, 3));
 }
 
 static int
-- 
2.16.3

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7 - was [meta-raspberrypi] VC4 not working for me with mesa 17.3.7

[Andreas Müller]

On Mon, Apr 2, 2018 at 2:42 PM, Daniel Stone  wrote:
> Hi Andreas,
>
> On 31 March 2018 at 15:18, Andreas Müller  wrote:
>> Thanks for prompt an VERY helpful support. I did:
>>
>> * Check my configure and found: --disable-dri3!
>> * Tested your patch (with --disable-dri3) and as expected it fixes the issue
>> * Found what causes --disable-dri3 - it came in by the Openembedded
>> update mentioned in first email. FWIW: I use a fork for
>> meta-raspberrypi - the original is not affected so I am the only one
>> with this issue...
>
> Glad to hear it!
>
>> I have two questions related to dri2/your patch (sorry asking for more :)
>>
>> 1. Your patch fixes improper initialized variable. Do you think it is
>> worth being applied?
>
> Yes, definitely: I've sent it in now. It's sadly missed 17.3.8
> (scheduled to be released about an hour ago), but hopefully we can get
> it in for a 17.3.9, if we have one. Else it'll be in 18.0.1.
>
>> 2. In the thread I mentioned in my first email Trevor mentioned that
>> he has seen error message 'Modifier 0x0 vs. tiling(0x7001)
>> mismatch' when trying to get chromium GLES accelerated. Maybe a stupid
>> question but is it possible that applications running at X can ask for
>> dri2 explicitly?
>
> He said that only happened when using the system (rather than bundled)
> libraries, which would presumably be using DRI2 by default. I've
> submitted a bug to OE to ask them to enable DRI3 by default, but in
> the meantime this Mesa fix should hopefully work anyway.
Thanks - I was thinking same. OE-Core enables DRI3 for x11 AND vulcan
only - and vulcan is not in my distro features (and does not make much
sense for VC4)

Added yocto mailing list to merge both threads together and avoid cross-tak.

Thanks again for taking care

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

Re: [Mesa-dev] [PATCH V2 kmscube] cube-tex: make use of modifiers

[Daniel Stone]

Hi Christian,

On 2 April 2018 at 12:49, Christian Gmeiner  wrote:
> Fixes rendering issues with mode rgba on etnaviv. I have applied
> the same change for nv12 variants but they are not supported on
> etnaviv.
>
> [...]
>
> +   EGLint attr[] = {
> EGL_WIDTH, texw,
> EGL_HEIGHT, texh,
> EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_ABGR,
> EGL_DMA_BUF_PLANE0_FD_EXT, fd,
> EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
> EGL_DMA_BUF_PLANE0_PITCH_EXT, stride,
> +   EGL_NONE, EGL_NONE, /* modifier lo */
> +   EGL_NONE, EGL_NONE, /* modifier hi */
> EGL_NONE
> };
> +
> +   if (egl->modifiers_supported) {
> +   unsigned size =  ARRAY_SIZE(attr);
> +   attr[size - 5] = EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT;
> +   attr[size - 4] = modifier & 0x;
> +   attr[size - 3] = EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT;
> +   attr[size - 2] = modifier >> 32;
> +   }

All these checks should be 'if (egl->modifiers_supported && modifier
!= DRM_FORMAT_MOD_INVALID)'.

With that fixed, and I suppose with the same weak-symbol handling as
the others, this is:
Reviewed-by: Daniel Stone 

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

Re: [Mesa-dev] [PATCH] RFC: Externd IMG_context_priority with NV_context_priority_realtime

[Daniel Stone]

On 30 March 2018 at 19:20, Kenneth Graunke  wrote:
> On Friday, March 30, 2018 7:40:13 AM PDT Chris Wilson wrote:
>> For i915, we are proposing to use a quality-of-service parameter in
>> addition to that of just a priority that usurps everyone. Due to our HW,
>> preemption may not be immediate and will be forced to wait until an
>> uncooperative process hits an arbitration point. To prevent that unduly
>> impacting the privileged RealTime context, we back up the preemption
>> request with a timeout to reset the GPU and forcibly evict the GPU hog
>> in order to execute the new context.
>
> I am strongly against exposing this in general.  Performing a GPU reset
> in the middle of a batch can completely screw up whatever application
> was running.  If the application is using robustness extensions, we may
> be forced to return GL_DEVICE_LOST, causing the application to have to
> recreate their entire GL context and start over.  If not, we may try to
> let them limp on(*) - and hope they didn't get too badly damaged by some
> of their commands not executing, or executing twice (if the kernel tries
> to resubmit it).  But it may very well cause the app to misrender, or
> even crash.
>
> This seems like a crazy plan to me.  Scheduling has never been allowed
> to just kill random processes.  If you ever hit that case, then your
> customers will see random application crashes, glitches, GPU hangs,
> and be pretty unhappy with the result.  And not because something was
> broken, but because somebody was impatient and an app was a bit slow.
>
> If you have work that is so mission critical, maybe you shouldn't run it
> on the same machine as one that runs applications which you care so
> little about that you're willing to watch them crash and burn.  Don't
> run the entertainment system on the flight computer, so to speak.

I don't know what the automotive correspondent of 'that boat has
already sailed is', but that car has already driven (under the control
of those guys in Wired). For better or worse, having infotainment and
cluster UI run on single silicon is incredibly common nowadays.
Virtualisation platforms have been big business for a while now, and
GPU sharing is absolutely something which is happening as part of
that.

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

Re: [Mesa-dev] VC4 not working for me with mesa 17.3.7

[Daniel Stone]

Hi Andreas,

On 31 March 2018 at 15:18, Andreas Müller  wrote:
> Thanks for prompt an VERY helpful support. I did:
>
> * Check my configure and found: --disable-dri3!
> * Tested your patch (with --disable-dri3) and as expected it fixes the issue
> * Found what causes --disable-dri3 - it came in by the Openembedded
> update mentioned in first email. FWIW: I use a fork for
> meta-raspberrypi - the original is not affected so I am the only one
> with this issue...

Glad to hear it!

> I have two questions related to dri2/your patch (sorry asking for more :)
>
> 1. Your patch fixes improper initialized variable. Do you think it is
> worth being applied?

Yes, definitely: I've sent it in now. It's sadly missed 17.3.8
(scheduled to be released about an hour ago), but hopefully we can get
it in for a 17.3.9, if we have one. Else it'll be in 18.0.1.

> 2. In the thread I mentioned in my first email Trevor mentioned that
> he has seen error message 'Modifier 0x0 vs. tiling(0x7001)
> mismatch' when trying to get chromium GLES accelerated. Maybe a stupid
> question but is it possible that applications running at X can ask for
> dri2 explicitly?

He said that only happened when using the system (rather than bundled)
libraries, which would presumably be using DRI2 by default. I've
submitted a bug to OE to ask them to enable DRI3 by default, but in
the meantime this Mesa fix should hopefully work anyway.

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.8 release candidate

[Daniel Stone]

Hi Juan,

On 29 March 2018 at 11:25, Juan A. Suarez Romero  wrote:
> The plan is to have 17.3.8 this Monday (2nd April), around or shortly after 
> 11:00
> GMT.

Does this mean we could expect 17.3.9 in a couple of weeks, or is this
the last release for the 17.3.x branch?

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

[Mesa-dev] [Bug 105847] Profile GL3bc is not available on X11GraphicsDevice

[bugzilla-daemon]

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

Bug ID: 105847
   Summary: Profile GL3bc is not available on X11GraphicsDevice
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: aidan.wal...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

I'm running the latest mesa drivers for radeon using Obilaf's ppa: on Ubuntu
17.10.

glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 4.5
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.1 Mesa 18.1.0-devel
OpenGL shading language version string: 1.40
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10


I'm trying to run Scilab, which previously worked with an Nvidia graphics card.

Since I changed to Radeon, Scilab graphics are broken. Scilab have an old
issue:
https://wiki.scilab.org/Graphical%20issues%20with%20Scilab%205.X

Which relates to a lack of pbuffer support, but I think this is not related.
However the workaround they suggest does not help.

I have tested with glxgears that both software and hardware based OpenGL
function on my system by toggling the LIBGL_ALWAYS_SOFTWARE=1 env variable and
with Scilab it makes no difference.

I see from scilab debug logging that the java jogl call fails:

Caused by: com.jogamp.opengl.GLException: Profile GL3bc is not available on
X11GraphicsDevice[type .x11, connection :1, unitID 0, handle 0x7f6b4c766120,
owner true, ResourceToolkitLock[obj 0x21c3eea, isOwner true, [count 1, qsz 0, owner ]]], but:
[GLProfile[GLES1/GLES1.hw], GLProfile[GLES2/GLES3.hw],
GLProfile[GL2ES1/GLES1.hw], GLProfile[GL4ES3/GL4.hw], GLProfile[GL2ES2/GL4.hw],
GLProfile[GL4/GL4.hw], GLProfile[GLES3/GLES3.hw], GLProfile[GL4/GL4.hw],
GLProfile[GL3/GL4.hw], GLProfile[GL2GL3/GL4.hw]]

So even though the driver offers support for a version of OpenGL above this,
the profile required here does not seem to be available.

I have no knowledge of how these profiles are translated between the graphics
driver (Mesa) and what X11 offers to clients. But clearly there is a problem.

Any help appreciated, and apologies if this is an obvious problem elsewhere
that is simply my lack of understanding, but still as it does not work

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

[Mesa-dev] [PATCH] st/dri: Initialise modifier to INVALID for DRI2

[Daniel Stone]

When allocating a buffer for DRI2, set the modifier to INVALID to inform
the backend that we have no supplied modifiers and it should do its own
thing. The missed initialisation forced linear, even if the
implementation had made other decisions.

This resulted in VC4 DRI2 clients failing with:
  Modifier 0x0 vs. tiling (0x701) mismatch

Signed-off-by: Daniel Stone 
Reported-by: Andreas Müller 
Fixes: 3f8513172ff6 ("gallium/winsys/drm: introduce modifier field to 
winsys_handle")
---
 src/gallium/state_trackers/dri/dri2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 31d17d46c29..58a6757f037 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -806,6 +806,7 @@ dri2_allocate_textures(struct dri_context *ctx,
  whandle.handle = buf->name;
  whandle.stride = buf->pitch;
  whandle.offset = 0;
+ whandle.modifier = DRM_FORMAT_MOD_INVALID;
  if (screen->can_share_buffer)
 whandle.type = DRM_API_HANDLE_TYPE_SHARED;
  else
-- 
2.16.2

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

[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675

[bugzilla-daemon]

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

--- Comment #3 from l...@protonmail.ch ---
Can't upload attachment here; got 500 internal server error.

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

[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675

[bugzilla-daemon]

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

--- Comment #2 from l...@protonmail.ch ---
link to coredump (also uploading as attachment):
https://doc-0o-4k-docs.googleusercontent.com/docs/securesc/pum26a1iie2onuvj4oi878g6cm4t7ee5/ogcgqid4h8vlgsdm101jckd6jo5jqqc5/152266320/00738005966732616001/00738005966732616001/11no6HF0WfEwwlE2IoeMx6aigsJ-504qp?e=download=lohv7ot3cnbqm=00738005966732616001=29id47ascb0lesgtto26eu8r8cmsptdn

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

[Mesa-dev] [PATCH V2 kmscube] cube-tex: make use of modifiers

[Christian Gmeiner]

Fixes rendering issues with mode rgba on etnaviv. I have applied
the same change for nv12 variants but they are not supported on
etnaviv.

Signed-off-by: Christian Gmeiner 
---
 common.c   |  3 +++
 common.h   | 19 +
 cube-tex.c | 91 +-
 3 files changed, 101 insertions(+), 12 deletions(-)

diff --git a/common.c b/common.c
index 1d97c91..faecd42 100644
--- a/common.c
+++ b/common.c
@@ -216,6 +216,9 @@ int init_egl(struct egl *egl, const struct gbm *gbm)
get_proc_dpy(EGL_KHR_fence_sync, eglClientWaitSyncKHR);
get_proc_dpy(EGL_ANDROID_native_fence_sync, eglDupNativeFenceFDANDROID);
 
+   egl->modifiers_supported = has_ext(egl_exts_dpy,
+  
"EGL_EXT_image_dma_buf_import_modifiers");
+
printf("Using display %p with EGL version %d.%d\n",
egl->display, major, minor);
 
diff --git a/common.h b/common.h
index 42eb236..898010d 100644
--- a/common.h
+++ b/common.h
@@ -31,6 +31,7 @@
 
 #include 
 #include 
+#include 
 
 #ifndef DRM_FORMAT_MOD_LINEAR
 #define DRM_FORMAT_MOD_LINEAR 0
@@ -59,6 +60,22 @@ EGLAPI EGLSurface EGLAPIENTRY 
eglCreatePlatformPixmapSurfaceEXT (EGLDisplay dpy,
 
 #define WEAK __attribute__((weak))
 
+/* Define tokens from EGL_EXT_image_dma_buf_import_modifiers */
+#ifndef EGL_EXT_image_dma_buf_import_modifiers
+#define EGL_EXT_image_dma_buf_import_modifiers 1
+#define EGL_DMA_BUF_PLANE3_FD_EXT 0x3440
+#define EGL_DMA_BUF_PLANE3_OFFSET_EXT 0x3441
+#define EGL_DMA_BUF_PLANE3_PITCH_EXT  0x3442
+#define EGL_DMA_BUF_PLANE0_MODIFIER_LO_EXT 0x3443
+#define EGL_DMA_BUF_PLANE0_MODIFIER_HI_EXT 0x3444
+#define EGL_DMA_BUF_PLANE1_MODIFIER_LO_EXT 0x3445
+#define EGL_DMA_BUF_PLANE1_MODIFIER_HI_EXT 0x3446
+#define EGL_DMA_BUF_PLANE2_MODIFIER_LO_EXT 0x3447
+#define EGL_DMA_BUF_PLANE2_MODIFIER_HI_EXT 0x3448
+#define EGL_DMA_BUF_PLANE3_MODIFIER_LO_EXT 0x3449
+#define EGL_DMA_BUF_PLANE3_MODIFIER_HI_EXT 0x344A
+#endif
+
 struct gbm {
struct gbm_device *dev;
struct gbm_surface *surface;
@@ -85,6 +102,8 @@ struct egl {
PFNEGLCLIENTWAITSYNCKHRPROC eglClientWaitSyncKHR;
PFNEGLDUPNATIVEFENCEFDANDROIDPROC eglDupNativeFenceFDANDROID;
 
+   bool modifiers_supported;
+
void (*draw)(unsigned i);
 };
 
diff --git a/cube-tex.c b/cube-tex.c
index 9e38ae8..71916e3 100644
--- a/cube-tex.c
+++ b/cube-tex.c
@@ -29,6 +29,7 @@
 #include "common.h"
 #include "esUtil.h"
 
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
 struct {
struct egl egl;
@@ -213,7 +214,10 @@ static const char *fragment_shader_source_2img =
 
 static const uint32_t texw = 512, texh = 512;
 
-static int get_fd_rgba(uint32_t *pstride)
+WEAK uint64_t
+gbm_bo_get_modifier(struct gbm_bo *bo);
+
+static int get_fd_rgba(uint32_t *pstride, uint64_t *modifier)
 {
struct gbm_bo *bo;
void *map_data = NULL;
@@ -235,6 +239,11 @@ static int get_fd_rgba(uint32_t *pstride)
 
fd = gbm_bo_get_fd(bo);
 
+   if (gbm_bo_get_modifier)
+   *modifier = gbm_bo_get_modifier(bo);
+   else
+   *modifier = DRM_FORMAT_MOD_LINEAR;
+
/* we have the fd now, no longer need the bo: */
gbm_bo_destroy(bo);
 
@@ -243,7 +252,7 @@ static int get_fd_rgba(uint32_t *pstride)
return fd;
 }
 
-static int get_fd_y(uint32_t *pstride)
+static int get_fd_y(uint32_t *pstride, uint64_t *modifier)
 {
struct gbm_bo *bo;
void *map_data = NULL;
@@ -265,6 +274,11 @@ static int get_fd_y(uint32_t *pstride)
 
fd = gbm_bo_get_fd(bo);
 
+   if (gbm_bo_get_modifier)
+   *modifier = gbm_bo_get_modifier(bo);
+   else
+   *modifier = DRM_FORMAT_MOD_LINEAR;
+
/* we have the fd now, no longer need the bo: */
gbm_bo_destroy(bo);
 
@@ -273,7 +287,7 @@ static int get_fd_y(uint32_t *pstride)
return fd;
 }
 
-static int get_fd_uv(uint32_t *pstride)
+static int get_fd_uv(uint32_t *pstride, uint64_t *modifier)
 {
struct gbm_bo *bo;
void *map_data = NULL;
@@ -295,6 +309,11 @@ static int get_fd_uv(uint32_t *pstride)
 
fd = gbm_bo_get_fd(bo);
 
+   if (gbm_bo_get_modifier)
+   *modifier = gbm_bo_get_modifier(bo);
+   else
+   *modifier = DRM_FORMAT_MOD_LINEAR;
+
/* we have the fd now, no longer need the bo: */
gbm_bo_destroy(bo);
 
@@ -306,16 +325,27 @@ static int get_fd_uv(uint32_t *pstride)
 static int init_tex_rgba(void)
 {
uint32_t stride;
-   int fd = get_fd_rgba();
-   const EGLint attr[] = {
+   uint64_t modifier;
+   int fd = get_fd_rgba(, );
+   EGLint attr[] = {
EGL_WIDTH, texw,
EGL_HEIGHT, texh,
EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_ABGR,
EGL_DMA_BUF_PLANE0_FD_EXT, fd,
EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,

Re: [Mesa-dev] [PATCH kmscube 2/2] Use weak functions to handle lack of gbm modifiers

[Rob Clark]

On Fri, Mar 30, 2018 at 10:17 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Add weak function declaration and check if they're valid prior
> to calling the functions.
>
> This allows us to remove conditional compilation, yet allowing the
> modifiers codepath to work if API is available.
>
> Cc: Christian Gmeiner 
> Cc: Rob Clark 
> Signed-off-by: Emil Velikov 

Reviewed-by: Rob Clark 

> ---
>  common.c | 32 +---
>  common.h |  2 ++
>  configure.ac | 16 
>  drm-common.c | 49 -
>  4 files changed, 55 insertions(+), 44 deletions(-)
>
> diff --git a/common.c b/common.c
> index 332e3e9..1d97c91 100644
> --- a/common.c
> +++ b/common.c
> @@ -33,23 +33,33 @@
>
>  static struct gbm gbm;
>
> +WEAK struct gbm_surface *
> +gbm_surface_create_with_modifiers(struct gbm_device *gbm,
> +  uint32_t width, uint32_t height,
> +  uint32_t format,
> +  const uint64_t *modifiers,
> +  const unsigned int count);
> +
>  const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier)
>  {
> gbm.dev = gbm_create_device(drm_fd);
> gbm.format = GBM_FORMAT_XRGB;
>
> -#ifndef HAVE_GBM_MODIFIERS
> -   if (modifier != DRM_FORMAT_MOD_LINEAR) {
> -   fprintf(stderr, "Modifiers requested but support isn't 
> available\n");
> -   return NULL;
> +   if (gbm_surface_create_with_modifiers) {
> +   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
> +   gbm.format,
> +   , 1);
> +
> +   } else {
> +   if (modifier != DRM_FORMAT_MOD_LINEAR) {
> +   fprintf(stderr, "Modifiers requested but support 
> isn't available\n");
> +   return NULL;
> +   }
> +   gbm.surface = gbm_surface_create(gbm.dev, w, h,
> +   gbm.format,
> +   GBM_BO_USE_SCANOUT | 
> GBM_BO_USE_RENDERING);
> +
> }
> -   gbm.surface = gbm_surface_create(gbm.dev, w, h,
> -   gbm.format,
> -   GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
> -#else
> -   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
> -   gbm.format, , 1);
> -#endif
>
> if (!gbm.surface) {
> printf("failed to create gbm surface\n");
> diff --git a/common.h b/common.h
> index dc87825..42eb236 100644
> --- a/common.h
> +++ b/common.h
> @@ -57,6 +57,8 @@ EGLAPI EGLSurface EGLAPIENTRY 
> eglCreatePlatformPixmapSurfaceEXT (EGLDisplay dpy,
>  #endif
>  #endif /* EGL_EXT_platform_base */
>
> +#define WEAK __attribute__((weak))
> +
>  struct gbm {
> struct gbm_device *dev;
> struct gbm_surface *surface;
> diff --git a/configure.ac b/configure.ac
> index 8397f7b..5a63afb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -49,21 +49,5 @@ if test "x$HAVE_GST" = "xyes"; then
>  fi
>  AM_CONDITIONAL(ENABLE_GST, [test "x$HAVE_GST" = "xyes"])
>
> -AC_CHECK_LIB([gbm], [gbm_bo_get_modifier], [gbm_modifiers=yes], [])
> -
> -AC_ARG_ENABLE([gbm-modifiers],
> - [AS_HELP_STRING([--enable-gbm-modifiers],
> - [enable using GBM modifiers @<:@default=auto@:>@])],
> - [enable_gbm_modifiers="$enableval"],
> - [enable_gbm_modifiers=auto])
> -
> -if test "x$enable_gbm_modifiers" = xyes -a "x$gbm_modifiers" != xyes; then
> -   AC_MSG_ERROR([Cannot find gbm modifier supported mesa])
> -fi
> -
> -if test "x$enable_gbm_modifiers" = xyes; then
> -   AC_DEFINE(HAVE_GBM_MODIFIERS, 1, [Define if you can use GBM 
> properties.])
> -fi
> -
>  AC_CONFIG_FILES([Makefile])
>  AC_OUTPUT
> diff --git a/drm-common.c b/drm-common.c
> index 1ec2820..136fe69 100644
> --- a/drm-common.c
> +++ b/drm-common.c
> @@ -31,6 +31,18 @@
>  #include "common.h"
>  #include "drm-common.h"
>
> +WEAK uint64_t
> +gbm_bo_get_modifier(struct gbm_bo *bo);
> +
> +WEAK int
> +gbm_bo_get_plane_count(struct gbm_bo *bo);
> +
> +WEAK uint32_t
> +gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int plane);
> +
> +WEAK uint32_t
> +gbm_bo_get_offset(struct gbm_bo *bo, int plane);
> +
>  static void
>  drm_fb_destroy_callback(struct gbm_bo *bo, void *data)
>  {
> @@ -62,26 +74,29 @@ struct drm_fb * drm_fb_get_from_bo(struct gbm_bo *bo)
> height = gbm_bo_get_height(bo);
> format = gbm_bo_get_format(bo);
>
> -#ifdef HAVE_GBM_MODIFIERS
> -   uint64_t modifiers[4] = {0};
> -   modifiers[0] = gbm_bo_get_modifier(bo);
> -   const int 

Re: [Mesa-dev] [PATCH kmscube 1/2] Rework default modifier handling

[Rob Clark]

On Fri, Mar 30, 2018 at 10:17 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Currently the default modifier is MOD_INVALID. At a later stage, if the
> modifier is the same (the user may have explicit selected MOD_INVALID),
> we'll fallback to MOD_LINEAR.
>
> Simplify things to a) use MOD_LINEAR by default b) use the user modifier
> - even if they request MOD_INVALID.
>
> Signed-off-by: Emil Velikov 

Reviewed-by: Rob Clark 

> ---
>  common.c  | 23 ++-
>  kmscube.c |  2 +-
>  2 files changed, 3 insertions(+), 22 deletions(-)
>
> diff --git a/common.c b/common.c
> index a092cdb..332e3e9 100644
> --- a/common.c
> +++ b/common.c
> @@ -33,24 +33,13 @@
>
>  static struct gbm gbm;
>
> -#ifdef HAVE_GBM_MODIFIERS
> -static int
> -get_modifiers(uint64_t **mods)
> -{
> -   /* Assumed LINEAR is supported everywhere */
> -   static uint64_t modifiers[] = {DRM_FORMAT_MOD_LINEAR};
> -   *mods = modifiers;
> -   return 1;
> -}
> -#endif
> -
>  const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier)
>  {
> gbm.dev = gbm_create_device(drm_fd);
> gbm.format = GBM_FORMAT_XRGB;
>
>  #ifndef HAVE_GBM_MODIFIERS
> -   if (modifier != DRM_FORMAT_MOD_INVALID) {
> +   if (modifier != DRM_FORMAT_MOD_LINEAR) {
> fprintf(stderr, "Modifiers requested but support isn't 
> available\n");
> return NULL;
> }
> @@ -58,16 +47,8 @@ const struct gbm * init_gbm(int drm_fd, int w, int h, 
> uint64_t modifier)
> gbm.format,
> GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
>  #else
> -   uint64_t *mods;
> -   int count;
> -   if (modifier != DRM_FORMAT_MOD_INVALID) {
> -   count = 1;
> -   mods = 
> -   } else {
> -   count = get_modifiers();
> -   }
> gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
> -   gbm.format, mods, count);
> +   gbm.format, , 1);
>  #endif
>
> if (!gbm.surface) {
> diff --git a/kmscube.c b/kmscube.c
> index 3a2c4dd..87a4205 100644
> --- a/kmscube.c
> +++ b/kmscube.c
> @@ -76,7 +76,7 @@ int main(int argc, char *argv[])
> const char *device = "/dev/dri/card0";
> const char *video = NULL;
> enum mode mode = SMOOTH;
> -   uint64_t modifier = DRM_FORMAT_MOD_INVALID;
> +   uint64_t modifier = DRM_FORMAT_MOD_LINEAR;
> int atomic = 0;
> int opt;
>
> --
> 2.16.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675

[bugzilla-daemon]

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

--- Comment #1 from l...@protonmail.ch ---
Created attachment 138489
  --> https://bugs.freedesktop.org/attachment.cgi?id=138489=edit
glxinfo for 0b73c8

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

[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675

[bugzilla-daemon]

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

Bug ID: 105846
   Summary: Assertion failure @ st_atom_array.c:675
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: have-backtrace
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: l...@protonmail.ch
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 138488
  --> https://bugs.freedesktop.org/attachment.cgi?id=138488=edit
glxinfo for 17.3.7

When running the game Natural Selection 2
(http://store.steampowered.com/app/4920/), I will eventually encounter an
assertion failure src/mesa/state_tracker/st_atom_array.c:675
(assert(attrib->Ptr)).

I have tried version 17.3.7 and also manually compiling mesa at commit 0b73c8.

I'm running the game with mesa_glthread=true and vblank_mode=0, haven't tried
without yet.

I am also using amdgpu driver, instead of the default radeon one for my GPU (R9
280).

I haven't yet noticed any pattern, but considering the quality of the game's
support for Linux, I assume Mesa didn't catch an invalid use of the API.

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

Re: [Mesa-dev] [PATCH kmscube 2/2] Use weak functions to handle lack of gbm modifiers

[Christian Gmeiner]

2018-03-30 16:17 GMT+02:00 Emil Velikov :
> From: Emil Velikov 
>
> Add weak function declaration and check if they're valid prior
> to calling the functions.
>
> This allows us to remove conditional compilation, yet allowing the
> modifiers codepath to work if API is available.
>
> Cc: Christian Gmeiner 
> Cc: Rob Clark 
> Signed-off-by: Emil Velikov 

Reviewed-by: Christian Gmeiner 

> ---
>  common.c | 32 +---
>  common.h |  2 ++
>  configure.ac | 16 
>  drm-common.c | 49 -
>  4 files changed, 55 insertions(+), 44 deletions(-)
>
> diff --git a/common.c b/common.c
> index 332e3e9..1d97c91 100644
> --- a/common.c
> +++ b/common.c
> @@ -33,23 +33,33 @@
>
>  static struct gbm gbm;
>
> +WEAK struct gbm_surface *
> +gbm_surface_create_with_modifiers(struct gbm_device *gbm,
> +  uint32_t width, uint32_t height,
> +  uint32_t format,
> +  const uint64_t *modifiers,
> +  const unsigned int count);
> +
>  const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier)
>  {
> gbm.dev = gbm_create_device(drm_fd);
> gbm.format = GBM_FORMAT_XRGB;
>
> -#ifndef HAVE_GBM_MODIFIERS
> -   if (modifier != DRM_FORMAT_MOD_LINEAR) {
> -   fprintf(stderr, "Modifiers requested but support isn't 
> available\n");
> -   return NULL;
> +   if (gbm_surface_create_with_modifiers) {
> +   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
> +   gbm.format,
> +   , 1);
> +
> +   } else {
> +   if (modifier != DRM_FORMAT_MOD_LINEAR) {
> +   fprintf(stderr, "Modifiers requested but support 
> isn't available\n");
> +   return NULL;
> +   }
> +   gbm.surface = gbm_surface_create(gbm.dev, w, h,
> +   gbm.format,
> +   GBM_BO_USE_SCANOUT | 
> GBM_BO_USE_RENDERING);
> +
> }
> -   gbm.surface = gbm_surface_create(gbm.dev, w, h,
> -   gbm.format,
> -   GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
> -#else
> -   gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
> -   gbm.format, , 1);
> -#endif
>
> if (!gbm.surface) {
> printf("failed to create gbm surface\n");
> diff --git a/common.h b/common.h
> index dc87825..42eb236 100644
> --- a/common.h
> +++ b/common.h
> @@ -57,6 +57,8 @@ EGLAPI EGLSurface EGLAPIENTRY 
> eglCreatePlatformPixmapSurfaceEXT (EGLDisplay dpy,
>  #endif
>  #endif /* EGL_EXT_platform_base */
>
> +#define WEAK __attribute__((weak))
> +
>  struct gbm {
> struct gbm_device *dev;
> struct gbm_surface *surface;
> diff --git a/configure.ac b/configure.ac
> index 8397f7b..5a63afb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -49,21 +49,5 @@ if test "x$HAVE_GST" = "xyes"; then
>  fi
>  AM_CONDITIONAL(ENABLE_GST, [test "x$HAVE_GST" = "xyes"])
>
> -AC_CHECK_LIB([gbm], [gbm_bo_get_modifier], [gbm_modifiers=yes], [])
> -
> -AC_ARG_ENABLE([gbm-modifiers],
> - [AS_HELP_STRING([--enable-gbm-modifiers],
> - [enable using GBM modifiers @<:@default=auto@:>@])],
> - [enable_gbm_modifiers="$enableval"],
> - [enable_gbm_modifiers=auto])
> -
> -if test "x$enable_gbm_modifiers" = xyes -a "x$gbm_modifiers" != xyes; then
> -   AC_MSG_ERROR([Cannot find gbm modifier supported mesa])
> -fi
> -
> -if test "x$enable_gbm_modifiers" = xyes; then
> -   AC_DEFINE(HAVE_GBM_MODIFIERS, 1, [Define if you can use GBM 
> properties.])
> -fi
> -
>  AC_CONFIG_FILES([Makefile])
>  AC_OUTPUT
> diff --git a/drm-common.c b/drm-common.c
> index 1ec2820..136fe69 100644
> --- a/drm-common.c
> +++ b/drm-common.c
> @@ -31,6 +31,18 @@
>  #include "common.h"
>  #include "drm-common.h"
>
> +WEAK uint64_t
> +gbm_bo_get_modifier(struct gbm_bo *bo);
> +
> +WEAK int
> +gbm_bo_get_plane_count(struct gbm_bo *bo);
> +
> +WEAK uint32_t
> +gbm_bo_get_stride_for_plane(struct gbm_bo *bo, int plane);
> +
> +WEAK uint32_t
> +gbm_bo_get_offset(struct gbm_bo *bo, int plane);
> +
>  static void
>  drm_fb_destroy_callback(struct gbm_bo *bo, void *data)
>  {
> @@ -62,26 +74,29 @@ struct drm_fb * drm_fb_get_from_bo(struct gbm_bo *bo)
> height = gbm_bo_get_height(bo);
> format = gbm_bo_get_format(bo);
>
> -#ifdef HAVE_GBM_MODIFIERS
> -   uint64_t modifiers[4] = {0};
> -   modifiers[0] = gbm_bo_get_modifier(bo);
> -   const int 

Re: [Mesa-dev] [PATCH kmscube 1/2] Rework default modifier handling

[Christian Gmeiner]

2018-03-30 16:17 GMT+02:00 Emil Velikov :
> From: Emil Velikov 
>
> Currently the default modifier is MOD_INVALID. At a later stage, if the
> modifier is the same (the user may have explicit selected MOD_INVALID),
> we'll fallback to MOD_LINEAR.
>
> Simplify things to a) use MOD_LINEAR by default b) use the user modifier
> - even if they request MOD_INVALID.
>
> Signed-off-by: Emil Velikov 

Reviewed-by: Christian Gmeiner 

> ---
>  common.c  | 23 ++-
>  kmscube.c |  2 +-
>  2 files changed, 3 insertions(+), 22 deletions(-)
>
> diff --git a/common.c b/common.c
> index a092cdb..332e3e9 100644
> --- a/common.c
> +++ b/common.c
> @@ -33,24 +33,13 @@
>
>  static struct gbm gbm;
>
> -#ifdef HAVE_GBM_MODIFIERS
> -static int
> -get_modifiers(uint64_t **mods)
> -{
> -   /* Assumed LINEAR is supported everywhere */
> -   static uint64_t modifiers[] = {DRM_FORMAT_MOD_LINEAR};
> -   *mods = modifiers;
> -   return 1;
> -}
> -#endif
> -
>  const struct gbm * init_gbm(int drm_fd, int w, int h, uint64_t modifier)
>  {
> gbm.dev = gbm_create_device(drm_fd);
> gbm.format = GBM_FORMAT_XRGB;
>
>  #ifndef HAVE_GBM_MODIFIERS
> -   if (modifier != DRM_FORMAT_MOD_INVALID) {
> +   if (modifier != DRM_FORMAT_MOD_LINEAR) {
> fprintf(stderr, "Modifiers requested but support isn't 
> available\n");
> return NULL;
> }
> @@ -58,16 +47,8 @@ const struct gbm * init_gbm(int drm_fd, int w, int h, 
> uint64_t modifier)
> gbm.format,
> GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
>  #else
> -   uint64_t *mods;
> -   int count;
> -   if (modifier != DRM_FORMAT_MOD_INVALID) {
> -   count = 1;
> -   mods = 
> -   } else {
> -   count = get_modifiers();
> -   }
> gbm.surface = gbm_surface_create_with_modifiers(gbm.dev, w, h,
> -   gbm.format, mods, count);
> +   gbm.format, , 1);
>  #endif
>
> if (!gbm.surface) {
> diff --git a/kmscube.c b/kmscube.c
> index 3a2c4dd..87a4205 100644
> --- a/kmscube.c
> +++ b/kmscube.c
> @@ -76,7 +76,7 @@ int main(int argc, char *argv[])
> const char *device = "/dev/dri/card0";
> const char *video = NULL;
> enum mode mode = SMOOTH;
> -   uint64_t modifier = DRM_FORMAT_MOD_INVALID;
> +   uint64_t modifier = DRM_FORMAT_MOD_LINEAR;
> int atomic = 0;
> int opt;
>
> --
> 2.16.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



-- 
greets
--
Christian Gmeiner, MSc

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

[Mesa-dev] [PATCH] compiler/spirv: set is_shadow for depth comparitor sampling opcodes

[Iago Toral Quiroga]

From the SPIR-V spec, OpTypeImage:

"Depth is whether or not this image is a depth image. (Note that
whether or not depth comparisons are actually done is a property of
the sampling opcode, not of this type declaration.)"

OpImageSample{Proj}Dref{Explicit,Implicit}Lod sampling opcodes always do
a depth comparison, regardless of the Depth property of the image type,
and as stated in the spec quote, this should be honored. For us, it means
that we always have to handle them as shadow sampling opcodes.

Fixes crashes in:
dEQP-VK.spirv_assembly.instruction.graphics.image_sampler.depth_property.*
---
 src/compiler/spirv/spirv_to_nir.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 72ab426e80..f968c4d387 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1908,7 +1908,22 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
const struct glsl_type *image_type = sampled.type->type;
const enum glsl_sampler_dim sampler_dim = glsl_get_sampler_dim(image_type);
const bool is_array = glsl_sampler_type_is_array(image_type);
-   const bool is_shadow = glsl_sampler_type_is_shadow(image_type);
+
+   bool is_shadow;
+   switch (opcode) {
+   /* These opcodes are always depth-comparitors regardless of the depth
+* property of the image
+*/
+   case SpvOpImageSampleDrefImplicitLod:
+   case SpvOpImageSampleProjDrefImplicitLod:
+   case SpvOpImageSampleDrefExplicitLod:
+   case SpvOpImageSampleProjDrefExplicitLod:
+  is_shadow = true;
+  break;
+   default:
+  is_shadow = glsl_sampler_type_is_shadow(image_type);
+  break;
+   }
 
/* Figure out the base texture operation */
nir_texop texop;
-- 
2.14.1

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

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 100239, which changed state.

Bug 100239 Summary: Incorrect rendering in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=100239

   What|Removed |Added

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

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

[Mesa-dev] XDC 2018: Call for Papers

[Samuel Iglesias Gonsálvez]

Hello,

I have the pleasure to announce that the X.org Developer Conference 2018
will be held in A Coruña, Spain from September 26th to September 28th.
The venue is located at the Computer Science faculty of the University
of Coruña.

This year, we have created a new website for the event:

https://xdc2018.x.org

And a Twitter account for announcing updates, please follow us!

https://twitter.com/xdc2018

However, we are going to keep updating the good old wiki too:

https://www.x.org/wiki/Events/XDC2018

As usual, we are open to talks across the layers of the graphics stack,
from the kernel to desktop environments / graphical applications and
about how to make things better for the developers who build them. Other
topics such as Virtual Reality are also welcome. If you're not sure if
something might fit, mail us or add it to the ideas list found in the
program page at:

https://www.x.org/wiki/Events/XDC2018/Program/

The Call for Papers information is here: https://xdc2018.x.org/#cfp.
Remember, the deadline for submissions is Wednesday 25th July 2018 17:00
UTC. Don't forget to send your proposals to bo...@foundation.x.org!

The conference is free of charge and open to the general public. If you
plan on coming, please add yourself to the attendees list:

https://www.x.org/wiki/Events/XDC2018/Attendees/

We'll use this list of attendees to make badges and plan for the
catering, so if you are attending please add your name as early as
possible.

I am looking forward to seeing you there. If you have any
inquiries/questions, please send an email to xdc2...@gpul.org, adding on
CC the X.org board (bo...@foundation.x.org).

Best regards,

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

[Mesa-dev] vmware change resolution mode

[Vignesh Raman]

Hi,

I have a question how to change screen resolution. I'm running a image in
vmplayer. From dmesg logs I see,
[2.947320] [drm] Screen Objects Display Unit initialized
[2.947346] [drm] width 1280
[2.947351] [drm] height 768
[2.947356] [drm] bpp 32

lsmod | grep vmwgfx
vmwgfx220505  2
ttm75481  1 vmwgfx
drm_kms_helper105053  1 vmwgfx
drm   279913  6 vmwgfx,ttm,drm_kms_helper

The status of the connector is,
cat /sys/class/drm/card0-Virtual-1/status
connected

cat /sys/class/drm/card0-Virtual-1/modes
preferred
2560x1600
1920x1440
1856x1392
1792x1344
1920x1200
1600x1200
1680x1050
1400x1050
1280x1024
1440x900
1280x960
1360x768
1280x800
1152x864
1280x768
1024x768
800x600
640x480

I tried the below to change the screen resolution to 1920x1200,
- Passing video=Virtual-1:1920x1200 as kernel option
- Setting below in vmx file  (https://kb.vmware.com/s/article/1003)
svga.vramSize = 9216000
svga.autodetect = "FALSE"
svga.maxWidth = 1920
svga.maxHeight = 1200

But the screen resolution doesn't change and in dmesg output I see width
and height as (1280x768).

Any pointers will be helpful. Thanks.

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

Re: [Mesa-dev] [PATCH 1/2] compiler/nir: add a is_image_sample_dref flag to texture instructions

[Iago Toral]

On Wed, 2018-03-28 at 17:19 -0700, Jason Ekstrand wrote:
> How is this different from is_shadow?

From the SPIR-V spec, OpTypeImage:

"Depth is whether or not this image is a depth image. (Note that
 whether or not depth comparisons are actually done is a property of
 the sampling opcode, not of this type declaration.)"

We only set is_shadow to true when the depth property is not zero, and
these tests are exercising the case where it is zero (but depth
comparison is still expected to happen because of the sampling opcode
used).

We can change this and set is_shadow to true unconditionally also when
any of these opcodes are involved, that also fixes the tests and is
simpler.

I didn't do this initially because I figured drivers could get confused
when in this scenario they see that the texture operation has is_shadow
set to true but the sampler type is not a shadow type (because the
image type has its depth property set to 0) , but maybe I was
overthiking things... looking at uses of is_shadow in the repository,
it seems that drivers only check is_shadow when they want to do depth
comparison and they don't look at anythig else, so it is probably just
fine to do this in general and it saves us from the hassle of adding a
new flag. I guess we can always add the new flag if someone hits a case
that needs to differentiate both scenarios anyway.

I'll send a new patch for review soon if Jenkins doesn't find any
issues.

Iago

> On March 28, 2018 02:33:50 Iago Toral Quiroga 
> wrote:
> 
> > So we can recognize image sampling instructions that involve a
> > depth
> > comparison against a reference, such as SPIR-V's
> > OpImageSample{Proj}Dref{Explicit,Implicit}Lod and we can
> > acknowledge
> > that they return a single scalar value instead of a vec4.
> > ---
> > src/compiler/nir/nir.h   | 9 +
> > src/compiler/nir/nir_clone.c | 1 +
> > src/compiler/nir/nir_instr_set.c | 2 ++
> > src/compiler/nir/nir_lower_tex.c | 5 -
> > src/compiler/nir/nir_serialize.c | 5 -
> > 5 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> > index 0d207d0ea5..625092cd2b 100644
> > --- a/src/compiler/nir/nir.h
> > +++ b/src/compiler/nir/nir.h
> > @@ -1231,6 +1231,12 @@ typedef struct {
> > */
> >bool is_new_style_shadow;
> > 
> > +   /**
> > +* If is_image_sample_dref is true, this is an image sample
> > with depth
> > +* comparing.
> > +*/
> > +   bool is_image_sample_dref;
> > +
> >/* gather component selector */
> >unsigned component : 2;
> > 
> > @@ -1316,6 +1322,9 @@ nir_tex_instr_dest_size(const nir_tex_instr
> > *instr)
> >   if (instr->is_shadow && instr->is_new_style_shadow)
> >  return 1;
> > 
> > +  if (instr->is_image_sample_dref)
> > + return 1;
> > +
> >   return 4;
> >}
> > }
> > diff --git a/src/compiler/nir/nir_clone.c
> > b/src/compiler/nir/nir_clone.c
> > index bcfdaa7594..7d6cfd896f 100644
> > --- a/src/compiler/nir/nir_clone.c
> > +++ b/src/compiler/nir/nir_clone.c
> > @@ -415,6 +415,7 @@ clone_tex(clone_state *state, const
> > nir_tex_instr *tex)
> >ntex->is_array = tex->is_array;
> >ntex->is_shadow = tex->is_shadow;
> >ntex->is_new_style_shadow = tex->is_new_style_shadow;
> > +   ntex->is_image_sample_dref = tex->is_image_sample_dref;
> >ntex->component = tex->component;
> > 
> >ntex->texture_index = tex->texture_index;
> > diff --git a/src/compiler/nir/nir_instr_set.c 
> > b/src/compiler/nir/nir_instr_set.c
> > index 9cb9ed43e8..5563f6f095 100644
> > --- a/src/compiler/nir/nir_instr_set.c
> > +++ b/src/compiler/nir/nir_instr_set.c
> > @@ -155,6 +155,7 @@ hash_tex(uint32_t hash, const nir_tex_instr
> > *instr)
> >hash = HASH(hash, instr->is_array);
> >hash = HASH(hash, instr->is_shadow);
> >hash = HASH(hash, instr->is_new_style_shadow);
> > +   hash = HASH(hash, instr->is_image_sample_dref);
> >unsigned component = instr->component;
> >hash = HASH(hash, component);
> >hash = HASH(hash, instr->texture_index);
> > @@ -310,6 +311,7 @@ nir_instrs_equal(const nir_instr *instr1,
> > const 
> > nir_instr *instr2)
> >   tex1->is_array != tex2->is_array ||
> >   tex1->is_shadow != tex2->is_shadow ||
> >   tex1->is_new_style_shadow != tex2->is_new_style_shadow ||
> > +  tex1->is_image_sample_dref != tex2->is_image_sample_dref 
> > ||
> >   tex1->component != tex2->component ||
> >  tex1->texture_index != tex2->texture_index ||
> >  tex1->texture_array_size != tex2->texture_array_size ||
> > diff --git a/src/compiler/nir/nir_lower_tex.c 
> > b/src/compiler/nir/nir_lower_tex.c
> > index 1062afd97f..03e7555679 100644
> > --- a/src/compiler/nir/nir_lower_tex.c
> > +++ b/src/compiler/nir/nir_lower_tex.c
> > @@ -114,6 +114,7 @@ get_texture_size(nir_builder *b, nir_tex_instr
> > *tex)
> >txs->is_array = tex->is_array;
> >txs->is_shadow = 

[Mesa-dev] [Bug 104665] r600: computer shaders break Bioshock on barts (bisected)

[bugzilla-daemon]

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

--- Comment #4 from Gert Wollny  ---
Since the game needs OpenGL 4.1 I have 

  export MESA_GL_VERSION_OVERRIDE=4.1

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

[Mesa-dev] [Bug 102204] GL_ARB_buffer_storage crippled extension on r600, radeonsi and amdgpu Mesa drivers

[bugzilla-daemon]

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

--- Comment #6 from H4nN1baL  ---
Created attachment 138484
  --> https://bugs.freedesktop.org/attachment.cgi?id=138484=edit
glxinfo4

Upgrade to Mesa 18.1
(https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa/)
I perceive the fixed bugs on 'auto' TearFree. Unfortunately, the issue with
buffer storage remains untouched.

The problem is very clear by setting the window resolution to 1280x960 or
above. And compare the difference in performance by using
'MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage' on mupen64plus or m64p.
Doesn't need to play ROMs to see the problem, even with 'm64p_test_rom.v64'
happens. (https://github.com/mupen64plus/mupen64plus-rom)

Other workaround is using this "patch" on GLideN64:
https://github.com/Jj0YzL5nvJ/GLideN64/commit/cc5d063c841fd53c26df4a1f14fa7ffdf10f1c18

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

[Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Sergii Romantsov]

Gen8+ use 48-bit address relocations so need to extend the sign
to 64-bit return value. Without it we have higher bits zeroed
and missing the negavive values.
Haswell and older use 32-bit deltas so are unaffected by this issue.

v2:
  used int32_t fucntion parameter instead of explicit type conversion.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
Signed-off-by: Sergii Romantsov 
Tested-by: Andriy Khulap 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index ebc02ff..7286140 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -1079,7 +1079,7 @@ brw_batch_references(struct intel_batchbuffer *batch, 
struct brw_bo *bo)
 static uint64_t
 emit_reloc(struct intel_batchbuffer *batch,
struct brw_reloc_list *rlist, uint32_t offset,
-   struct brw_bo *target, uint32_t target_offset,
+   struct brw_bo *target, int32_t target_offset,
unsigned int reloc_flags)
 {
assert(target != NULL);
-- 
2.7.4

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