All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mesa: Upgrade to 17.1.5 release
@ 2017-07-17 18:40 Otavio Salvador
  2017-07-20 15:37 ` Burton, Ross
  0 siblings, 1 reply; 10+ messages in thread
From: Otavio Salvador @ 2017-07-17 18:40 UTC (permalink / raw)
  To: OpenEmbedded Core Mailing List; +Cc: Otavio Salvador

This is a stable bugfix release. Following upstream bugs were fixed:

Bug 100242 - radeon buffer allocation failure during startup of Factorio
Bug 101657 - strtod.c:32:10: fatal error: xlocale.h: No such file or directory
Bug 101666 - bitfieldExtract is marked as a built-in function on OpenGL ES 3.0, but was added in OpenGL ES 3.1
Bug 101703 - No stencil buffer allocated when requested by GLUT

Also, the following patches were included in this release and as such
deleted:

- etnaviv_fix-shader-miscompilation.patch

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---

 .../files/etnaviv_fix-shader-miscompilation.patch  | 220 ---------------------
 .../mesa/{mesa-gl_17.1.4.bb => mesa-gl_17.1.5.bb}  |   0
 .../mesa/{mesa_17.1.4.bb => mesa_17.1.5.bb}        |   6 +-
 3 files changed, 2 insertions(+), 224 deletions(-)
 delete mode 100644 meta/recipes-graphics/mesa/files/etnaviv_fix-shader-miscompilation.patch
 rename meta/recipes-graphics/mesa/{mesa-gl_17.1.4.bb => mesa-gl_17.1.5.bb} (100%)
 rename meta/recipes-graphics/mesa/{mesa_17.1.4.bb => mesa_17.1.5.bb} (80%)

diff --git a/meta/recipes-graphics/mesa/files/etnaviv_fix-shader-miscompilation.patch b/meta/recipes-graphics/mesa/files/etnaviv_fix-shader-miscompilation.patch
deleted file mode 100644
index 0354e2a57f..0000000000
--- a/meta/recipes-graphics/mesa/files/etnaviv_fix-shader-miscompilation.patch
+++ /dev/null
@@ -1,220 +0,0 @@
-From ec43605189907fa327a4a7f457aa3c822cfdea5d Mon Sep 17 00:00:00 2001
-From: Lucas Stach <l.stach@pengutronix.de>
-Date: Mon, 26 Jun 2017 18:24:31 +0200
-Subject: etnaviv: fix shader miscompilation with more than 16 labels
-
-The labels array may change its virtual address on a reallocation, so
-it is invalid to cache pointers into the array. Rather than using the
-pointer directly, remember the array index.
-
-Fixes miscompilation of shaders in glmark2 ideas, leading to GPU hangs.
-
-Fixes: c9e8b49b (etnaviv: gallium driver for Vivante GPUs)
-Cc: mesa-stable@lists.freedesktop.org
-Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
-
-Upstream-Status: Backport [17.1.5]
-
-diff --git a/src/gallium/drivers/etnaviv/etnaviv_compiler.c b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
-index eafb511..af0f76b 100644
---- a/src/gallium/drivers/etnaviv/etnaviv_compiler.c
-+++ b/src/gallium/drivers/etnaviv/etnaviv_compiler.c
-@@ -119,10 +119,10 @@ enum etna_compile_frame_type {
-  */
- struct etna_compile_frame {
-    enum etna_compile_frame_type type;
--   struct etna_compile_label *lbl_else;
--   struct etna_compile_label *lbl_endif;
--   struct etna_compile_label *lbl_loop_bgn;
--   struct etna_compile_label *lbl_loop_end;
-+   int lbl_else_idx;
-+   int lbl_endif_idx;
-+   int lbl_loop_bgn_idx;
-+   int lbl_loop_end_idx;
- };
- 
- struct etna_compile_file {
-@@ -178,7 +178,7 @@ struct etna_compile {
-    /* Fields for handling nested conditionals */
-    struct etna_compile_frame frame_stack[ETNA_MAX_DEPTH];
-    int frame_sp;
--   struct etna_compile_label *lbl_usage[ETNA_MAX_INSTRUCTIONS];
-+   int lbl_usage[ETNA_MAX_INSTRUCTIONS];
- 
-    unsigned labels_count, labels_sz;
-    struct etna_compile_label *labels;
-@@ -990,7 +990,7 @@ etna_src_uniforms_conflict(struct etna_inst_src a, struct etna_inst_src b)
- }
- 
- /* create a new label */
--static struct etna_compile_label *
-+static unsigned int
- alloc_new_label(struct etna_compile *c)
- {
-    struct etna_compile_label label = {
-@@ -999,7 +999,7 @@ alloc_new_label(struct etna_compile *c)
- 
-    array_insert(c->labels, label);
- 
--   return &c->labels[c->labels_count - 1];
-+   return c->labels_count - 1;
- }
- 
- /* place label at current instruction pointer */
-@@ -1015,10 +1015,10 @@ label_place(struct etna_compile *c, struct etna_compile_label *label)
-  * as the value becomes known.
-  */
- static void
--label_mark_use(struct etna_compile *c, struct etna_compile_label *label)
-+label_mark_use(struct etna_compile *c, int lbl_idx)
- {
-    assert(c->inst_ptr < ETNA_MAX_INSTRUCTIONS);
--   c->lbl_usage[c->inst_ptr] = label;
-+   c->lbl_usage[c->inst_ptr] = lbl_idx;
- }
- 
- /* walk the frame stack and return first frame with matching type */
-@@ -1099,8 +1099,8 @@ trans_if(const struct instr_translater *t, struct etna_compile *c,
-    /* push IF to stack */
-    f->type = ETNA_COMPILE_FRAME_IF;
-    /* create "else" label */
--   f->lbl_else = alloc_new_label(c);
--   f->lbl_endif = NULL;
-+   f->lbl_else_idx = alloc_new_label(c);
-+   f->lbl_endif_idx = -1;
- 
-    /* We need to avoid the emit_inst() below becoming two instructions */
-    if (etna_src_uniforms_conflict(src[0], imm_0))
-@@ -1108,7 +1108,7 @@ trans_if(const struct instr_translater *t, struct etna_compile *c,
- 
-    /* mark position in instruction stream of label reference so that it can be
-     * filled in in next pass */
--   label_mark_use(c, f->lbl_else);
-+   label_mark_use(c, f->lbl_else_idx);
- 
-    /* create conditional branch to label if src0 EQ 0 */
-    emit_inst(c, &(struct etna_inst){
-@@ -1129,8 +1129,8 @@ trans_else(const struct instr_translater *t, struct etna_compile *c,
-    assert(f->type == ETNA_COMPILE_FRAME_IF);
- 
-    /* create "endif" label, and branch to endif label */
--   f->lbl_endif = alloc_new_label(c);
--   label_mark_use(c, f->lbl_endif);
-+   f->lbl_endif_idx = alloc_new_label(c);
-+   label_mark_use(c, f->lbl_endif_idx);
-    emit_inst(c, &(struct etna_inst) {
-       .opcode = INST_OPCODE_BRANCH,
-       .cond = INST_CONDITION_TRUE,
-@@ -1138,7 +1138,7 @@ trans_else(const struct instr_translater *t, struct etna_compile *c,
-    });
- 
-    /* mark "else" label at this position in instruction stream */
--   label_place(c, f->lbl_else);
-+   label_place(c, &c->labels[f->lbl_else_idx]);
- }
- 
- static void
-@@ -1151,10 +1151,10 @@ trans_endif(const struct instr_translater *t, struct etna_compile *c,
- 
-    /* assign "endif" or "else" (if no ELSE) label to current position in
-     * instruction stream, pop IF */
--   if (f->lbl_endif != NULL)
--      label_place(c, f->lbl_endif);
-+   if (f->lbl_endif_idx != -1)
-+      label_place(c, &c->labels[f->lbl_endif_idx]);
-    else
--      label_place(c, f->lbl_else);
-+      label_place(c, &c->labels[f->lbl_else_idx]);
- }
- 
- static void
-@@ -1166,10 +1166,10 @@ trans_loop_bgn(const struct instr_translater *t, struct etna_compile *c,
- 
-    /* push LOOP to stack */
-    f->type = ETNA_COMPILE_FRAME_LOOP;
--   f->lbl_loop_bgn = alloc_new_label(c);
--   f->lbl_loop_end = alloc_new_label(c);
-+   f->lbl_loop_bgn_idx = alloc_new_label(c);
-+   f->lbl_loop_end_idx = alloc_new_label(c);
- 
--   label_place(c, f->lbl_loop_bgn);
-+   label_place(c, &c->labels[f->lbl_loop_bgn_idx]);
- 
-    c->num_loops++;
- }
-@@ -1185,7 +1185,7 @@ trans_loop_end(const struct instr_translater *t, struct etna_compile *c,
- 
-    /* mark position in instruction stream of label reference so that it can be
-     * filled in in next pass */
--   label_mark_use(c, f->lbl_loop_bgn);
-+   label_mark_use(c, f->lbl_loop_bgn_idx);
- 
-    /* create branch to loop_bgn label */
-    emit_inst(c, &(struct etna_inst) {
-@@ -1195,7 +1195,7 @@ trans_loop_end(const struct instr_translater *t, struct etna_compile *c,
-       /* imm is filled in later */
-    });
- 
--   label_place(c, f->lbl_loop_end);
-+   label_place(c, &c->labels[f->lbl_loop_end_idx]);
- }
- 
- static void
-@@ -1207,7 +1207,7 @@ trans_brk(const struct instr_translater *t, struct etna_compile *c,
- 
-    /* mark position in instruction stream of label reference so that it can be
-     * filled in in next pass */
--   label_mark_use(c, f->lbl_loop_end);
-+   label_mark_use(c, f->lbl_loop_end_idx);
- 
-    /* create branch to loop_end label */
-    emit_inst(c, &(struct etna_inst) {
-@@ -1227,7 +1227,7 @@ trans_cont(const struct instr_translater *t, struct etna_compile *c,
- 
-    /* mark position in instruction stream of label reference so that it can be
-     * filled in in next pass */
--   label_mark_use(c, f->lbl_loop_bgn);
-+   label_mark_use(c, f->lbl_loop_bgn_idx);
- 
-    /* create branch to loop_end label */
-    emit_inst(c, &(struct etna_inst) {
-@@ -1998,8 +1998,9 @@ static void
- etna_compile_fill_in_labels(struct etna_compile *c)
- {
-    for (int idx = 0; idx < c->inst_ptr; ++idx) {
--      if (c->lbl_usage[idx])
--         etna_assemble_set_imm(&c->code[idx * 4], c->lbl_usage[idx]->inst_idx);
-+      if (c->lbl_usage[idx] != -1)
-+         etna_assemble_set_imm(&c->code[idx * 4],
-+                               c->labels[c->lbl_usage[idx]].inst_idx);
-    }
- }
- 
-@@ -2301,6 +2302,8 @@ etna_compile_shader(struct etna_shader_variant *v)
-    if (!c)
-       return false;
- 
-+   memset(&c->lbl_usage, -1, ARRAY_SIZE(c->lbl_usage));
-+
-    const struct tgsi_token *tokens = v->shader->tokens;
- 
-    c->specs = specs;
-@@ -2430,12 +2433,13 @@ etna_compile_shader(struct etna_shader_variant *v)
-    etna_compile_add_z_div_if_needed(c);
-    etna_compile_frag_rb_swap(c);
-    etna_compile_add_nop_if_needed(c);
--   etna_compile_fill_in_labels(c);
- 
-    ret = etna_compile_check_limits(c);
-    if (!ret)
-       goto out;
- 
-+   etna_compile_fill_in_labels(c);
-+
-    /* fill in output structure */
-    v->processor = c->info.processor;
-    v->code_size = c->inst_ptr * 4;
--- 
-cgit v0.10.2
-
diff --git a/meta/recipes-graphics/mesa/mesa-gl_17.1.4.bb b/meta/recipes-graphics/mesa/mesa-gl_17.1.5.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_17.1.4.bb
rename to meta/recipes-graphics/mesa/mesa-gl_17.1.5.bb
diff --git a/meta/recipes-graphics/mesa/mesa_17.1.4.bb b/meta/recipes-graphics/mesa/mesa_17.1.5.bb
similarity index 80%
rename from meta/recipes-graphics/mesa/mesa_17.1.4.bb
rename to meta/recipes-graphics/mesa/mesa_17.1.5.bb
index f0b634a045..ddfcb371ec 100644
--- a/meta/recipes-graphics/mesa/mesa_17.1.4.bb
+++ b/meta/recipes-graphics/mesa/mesa_17.1.5.bb
@@ -3,15 +3,13 @@ require ${BPN}.inc
 SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
            file://replace_glibc_check_with_linux.patch \
            file://disable-asm-on-non-gcc.patch \
-           file://etnaviv_fix-shader-miscompilation.patch \
            file://0001-Use-wayland-scanner-in-the-path.patch \
            file://0002-hardware-gloat.patch \
            file://0001-mapi-Only-install-khrplatform.h-with-EGL-or-GLES.patch \
            file://vulkan-mkdir.patch \
 "
-
-SRC_URI[md5sum] = "be2ef7c9edec23b07f74f6512a6a6fa5"
-SRC_URI[sha256sum] = "06f3b0e6a28f0d20b7f3391cf67fe89ae98ecd0a686cd545da76557b6cec9cad"
+SRC_URI[md5sum] = "6cf936fbcaadd98924298a7009e8265d"
+SRC_URI[sha256sum] = "378516b171712687aace4c7ea8b37c85895231d7a6d61e1e27362cf6034fded9"
 
 #because we cannot rely on the fact that all apps will use pkgconfig,
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
-- 
2.13.3



^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-17 18:40 [PATCH] mesa: Upgrade to 17.1.5 release Otavio Salvador
@ 2017-07-20 15:37 ` Burton, Ross
  2017-07-20 19:22   ` Burton, Ross
  0 siblings, 1 reply; 10+ messages in thread
From: Burton, Ross @ 2017-07-20 15:37 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: OpenEmbedded Core Mailing List

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On 17 July 2017 at 19:40, Otavio Salvador <otavio@ossystems.com.br> wrote:

> This is a stable bugfix release. Following upstream bugs were fixed:
>
> Bug 100242 - radeon buffer allocation failure during startup of Factorio
> Bug 101657 - strtod.c:32:10: fatal error: xlocale.h: No such file or
> directory
> Bug 101666 - bitfieldExtract is marked as a built-in function on OpenGL ES
> 3.0, but was added in OpenGL ES 3.1
> Bug 101703 - No stencil buffer allocated when requested by GLUT
>
> Also, the following patches were included in this release and as such
> deleted:
>
> - etnaviv_fix-shader-miscompilation.patch
>

This fails to build on ppc:

| checking for libdrm >= 2.4.75 libdrm_intel >= 2.4.75... no
| configure: error: Package requirements (libdrm >= 2.4.75 libdrm_intel >=
2.4.75) were not met:
|
| No package 'libdrm_intel' found

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/1191/steps/BuildImages/logs/stdio

Ross

[-- Attachment #2: Type: text/html, Size: 1732 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 15:37 ` Burton, Ross
@ 2017-07-20 19:22   ` Burton, Ross
  2017-07-20 19:46     ` Khem Raj
  0 siblings, 1 reply; 10+ messages in thread
From: Burton, Ross @ 2017-07-20 19:22 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: OpenEmbedded Core Mailing List

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

On 20 July 2017 at 16:37, Burton, Ross <ross.burton@intel.com> wrote:

> This fails to build on ppc:
>
> | checking for libdrm >= 2.4.75 libdrm_intel >= 2.4.75... no
>

Same on arm and mips now.  Basically everything that isn't x86, so I'm
wondering what the difference between your build environment and the
autobuilder is!

Ross

[-- Attachment #2: Type: text/html, Size: 739 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 19:22   ` Burton, Ross
@ 2017-07-20 19:46     ` Khem Raj
  2017-07-20 19:56       ` Otavio Salvador
  0 siblings, 1 reply; 10+ messages in thread
From: Khem Raj @ 2017-07-20 19:46 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List

On Thu, Jul 20, 2017 at 3:22 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 20 July 2017 at 16:37, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> This fails to build on ppc:
>>
>> | checking for libdrm >= 2.4.75 libdrm_intel >= 2.4.75... no
>
>
> Same on arm and mips now.  Basically everything that isn't x86, so I'm
> wondering what the difference between your build environment and the
> autobuilder

may be pkgconfig is installed on working system.

>
> Ross
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 19:46     ` Khem Raj
@ 2017-07-20 19:56       ` Otavio Salvador
  2017-07-20 20:14         ` Nicolas Dechesne
  0 siblings, 1 reply; 10+ messages in thread
From: Otavio Salvador @ 2017-07-20 19:56 UTC (permalink / raw)
  To: Khem Raj; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List

On Thu, Jul 20, 2017 at 4:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, Jul 20, 2017 at 3:22 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 20 July 2017 at 16:37, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> This fails to build on ppc:
>>>
>>> | checking for libdrm >= 2.4.75 libdrm_intel >= 2.4.75... no
>>
>>
>> Same on arm and mips now.  Basically everything that isn't x86, so I'm
>> wondering what the difference between your build environment and the
>> autobuilder
>
> may be pkgconfig is installed on working system.

I wonder why; I will try to reproduce it and also will inspect the
changes on configure.ac to find possible causes.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 19:56       ` Otavio Salvador
@ 2017-07-20 20:14         ` Nicolas Dechesne
  2017-07-20 20:25           ` Burton, Ross
  0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Dechesne @ 2017-07-20 20:14 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List

On Thu, Jul 20, 2017 at 9:56 PM, Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
> On Thu, Jul 20, 2017 at 4:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Thu, Jul 20, 2017 at 3:22 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 20 July 2017 at 16:37, Burton, Ross <ross.burton@intel.com> wrote:
>>>>
>>>> This fails to build on ppc:
>>>>
>>>> | checking for libdrm >= 2.4.75 libdrm_intel >= 2.4.75... no
>>>
>>>
>>> Same on arm and mips now.  Basically everything that isn't x86, so I'm
>>> wondering what the difference between your build environment and the
>>> autobuilder
>>
>> may be pkgconfig is installed on working system.
>
> I wonder why; I will try to reproduce it and also will inspect the
> changes on configure.ac to find possible causes.

It built fine for me (OE-core/nodistro + meta-qcom) with and without
pkg-config installed on the host.

>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 20:14         ` Nicolas Dechesne
@ 2017-07-20 20:25           ` Burton, Ross
  2017-07-20 20:36             ` Otavio Salvador
  0 siblings, 1 reply; 10+ messages in thread
From: Burton, Ross @ 2017-07-20 20:25 UTC (permalink / raw)
  To: Nicolas Dechesne
  Cc: Otavio Salvador, Otavio Salvador, OpenEmbedded Core Mailing List

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On 20 July 2017 at 21:14, Nicolas Dechesne <nicolas.dechesne@linaro.org>
wrote:

> It built fine for me (OE-core/nodistro + meta-qcom) with and without
> pkg-config installed on the host.
>

Yeah it's not that, mesa builds fine for intel-corei7 on my machine, but
fails with qemuppc.

libdrm isn't generating a libdrm_intel if I build for qemuppc.  Maybe it's
looking for kernel bits that are disabled in our latest kernels?

Ross

[-- Attachment #2: Type: text/html, Size: 881 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 20:25           ` Burton, Ross
@ 2017-07-20 20:36             ` Otavio Salvador
  2017-07-20 21:34               ` Burton, Ross
  0 siblings, 1 reply; 10+ messages in thread
From: Otavio Salvador @ 2017-07-20 20:36 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List

On Thu, Jul 20, 2017 at 5:25 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 20 July 2017 at 21:14, Nicolas Dechesne <nicolas.dechesne@linaro.org>
> wrote:
>>
>> It built fine for me (OE-core/nodistro + meta-qcom) with and without
>> pkg-config installed on the host.
>
>
> Yeah it's not that, mesa builds fine for intel-corei7 on my machine, but
> fails with qemuppc.
>
> libdrm isn't generating a libdrm_intel if I build for qemuppc.  Maybe it's
> looking for kernel bits that are disabled in our latest kernels?

My understanding was that mesa was going to include those headers and
stop requiring libdrm-intel. I don't recall if it made into 17.1 or it
is master development.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 20:36             ` Otavio Salvador
@ 2017-07-20 21:34               ` Burton, Ross
  2017-07-21 12:59                 ` Burton, Ross
  0 siblings, 1 reply; 10+ messages in thread
From: Burton, Ross @ 2017-07-20 21:34 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On 20 July 2017 at 21:36, Otavio Salvador <otavio.salvador@ossystems.com.br>
wrote:

> My understanding was that mesa was going to include those headers and
> stop requiring libdrm-intel. I don't recall if it made into 17.1 or it
> is master development.
>

Ok, this isn't related to the upgrade, I reverted it and 17.1.4 does the
same:

| configure: error: Package requirements (libdrm >= 2.4.75 libdrm_intel >=
2.4.75) were not met:

I'll bisect that tomorrow...

Ross

[-- Attachment #2: Type: text/html, Size: 1081 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mesa: Upgrade to 17.1.5 release
  2017-07-20 21:34               ` Burton, Ross
@ 2017-07-21 12:59                 ` Burton, Ross
  0 siblings, 0 replies; 10+ messages in thread
From: Burton, Ross @ 2017-07-21 12:59 UTC (permalink / raw)
  To: Otavio Salvador; +Cc: Otavio Salvador, OpenEmbedded Core Mailing List

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

On 20 July 2017 at 22:34, Burton, Ross <ross.burton@intel.com> wrote:

> I'll bisect that tomorrow...
>

Richard discovered that this is due to enabling Vulkan, so that change has
been dropped from meta-poky.

Ross

[-- Attachment #2: Type: text/html, Size: 587 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-07-21 13:00 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-17 18:40 [PATCH] mesa: Upgrade to 17.1.5 release Otavio Salvador
2017-07-20 15:37 ` Burton, Ross
2017-07-20 19:22   ` Burton, Ross
2017-07-20 19:46     ` Khem Raj
2017-07-20 19:56       ` Otavio Salvador
2017-07-20 20:14         ` Nicolas Dechesne
2017-07-20 20:25           ` Burton, Ross
2017-07-20 20:36             ` Otavio Salvador
2017-07-20 21:34               ` Burton, Ross
2017-07-21 12:59                 ` Burton, Ross

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.