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 L
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 LIBGL_ALWAYS_SOFTWARE=1; time glmark2)
F
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?
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?
Thanks
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
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
> LIBGL_ALWAYS_SOFTWA
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
Davin McCall writes:
> 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:
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 accessed by an
Francisco Jerez writes:
> Erik Faye-Lund writes:
>
>> On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez
>> 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
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 accessed by any other type than the
> type of
On Fri, Jun 26, 2015 at 5:32 PM, Davin McCall wrote:
> 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 ev
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 const
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 least two oper
On Fri, Jun 26, 2015 at 5:25 PM, Francisco Jerez wrote:
> Erik Faye-Lund writes:
>
>> On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez
>> wrote:
>>> Erik Faye-Lund writes:
>>>
On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall wrote:
> On 26/06/15 14:53, Erik Faye-Lund wrote:
>>
>
Erik Faye-Lund writes:
> On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez
> 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 McC
Erik Faye-Lund writes:
> On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez
> wrote:
>> Erik Faye-Lund writes:
>>
>>> 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:
>>
>
On Fri, Jun 26, 2015 at 5:09 PM, Erik Faye-Lund wrote:
> On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez
> wrote:
>> Erik Faye-Lund writes:
>>
>>> 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, Da
On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez wrote:
> Erik Faye-Lund writes:
>
>> 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:
>
> On 26/06/15 12:55, Erik Faye-Lund wr
On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez 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 valu
Erik Faye-Lund writes:
> 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:
On 26/06/15 12:55, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall wrot
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:
>>>
>>> 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, Davi
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 other type th
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 accessed by any other type than the
> type of
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 other type than the
> type of n itself. This v
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 constructed
> properly using
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 cast to a differe
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 cast to a different pointer type. You
>>> are mistaken i
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 i
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
are mistaken if
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 is a problem in exec_lis
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
>> are mistaken if you think that the cast access
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 value" access that i
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 'st
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 'struct exec_node *' members to impl
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,
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.
(Do other drivers have something simila
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 a
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?)
-fno-strict-aliasing:
glmark2 Score: 244
real5m34.707s
user11m36.192s
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
> -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 debugging symbols can drown change
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
44 matches
Mail list logo
