or) == EGL_FALSE) { // ERROR
> 12290 is generated here std::cerr << "Failed to initialize EGL: " <<
> eglGetError() << std::endl; exit(EXIT_FAILURE); } ...
>
>
> Any help would be greatly appreciated.
>
--
Stuart Young (aka Cefiar)
>> _mesa_warning(NULL, "shmget failed while allocating back
>> buffer.\n");
>>XDestroyImage(b->backxrb->ximage);
>> --
>> 1.8.5.6
>>
>> ___
>> 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
--
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
ssage generally appears directly.
> >
> > Bugs have been reported on Debian.
>
> Can you point me to the bug and make sure your dmesg output is
> attached and xorg log (if using X)?
>
> Alex
> ____
Sorry. Copy-paste decided to send a msg rather than paste into it.
On Fri, 21 Dec 2018 at 17:36, Stuart Young wrote:
> On Fri, 21 Dec 2018 at 04:18, Eero Tamminen
> wrote:
>
>> On 20.12.2018 4.40, Stuart Young wrote:
>> > Could this be reduced this from an erro
On Fri, 21 Dec 2018 at 04:18, Eero Tamminen
wrote:
> On 20.12.2018 4.40, Stuart Young wrote:
> > Could this be reduced this from an error to a warning, with the
> > command-line option suppressing the warning?
> >
> > Perhaps as well as producing the warning, the build
enable-autotools to the configure call once - a little hickup in the
> workflow of those who do not yet use exclusively meson, but it gets the
> message out to the others that things are going to change.
>
> Best,
> Gert
>
> ___
x-direct
> > >
> > > meson.build | 33 ---
> > > meson_options.txt | 6
> > > src/gallium/state_trackers/clover/meson.build | 3 ++
> > > 3 files changed, 31 insertions(+),
> >> diff --git a/meson_options.txt b/meson_options.txt
> > >> index a1d5ab0e185..4d5f36bf33d 100644
> > >> --- a/meson_options.txt
> > >> +++ b/meson_options.txt
> > >> @@ -205,6 +205,12 @@ option(
> > >>choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
> > >>description : 'Build support for GLX platform'
> > >> )
> > >> +option(
> > >> + 'glx-direct',
> > >> + type : 'boolean',
> > >> + value : 'true',
> > >> + description : 'Enable direct rendering in GLX and EGL for DRI'
> > >> +)
> > >> option(
> > >>'egl',
> > >>type : 'combo',
> > >>
> > >>
> > >
> > > I'm glad that this actually worked :) I tried to wire up direct glx so
> adding a
> > > toggle would be easy if we needed it. Do you need this for Hurd Timo?
> >
> > Yep, it also needs -D_GNU_SOURCE which hopefully is fixed by this:
> >
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -779,7 +779,7 @@ if cc.compiles('int foo(void) __attribut
> > endif
> >
> > # TODO: this is very incomplete
> > -if ['linux', 'cygwin'].contains(host_machine.system())
> > +if ['linux', 'linux-gnu', 'cygwin',
> 'gnu'].contains(host_machine.system())
> >pre_args += '-D_GNU_SOURCE'
> > endif
>
> Would you like to send those as patches and CC me on them, or would you
> like me
> to send them and CC you? We'll need to make sure we have fixes tags so
> they get
> pulled into stable as well presumably.
>
> >
> > (to match configure.ac)
> >
> > And that ppc64el build fail might be because it for some reason doesn't
> seem to get -DUSE_PPC64LE_ASM..
>
> (assuming that should be ppc64le) We probably are missing an endian check,
> I'll
> look at that in a minute.
>
> Dylan
>
> >
> >
> >
> > --
> > t
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
> > .../compiler/brw_nir_analyze_ubo_ranges.c | 15 +-
> > src/intel/compiler/brw_vec4.h | 2 +
> > src/intel/compiler/brw_vec4_gs_nir.cpp| 12 +-
> > src/intel/compiler/brw_vec4_nir.cpp | 190
Just a follow-up to make sure this makes it into mesa-stable.
I know the release window for 18.2.2 is coming up.
On Thu, 27 Sep 2018 at 16:32, Dave Airlie wrote:
> On Thu, 27 Sep 2018 at 15:40, Stuart Young wrote:
> >
> > Hi All,
> >
> > Can we get some fe
On Tue, 25 Sep 2018 at 02:04, Eric Engestrom
wrote:
> +Cc Keith, Jason & Daniel, who know this code best.
>
> On Monday, 2018-09-24 08:46:22 +1000, Stuart Young wrote:
> > From: Maxime
> >
> > Since the Randr lease code was added, compiling against libxcb 1.12 no
Used a variation on the standard boilerplate version info that is used in
the release notes.
v2: Fixed text re: context creation.
---
docs/faq.html | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/docs/faq.html b/docs/faq.html
index 6270a071da..d1be04bf71 100644
On Sun, 23 Sep 2018 at 20:35, Bas Nieuwenhuizen
wrote:
> On Sun, Sep 23, 2018 at 2:05 AM Stuart Young wrote:
> >
> > Used a variation on the standard boilerplate version info that is used in
> > the release notes.
> >
> > ---
> > docs/faq.html |
From: Maxime
Since the Randr lease code was added, compiling against libxcb 1.12 no
longer works.
CC: mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108024
Fixes: 7ab1fffcd2a504024b16e408de329f7a94553ecc
Tested-By: Maxime
---
src/vulkan/wsi/wsi_common
Used a variation on the standard boilerplate version info that is used in
the release notes.
---
docs/faq.html | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/faq.html b/docs/faq.html
index 6270a071da..080c6b6da7 100644
--- a/docs/faq.html
+++ b/docs/faq.html
Hi Eric,
Yes, someone would need to push thanks. Part of the reason I noticed it in
the first place was cos of the dead link. ;)
On Thu, 20 Sep 2018 at 21:59, Eric Engestrom
wrote:
> On Thursday, 2018-09-20 17:12:43 +1000, Stuart Young wrote:
> > It's just over 10 months si
It's just over 10 months since 17.3.0 was released with s3tc support enabled.
Probably a good idea to update the FAQ page.
v2: Incorporate feedback from Adam Jackson
Reviewed-by: Adam Jackson
CC:
---
docs/faq.html | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
di
It's just over 10 months since 17.3.0 was released with s3tc support enabled.
Probably a good idea to update the FAQ page.
CC:
---
docs/faq.html | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/docs/faq.html b/docs/faq.html
index 1f2fd66034..3d0010885a 10
tforms to set platforms. Patches
> gladly accepted to fix this.')
> +error('Unknown OS. Please pass -Dplatforms to set platforms. Patches
> gladly accepted to fix this.'.format(
> + host_machine.system()))
>endif
> endif
>
Did you mean that last
> On 2018-07-01 08:36 AM, Stuart Young wrote:
> > PowerPC variants with the Signal Processing Engine do not support
> > Altivec instructions, as the SPE instruction set uses the same
> > instruction codes as the Altivec set available in most PowerPC
> > cores. Note tha
explains its quirks in more detail:
https://wiki.debian.org/PowerPCSPEPort
Patch I provided compiles fine on non-PPC platforms, but would be worth
someone with a proper PPC platform (ie: non-SPE) confirm it still produces
Altivec instructions.
On Sun, 1 Jul 2018 at 16:36, Stuart Young wrote
PowerPC variants with the Signal Processing Engine do not support
Altivec instructions, as the SPE instruction set uses the same
instruction codes as the Altivec set available in most PowerPC
cores. Note that this is not related to the "Synergistic Processing
Element" units on IBM Cell microprocess
your employer, I have little say over how you actually do this ... my
> options are whether I opt into the stable process or not. I've been
> frustrated with the process for a long time - since the mid 10.x's, as
> evidenced by my periodic outbursts on the matter,
content side of things and
will (hopefully) send patches as necessary. I definitely feel this is going
to make reviewing and working on the content much easier.
The series as per the above branch is
Acked-by: Stuart Young
On Sat, 16 Jun 2018 at 08:41, Laura Ekstrand wrote:
> Stuart,
>
&g
bout it, though, since the Khronos registry is on
> Github now instead of SVN, maybe a git submodule would work?
>
> -Kyle
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
Stuart Young (aka Cefiar)
___
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
>
--
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
inx
>> websites,
>> > >> > > > including every readthedocs book.
>> > >> > > >
>> > >> > > > Based on http://www.sphinx-doc.org/en/master/ and
>> > >> > > > https://www.python.org/, I would say sph
alls to a git
> repository, but the more I think about it, the more I like the idea.
> It makes it more clear where they're coming from, makes the provenance
> easier to verify, gives us audit logs of who put them in, and so on.
>
> Cheers,
> Daniel
> _
t;> Sorry, I'm doing ARMv7/32-bit builds so this slipped through.
>>
>> Reviewed-By: Stefan Schake
>>
>> Thanks!
>>
>
> May I ask a second review by for intel x86 based platforms to Emil or
> other developer in Cc: ?
> Thanks
>
> Mauro
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
--
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
he issue of what happens when the branch stops being
maintained (ie: going back to developer if not needed). Otherwise you might
end up with more and more masters over time that are unnecessary.
Of course, as Ilia and Daniel mentioned, this would be good to be set out
somewhere if this is the case, to
g
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
--
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Seems that when the rnndb files for etniviv were updated/included back
in Nov 2017, hw/texdesc_3d.xml.h was missed from Makefile.sources and
meson.build. This was all during the conversion to meson, so it apears
to have slipped through the cracks. As such, this file has been missing
from the offici
set + 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
33 matches
Mail list logo
