On 11/02/17 12:03, Timothy Arceri wrote:
>
>
> On 10/02/17 21:43, Nicolai Hähnle wrote:
>> On 07.02.2017 04:42, Timothy Arceri wrote:
>>> From: Timothy Arceri
>>>
>>> This will be used to store all pointers in the cache as 64bit ints
>>> allowing us to avoid issues when a 32bit program reads a cac
On 02/07/15 14:58, Neil Roberts wrote:
Davin McCall writes:
I actually had thought about this, but technically, you can only use
unions for type aliasing if you perform all accesses (that are not to
the 'active' member) through the union. All the list processing code
that iterates t
On 01/07/15 16:46, Eero Tamminen wrote:
Hi,
On 06/30/2015 01:15 AM, Davin McCall wrote:
This is the third iteration of a patch to resolve a strict aliasing
problem in the exec_list structure.
At the suggestion of Francisco Jerez this is a return to the original
(v1) style of the patch, which
Re-post, where lines are hopefully not wrapped.
Davin
From b946157dcac2ca198ccf1981151525a1fc3ae39f Mon Sep 17 00:00:00 2001
From: Davin McCall
Date: Sat, 27 Jun 2015 13:48:41 +0100
Subject: [PATCH] glsl: fix some strict aliasing issues in exec_list
There is a problem in exec_list due to it
Hi Neil,
On 01/07/15 17:08, Neil Roberts wrote:
If we wanted to avoid growing the size of exec_list to four pointers
instead of three, maybe we could store it in a union like below:
struct exec_list {
union {
struct {
struct exec_node head_sentinel;
struct exec_no
On 01/07/15 13:32, Eero Tamminen wrote:
Hi,
On 06/25/2015 04:56 PM, Davin McCall wrote:
On 25/06/15 14:32, Eero Tamminen wrote:
On 06/25/2015 03:53 PM, Davin McCall wrote:
On 25/06/15 12:27, Eero Tamminen wrote:
On 06/25/2015 02:48 AM, Davin McCall wrote:
In terms of performance:
(export
This is the third iteration of a patch to resolve a strict aliasing
problem in the exec_list structure.
At the suggestion of Francisco Jerez this is a return to the original
(v1) style of the patch, which replaces the three 'exec_node *' members
in the list with two 'struct exec_node' members.
On 29/06/15 13:26, Francisco Jerez wrote:
Davin McCall writes:
On 29/06/15 10:40, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 14:53, Francisco Jerez wrote:
[...]
Your first approach seemed quite reasonable IMHO. Were you able to
measure any performance regression from it
On 29/06/15 13:26, Francisco Jerez wrote:
Davin McCall writes:
On 29/06/15 10:40, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 14:53, Francisco Jerez wrote:
[...]
Your first approach seemed quite reasonable IMHO. Were you able to
measure any performance regression from it
On 29/06/15 10:40, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 14:53, Francisco Jerez wrote:
[...]
Your first approach seemed quite reasonable IMHO. Were you able to
measure any performance regression from it?
Thanks.
When I run an apitrace replay of a Dota 2 trace [1] with
On 26/06/15 14:53, Francisco Jerez wrote:
[...]
Your first approach seemed quite reasonable IMHO. Were you able to
measure any performance regression from it?
Thanks.
When I run an apitrace replay of a Dota 2 trace [1] with
LIBGL_ALWAYS_SOFTWARE and without the patch I get (averaged over
On 26/06/15 17:08, Eirik Byrkjeflot Anonsen wrote:
Davin McCall writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not a
On 26/06/15 14:53, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 13:18, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 11:08, Erik Faye-Lund wrote:
On Thu, Jun 25, 2015 at 1:48 AM, Davin McCall wrote:
This is an alternative to my earlier patch [1] (and it is now
On 26/06/15 15:29, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall wrote:
On 26/06/15 14:53, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall wrote:
[...]
It is. In fact, it's not even possible to violate strict-aliasing
without doing at leas
On 26/06/15 14:53, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall wrote:
On 26/06/15 12:55, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by any
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by any other type than the
type of n itself. This value is then
On 26/06/15 13:18, Francisco Jerez wrote:
Davin McCall writes:
On 26/06/15 11:08, Erik Faye-Lund wrote:
On Thu, Jun 25, 2015 at 1:48 AM, Davin McCall wrote:
This is an alternative to my earlier patch [1] (and it is now constructed
properly using git format-patch).
Quick background:
There
On 26/06/15 12:55, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by any other type than the
type of n itself. This value is then cast to a different pointer type. You
ar
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by any other type than the
type of n itself. This value is then cast to a different pointer type.
You are mistaken if you think that the cast accesses the stored value
of n. The other "stored val
On 26/06/15 11:08, Erik Faye-Lund wrote:
On Thu, Jun 25, 2015 at 1:48 AM, Davin McCall wrote:
This is an alternative to my earlier patch [1] (and it is now constructed
properly using git format-patch).
Quick background:
There is a problem in exec_list due to it directly including a trio
of
On 25/06/15 14:32, Eero Tamminen wrote:
Hi,
On 06/25/2015 03:53 PM, Davin McCall wrote:
On 25/06/15 12:27, Eero Tamminen wrote:
On 06/25/2015 02:48 AM, Davin McCall wrote:
In terms of performance:
(export LIBGL_ALWAYS_SOFTWARE=1; time glmark2)
For Intel driver, INTEL_NO_HW=1 could be used
On 25/06/15 14:32, Eero Tamminen wrote:
Hi,
On 06/25/2015 03:53 PM, Davin McCall wrote:
On 25/06/15 12:27, Eero Tamminen wrote:
On 06/25/2015 02:48 AM, Davin McCall wrote:
In terms of performance:
(export LIBGL_ALWAYS_SOFTWARE=1; time glmark2)
For Intel driver, INTEL_NO_HW=1 could be used
Hi Eero,
On 25/06/15 12:27, Eero Tamminen wrote:
Hi,
On 06/25/2015 02:48 AM, Davin McCall wrote:
In terms of performance:
(export LIBGL_ALWAYS_SOFTWARE=1; time glmark2)
For Intel driver, INTEL_NO_HW=1 could be used.
(Do other drivers have something similar?)
Unfortunately I do not have
On 25/06/15 01:13, Dave Airlie wrote:
-fno-strict-aliasing:with strict aliasing:
libGL.so 699188 699188(no change)
*_dri.so 9575876 9563104(-2772)
Use the size command to get the actual text segment size,
otherwise
This is an alternative to my earlier patch [1] (and it is now constructed
properly using git format-patch).
Quick background:
There is a problem in exec_list due to it directly including a trio
of 'struct exec_node *' members to implement two overlapping sentinel
nodes. The sentinel nodes do not
On 24/06/15 03:35, Ian Romanick wrote:
I'd also like to see assembly dumps with and without
-fno-strict-aliasing of some place where this goes wrong. If you,
Davin, or someone else can point out a specific function that actually
does the wrong thing, I can generate assembly myself. For that
ma
On 24/06/15 03:35, Ian Romanick wrote:
On 06/23/2015 07:01 PM, Dave Airlie wrote:
Oh we've always had aliasing problems this is just one, you can't
expect one person to fix them all at once.
But "With this patch, I can build a working (though perhaps not 100%
bug-free) Mesa without using -fno-
Hi Ian,
On 23/06/15 23:26, Ian Romanick wrote:
On 06/23/2015 02:36 PM, Thomas Helland wrote:
2015-06-24 23:05 GMT+02:00 Davin McCall :
Hi - I'm new here.
I've recently started poking the Mesa codebase for little reason other than
personal interest. In the "help wanted" se
Hi Ilia (and Matt and Thomas)
On 23/06/15 22:30, Ilia Mirkin wrote:
The biggest part of the process is to send a proper commit to the
mailing list. There are two issues with your mailing (without
commenting on your actual changes) --
(a) The patch is attached, not inlined
(b) You sent a diff, n
Hi - I'm new here.
I've recently started poking the Mesa codebase for little reason other
than personal interest. In the "help wanted" section of the website it
mentions aliasing violations as a target for newcomers to fix, so with
that in mind I've attached a patch (against git head) which re
30 matches
Mail list logo