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)
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
On 29/06/15 13:26, Francisco Jerez wrote:
Davin McCall dav...@davmac.org writes:
On 29/06/15 10:40, Francisco Jerez wrote:
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:53, Francisco Jerez wrote:
[...]
Your first approach seemed quite reasonable IMHO. Were you able to
measure
Davin McCall dav...@davmac.org 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 29/06/15 10:40, Francisco Jerez wrote:
Davin McCall dav...@davmac.org 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
Davin McCall dav...@davmac.org writes:
On 29/06/15 10:40, Francisco Jerez wrote:
Davin McCall dav...@davmac.org 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 dav...@davmac.org writes:
On 29/06/15 10:40, Francisco Jerez wrote:
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:53, Francisco Jerez wrote:
[...]
Your first approach seemed quite reasonable IMHO. Were you able to
measure
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
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez curroje...@riseup.net
wrote:
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 1:23 PM,
Francisco Jerez curroje...@riseup.net writes:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez curroje...@riseup.net
wrote:
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by
On 26/06/15 14:53, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:55, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n'
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by
Davin McCall dav...@davmac.org writes:
On 26/06/15 13:18, Francisco Jerez wrote:
Davin McCall dav...@davmac.org writes:
On 26/06/15 11:08, Erik Faye-Lund wrote:
On Thu, Jun 25, 2015 at 1:48 AM, Davin McCall dav...@davmac.org wrote:
This is an alternative to my earlier patch [1] (and it is
On Fri, Jun 26, 2015 at 3:05 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:55, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org wrote:
On 26/06/15 12:03, Davin McCall wrote:
... The stored value of 'n' is not accessed by any other type than
On Fri, Jun 26, 2015 at 4:01 PM, Francisco Jerez curroje...@riseup.net wrote:
Davin McCall dav...@davmac.org writes:
On 26/06/15 14:31, Eirik Byrkjeflot Anonsen wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org wrote:
On
On Fri, Jun 26, 2015 at 5:25 PM, Francisco Jerez curroje...@riseup.net wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 4:53 PM, Francisco Jerez curroje...@riseup.net
wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 4:16 PM, Davin McCall
On Thu, Jun 25, 2015 at 1:48 AM, Davin McCall dav...@davmac.org 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 *'
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org 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
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 it
On 26/06/15 12:55, Erik Faye-Lund wrote:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org 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.
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, Jun 26, 2015 at 1:23 PM, Davin McCall dav...@davmac.org 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
On 26/06/15 11:08, Erik Faye-Lund wrote:
On Thu, Jun 25, 2015 at 1:48 AM, Davin McCall dav...@davmac.org 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
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
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 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
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
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
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
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
-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 changes.
31 matches
Mail list logo
