Hello Marek
instead of utilizing jemalloc, I strongly recommend you take a look (for
example) at:
- classes such as ir_copy_propagation_elements_visitor
- file glcpp-parse.y
and to put optimizations and better algorithms in there.
Eliminating the causes of malloc-like calls will result in
On Sat, Aug 6, 2016 at 4:32 PM, Jan Vesely wrote:
> sure I can set LD_BIND_NOW
> env var, but there are programs that have much stronger case for using
> lazy binding (like LO) that would be negatively affected.
What is "LO"?
___
mesa-dev mailing list
m
On Sat, Aug 6, 2016 at 4:32 PM, Jan Vesely wrote:
> On Sat, 2016-08-06 at 13:00 +0200, ⚛ wrote:
>> We could add a verifier to the build process that tests the
>> foo_dri.so
>> libraries (as well as all other libs subject to dlopen by Mesa) for
>> undefined symbols:
>
On Sat, Aug 6, 2016 at 5:52 PM, Jan Vesely wrote:
> The situation I'm concerned about is as
> follows:
> 1.) mesa builds fine using existing build environment.
>
> 2.) I update LLVM. This update changes symbols (function parameter
> changed type, a function was moved to header, or devirtualization
On Mon, Aug 8, 2016 at 6:22 PM, Ian Romanick wrote:
> I'm pretty sure this breaks ABI. Did you try using an unpatched libGL
> with a patched *_dri.so (and vice-versa)?
Can you be more specific?
Where is the ABI documented?
___
mesa-dev mailing list
me
Hello
https://patchwork.freedesktop.org/series/10079/ has been merged to
master but it is still marked as "new" at patchwork.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Aug 8, 2016 at 7:14 PM, Ian Romanick wrote:
> On 08/08/2016 09:38 AM, ⚛ wrote:
>> On Mon, Aug 8, 2016 at 6:22 PM, Ian Romanick wrote:
>>> I'm pretty sure this breaks ABI. Did you try using an unpatched libGL
>>> with a patched *_dri.so (and vice-versa)
On Mon, Aug 15, 2016 at 8:08 PM, Emil Velikov wrote:
>
> On 4 August 2016 at 03:13, Nicolas Boichat wrote:
> > Thanks! See also related series here, which fixes the other platforms:
> > https://lists.freedesktop.org/archives/mesa-dev/2016-August/125147.html
> >
> > Fixes: 9ee683f877 (egl/dri2: Ad
I am marking this patch as (de-facto) rejected at Patchwork.
Reason: The patch moved from the 1st page to the 2nd page of
https://patchwork.freedesktop.org/project/mesa/series/?ordering=-last_updated
Although I am letting it go you can still merge it to master if you want to.
On Wed, Jul 27, 201
I am marking this patch as rejected at Patchwork.
Reason: The patch moved from the 1st page to the 2nd page of
https://patchwork.freedesktop.org/project/mesa/series/?ordering=-last_updated
Although I am letting it go you can still merge it to master if you want to.
___
It's an incompatibility between two rule systems.
On Mon, Aug 22, 2016 at 7:09 PM, Jason Ekstrand wrote:
>
> You don't need to send an e-mail to the list every time you change something
> in patchwork. Also, there's really nothing special about the first page of
> the patch series list. Stuff
On Mon, Aug 22, 2016 at 7:24 PM, Rob Clark wrote:
> On Mon, Aug 22, 2016 at 12:58 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> I am marking this patch as rejected at Patchwork.
>>
>> Reason: The patch moved from the 1st page to the 2nd page of
>> https://patch
On Mon, Aug 22, 2016 at 7:47 PM, Matt Turner wrote:
> On Mon, Aug 22, 2016 at 10:41 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> On Mon, Aug 22, 2016 at 7:24 PM, Rob Clark wrote:
>>> On Mon, Aug 22, 2016 at 12:58 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>>>&
On Mon, Aug 22, 2016 at 7:47 PM, Matt Turner wrote:
> On Mon, Aug 22, 2016 at 10:41 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> On Mon, Aug 22, 2016 at 7:24 PM, Rob Clark wrote:
>>> On Mon, Aug 22, 2016 at 12:58 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>>>&
On Mon, Aug 22, 2016 at 8:22 PM, Alex Deucher wrote:
> On Mon, Aug 22, 2016 at 1:57 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> On Mon, Aug 22, 2016 at 7:47 PM, Matt Turner wrote:
>>> On Mon, Aug 22, 2016 at 10:41 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>>>
I am marking this patch as (de-facto) rejected at Patchwork.
Reason: The patch moved from the 1st page to the 2nd page of
https://patchwork.freedesktop.org/project/mesa/series/?ordering=-last_updated
Although I am letting it go you can still merge it to master if you want to.
On Tue, Oct 18, 2016 at 12:45 AM, Thomas Helland
wrote:
> I can't quite tell, as Gmail tends to mangle whitespace stuff,
> but it looks like there might be some style issues with
> not everything following the three-space indent, no tabs
> policy that mesa tries to stick to.
I followed the 3-spac
Hello
I would like to test http://patchwork.freedesktop.org/series/9987/ and
http://patchwork.freedesktop.org/series/9988/ but the mbox patches
aren't compatible with mesa-git.
Would it be possible to update 9987 and 9988 to match mesa-git?
Do 9987 and 9988 assume additional public patches that
nded.
>
> The second one will take some time I guess.
>
> This branch contains both, but it won't be merged in this form:
> https://cgit.freedesktop.org/~mareko/mesa/log/?h=si-mid-ib-gfx-fence
>
> Marek
>
> On Tue, Jul 19, 2016 at 3:53 PM, ⚛ <0xe2.0x9a.0...@gmail.com&
On Wed, Jul 20, 2016 at 3:10 PM, Marek Olšák wrote:
> Did you test this?
> https://cgit.freedesktop.org/~mareko/mesa/commit/?h=si-mid-ib-gfx-fence&id=a993d93a16da86ef1ead4a55aed969752ad3965a
I compiled your git branch and tested some games.
Bioshock Infinite benchmark on Ultra settings goes from
GCC 6.1 -O3
Mesa 12.1.0-devel (git-d2b4b16)
Some line numbers provided below may be off by a few lines.
List of warnings generated AFTER
http://patchwork.freedesktop.org/series/9204/ rev 2 has been applied:
*
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/mesa/state_tracker/st_glsl_
On Wed, Jul 27, 2016 at 12:15 PM, Eric Engestrom
wrote:
> The version change is good and would get my r-b, but the LLVM_COMPONENTS
> change would need some testing to make sure it doesn't interfere with
> anything before enabling it for everyone.
I am unable to imagine how it could interfere.
___
On Wed, Jul 27, 2016 at 2:44 PM, Emil Velikov wrote:
> On 27 July 2016 at 12:36, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
>> ---
>> configure.ac | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletions(-)
>>
>> diff
On Wed, Jul 27, 2016 at 3:44 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> On Wed, Jul 27, 2016 at 2:44 PM, Emil Velikov
> wrote:
>> On 27 July 2016 at 12:36, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>>> diff --git a/configure.ac b/configure.ac
>>&g
On Mon, Aug 1, 2016 at 2:46 PM, Eric Engestrom
wrote:
> On Sun, Jul 31, 2016 at 05:49:02PM +0200, Jan Ziak wrote:
>> Signed-off-by: Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com>
>
> This is a good change, and with a couple things to fix below, it is:
> Reviewed-by: Eric Engestrom
>
On Tue, Aug 2, 2016 at 4:13 PM, Brian Paul wrote:
> In bufferobj.c, it looks like we're just using %d or %s and casting the
> arguments to int. But in other places, we're using %ld and casting to long.
> That's not going to accurately report 64-bit values, but I guess that hasn't
> been a concern
Your patch created rev4 at https://patchwork.freedesktop.org/series/10429/
I just created rev5 which no longer includes field hasPresent.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Aug 5, 2016 at 2:34 PM, Eric Engestrom
wrote:
> On Wed, Aug 03, 2016 at 01:22:35PM +0200, Jan Ziak wrote:
> It is customary to put [PATCH vN] in the subject to keep track of which
> version is current, as well as to add a description of what changed
> since the previous version, here, afte
> Most people just consume the emails/patches directly via their email client.
> You can make the subject be generated properly by passing -vN to git
> format-patch.
I think I will create a tool for me.
___
mesa-dev mailing list
mesa-dev@lists.freedesk
On Sat, Aug 6, 2016 at 3:37 AM, Jan Vesely wrote:
> On Sat, 2016-08-06 at 02:42 +0200, Jan Ziak wrote:
>> Mesa source code prior to this patch uses both RTLD_NOW and
>> RTLD_LAZY.
>> This patch removes all RTLD_NOW in favor of RTLD_LAZY.
>>
>> In comparison to early binding, lazy binding reduces C
On Sat, Aug 6, 2016 at 4:34 AM, Rob Clark wrote:
> On Fri, Aug 5, 2016 at 8:42 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>> Mesa source code prior to this patch uses both RTLD_NOW and RTLD_LAZY.
>> This patch removes all RTLD_NOW in favor of RTLD_LAZY.
>>
>> In comparison to early binding, la
After applying the patch, I was able to build Mesa with flex-2.5.39. Thanks.
On Thu, Feb 4, 2016 at 7:19 AM, Tapani Pälli wrote:
> Reviewed-by: Tapani Pälli
>
>
> On 02/03/2016 10:04 PM, Matt Turner wrote:
>
>> Reported-by: Jan Ziak <0xe2.0x9a.0...@gmail.com>
>> Bugzilla: https://bugs.freedeskt
Hello
I would like to make a few comments about wiki pages such as
https://www.freedesktop.org/wiki/AccountRequests/
At first glance, the wiki page feels very old-school. That isn't a major
problem by itself, because retro-things can have their own distinct
quality. Unfortunately, I do not see th
Hello.
Please add "Drivers/Gallium/swr" to the list "Component" at
https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Thanks.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hello.
http://en.cppreference.com/w/cpp/thread/future
http://en.cppreference.com/w/cpp/thread/async
Assumption: Shader compilation will need run on separate thread(s).
>From a certain perspective, one of the easy ways of removing Mesa shader
compilation from the "main" thread would be to use std
This patch enables compilation with -flto.
The performance benefits of LTO (GCC 4.9 & 6.1) are about 1% for glxgears.
Performance changes in OpenGL games haven't been measured yet, my feeling
is that they are negligible.
diff --git a/configure.ac b/configure.ac
index fc0b1db..e84a1ad 100644
--- a/
On Mon, May 30, 2016 at 8:07 PM, Pierre Moreau wrote:
> On 07:28 PM - May 30 2016, ⚛ wrote:
>> +if COMPILER_UNDERSTANDS_LTO
>> +CFLAGS += -fno-lto
>> +CXXFLAGS += -fno-lto
>
> This should be `-flto` if I’m not mistaken.
>
> Pierre
-fno-lto is correct bec
On Mon, May 30, 2016 at 9:27 PM, Emil Velikov wrote:
> - Are you use the mapi hunk is needed ? last time I've tried (some
> months ago, copying the tweaks from the Clearlinux spec file [2])
> things built without issues.
I tried Clearlinux today, but I failed to execute rpmbuild on the
mesa.src.
On Tue, May 31, 2016 at 8:04 PM, Chuck Atkins wrote:
> Agreed. I've been building on both Fedora and EL7 for the past few months
> with -flto and haven't seen any issues with the files in mapi. You reported
> that you get build failures with gcc for this though so what is your
> particular build
On Tue, May 31, 2016 at 8:30 PM, Aaron Watry wrote:
>
> Given the header that it's failing in, I removed the --enable-glx-tls flag,
> and then things built successfully.
mesa.spec in
http://download.clearlinux.org/releases/8490/clear/source/SRPMS/mesa-11.2.99.1-21.src.rpm
seems to be using both
On Wed, Jun 1, 2016 at 2:19 PM, Marek Olšák wrote:
> I'll let you figure it out by yourself.
Why would you withhold information if you already have it? Are you a
"bad person" or something?
As far as my memory goes, I have never posted the sentence "I'll let
you figure it out by yourself" to the
On Wed, Jun 1, 2016 at 2:19 PM, Marek Olšák wrote:
> On Fri, May 27, 2016 at 8:49 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> Hello.
>>
>> http://en.cppreference.com/w/cpp/thread/future
>> http://en.cppreference.com/w/cpp/thread/async
>>
>> Assumption:
On Wed, Jun 1, 2016 at 3:50 PM, Erik Faye-Lund wrote:
> On Wed, Jun 1, 2016 at 3:02 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> On Wed, Jun 1, 2016 at 2:19 PM, Marek Olšák wrote:
>>> I'll let you figure it out by yourself.
>>
>> Why would you withhold info
On Wed, Jun 1, 2016 at 3:53 PM, Marek Olšák wrote:
> Because of external factors you can't predict, your driver suddenly
> receives a bunch of shaders that take 2000 ms to compile right before
> a draw call. Your budget is 16 ms per frame to get 30 fps, but you
> can't render the frame if you don'
On Wed, Jun 1, 2016 at 4:06 PM, Brian Paul wrote:
> I think the issue here is someone comes along with no history in the project
> and asserts that he has a great solution for a problem
Asynchronous computation is an essential part of the solution to the
problem (problem == faster compiler respon
Some R9 390 results:
Tomb Raider (normal settings): 80 -> 88 FPS
Talos Principle (custom settings): 23 -> 56 FPS
Metro Last Light Redux (default benchmark settings): 39 -> 40 FPS
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.free
to -O2 -DNDEBUG" succeeds with GCC 4.9 and 5.3
The patch assumes that the assembler understands ".hidden" directive.
Signed-off-by: Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com>
---
src/mapi/entry_x86-64_tls.h | 5 +++--
src/mapi/entry_x86_tls.h| 12 +---
2 files chan
Hello.
The patch has moved to
http://lists.freedesktop.org/archives/mesa-dev/2016-June/119257.html (
http://patchwork.freedesktop.org/series/8176/)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/me
Hello
Situation: Looking at the content displayed by the web browser for URL
http://patchwork.freedesktop.org/project/mesa/series and sub-pages
accessible via the links.
The following questions are troubling me:
- How does a patch submitter know when a reviewer will take a look at the patch?
- W
On Fri, Jun 3, 2016 at 2:08 PM, Nicolai Hähnle wrote:
> On 03.06.2016 13:12, wrote:
>>
>> Situation: Looking at the content displayed by the web browser for URL
>> http://patchwork.freedesktop.org/project/mesa/series and sub-pages
>> accessible via the links.
>
>
> Patchwork isn't really central t
On Fri, Jun 3, 2016 at 5:54 PM, Ilia Mirkin wrote:
> On Fri, Jun 3, 2016 at 11:49 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> On Fri, Jun 3, 2016 at 2:08 PM, Nicolai Hähnle wrote:
>>> On 03.06.2016 13:12, wrote:
>>>>
>>>> Situation: Looking at
On Fri, Jun 3, 2016 at 6:32 PM, Patrick Baggett
wrote:
> While I agree with the principle of what you're saying (the process
> can be improved, etc.), being extremely sarcastic and condescending is
> not the best way to effect change.
Can you please point out which part of the *1st* message in th
Valgrind detected that variable ir_copy_propagation_visitor::killed_all
is uninitialized.
Signed-off-by: Jan Ziak (⚛) atom-symbol.net <0xe2.0x9a.0...@gmail.com>
---
src/compiler/glsl/opt_copy_propagation.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compile
Hello
I would like to keep the number of lines displayed at
http://patchwork.freedesktop.org/project/mesa/patches/?submitter=15850
to a low number.
0 is the best, 1 or 2 is meh...ok, 3+ is too much. Seeing 0 lines
allows me to move on and start working on the next patch.
From my viewpoint, the i
between a name and substance/content.
> On Mon, 2016-06-06 at 12:11 +0200, ⚛ wrote:
>> Hello
>>
>> I would like to keep the number of lines displayed at
>> http://patchwork.freedesktop.org/project/mesa/patches/?submitter=1585
>> 0
>> to a low number.
>>
On Wed, Jun 1, 2016 at 7:07 PM, Marek Olšák wrote:
> On Wed, Jun 1, 2016 at 6:06 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>> On Wed, Jun 1, 2016 at 3:53 PM, Marek Olšák wrote:
>>> Because of external factors you can't predict, your driver suddenly
>>> receive
On Mon, Jun 6, 2016 at 12:40 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> I apologize for the confusion. I won't happen again.
Typo: "I won't ..." -> "It won't ..."
___
mesa-dev mailing list
mesa-dev@list
On Mon, Jun 6, 2016 at 1:12 PM, Emil Velikov wrote:
>
> Hi Jan,
>
> Fwiw I fully agree on your point on outstanding patches.
>
> Now about this patch itself.
>
> On 2 June 2016 at 18:41, Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com> wrote:
> > LTO compilation can som
On Mon, Jun 6, 2016 at 3:39 PM, Mike Lothian wrote:
>
> This doesn't seem to affect me using GCC 6.1 and gold
I don't have GCC 6.1 installed at the moment, and it takes quite long
to install it on Gentoo.
Can you please send me the output of the following command?
$ cd mesa/src/mapi
$ make clea
On Mon, Jun 6, 2016 at 9:01 PM, Mike Lothian wrote:
>
> I'm running Gentoo too, it didn't take significantly longer to compile GCC
> 6.1 than any other version of GCC
>
> I use portage to compile mesa
Ok. What is the output of a command like:
$ ls --sort=time /var/log/portage/media-libs:mesa-*.
On Mon, Jun 6, 2016 at 1:12 PM, Emil Velikov wrote:
> On 2 June 2016 at 18:41, Jan Ziak (⚛) <0xe2.0x9a.0...@gmail.com> wrote:
>> LTO compilation can sometimes fail with GCC 4.9 and GCC 5.3 because
>> src/mapi uses unusual mixing of C code and assembly code. The issue
>>
On Tue, Jun 7, 2016 at 2:43 AM, Timothy Arceri
wrote:
> On Mon, 2016-06-06 at 12:33 +0200, ⚛ wrote:
>> On Mon, Jun 6, 2016 at 12:29 PM, Timothy Arceri
>> wrote:
>> >
>> > I'm pretty sure someone told you this already. But you need to
>> > remove
&g
Hello
Mesa 12.1.0-devel (git-8c3ecde) has rendering issues when running
"glxgears -samples N" with N >= 1 on R9 390. It was running ok
yesterday/previously.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
Hello. Are you editing those files by hand?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hello.
The result file at
http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
multiple issues, some of them are:
[Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 has a
performance regression on R9 290
[Major issue] R7 370 yields 133 FPS in Tesseract, while R9 285
unexpec
On Mon, Jun 20, 2016 at 3:36 PM, Nicolai Hähnle wrote:
> On 20.06.2016 11:59, wrote:
>>
>> Hello.
>>
>> The result file at
>> http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
>> multiple issues, some of them are:
>>
>> [Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 ha
Hi, there are minor rendering glitches in Shadow of Mordor on R9 390.
git-59156b2 + this patch v2. I can send a screenshot if you are unable to
reproduce this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/
67 matches
Mail list logo
