Re: [Mesa-dev] [PATCH 1/4] i965: Switch mapping modes for non-explicit-flush blit-temporary maps.
Any reason why these patches are not applied in current GIT other than
lack of review? I was kind of hoping that maybe some of them can
impact Dota 2 perf, since it seems that Dota 2 is memory bandwidth
limited.
On Thu, Feb 27, 2014 at 11:53 PM, Eric Anholt wrote:
> On LLC, it should always be better to use a cached mapping than the GTT.
> On non-LLC, it seems pretty silly to try to optimize read performance for
> the INVALIDATE_RANGE_BIT case. This will make the buffer_storage logic
> easier.
> ---
> src/mesa/drivers/dri/i965/intel_buffer_objects.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> index e6124dc..5bf4533 100644
> --- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> +++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> @@ -421,11 +421,11 @@ intel_bufferobj_map_range(struct gl_context * ctx,
> "range map",
> length + extra,
> alignment);
> -if (!(access & GL_MAP_READ_BIT)) {
> - drm_intel_gem_bo_map_gtt(intel_obj->range_map_bo[index]);
> -} else {
> +if (brw->has_llc) {
> drm_intel_bo_map(intel_obj->range_map_bo[index],
> (access & GL_MAP_WRITE_BIT) != 0);
> +} else {
> + drm_intel_gem_bo_map_gtt(intel_obj->range_map_bo[index]);
> }
> obj->Mappings[index].Pointer =
> intel_obj->range_map_bo[index]->virtual + extra;
> --
> 1.9.rc1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Interesting i965 behavior: more fast color clears not helping dota2
On Wed, Oct 30, 2013 at 2:43 PM, Paul Berry wrote: > - What percentage of clears are affected by this patch? Even with this > patch, some clears still won't take the fast path (e.g. stencil clears, MSAA > color clears, and scissored clears). > When I was doing my Wine tweaks for the Windows Dota 2 client, the biggest win by far was disabling GL_SCISSOR_TEST to enable fast depth clear. Additionally, Chris mentioned this in chat regarding Dota 2: "weird viewport is badness". ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965/gen7: Set MOCS L3 cacheability for IVB/BYT
On Tue, Sep 3, 2013 at 9:19 PM, Ville Syrjälä wrote: > On Thu, Aug 15, 2013 at 10:39:31PM +0200, Vedran Rodic wrote: >> > We do have the set_caching ioctl. It's enough to flip the PTEs to UC and >> > let MOCS manage things. I actually did a few experiments on my IVB. I >> > made all Mesa's buffers UC via PTEs by patching libdrm to change the >> > cache mode of each bo after allocation. Then I fiddled with the MOCS >> > LLC bits in various ways. It definitely has an effect, sometimes making >> > things slower, sometimes faster. xonotic again seemed to benefit. IIRC >> > leaving everything LLC uncached was actually the fastest (w/ high quality >> > at least) so we may be thrashing the LLC a bit there. But eg. reaction >> > quake regressed quite a lot if most things were left as UC. >> >> Can you share the libdrm patch? > > Sorry, forgot to reply. > > Here's the patch if you're still interested. Thanks, Just as a data point, I tried my OpenGL test application (Dota 2 on Wine with my patches to enable fast depth clear), and performance doesn't change when I use libdrm with your patch applied. I also disabled all MOCS_L3 stuff for my IVB, still no changes. Vedran ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965/gen7: Set MOCS L3 cacheability for IVB/BYT
> We do have the set_caching ioctl. It's enough to flip the PTEs to UC and > let MOCS manage things. I actually did a few experiments on my IVB. I > made all Mesa's buffers UC via PTEs by patching libdrm to change the > cache mode of each bo after allocation. Then I fiddled with the MOCS > LLC bits in various ways. It definitely has an effect, sometimes making > things slower, sometimes faster. xonotic again seemed to benefit. IIRC > leaving everything LLC uncached was actually the fastest (w/ high quality > at least) so we may be thrashing the LLC a bit there. But eg. reaction > quake regressed quite a lot if most things were left as UC. Can you share the libdrm patch? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] i965/gen7: Set MOCS L3 cacheability for IVB/BYT
On Mon, Aug 12, 2013 at 3:07 PM, wrote: > From: Ville Syrjälä > > IVB/BYT also has the same L3 cacheability control in MOCS as HSW, > so let's make use of it. According to the discussion we had on #intel-gfx a few weeks ago, on IVB all Mesa memory is already marked as cached in DRM allocated PTEs. So this should not have any effect. Or I'm misunderstanding something. As I understand, marking everything uncacheable and then marking just certain things cacheable could make a difference (since AFAIK, you can't mark select regions as uncacheable after you mark PTEs as cacheable on IVB). Can somebody more knowledgeable comment? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Enable GLX TLS by default in Mesa?
On Tue, Aug 13, 2013 at 7:19 PM, Kenneth Graunke wrote: > > > As far as I know, --enable-glx-tls just makes things more efficient. > > Nothing should *rely* on it, or even be able to detect it... Dota 2 crashes without that option when loading the actual game map. I assumed it adds thread safety. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Enable GLX TLS by default in Mesa?
Hi, I've been burned with the issue of GLX TLS not being enabled by default in Mesa (Dota 2 seems to rely on it). What's the rationale of not enabling it by default? Thanks, Vedran Rodic ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2] i965: fix alpha test for MRT
Sorry, please ignore me, sending fake patches through gmail is not my a thing. :) But please apply the fix from Chris. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2] i965: fix alpha test for MRT
Can we pretend this came from Chris so it can be applied sooner rather
than later ? :)
Include src0 alpha in the RT write message when using MRT, so it is used
for the alpha test instead of the normal per-RT alpha value.
No Piglit regressions on Ivybridge.
V2: reuse (and simplify) existing sample_alpha_to_coverage flag in
the FS key, rather than adding another redundant one.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62647
NOTE: This is a candidate for the stable branches.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_fs_emit.cpp| 4 +---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +--
src/mesa/drivers/dri/i965/brw_wm.c | 10 ++
src/mesa/drivers/dri/i965/brw_wm.h | 2 +-
4 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index f390989..c158016 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -127,9 +127,7 @@ fs_generator::generate_fb_write(fs_inst *inst)
retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
brw_set_compression_control(p, BRW_COMPRESSION_NONE);
- if (inst->target > 0 &&
- c->key.nr_color_regions > 1 &&
- c->key.sample_alpha_to_coverage) {
+ if (inst->target > 0 && c->key.replicate_alpha) {
/* Set "Source0 Alpha Present to RenderTarget" bit in message
* header.
*/
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index a67b6ed..3353f55 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2254,8 +2254,7 @@ fs_visitor::emit_fb_writes()
if (header_present) {
src0_alpha_to_render_target = intel->gen >= 6 &&
!do_dual_src &&
-c->key.nr_color_regions > 1 &&
-c->key.sample_alpha_to_coverage;
+c->key.replicate_alpha;
/* m2, m3 header */
nr += 2;
}
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index 6eb4a1d..5f681f6 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -277,8 +277,8 @@ brw_wm_debug_recompile(struct brw_context *brw,
old_key->flat_shade, key->flat_shade);
found |= key_debug(intel, "number of color buffers",
old_key->nr_color_regions, key->nr_color_regions);
- found |= key_debug(intel, "sample alpha to coverage",
- old_key->sample_alpha_to_coverage,
key->sample_alpha_to_coverage);
+ found |= key_debug(intel, "MRT alpha test or alpha-to-coverage",
+ old_key->replicate_alpha, key->replicate_alpha);
found |= key_debug(intel, "rendering to FBO",
old_key->render_to_fbo, key->render_to_fbo);
found |= key_debug(intel, "fragment color clamping",
@@ -461,8 +461,10 @@ static void brw_wm_populate_key( struct brw_context *brw,
/* _NEW_BUFFERS */
key->nr_color_regions = ctx->DrawBuffer->_NumColorDrawBuffers;
- /* _NEW_MULTISAMPLE */
- key->sample_alpha_to_coverage = ctx->Multisample.SampleAlphaToCoverage;
+
+ /* _NEW_MULTISAMPLE, _NEW_COLOR, _NEW_BUFFERS */
+ key->replicate_alpha = ctx->DrawBuffer->_NumColorDrawBuffers > 1 &&
+ (ctx->Multisample.SampleAlphaToCoverage || ctx->Color.AlphaEnabled);
/* BRW_NEW_VUE_MAP_GEOM_OUT */
if (intel->gen < 6)
diff --git a/src/mesa/drivers/dri/i965/brw_wm.h
b/src/mesa/drivers/dri/i965/brw_wm.h
index 28e8734..57db27f 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.h
+++ b/src/mesa/drivers/dri/i965/brw_wm.h
@@ -62,7 +62,7 @@ struct brw_wm_prog_key {
GLuint stats_wm:1;
GLuint flat_shade:1;
GLuint nr_color_regions:5;
- GLuint sample_alpha_to_coverage:1;
+ GLuint replicate_alpha:1;
GLuint render_to_fbo:1;
GLuint clamp_fragment_color:1;
GLuint line_aa:2;
--
1.8.3.2
On Tue, Jul 2, 2013 at 8:46 PM, Ian Romanick wrote:
> On 07/02/2013 01:42 AM, Chris Forbes wrote:
>>
>> Include src0 alpha in the RT write message when using MRT, so it is used
>> for the alpha test instead of the normal per-RT alpha value.
>>
>> Fixes broken rendering in Dota2 under Wine [FDO #62647].
>
>
> Could you use the normative bugzilla reference, and add a note for the
> stable branches. :)
>
>
>> No Piglit regressions on Ivybridge.
>>
>> V2: reuse (and simplify) existing sample_alpha_to_coverage flag in
>> the FS key, rather than adding another redundant one.
>>
>> Signed-off-by: Chris Forbes
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_emit.cpp| 4 +---
>> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +--
>> src/mesa/drivers/dri/i965/brw_wm.c | 10 ++
>> src/mesa/drivers/dri/i965/brw_wm.h | 2 +-
>> 4 files changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
>> b/sr
Re: [Mesa-dev] [PATCH] i965: Don't disable unused shader stages from BLORP.
Yes, it is fixed now. I had to revert the proposed patch from beginning of this thread too. Thank you, Vedran On Tue, Jun 11, 2013 at 7:54 PM, Kenneth Graunke wrote: > On 06/10/2013 10:55 PM, Vedran Rodic wrote: >> >> On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke >> wrote: >>> >>> >>> Vedran, >>> >>> Can you try this patch and see if it solves your GPU hang issues? I >>> still >>> haven't been able to reproduce it, but I believe I may just be getting >>> lucky. >>> >> >> Nope, with this one it's even worse. >> >> Before after the initial hang glretrace would finish "normally" (I >> guess, though I've seen some screen corruption with 2D font rendering >> afterwards), but with this patch the hangs are happening multiple >> times. >> >> As I've said earlier, I'm not using an accelerated compositor, just simple >> LXDE. >> >> DDX is latest from git, kernel is 3.9.4, and I've confirmed the bug >> with just simple glxgears. >> >> I can reproduce it every time after a clean reboot. > > > Okay, I was able to reproduce this with a clean reboot and starting X with > SNA, xterm, and then glxgears, with nothing else running. I did later see > font corruption in Firefox. I was also able to reproduce the hangs with > UXA. > > I've pushed a revert for "i965: Disable unused pipeline stages once at > startup on Gen7+." Does this fix the GPU hangs for you? > > --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't disable unused shader stages from BLORP.
My other sw info: Running Ubuntu 13.04 64bit, with xorg edgers ppa, so my base installation is mesa e54c924a0e9b9a504eae1eb68daaf51f21689629 currently and when I'm testing the new mesa I'm setting LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH to my $HOME/src/mesa/lib (I do this before I run glxgears for this issue for example). On Tue, Jun 11, 2013 at 7:55 AM, Vedran Rodic wrote: > On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke > wrote: >> >> Vedran, >> >> Can you try this patch and see if it solves your GPU hang issues? I still >> haven't been able to reproduce it, but I believe I may just be getting lucky. >> > > Nope, with this one it's even worse. > > Before after the initial hang glretrace would finish "normally" (I > guess, though I've seen some screen corruption with 2D font rendering > afterwards), but with this patch the hangs are happening multiple > times. > > As I've said earlier, I'm not using an accelerated compositor, just simple > LXDE. > > DDX is latest from git, kernel is 3.9.4, and I've confirmed the bug > with just simple glxgears. > > I can reproduce it every time after a clean reboot. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't disable unused shader stages from BLORP.
On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke wrote: > > Vedran, > > Can you try this patch and see if it solves your GPU hang issues? I still > haven't been able to reproduce it, but I believe I may just be getting lucky. > Nope, with this one it's even worse. Before after the initial hang glretrace would finish "normally" (I guess, though I've seen some screen corruption with 2D font rendering afterwards), but with this patch the hangs are happening multiple times. As I've said earlier, I'm not using an accelerated compositor, just simple LXDE. DDX is latest from git, kernel is 3.9.4, and I've confirmed the bug with just simple glxgears. I can reproduce it every time after a clean reboot. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] i965: Disable unused pipeline stages once at startup on Gen7+.
> And just any old GL application hangs it? Nothing specific? > Yes, i tried some glretraces, shader toy in chrome (webgl). Hangs on both. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] i965: Disable unused pipeline stages once at startup on Gen7+.
>> This is my CPU: >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 58 >> model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz >> stepping : 9 >> microcode : 0x12 > > > Yikes. I definitely tested this on my HD 4000. What kernel are you using > (uname -a)? Linux 3.9.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/8] i965: Disable unused pipeline stages once at startup on Gen7+.
Hi,
This patch makes my Ivy Bridge hang when starting an OpenGL application:
[ 30.835248] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 30.835255] [drm] capturing error event; look for more information
in/sys/kernel...
This is my CPU:
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz
stepping : 9
microcode : 0x12
On Sat, Jun 8, 2013 at 9:01 PM, Kenneth Graunke wrote:
> This removes a tiny bit of code from our drawing loop.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_state.h| 4 +++-
> src/mesa/drivers/dri/i965/brw_state_upload.c | 5 -
> src/mesa/drivers/dri/i965/gen7_disable.c | 13 ++---
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_state.h
> b/src/mesa/drivers/dri/i965/brw_state.h
> index 7215128..62d5efc 100644
> --- a/src/mesa/drivers/dri/i965/brw_state.h
> +++ b/src/mesa/drivers/dri/i965/brw_state.h
> @@ -111,7 +111,6 @@ extern const struct brw_tracked_state
> gen7_cc_state_pointer;
> extern const struct brw_tracked_state gen7_cc_viewport_state_pointer;
> extern const struct brw_tracked_state gen7_clip_state;
> extern const struct brw_tracked_state gen7_depth_stencil_state_pointer;
> -extern const struct brw_tracked_state gen7_disable_stages;
> extern const struct brw_tracked_state gen7_ps_state;
> extern const struct brw_tracked_state gen7_push_constant_alloc;
> extern const struct brw_tracked_state gen7_samplers;
> @@ -215,6 +214,9 @@ uint32_t
> get_attr_override(const struct brw_vue_map *vue_map, int
> urb_entry_read_offset,
>int fs_attr, bool two_side_color, uint32_t
> *max_source_attr);
>
> +/* gen7_disable.c */
> +void gen7_disable_unused_stages(struct brw_context *brw);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index 6a69a67..fa9b5af 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -211,7 +211,6 @@ static const struct brw_tracked_state *gen7_atoms[] =
> &gen7_samplers,
> &gen6_multisample_state,
>
> - &gen7_disable_stages,
> &gen7_vs_state,
> &gen7_sol_state,
> &gen7_clip_state,
> @@ -252,6 +251,10 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
>return;
>
> brw_upload_invariant_state(brw);
> +
> + if (intel->gen >= 7) {
> + gen7_disable_unused_stages(brw);
> + }
> }
>
> void brw_init_state( struct brw_context *brw )
> diff --git a/src/mesa/drivers/dri/i965/gen7_disable.c
> b/src/mesa/drivers/dri/i965/gen7_disable.c
> index aaf88a8..c152d0a 100644
> --- a/src/mesa/drivers/dri/i965/gen7_disable.c
> +++ b/src/mesa/drivers/dri/i965/gen7_disable.c
> @@ -26,8 +26,8 @@
> #include "brw_defines.h"
> #include "intel_batchbuffer.h"
>
> -static void
> -disable_stages(struct brw_context *brw)
> +void
> +gen7_disable_unused_stages(struct brw_context *brw)
> {
> struct intel_context *intel = &brw->intel;
>
> @@ -123,12 +123,3 @@ disable_stages(struct brw_context *brw)
> OUT_BATCH(0);
> ADVANCE_BATCH();
> }
> -
> -const struct brw_tracked_state gen7_disable_stages = {
> - .dirty = {
> - .mesa = 0,
> - .brw = BRW_NEW_CONTEXT,
> - .cache = 0,
> - },
> - .emit = disable_stages,
> -};
> --
> 1.8.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Intel HD4000 Epic Citadel (Unreal Engine WebGL demo) performance regression and some comparisons with Windows
As Eric suggested in the bug, setting layers.acceleration.force-enabled (current Mesa git + patch series to fix Y tiling) frame-rate goes to 43.7 FPS, compared to 40.5 FPS in Windows 7 (latest Intel drivers). Congratulations, we're faster than Windows (assuming that Windows aren't blacklisted too) :) On Sat, May 4, 2013 at 4:15 PM, Vedran Rodic wrote: > Hi, > > I bisected a performance regression here: > https://bugs.freedesktop.org/show_bug.cgi?id=64213 > > Here's some benchmark numbers: > > Core i5-3320M, Firefox 23 nightly build 2013-05-04 > > Epic Citadel 1920x1080 (browser window maximized, not game screen) > > Windows 40.5 FPS > > Linux mesa git: 18.9 FPS 2013-05-04 with tiling fix > > Linux mesa 9.1.1: 18.9 FPS > > Vedran ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Intel HD4000 Epic Citadel (Unreal Engine WebGL demo) performance regression and some comparisons with Windows
Hi, I bisected a performance regression here: https://bugs.freedesktop.org/show_bug.cgi?id=64213 Here's some benchmark numbers: Core i5-3320M, Firefox 23 nightly build 2013-05-04 Epic Citadel 1920x1080 (browser window maximized, not game screen) Windows 40.5 FPS Linux mesa git: 18.9 FPS 2013-05-04 with tiling fix Linux mesa 9.1.1: 18.9 FPS Vedran ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
