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
hive/mesa-18.1.0.tar.xz.sig
>
> ___
> 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
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,
>
> We are no
> 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, and I've largely
> opted out since around 18.0 - it's not worth the heartach
ce 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
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 avoid any conf
e 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
> ______
RMv7/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
dthedocs book.
>> > >> > > >
>> > >> > > > Based on http://www.sphinx-doc.org/en/master/ and
>> > >> > > > https://www.python.org/, I would say sphinx gives a lot of
>> > >> > > > opportunities for a cus
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
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
7-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 that this is not r
> 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 "Unknown OS." to be "Unknown OS @0
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
>>
>> ___
>>
ze_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 ---
> > src/intel/compil
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
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(-)
, 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
> > longer works.
>
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 sin
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
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
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
---
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 |
| 33 ---
> > > meson_options.txt | 6
> > > src/gallium/state_trackers/clover/meson.build | 3 ++
> > > 3 files changed, 31 insertions(+), 11 deletions(-)
> > >
> >
>
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
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 fr
t; > >> @@ -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
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
figure 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
>
> _____
rally 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
> ______
>> _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
erated here std::cerr << "Failed to initialize EGL: " <<
> eglGetError() << std::endl; exit(EXIT_FAILURE); } ...
>
>
> Any help would be greatly appreciated.
>
--
Stuart Young (aka Cefiar)
33 matches
Mail list logo
