Re: [Mesa-dev] amdgpu: The CS has been cancelled because the context is lost.
Jean has logged 3 versions of the same bug in Debian, as he wasn't sure which package was causing the issues. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921114 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921145 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921004 None of the bug logs currently contain dmesg or xorg logs. Jean: Can you reply when you've added the logs to one of the Debian bug reports? I suspect the one against libglx-mesa0 is probably a good choice for the moment ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921145 ). On Sun, 3 Feb 2019 at 04:27, Alex Deucher wrote: > On Sat, Feb 2, 2019 at 4:13 AM Jean-Dominique Frattini > wrote: > > > > Hello, > > > > I am on Debian Linux testing. And after an update > (firmware-amd-graphics, xserver-xorg-video-amdgup and Mesa), my program > often raises this error message: > > > > amdgpu: The CS has been cancelled because the context is lost. > > > > When this message shows up (hundreds of lines are displaying in the > console every seconds), the window does not show anything anymore. From > what I understand from this message the context is lost, explaining why > there is no more display. The program creates a single context at the > begining, and a single thread is used (so the context is made current > once). This same program works well on other plateforms (Debian + nvidia, > Debian + intel, Windows + nvidia...). > > > > Also, I would like to add that since some months (since mesa 18.2.x), > when allocating memory for VBOs, sometimes the system can take up to 1.5 > second whereas generally it is almost instantaneous. > > > > Downgrading to the previous firmware solved the issue temporarily: after > some hours of uptime of the OS, the same error can be raised. > > Generally, a reboot will solve temporarilly the issue (the message will > not show up for some times), except when using the latest firmware and mesa > version on debian where this message 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 > _______ > 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
Re: [Mesa-dev] GitLab Migration: Users and Groups
On 31 May 2018 at 02:15, Jason Ekstrand wrote: > Gitlab divides users into three categories per-project: Guests, > Developers, and Masters. In general, developers and masters will have push > access. Masters have the ability to add developers to the project. > Masters will also have the ability to unlock the branch, force-push, and > then re-lock if needed. > Just wondering if force-pushing like this would be necessary for people maintaining the stable branches? From what I gather this would probably be a rare event (and therefore one of the masters could do it on the maintainers behalf) but I'm not the one doing this sort of stuff on a day to day basis. If so, then you'd need to add Dylan Baker to the list (for 18.1), and of course add each release maintainer as time goes on (unless they're already a master of course). There is then also the 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 avoid any confusion. -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] android: gallium/util: fix u_debug_stack_android build
A related note on this:
Seems this file (src/gallium/auxiliary/util/u_debug_stack_android.cpp)
doesn't make it into the tarballs (didn't for 18.1.0). Probably needs to be
added to Makefile.source and meson.build somewhere so that building the
tarball finds it. I checked for commits to both since 18.1.0 and saw
nothing, so I suspect it's still missing (though not tested).
On 1 June 2018 at 15:49, Mauro Rossi wrote:
> Hi there,
>
> 2018-04-22 15:36 GMT+02:00 Stefan Schake :
>
>> On Sun, Apr 22, 2018 at 1:11 PM, Mauro Rossi
>> wrote:
>> > Fix for build errors in src/gallium/auxiliary/util/u_d
>> ebug_stack_android.cpp
>> > error: cast to 'void *' from smaller integer type pid_t
>> >
>> > Fixes: ff904978a1 ("gallium/util: Android backtrace support")
>> >
>> > Cc: "18.1"
>> > ---
>> > src/gallium/auxiliary/util/u_debug_stack_android.cpp | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/src/gallium/auxiliary/util/u_debug_stack_android.cpp
>> b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
>> > index b3d56aebe6..11e2d3962b 100644
>> > --- a/src/gallium/auxiliary/util/u_debug_stack_android.cpp
>> > +++ b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
>> > @@ -49,10 +49,10 @@ debug_backtrace_capture(debug_stack_frame
>> *mesa_backtrace,
>> >backtrace_table = _mesa_hash_table_create(NULL,
>> _mesa_hash_pointer,
>> >
>> _mesa_key_pointer_equal);
>> >
>> > - backtrace_entry = _mesa_hash_table_search(backtrace_table, (void*)
>> tid);
>> > + backtrace_entry = _mesa_hash_table_search(backtrace_table,
>> (void*)(uintptr_t) tid);
>> > if (!backtrace_entry) {
>> >backtrace = Backtrace::Create(getpid(), tid);
>> > - _mesa_hash_table_insert(backtrace_table, (void*) tid,
>> backtrace);
>> > + _mesa_hash_table_insert(backtrace_table, (void*)(uintptr_t)
>> tid, backtrace);
>> > } else {
>> >backtrace = (Backtrace *) backtrace_entry->data;
>> > }
>> > --
>> > 2.14.1
>> >
>>
>> 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
Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx
Perhaps just have the archive as a separate repo that gets pulled in by the main ci yaml at build, just to populate the archives directory? This avoids any possible submodule breakage (just not worth it here IMO), with no chance of accidentally pulling down all the archives. I know a few people who have git shortcuts that update submodules by default for example, whether they exist or not. Also I personally think the archives dir needs a bit of re-org/cleanup to make it a bit more persistent over time (eg: like moving the old stuff into the older-versions dir effectively breaks links for distros, etc). That's getting more into content, but it'd be worth exploring if that should/would get done before or after the move to a git repo (ie: would it being in git make the process harder/a nightmare if it was to happen). On 4 June 2018 at 06:19, Daniel Stone wrote: > Hi Laura, > > On 25 May 2018 at 01:27, Laura Ekstrand wrote: > > When reviewing these patches, please note: > > 1. This patch series does *not* touch content. Please do not > bikeshed > >the content of webpages here. That will be addressed in later > >commits. > > 2. Please do *not* bikeshed website style here. We are using the > >classic ReadTheDocs style for now and we will update style in > a > >future commit. > > 3. I've done my best to make your current content look > beautiful. If > >there's a problem, please let me know. > > 4. There were some commits to the website between when I started > this > >series and now. I've done my best to incorporate your changes. > >So if you changed your content in the past two weeks, take a > look > >at your page. > > One thing I've just remembered is that https://www.mesa3d.org/archive/ > serves all the tarballs for Mesa releases. Given how Pages is > structured, we don't have a good way to redirect these to the old > server, so the Pages repository needs to hold all the tarballs. This > probably suggests to me that the site should live in a different repo, > where we can just commit all the tarballs. > > I reflexively didn't love the idea of committing tarballs 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 > ___ > 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
Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx
t; > >> > >> > > > I think the theme should be changed to look somewhat close to >> the >> > >> > > > current mesa3d.org website before changing the main site. >> (Color >> > >> > > > scheme and missing icons.) >> > >> > > > >> > >> > > > Right now the test website looks like a million other sphinx >> websites, >> > >> > > > including every readthedocs 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 custom look. >> > >> > > >> > >> > > I think looking like a generic other sphinx website is a step >> forward, >> > >> > > and I look forward to this series landing. No need for >> continuity with >> > >> > > the old theme. >> > >> > >> > >> > I think it is 1 step forward, 1 step back. As no else appears to >> > >> > agree, I'll withdraw my feedback. >> > >> > >> > >> > -Jordan >> > >> > >> > > ___ >> > > 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 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
Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx
Laura: Brilliant. Don't let it hang any deployment though. There's so much more good in this that losing the favicon for a while is definitely worth it. On Tue, 12 Jun 2018 at 08:27, Laura Ekstrand wrote: > I really like the rotate on hover effect for the gears. I would rather > that we use 2D WebGL for it if we could, though, since Mesa enables WebGL > on certain platforms. > > Stuart, I will try to get the favicon and rtd_theme fixed. We may have to > make our Docker image. > > Thanks. > > Laura > > On Fri, Jun 8, 2018 at 7:23 AM, Erik Faye-Lund > wrote: > >> On Fri, Jun 8, 2018 at 4:09 PM Rhys Perry >> wrote: >> > >> > Might be good to do something like this: >> https://codepen.io/anon/pen/ERNdYJ >> > So that those with NoScript or something won't have gears constantly >> > rotating on their screen. >> > >> >> Yeah, good point. >> ___ >> 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
Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled
Any movement on one of these solutions ending up in master and 18.1.x anytime soon? On Thu, 31 May 2018 at 05:09, Kyle Brenneman wrote: > On 05/29/2018 12:04 PM, Adam Jackson wrote: > > On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: > >> Quoting Adam Jackson (2018-05-29 06:50:46) > >>> GL_LIB expands to GLX_mesa, but applications should not link against > >>> that. -lGL is never wrong, just hardcode it. > >> Actually There is this really stupid option in the autotools build > called > >> --gl-lib-name. We should remove that. > >> > >> Emil and I had also discussed that glvnd should provide the gl.pc file > when used > >> instead of mesa. It appears he never got around to that, but it seems > like a > >> useful thing to do. > > https://github.com/NVIDIA/libglvnd/pull/86 > > > > Branch is a bit stale but better than reinventing everything. > > > > Part of the reason I didn't get much further on that is the question of > > distributing the _headers_. It would be a bit awkward if glvnd provided > > the library you link to but not the headers defining its interface - > > though, I guess no more awkward than the current situation. At any rate > > glvnd doesn't install any, and there's no way to generate > > from the Khronos scripts at the moment (it's assumed to be a platform > > implementation detail, and the version in Mesa is just handcoded > > history). > > > > - ajax > > > Yeah, the headers versus libraries question is what makes it awkward. > Libglvnd provides the libraries that an application links against, but > the header files are basically from the Khronos repository. Treating > libglvnd as the source for the libraries and the Khronos tree as the > source for the headers would seem to be the cleanest option, but the > pkg-config files would have to include the paths to both. > > Now that I think about 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
Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx
Definitely looks to be the case that those issues have been addressed. I see that you updated font-awesome while you were at it. :D Once again, thanks for all the work on this (plus all those in the background). It's much appreciated. After it's live I'll see if I can review the 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, > > We are now running on our own Docker image: > https://mesa-test.freedesktop.org/. > > This should have fixed both of the issues you encountered. > > Thanks. > > Laura > > On Mon, Jun 11, 2018 at 3:24 PM, Laura Ekstrand > wrote: > >> I really like the rotate on hover effect for the gears. I would rather >> that we use 2D WebGL for it if we could, though, since Mesa enables WebGL >> on certain platforms. >> >> Stuart, I will try to get the favicon and rtd_theme fixed. We may have >> to make our Docker image. >> >> Thanks. >> >> Laura >> >> On Fri, Jun 8, 2018 at 7:23 AM, Erik Faye-Lund >> wrote: >> >>> On Fri, Jun 8, 2018 at 4:09 PM Rhys Perry >>> wrote: >>> > >>> > Might be good to do something like this: >>> https://codepen.io/anon/pen/ERNdYJ >>> > So that those with NoScript or something won't have gears constantly >>> > rotating on their screen. >>> > >>> >>> Yeah, good point. >>> ___ >>> 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
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Whichever way this goes, is it possible to have the pre-announce include a link to the git repo/branch in question? This way, even if it's not part of the main repo, people can easily find it and check out the pre-release in full. FWIW: An advantage of not requiring it to be in the main repo is that if for whatever reason the main repo isn't available on the day (eg: outage, major re-org, gitlab down for a few hours, network issues, etc), it can be uploaded elsewhere and people can still proceed to check things out till the main repo is available again. Personally I think it makes sense to be in the main repo where possible, but allowing for the possibility of it not being there in certain circumstances, by explicitly linking to it in the pre-release so it's unambiguous. Of course, it should be in the main repo for final release. On Wed, 20 Jun 2018 at 03:23, Ilia Mirkin wrote: > On Mon, Jun 18, 2018 at 12:56 PM, Dylan Baker wrote: > > Quoting Juan A. Suarez Romero (2018-06-18 00:22:02) > >> On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote: > >> > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker > wrote: > >> > > I don't even understand why we make these announcements TBH. I have > a public > >> > > 18.1-proposed branch that I push to *every weekday*. Anyone can > pull that branch > >> > > *anytime* to get the latest version. The only thing the announce > email really > >> > > serves AFAICT, is to say "the staging/proposed branch has been > merged to the > >> > > release branch". I don't think that's all that interesting TBH. > >> > > >> > "any time" means "no time". The announcement is "speak now or forever > >> > hold your peace". Gives driver teams a chance to review the list and > >> > test things out before they go out into a full release. Should they be > >> > doing this daily/continuously? Probably. But that's not the current > >> > state. > >> > > >> > >> I agree on this. And I think the reason to wait 48h is to give time > enough for > >> teams to do proper testing, specially when there are many timezones > that people > >> get the pre-announcement several hours later. > >> > >> > >> But, I also think that the pre-announcement is too much verbose. It > includes lot > >> of information that can be easily get from the git branch itself. The > only thing > >> I would probably keep is about trivial conflicts, sending an explicit > email to > >> the authors to say "I [slightly] changed your commit; please, take a > look just > >> in case", and the rejected patch list, also mailing the authors. > > > > I follow up with authors about changes immediately. If it was rejected I > reply > > to the original patch letting them know I'm not planning to pull the > commit and > > why. If there's conflicts I ask the original author to look at the > changes I've > > made before pulling them into the staging branch. > > That's really helpful, thanks! > > > It feels much too late to be > > asking someone to do that when the release is happening shortly. > > In order for me to find it useful, the flow has to be: > > 1. Pre-announce saying which patches you're taking > 2. Take feedback from driver maintainers regarding patches to remove or add > 3. Do release (or go to 1 if the requested changes were substantial, > at your discretion) > > I realize you're doing this as part of your job, and since I'm not > 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, and I've largely > opted out since around 18.0 - it's not worth the heartache for me. > Which is fine - I just tell people to build from HEAD and all is well. > Perhaps I'm in a unique situation and can be ignored -- like I said, > I'm perfectly fine with the status quo of not caring about stable. > Basically no one uses nouveau anyways. > > -ilia > ___ > 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] [PATCH] gallium: Disable Altivec on PPC SPE variants
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 microprocessors. This patch prevents any Altivec specialising on these cores by looking for __NO_FPRS__ (should only be defined on these variants). --- src/gallium/include/pipe/p_config.h | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index 3fa43ed797..0a6251e060 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -103,12 +103,16 @@ #endif #endif +#if defined (__NO_FPRS__) +/* Skip PPC tests as possible PowerPC SPE (Signal Processing Engine) variant */ +#else #if defined(__ppc__) || defined(__ppc64__) || defined(__PPC__) #define PIPE_ARCH_PPC #if defined(__ppc64__) || defined(__PPC64__) #define PIPE_ARCH_PPC_64 #endif #endif +#endif #if defined(__s390x__) #define PIPE_ARCH_S390 -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Disable Altivec on PPC SPE variants
Further info on this: The original patch in Debian is at https://sources.debian.org/src/mesa/18.1.2-1/debian/patches/07_gallium-fix-build-failure-on-powerpcspe.diff/ (URL will change based on version of Mesa in Debian - URL is current when I sent this email). PowerPCSPE port page in Debian which 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 microprocessors. > > This patch prevents any Altivec specialising on these cores by > looking for __NO_FPRS__ (should only be defined on these variants). > --- > src/gallium/include/pipe/p_config.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/src/gallium/include/pipe/p_config.h > b/src/gallium/include/pipe/p_config.h > index 3fa43ed797..0a6251e060 100644 > --- a/src/gallium/include/pipe/p_config.h > +++ b/src/gallium/include/pipe/p_config.h > @@ -103,12 +103,16 @@ > #endif > #endif > > +#if defined (__NO_FPRS__) > +/* Skip PPC tests as possible PowerPC SPE (Signal Processing Engine) > variant */ > +#else > #if defined(__ppc__) || defined(__ppc64__) || defined(__PPC__) > #define PIPE_ARCH_PPC > #if defined(__ppc64__) || defined(__PPC64__) > #define PIPE_ARCH_PPC_64 > #endif > #endif > +#endif > > #if defined(__s390x__) > #define PIPE_ARCH_S390 > -- > 2.11.0 > > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: Disable Altivec on PPC SPE variants
Possibly you might be right. If so, I suspect it'll just continue to languish in Debian I will point out that this isn't quite your typical PowerPC core, and quite a bit was hacked out to implement the Signal Processing Engine by Freescale when it was created. I will also note that while the core is supposedly still in production, it's not sold for new designs. Apart from the missing Altivec unit, the e500v1 and e500v2 cores use the "Book E instruction set for 32-bit implementations. This is composed primarily of the user-level instructions defined by the PowerPC user instruction set architecture (UISA). The e500 does not include Book E floating-point, load string, or store string instructions." (Quoted from http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf page 1-12, section 1.4). On Mon, 2 Jul 2018 at 19:35, Michel Dänzer wrote: > 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 that this is not related to the "Synergistic Processing > > Element" units on IBM Cell microprocessors. > > > > This patch prevents any Altivec specialising on these cores by > > looking for __NO_FPRS__ (should only be defined on these variants). > > --- > > src/gallium/include/pipe/p_config.h | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/src/gallium/include/pipe/p_config.h > b/src/gallium/include/pipe/p_config.h > > index 3fa43ed797..0a6251e060 100644 > > --- a/src/gallium/include/pipe/p_config.h > > +++ b/src/gallium/include/pipe/p_config.h > > @@ -103,12 +103,16 @@ > > #endif > > #endif > > > > +#if defined (__NO_FPRS__) > > +/* Skip PPC tests as possible PowerPC SPE (Signal Processing Engine) > variant */ > > +#else > > #if defined(__ppc__) || defined(__ppc64__) || defined(__PPC__) > > #define PIPE_ARCH_PPC > > #if defined(__ppc64__) || defined(__PPC64__) > > #define PIPE_ARCH_PPC_64 > > #endif > > #endif > > +#endif > > > > #if defined(__s390x__) > > #define PIPE_ARCH_S390 > > > > This is probably too big a hammer — PIPE_ARCH_PPC(_64) are used for > other things than Altivec detection. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] etnaviv: Fix missing rnndb file in tarballs
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 official tarballs since inclusion in Mesa, so the git trees
and tarballs differ.
Found due to lintian errors in the Debian packages.
Fixes: f1e1c60ff6 ("etnaviv: Update from rnndb")
---
src/gallium/drivers/etnaviv/Makefile.sources | 1 +
src/gallium/drivers/etnaviv/meson.build | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/gallium/drivers/etnaviv/Makefile.sources
b/src/gallium/drivers/etnaviv/Makefile.sources
index 05df2d9c5f..0b20812299 100644
--- a/src/gallium/drivers/etnaviv/Makefile.sources
+++ b/src/gallium/drivers/etnaviv/Makefile.sources
@@ -6,6 +6,7 @@ C_SOURCES := \
hw/state_3d.xml.h \
hw/state_blt.xml.h \
hw/state.xml.h \
+ hw/texdesc_3d.xml.h \
\
etnaviv_asm.c \
etnaviv_asm.h \
diff --git a/src/gallium/drivers/etnaviv/meson.build
b/src/gallium/drivers/etnaviv/meson.build
index 48e99d28c8..1733024ac9 100644
--- a/src/gallium/drivers/etnaviv/meson.build
+++ b/src/gallium/drivers/etnaviv/meson.build
@@ -26,6 +26,7 @@ files_etnaviv = files(
'hw/state_3d.xml.h',
'hw/state_blt.xml.h',
'hw/state.xml.h',
+ 'hw/texdesc_3d.xml.h',
'etnaviv_asm.c',
'etnaviv_asm.h',
'etnaviv_blend.c',
--
2.11.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] mesa 18.1.0
Appears that while the release notes for 18.1.0 are actually up on the website[1], the News[2] column on the main website didn't get updated, as 18.1.0 isn't listed there. 1. https://www.mesa3d.org/relnotes/18.1.0.html 2. https://www.mesa3d.org/index.html On 19 May 2018 at 09:43, wrote: > Mesa 18.1.0 is now available. > > Here is a short list of notable features compared to 18.0 > - OpenGL 3.1 with ARB_compatibility on nv50, nvc0, r600, radeonsi, > softpipe, llvmpipe, svga > - GL_ARB_bindless_texture on nvc0/maxwell+ > - GL_ARB_transform_feedback_overflow_query on nvc0 > - GL_EXT_semaphore on radeonsi > - GL_EXT_semaphore_fd on radeonsi > - GL_EXT_shader_framebuffer_fetch on i965 on desktop GL (GLES was > already supported) > - GL_EXT_shader_framebuffer_fetch_non_coherent on i965 > - GL_KHR_blend_equation_advanced on radeonsi > - Disk shader cache support for i965 enabled by default > > git tag: mesa-18.1.0 > > https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.gz > MD5: 45e5f4ae434f8e28e11838f6f4de9e32 mesa-18.1.0.tar.gz > SHA1: afaa43310b58154e2fcbc62b5f2b9e30e3cc16ca mesa-18.1.0.tar.gz > SHA256: b1c1dbb42597190503d3abc518b12de880623f097c6cb6c293ecf69ae87e6fbf > mesa-18.1.0.tar.gz > SHA512: 409ba9fc3cfe3668d82e3026d3d12b4ac816bd2732cc1f87302249142530 > 2475ab24a1e19963e1a80dadfadab8e341e71b0ed8c3acc87950378e86ea2e14bbf1 > mesa-18.1.0.tar.gz > PGP: https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.gz.sig > > https://mesa.freedesktop.org/archive/mesa-18.1.0.tar.xz > MD5: 5f4b0d414f2fcef927e465315eb6aa45 mesa-18.1.0.tar.xz > SHA1: 3da4b5f4ae3705c017a8f988f1304be45eed875f mesa-18.1.0.tar.xz > SHA256: c855c5b67ef993b7621f76d8b120769ec0415f1c3616eaff44ef7f7f300aceba > mesa-18.1.0.tar.xz > SHA512: 8b26af2df8b94373cbc339521974cd568c1d4ff4204986ee7b439e4cf3eb > e14d822ea081a7769b68eca9263b7bc6dbca01836b8bb0d6495d2e2614c4e3d601ad > mesa-18.1.0.tar.xz > PGP: https://mesa.freedesktop.org/archive/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
Re: [Mesa-dev] [PATCH 1/2] meson: Be a bit more helpful when arch or OS is unknown
On Fri, 24 Aug 2018 at 22:23, Guido Günther wrote:
>
> @@ -230,7 +236,8 @@ if _platforms.contains('auto')
>elif ['haiku'].contains(host_machine.system())
> _platforms = ['haiku']
>else
> -error('Unknown OS. Please pass -Dplatforms 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 "Unknown OS." to be "Unknown OS @0@." like all the
others?
--
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: Update FAQ with respect to s3tc support
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 100644 --- a/docs/faq.html +++ b/docs/faq.html @@ -16,7 +16,7 @@ Mesa Frequently Asked Questions -Last updated: 9 October 2012 +Last updated: 19 September 2018 @@ -371,20 +371,17 @@ the archives) is a good way to get information. -4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa? +4.3 The GL_EXT_texture_compression_s3tc feature and Mesa? -The http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt";>specification for the extension -indicates that there are intellectual property (IP) and/or patent issues -to be dealt with. +Prior to 2nd October 2017, the Mesa project did not include s3tc support due +to intellectual property (IP) and/or patent issues around the s3tc algorithm. -We've been unsuccessful in getting a response from S3 (or whoever owns -the IP nowadays) to indicate whether or not an open source project can -implement the extension (specifically the compression/decompression -algorithms). + +As of Mesa 17.3.0, Mesa now officially supports s3tc, as the patent has expired. -In the mean time, a 3rd party https://dri.freedesktop.org/wiki/S3TC";> -plug-in library is available. +In versions prior to this, a 3rd party https://dri.freedesktop.org/wiki/S3TC";> +plug-in library was required. -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] docs: Update FAQ with respect to s3tc support
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(-) diff --git a/docs/faq.html b/docs/faq.html index 1f2fd66034..6270a071da 100644 --- a/docs/faq.html +++ b/docs/faq.html @@ -16,7 +16,7 @@ Mesa Frequently Asked Questions -Last updated: 9 October 2012 +Last updated: 19 September 2018 @@ -373,18 +373,16 @@ the archives) is a good way to get information. 4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa? -The http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt";>specification for the extension -indicates that there are intellectual property (IP) and/or patent issues -to be dealt with. +Oh but it is! Prior to 2nd October 2017, the Mesa project did not include s3tc +support due to intellectual property (IP) and/or patent issues around the s3tc +algorithm. -We've been unsuccessful in getting a response from S3 (or whoever owns -the IP nowadays) to indicate whether or not an open source project can -implement the extension (specifically the compression/decompression -algorithms). + +As of Mesa 17.3.0, Mesa now officially supports s3tc, as the patent has expired. -In the mean time, a 3rd party https://dri.freedesktop.org/wiki/S3TC";> -plug-in library is available. +In versions prior to this, a 3rd party https://dri.freedesktop.org/wiki/S3TC";> +plug-in library was required. -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] docs: Update FAQ with respect to s3tc support
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 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(-) > > > > diff --git a/docs/faq.html b/docs/faq.html > > index 1f2fd66034..6270a071da 100644 > > --- a/docs/faq.html > > +++ b/docs/faq.html > > @@ -16,7 +16,7 @@ > > > > > > Mesa Frequently Asked Questions > > -Last updated: 9 October 2012 > > +Last updated: 19 September 2018 > > > > > > > > @@ -373,18 +373,16 @@ the archives) is a good way to get information. > > > > 4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in > Mesa? > > > > -The http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt";>specification > for the extension > > That link is apparently dead as well :) > > Reviewed-by: Eric Engestrom > > I assume you need someone to push this for you? > > > -indicates that there are intellectual property (IP) and/or patent issues > > -to be dealt with. > > +Oh but it is! Prior to 2nd October 2017, the Mesa project did not > include s3tc > > +support due to intellectual property (IP) and/or patent issues around > the s3tc > > +algorithm. > > > > -We've been unsuccessful in getting a response from S3 (or whoever > owns > > -the IP nowadays) to indicate whether or not an open source project can > > -implement the extension (specifically the compression/decompression > > -algorithms). > > + > > +As of Mesa 17.3.0, Mesa now officially supports s3tc, as the patent has > expired. > > > > > > -In the mean time, a 3rd party https://dri.freedesktop.org/wiki/S3TC";> > > -plug-in library is available. > > +In versions prior to this, a 3rd party https://dri.freedesktop.org/wiki/S3TC";> > > +plug-in library was required. > > > > > > > > -- > > 2.11.0 > > > > ___ > > 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] [PATCH] docs: Update FAQ with current OpenGL API version supported
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 @@ -45,7 +45,16 @@ See the https://www.opengl.org/";>OpenGL website for more information. -Mesa 9.x supports the OpenGL 3.1 specification. +Since the release of 17.0.0, Mesa supports the OpenGL 4.5 API specification. +Note that the version reported by glGetString(GL_VERSION) or +glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on +the particular driver being used. Some drivers don't support all the features +required in OpenGL 4.5. OpenGL 4.5 is only available if requested at context +creation because compatibility contexts are not supported. + + +For earlier versions, consult the release notes for the version of the +OpenGL API they support. -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vulkan: Disable randr lease for libxcb < 1.13
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_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/vulkan/wsi/wsi_common_display.c b/src/vulkan/wsi/wsi_common_display.c index e99b0465ec..e23d2983c9 100644 --- a/src/vulkan/wsi/wsi_common_display.c +++ b/src/vulkan/wsi/wsi_common_display.c @@ -2304,6 +2304,7 @@ wsi_acquire_xlib_display(VkPhysicalDevice physical_device, if (!crtc) return VK_ERROR_INITIALIZATION_FAILED; +#ifdef HAVE_DRI3_MODIFIERS xcb_randr_lease_t lease = xcb_generate_id(connection); xcb_randr_create_lease_cookie_t cl_c = xcb_randr_create_lease(connection, root, lease, 1, 1, @@ -2324,6 +2325,7 @@ wsi_acquire_xlib_display(VkPhysicalDevice physical_device, return VK_ERROR_INITIALIZATION_FAILED; wsi->fd = fd; +#endif return VK_SUCCESS; } -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: Update FAQ with current OpenGL API version supported
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 | 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 > > @@ -45,7 +45,16 @@ See the https://www.opengl.org/";>OpenGL > website for more > > information. > > > > > > -Mesa 9.x supports the OpenGL 3.1 specification. > > +Since the release of 17.0.0, Mesa supports the OpenGL 4.5 API > specification. > > +Note that the version reported by glGetString(GL_VERSION) or > > +glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) > depends on > > +the particular driver being used. Some drivers don't support all the > features > > +required in OpenGL 4.5. OpenGL 4.5 is only available if requested at > context > > +creation because compatibility contexts are not supported. > > Aren't hey supported for radeonsi these days? > Ahh yes. Sorry, think I pulled this from the 17.0.0 release notes and didn't notice the difference at the time compared to the 18.2.1 notes. Well spotted. Will update and resend. -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] docs: Update FAQ re: OpenGL API version supported
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 --- a/docs/faq.html +++ b/docs/faq.html @@ -45,7 +45,18 @@ See the https://www.opengl.org/";>OpenGL website for more information. -Mesa 9.x supports the OpenGL 3.1 specification. +Since the release of 17.0.0, Mesa supports the OpenGL 4.5 API specification. +Note that the version reported by glGetString(GL_VERSION) or +glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on +the particular driver being used. Some drivers don't support all the features +required in OpenGL 4.5. OpenGL 4.5 is only available if +requested at context creation. Compatibility contexts may report a lower +version depending on each driver. Note that compatibility contexts were not +supported prior to 18.1.0. + + +For earlier versions, consult the release notes for the version of the +OpenGL API they support. -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vulkan: Disable randr lease for libxcb < 1.13
Hi All, Can we get some feedback on this patch please? At the moment, we can't compile vulkan using libxcb < 1.13 due to the use of the RandR lease mechanism. Dave Airlie (cc'd) did some work previously to allow things to be compiled with libxcb 1.11/1.12, mainly by ifdef'ing certain code with HAVE_DRI3_MODIFIERS so that it would compile, but without the extra features that xcb 1.13+ provides. See commit 7aeef2d4efdc809a698e "dri3: allow building against older xcb (v3)" for that. The patch (originally provided by Maxime) appears to solve the new build issue, and in much the same way as Dave Airlie did with his previous patch. Note: If we "must have" xcb 1.13, then that's fine. But if that is the case, then we need to update mesa's build deps so that this is explicit (ie: effectively reverting Dave Airlie's commits on the issue). 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 > > longer works. > > > > CC: mesa-sta...@lists.freedesktop.org > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108024 > > Fixes: 7ab1fffcd2a504024b16e408de329f7a94553ecc > > Thanks for the `Fixes:` tag, it's really useful :) > We usually also add the commit title as well, to help humans know what it's > about without having to look it up (makes no difference to scripts though): > Fixes: 7ab1fffcd2a504024b16 "vulkan: Add EXT_acquire_xlib_display [v5]" > > > Tested-By: Maxime > > > > --- > > src/vulkan/wsi/wsi_common_display.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/src/vulkan/wsi/wsi_common_display.c > b/src/vulkan/wsi/wsi_common_display.c > > index e99b0465ec..e23d2983c9 100644 > > --- a/src/vulkan/wsi/wsi_common_display.c > > +++ b/src/vulkan/wsi/wsi_common_display.c > > @@ -2304,6 +2304,7 @@ wsi_acquire_xlib_display(VkPhysicalDevice > physical_device, > > if (!crtc) > >return VK_ERROR_INITIALIZATION_FAILED; > > > > +#ifdef HAVE_DRI3_MODIFIERS > > xcb_randr_lease_t lease = xcb_generate_id(connection); > > xcb_randr_create_lease_cookie_t cl_c = > >xcb_randr_create_lease(connection, root, lease, 1, 1, > > @@ -2324,6 +2325,7 @@ wsi_acquire_xlib_display(VkPhysicalDevice > physical_device, > >return VK_ERROR_INITIALIZATION_FAILED; > > > > wsi->fd = fd; > > +#endif > > > > return VK_SUCCESS; > > } > > -- > > 2.11.0 > > > > ___ > > 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
Re: [Mesa-dev] [PATCH] vulkan: Disable randr lease for libxcb < 1.13
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 feedback on this patch please? > > > > At the moment, we can't compile vulkan using libxcb < 1.13 due to the > use of the RandR lease mechanism. Dave Airlie (cc'd) did some work > previously to allow things to be compiled with libxcb 1.11/1.12, mainly by > ifdef'ing certain code with HAVE_DRI3_MODIFIERS so that it would compile, > but without the extra features that xcb 1.13+ provides. See commit > 7aeef2d4efdc809a698e "dri3: allow building against older xcb (v3)" for that. > > > > The patch (originally provided by Maxime) appears to solve the new build > issue, and in much the same way as Dave Airlie did with his previous patch. > > > > Note: If we "must have" xcb 1.13, then that's fine. But if that is the > case, then we need to update mesa's build deps so that this is explicit > (ie: effectively reverting Dave Airlie's commits on the issue). > > > > Pushed it, was building on old Ubuntu yesterday and forgot to actually > push it back out. > > Dave. > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Lets talk about autotools
Hurd:
> > >>
> > >> diff --git a/meson.build b/meson.build
> > >> index 33f4e5ad3cf..90cc0bb3af2 100644
> > >> --- a/meson.build
> > >> +++ b/meson.build
> > >> @@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
> > >> with_valgrind = get_option('valgrind')
> > >> with_libunwind = get_option('libunwind')
> > >> with_asm = get_option('asm')
> > >> +with_glx_direct= get_option('glx-direct')
>
> There should be a space between t and =
>
> > >> with_glx_read_only_text = get_option('glx-read-only-text')
> > >> with_osmesa = get_option('osmesa')
> > >> with_swr_arches = get_option('swr-arches')
> > >> @@ -370,9 +371,6 @@ if with_glvnd
> > >>endif
> > >> endif
> > >>
> > >> -# TODO: toggle for this
> > >> -with_glx_direct = true
> > >> -
> > >> if with_vulkan_icd_dir == ''
> > >>with_vulkan_icd_dir = join_paths(get_option('datadir'),
> 'vulkan/icd.d')
> > >> endif
> > >> 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
Re: [Mesa-dev] [PATCH 0/5] Fixueps for ppc64 and gnu hurd
Hi Dylan, Can't speak on Timo's behalf, but looking at the build logs for 18.3.0 (which is patched with these patches), it built fine on ppc64el (Little Endian PPC64), but hurd is having issues, tho it looks like it's not directly related to the patch you provided. Seems like the issue is that hurd is falling through the tests in src/util/os_misc.c: In function ‘os_get_total_physical_memory’ ...and ends up bailing out with: src/util/os_misc.c:173:2: error: #error unexpected platform in os_sysinfo.c Build log output for that specific build on hurd here: https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=hurd-i386&ver=18.3.0-1&stamp=1544515311&raw=0 On Tue, 18 Dec 2018 at 04:11, Dylan Baker wrote: > Quoting Timo Aaltonen (2018-12-05 03:56:54) > > On 4.12.2018 23.52, Dylan Baker wrote: > > > This little series is aimed at fixing problems reported by fedora and > debian > > > when using meson, there's a couple of patches in here for fixing ppc64 > detection > > > (tested without llvm), and a couple for gnu hurd (not tested). > > > > > > Dylan Baker (5): > > > meson: remove duplicate definition > > > meson: Fix ppc64 little endian detection > > > meson: Override C++ standard to gnu++11 when building with altivec on > > > ppc64le > > > meson: Add support for gnu hurd > > > meson: Add toggle for glx-direct > > > > > > meson.build | 33 --- > > > meson_options.txt | 6 > > > src/gallium/state_trackers/clover/meson.build | 3 ++ > > > 3 files changed, 31 insertions(+), 11 deletions(-) > > > > > > > Thanks, I'll give these a try soon. > > > > -- > > t > > Ping > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
Gert/Ilia, 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 could sleep for say 30 seconds after producing the warning message. This would be noticeable if you're building it yourself (which would definitely get the message out there), but wouldn't stop automated build processes (as it's not stopping, just sleeping). At a later date (when meson has more exposure) then perhaps we could move from a warning to an error. Thoughts? On Thu, 20 Dec 2018 at 07:37, Gert Wollny wrote: > Am Mittwoch, den 19.12.2018, 12:19 -0500 schrieb Ilia Mirkin: > > On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny > > wrote: > > > > > > Since Meson will eventually be the only build system deprecate > > > autotools > > > now. It can still be used by invoking configure with the flag > > > --enable-autotools > > > > > > Signed-off-by: Gert Wollny > > > > In case it's not clear from the later discussion: > > > > Strongly NAKed-by: Ilia Mirkin > > This should not be applied to the repository. > > You should probably add this to the patch proposals that want to remove > autotools then. > > I'm certainly not going to push this patch with your NAK, but I'd like > to ask you to reconsider: All this patch does is require to add -- > 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 > > ___ > 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
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
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 could sleep for say > > 30 seconds after producing the warning message. This would be noticeable > > if you're building it yourself (which would definitely get the message > > out there), but wouldn't stop automated build processes (as it's not > > stopping, just sleeping). > > > > At a later date (when meson has more exposure) then perhaps we could > > move from a warning to an error. > > > > Thoughts? > > So it would take 2 releases i.e. about 1/2 year? > Not necessarily. IMO if there's enough consensus between 19.0 and 19.1, then changing it to an error could happen then. I'm basing this on the fact that every .0 release specifically says something like this: > > * In next release autotools build is going to warn that meson should be > used instead, as autotools support will be eventually removed. > > * Next release from that: >- errors out if specific option isn't used for doing building with > autotools >- tells that autotools support will be removed in following release > > * Release after that removes autotools support. > > > (I assume Emil would be the person supporting Autotools during this as > he had already volunteered for it.) > > > While I think above is closer to how other large projects do deprecation > in general (= have clear deprecation period/releases), build system > changes are probably more often done just with flag day (early in the > release cycle, as maintaining multiple build systems can be pretty large > pain). > Yes, but at the moment we have no consensus and a deadlock on the issue. -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools
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 error to a warning, with the >> > command-line option suppressing the warning? >> > >> > Perhaps as well as producing the warning, the build could sleep for say >> > 30 seconds after producing the warning message. This would be >> noticeable >> > if you're building it yourself (which would definitely get the message >> > out there), but wouldn't stop automated build processes (as it's not >> > stopping, just sleeping). >> > >> > At a later date (when meson has more exposure) then perhaps we could >> > move from a warning to an error. >> > >> > Thoughts? >> >> So it would take 2 releases i.e. about 1/2 year? >> > > Not necessarily. IMO if there's enough consensus between 19.0 and 19.1, > then changing it to an error could happen then. I'm basing this on the fact > that every .0 release specifically says something like this: > Mesa 18.3.0 is a new development release. People who are concerned with stability and reliability should stick with a previous release or wait for Mesa 18.3.1. Of course, this isn't my call. I'm just trying to suggest ways to break the deadlock. * In next release autotools build is going to warn that meson should be >> used instead, as autotools support will be eventually removed. >> >> * Next release from that: >>- errors out if specific option isn't used for doing building with >> autotools >>- tells that autotools support will be removed in following release >> >> * Release after that removes autotools support. >> >> >> (I assume Emil would be the person supporting Autotools during this as >> he had already volunteered for it.) >> >> >> While I think above is closer to how other large projects do deprecation >> in general (= have clear deprecation period/releases), build system >> changes are probably more often done just with flag day (early in the >> release cycle, as maintaining multiple build systems can be pretty large >> pain). >> > > Yes, but at the moment we have no consensus and a deadlock on the issue. > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] nir: Add better helpers for handling constant sources
; > src/intel/compiler/brw_vec4_nir.cpp | 190 --- > > src/intel/compiler/brw_vec4_tcs.cpp | 6 +- > > .../vulkan/anv_nir_apply_pipeline_layout.c| 15 +- > > .../vulkan/anv_nir_lower_ycbcr_textures.c | 6 +- > > 30 files changed, 423 insertions(+), 499 deletions(-) > > ___ > 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
Re: Headless OpenGL Rendering using SSH and X11 forwarding
Hi Richard,
If your program works without X11 forwarding but doesn't work WITH X11
forwarding (on the same remote machine), then perhaps the easiest thing
might be to unset the DISPLAY variable using something like unsetenv() or
putenv() from cstdlib / stdlib.h within your program?
Of course, this assumes that you want that program to not bother with X11
output to you (remotely) at all. If that's not the case, then you'd
definitely need to look into the other methods people have described.
On Wed, 8 Mar 2023 at 12:17, Richard Haney wrote:
> Please help,
>
> I have been going around and around with this problem but cannot seem to
> make any headway. I hope that one of you OpenGL EGL experts can help. [image:
> :slight_smile:]
>
> I have created a program that uses OpenGL EGL (version 1.5) with OpenGL 3
> that successfully renders an offscreen triangle and saves it to an image
> file (PNG) when I ssh *without* X11 forwarding on my Linux (Ubuntu 22.04)
> machine.
>
> However when I try the same thing using ssh *with* X11 forwarding enabled
> I get the following EGL error when I call eglInitialize(…): 12290 (I
> *think* is EGL_BAD_ACCESS).
>
> This seems really weird and I hope it is something simple that I am just
> not currently seeing.
>
> I really like using OpenGL with EGL but need a way to remedy this
> situation if possible. Is there a way for EGL to determine if X11
> forwarding is being employed and to ignore it or some other solution?
>
> The snippet of relevant C++ code follows, with area where error occurs
> marked:
>
> #include #include #include #define
> EGL_EGLEXT_PROTOTYPES #define GL_GLEXT_PROTOTYPES #include
> #include ... EGLDisplay display =
> eglGetDisplay(EGL_DEFAULT_DISPLAY);
> if(display == EGL_NO_DISPLAY) { std::cerr << "Failed to get EGL display: "
> << eglGetError() << std::endl; exit(EXIT_FAILURE); } EGLint major; EGLint
> minor; if(eglInitialize(display, &major, &minor) == 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)
Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits
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
Re: [Mesa-dev] [PATCH] Call shmget() with permission 0600 instead of 0777
Not my call, but both of these went into my gmail spam folder for DMARC
failures, so a lot of people might not have seen it.
On Fri, 25 Oct 2019 at 08:25, Brian Paul wrote:
> Ping. Anyone?
>
> -Brian
>
> On Tue, Oct 22, 2019 at 3:52 PM Brian Paul wrote:
>
>> A security advisory (TALOS-2019-0857/CVE-2019-5068) found that
>> creating shared memory regions with permission mode 0777 could allow
>> any user to access that memory. Several Mesa drivers use shared-
>> memory XImages to implement back buffers for improved performance.
>>
>> This path changes the shmget() calls to use 0600 (user r/w).
>>
>> Tested with legacy Xlib driver and llvmpipe.
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>> ---
>> src/gallium/winsys/sw/dri/dri_sw_winsys.c | 3 ++-
>> src/gallium/winsys/sw/xlib/xlib_sw_winsys.c | 3 ++-
>> src/mesa/drivers/x11/xm_buffer.c| 3 ++-
>> 3 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
>> b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
>> index 761f5d1..2e5970b 100644
>> --- a/src/gallium/winsys/sw/dri/dri_sw_winsys.c
>> +++ b/src/gallium/winsys/sw/dri/dri_sw_winsys.c
>> @@ -92,7 +92,8 @@ alloc_shm(struct dri_sw_displaytarget *dri_sw_dt,
>> unsigned size)
>> {
>> char *addr;
>>
>> - dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777);
>> + /* 0600 = user read+write */
>> + dri_sw_dt->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600);
>> if (dri_sw_dt->shmid < 0)
>>return NULL;
>>
>> diff --git a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
>> b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
>> index c14c9de..edebb48 100644
>> --- a/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
>> +++ b/src/gallium/winsys/sw/xlib/xlib_sw_winsys.c
>> @@ -126,7 +126,8 @@ alloc_shm(struct xlib_displaytarget *buf, unsigned
>> size)
>> shminfo->shmid = -1;
>> shminfo->shmaddr = (char *) -1;
>>
>> - shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT|0777);
>> + /* 0600 = user read+write */
>> + shminfo->shmid = shmget(IPC_PRIVATE, size, IPC_CREAT | 0600);
>> if (shminfo->shmid < 0) {
>>return NULL;
>> }
>> diff --git a/src/mesa/drivers/x11/xm_buffer.c
>> b/src/mesa/drivers/x11/xm_buffer.c
>> index d945d8a..0da08a6 100644
>> --- a/src/mesa/drivers/x11/xm_buffer.c
>> +++ b/src/mesa/drivers/x11/xm_buffer.c
>> @@ -89,8 +89,9 @@ alloc_back_shm_ximage(XMesaBuffer b, GLuint width,
>> GLuint height)
>>return GL_FALSE;
>> }
>>
>> + /* 0600 = user read+write */
>> b->shminfo.shmid = shmget(IPC_PRIVATE,
>> b->backxrb->ximage->bytes_per_line
>> -* b->backxrb->ximage->height,
>> IPC_CREAT|0777);
>> + * b->backxrb->ximage->height, IPC_CREAT |
>> 0600);
>> if (b->shminfo.shmid < 0) {
>> _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
