On Thu, Jul 19, 2012 at 10:25 PM, Marek Olšák wrote:
> On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote:
>> On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote:
>>> I actually care a lot about lockups. Well, you are complaing about
>>> lockups, yet you have quite obvious bugs in your hyperz
On Fri, Jul 20, 2012 at 4:17 AM, Jerome Glisse wrote:
> On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote:
>> I actually care a lot about lockups. Well, you are complaing about
>> lockups, yet you have quite obvious bugs in your hyperz code, so let's
>> fix them first. (I wouldn't even try and
On Thu, Jul 19, 2012 at 10:06 PM, Marek Olšák wrote:
> I actually care a lot about lockups. Well, you are complaing about
> lockups, yet you have quite obvious bugs in your hyperz code, so let's
> fix them first. (I wouldn't even try and run the hyperz code in its
> current state. Please don't tak
I actually care a lot about lockups. Well, you are complaing about
lockups, yet you have quite obvious bugs in your hyperz code, so let's
fix them first. (I wouldn't even try and run the hyperz code in its
current state. Please don't take that personally.) Then, if the
lockups persist, we can start
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
> When downsampling a compressed multisampled surface, we can take a
> shortcut to downsample any pixels that were completely covered by a
> single primitive. In this case, the first color value we fetch is the
> correct final color for the down
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
> This patch series makes three improvements to the blorp engine (which
> does MSAA resolves and other blits) for Gen7:
>
> Patches 1-3 fix downsampling of integer format framebuffers on Gen7,
> by using the "AVG" instruction to average the sampl
On Thu, Jul 19, 2012 at 9:00 PM, Marek Olšák wrote:
> On Fri, Jul 20, 2012 at 1:34 AM, Jerome Glisse wrote:
>> On Thu, Jul 19, 2012 at 6:07 PM, Marek Olšák wrote:
>>> I have these issues with the patch:
>>>
>>> 1) On GPUs without a vertex cache, you flush the texture cache every
>>> draw operati
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
> When downsampling from an MSAA image to a single-sampled image, it is
> inevitable that some loss of numerical precision will occur, since we
> have to use 32-bit floating point registers to hold the intermediate
> results while blending. Howe
On Fri, Jul 20, 2012 at 1:34 AM, Jerome Glisse wrote:
> On Thu, Jul 19, 2012 at 6:07 PM, Marek Olšák wrote:
>> I have these issues with the patch:
>>
>> 1) On GPUs without a vertex cache, you flush the texture cache every
>> draw operation. Are you kidding?
>
> Show me one app with perf regressio
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
> Previously, on Gen7, when texturing from a depth or stencil surface,
> the blorp engine would configure the 3D pipeline as though the input
> surface was non-multisampled, and perform the necessary coordinate
> transformations in the fragment s
https://bugs.freedesktop.org/show_bug.cgi?id=52282
Bug #: 52282
Summary: [softpipe] piglit arb_shader_texture_lod-texgrad
regression
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
> Previously, on Gen7, compute_msaa_layout_for_pipeline() would verify
> that IMS layout is not used. However, now that we configure
> SURFACE_STATE correctly for IMS surfaces, IMS layout is available.
> ---
> src/mesa/drivers/dri/i965/brw_blor
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
> This patch modifies gen7_set_surface_num_multisamples() to set up the
> SURFACE_STATE appropriately for texturing from IMS format MSAA
> surfaces (which are only used on Gen7 for depth and stencil buffers).
> Since the function now sets more th
On Thu, Jul 19, 2012 at 10:13 AM, Eric Anholt wrote:
> Ken Phillis Jr writes:
>
>> Hi, I am looking to enter the Xorg EVoC for 2012, and am wanting to Implement
>> two Core extensions for OpenGL 4.0 and GLSL 4.00.
>>
>>
>>
>
On Thu, Jul 19, 2012 at 12:54 PM, Brian Paul wrote:
> Hi Jordan,
>
> I'd like to see this patch committed so I can do some follow-on
> re-org. Just minor comments below.
Do you mean you would like to see it committed before the
rest of the series?
I'll fix your other recommendations.
Thanks,
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
> When downsampling an integer-format buffer on Gen7, we need to use the
> "avg" instruction rather than the "add" instruction, to ensure that we
> don't overflow the range of 32-bit integers. Also, we need to use the
> proper register type (BRW
Use $(TOP_SRCDIR) in the static Makefile, but use
a more specific variable for glapi_gen.mk now.
---
src/mapi/es1api/Makefile |4 ++--
src/mapi/glapi/gen/glapi_gen.mk | 14 +++---
src/mapi/shared-glapi/Makefile.am |2 --
3 files changed, 9 insertions(+), 11 deletions(-
Useful while the static Makefiles are still alive.
---
configs/current.in |4 +++-
configure.ac | 15 ++-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/configs/current.in b/configs/current.in
index dc0dea8..ea926d5 100644
--- a/configs/current.in
+++ b/con
This makes it possible to share sources.mak with the
Android build again.
v2: Keep $(TOP) variable that is actually used by an
included Makefile.
---
src/mapi/glapi/Makefile.am|5 +++--
src/mapi/mapi/sources.mak | 25 ++---
src/mapi/shared-glapi/Makefile.
https://bugs.freedesktop.org/show_bug.cgi?id=38970
ajax at nwnk dot net changed:
What|Removed |Added
AssignedTo|a...@nwnk.net |xunx.f...@intel.com
--- Comment #
I have these issues with the patch:
1) On GPUs without a vertex cache, you flush the texture cache every
draw operation. Are you kidding?
2) All colorbuffers / streamout buffers are flushed, even those which
are not enabled. E.g. instead of flushing only CB0 when there is only
one, this code flus
On 07/19/2012 02:41 PM, Kenneth Graunke wrote:
Calling glDeleteShader() should mark shaders as pending for deletion,
but shouldn't decrement the refcount every time. Otherwise, repeated
glDeleteShader() is not safe.
This is particularly bad since glDeleteProgram() frees shaders: if you
first ca
On Thu, Jul 12, 2012 at 10:43 AM, Paul Berry wrote:
>
> From the Ivy Bridge PRM, Vol4 Part3 p152:
>
> "The avg instruction performs component-wise integer average of
> src0 and src1 and stores the results in dst. An integer average
> uses integer upward rounding. It is equivalent to in
Paul Berry writes:
> Previously, the code for setting this flag for GLSL programs was
> duplicated in three places: brw_link_shader(), glsl_to_tgsi_visitor,
> and ir_to_mesa_visitor. In addition to the unnecessary duplication,
> there was a performance problem on i965: brw_link_shader() set the
Calling glDeleteShader() should mark shaders as pending for deletion,
but shouldn't decrement the refcount every time. Otherwise, repeated
glDeleteShader() is not safe.
This is particularly bad since glDeleteProgram() frees shaders: if you
first call glDeleteShader() on the shaders attached to th
On Thu, Jul 19, 2012 at 3:26 PM, Kristian Høgsberg wrote:
> On Thu, Jul 19, 2012 at 2:44 PM, Jose Fonseca wrote:
>>
>>
>> - Original Message -
>>> This commit is causing build failures in several platforms because
>>> EGL_WL_bind_wayland_display is defined everywhere (including
>>> window
This patch ensures that integers will pass through unscathed. Doing
(useless) computations on them is risky, especially when their bit
patterns correspond to values like inf or nan.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_clip_util.c | 48 ++--
At this point all interpolation tests with fixed clipping work.
Signed-off-by: Olivier Galibert
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip.c |9 ++
src/mesa/drivers/dri/i965/brw_clip.h |1 +
src/mesa/drivers/dri/i965/brw_clip_util.c | 147 +
At that point, all interpolation piglit tests involving fixed clipping
work as long as there's no noperspective.
Signed-off-by: Olivier Galibert
Reviewed-by: Paul Berry
---
src/mesa/drivers/dri/i965/brw_clip.c | 13 --
src/mesa/drivers/dri/i965/brw_clip.h |6 +--
src
This patch also correct a couple of problems with noperspective
interpolation.
At that point all the glsl 1.1/1.3 interpolation tests that do not
clip pass (the -none ones).
The fs code does not use the pre-resolved interpolation modes in order
not to mess with gen6+. Sharing the resolution woul
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_clip.c| 90 ++-
src/mesa/drivers/dri/i965/brw_clip.h|1 +
src/mesa/drivers/dri/i965/brw_context.h | 11
sr
Shaders, piglit test ones in particular, may write only to one of
gl_FrontColor/gl_BackColor. The standard is unclear on whether the
behaviour is defined in that case, but it seems reasonable to support
it.
The choice done there to pick up whichever color was actually written
to. That makes most
Previous code only selected two side in pure fixed-function setups.
This version also activates it when needed with shaders programs.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_sf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri
This patch is mostly designed to make followup patches simpler, but
it's a simplification by itself.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_sf_emit.c | 93 +--
1 file changed, 52 insertions(+), 41 deletions(-)
diff --git a/src/mesa/driver
In some cases the fragment shader view of the vue registers was out of
sync with the builder. This fixes it.
Signed-off-by: Olivier Galibert
---
src/mesa/drivers/dri/i965/brw_fs.cpp |9 -
src/mesa/drivers/dri/i965/brw_wm_pass2.c | 10 +-
2 files changed, 17 insertions(
Hi,
This is the second verion of the clipping/interpolation patches.
Main differences:
- I tried to take all of Paul's remarks into account
- I exploded the first patch in 4 independant ones
- I've added a patch to ensure that integers pass through unscathed
Patch 4/9 is (slightly) controversi
Hi Jordan,
I'd like to see this patch committed so I can do some follow-on
re-org. Just minor comments below.
On Wed, Jul 11, 2012 at 3:58 PM, Jordan Justen
wrote:
> _mesa_is_integer_format is moved to formats.c and renamed
> as _mesa_is_enum_format_integer.
>
> _mesa_is_format_unsigned, _mesa
https://bugs.freedesktop.org/show_bug.cgi?id=47375
--- Comment #3 from Brian Paul 2012-07-19 19:31:37 PDT
---
(In reply to comment #2)
> same bug with a radeon 9000 card ( M9 ) :
>
> OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2
>
> blender crashs with this message w
On Thu, Jul 19, 2012 at 2:44 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> This commit is causing build failures in several platforms because
>> EGL_WL_bind_wayland_display is defined everywhere (including
>> windows), and not just on platforms where wayland-drm.h exists.
Yes, I s
https://bugs.freedesktop.org/show_bug.cgi?id=52250
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Someone tried to be clever and "optimized" add_vertex_data2() to just use
two points for the texture coordinates and then reuse individual
components. Sadly this is not how matrix multiplication works.
Fixes rendercheck -t tmcoords
Signed-off-by: Lucas Stach
---
src/gallium/state_trackers/xorg/
On Thu, Jul 19, 2012 at 10:57:38AM -0600, Brian Paul wrote:
>
> static const float ...
Indeed.
> Reviewed-by: Brian Paul
Thanks. Could you commit it please?
Best,
OG.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=52277
Bug #: 52277
Summary: src/gallium/state_trackers/egl/common/egl_g3d_api.c:43
:25: fatal error: wayland-drm.h: No such file or
directory
Classification: Unclassified
Pro
- Original Message -
> This commit is causing build failures in several platforms because
> EGL_WL_bind_wayland_display is defined everywhere (including
> windows), and not just on platforms where wayland-drm.h exists.
Actually it is more subtle. On scons + cross mingw it fails as:
Co
This commit is causing build failures in several platforms because
EGL_WL_bind_wayland_display is defined everywhere (including windows), and not
just on platforms where wayland-drm.h exists.
Don't know why it was not failing before though.
I'm not very familiar with the st/egl code, but should
On 07/19/2012 11:00 AM, nobled wrote:
> This (sort of) reverts commit 5154b45217695e5daf24110bcff043fa1959d0a5
> "mapi: Fix Android build"
> ---
> src/mapi/Android.mk | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/src/mapi/Android.mk b/src/mapi/Android
On 07/19/2012 10:59 AM, nobled wrote:
> This makes it possible to share sources.mak with the
> Android build again.
> ---
>
> Still todo: sharing this with the SConscript build, which still
> duplicates the list of sources.
>
> src/mapi/glapi/Makefile.am|4 +++-
> src/mapi/mapi/sourc
This (sort of) reverts commit 5154b45217695e5daf24110bcff043fa1959d0a5
"mapi: Fix Android build"
---
src/mapi/Android.mk | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/mapi/Android.mk b/src/mapi/Android.mk
index d1749a2..9d54210 100644
--- a/src/mapi/And
This makes it possible to share sources.mak with the
Android build again.
---
Still todo: sharing this with the SConscript build, which still
duplicates the list of sources.
src/mapi/glapi/Makefile.am|4 +++-
src/mapi/mapi/sources.mak | 25 ++---
src/map
On Thu, Jul 19, 2012 at 09:39:09 -0700, Ian Romanick wrote:
> On 07/19/2012 07:46 AM, Julien Cristau wrote:
> >From: Julien Cristau
> >
> >We were stomping on the caller's buffer by ignoring their alignment
> >requests. This patch makes the USE_XCB path match the older one more
> >closely.
> >
>
The kill_emitted variable was duplicating the functionality of
gl_fragment_program::UsesKill. There's no need for both.
---
src/mesa/drivers/dri/i965/brw_fs.h |1 -
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |4 +---
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git
Previously, the code for setting this flag for GLSL programs was
duplicated in three places: brw_link_shader(), glsl_to_tgsi_visitor,
and ir_to_mesa_visitor. In addition to the unnecessary duplication,
there was a performance problem on i965: brw_link_shader() set the
flag before doing its final r
On 07/19/2012 10:55 AM, Olivier Galibert wrote:
The cube sampler generates two-dimensional texture coordinates and
hence passes NULL for the array for the third one. The actual 2D
sampler, lower in the pipe, knew not to used that array since it
didn't need it. But the samplers have become singl
The cube sampler generates two-dimensional texture coordinates and
hence passes NULL for the array for the third one. The actual 2D
sampler, lower in the pipe, knew not to used that array since it
didn't need it. But the samplers have become single-texel and the
coordinate array dereference has b
On 07/19/2012 07:46 AM, Julien Cristau wrote:
From: Julien Cristau
Doing
size = reply.length * 4;
[...]
extra = 4 - (size & 3);
is useless, size & 3 will always be 0.
Signed-off-by: Julien Cristau
Reviewed-by: Ian Romanick
---
src/mapi/glapi/gen/glX_proto_send.
On 07/19/2012 07:46 AM, Julien Cristau wrote:
From: Julien Cristau
We were stomping on the caller's buffer by ignoring their alignment
requests. This patch makes the USE_XCB path match the older one more
closely.
Signed-off-by: Julien Cristau
Say
Bugzilla: https://bugs.freedesktop.org/sho
https://bugs.freedesktop.org/show_bug.cgi?id=44345
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 07/19/2012 01:46 AM, Kenneth Graunke wrote:
Presumably the function didn't exist when we wrote this code.
Signed-off-by: Kenneth Graunke
Reviewed-by: Ian Romanick
---
src/glsl/ast_to_hir.cpp | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/glsl
On 07/19/2012 07:36 AM, Paul Berry wrote:
On 18 July 2012 15:11, Kenneth Graunke mailto:kenn...@whitecape.org>> wrote:
On 07/18/2012 12:16 PM, Paul Berry wrote:
> This patch series cleans up a bug fix I made to Mesa on June 22
> (commit 82d2596: i965: Compute dFdy() correctly for F
On Thu, Jul 19, 2012 at 7:46 AM, Julien Cristau wrote:
> From: Julien Cristau
>
> Doing
> size = reply.length * 4;
> [...]
> extra = 4 - (size & 3);
>
> is useless, size & 3 will always be 0.
>
> Signed-off-by: Julien Cristau
> ---
> src/mapi/glapi/gen/glX_proto_send.py
On Thu, Jul 19, 2012 at 1:46 AM, Kenneth Graunke wrote:
> Presumably the function didn't exist when we wrote this code.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/ast_to_hir.cpp | 16 +---
> 1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/src/glsl/ast_to_hir
https://bugs.freedesktop.org/show_bug.cgi?id=52250
Lucas Stach changed:
What|Removed |Added
CC|d...@lynxeye.de |
--
Configure bugmail: https://bugs.free
Ken Phillis Jr writes:
> Hi, I am looking to enter the Xorg EVoC for 2012, and am wanting to Implement
> two Core extensions for OpenGL 4.0 and GLSL 4.00.
>
>
>
> Name:
> Piglit - Implement Tessellation shaders Extensi
Hi Halley,
I don't think we need to create YUYV buffers in GBM. For test cases,
it's fine to just use libdrm-intel directly, like what I've done here:
http://cgit.freedesktop.org/~krh/simple-yuv
and for real use-cases, libva will use libdrm-intel directly.
Kristian
On Thu, Jul 19, 2012 at 5
https://bugs.freedesktop.org/show_bug.cgi?id=52059
Julien Cristau changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Julien Crista
From: Julien Cristau
Doing
size = reply.length * 4;
[...]
extra = 4 - (size & 3);
is useless, size & 3 will always be 0.
Signed-off-by: Julien Cristau
---
src/mapi/glapi/gen/glX_proto_send.py |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/
From: Julien Cristau
We were stomping on the caller's buffer by ignoring their alignment
requests. This patch makes the USE_XCB path match the older one more
closely.
Signed-off-by: Julien Cristau
---
src/mapi/glapi/gen/glX_proto_send.py | 36 -
1 files chang
On Tue, Jul 17, 2012 at 7:58 PM, wrote:
> From: Jerome Glisse
>
> htile is used for HiZ and HiS support and fast Z/S clears.
> This commit just adds the htile setup and Fast Z clear.
> We don't take full advantage of HiS with that patch.
>
> v2 really use fast clear, still random issue with some
On Don, 2012-07-19 at 10:38 -0400, Kristian Høgsberg wrote:
> On Thu, Jul 19, 2012 at 8:39 AM, Michel Dänzer wrote:
> > On Don, 2012-07-19 at 01:15 -0600, Scott Moreau wrote:
> >> gbm_bo_get_pitch was renamed to gbm_bo_get_stride. eglkms fails
> >> to build against mesa master without this.
> >>
On Thu, Jul 19, 2012 at 8:39 AM, Michel Dänzer wrote:
> On Don, 2012-07-19 at 01:15 -0600, Scott Moreau wrote:
>> gbm_bo_get_pitch was renamed to gbm_bo_get_stride. eglkms fails
>> to build against mesa master without this.
>> ---
>> src/egl/opengl/eglkms.c |2 +-
>> 1 file changed, 1 inserti
On 18 July 2012 15:11, Kenneth Graunke wrote:
> On 07/18/2012 12:16 PM, Paul Berry wrote:
> > This patch series cleans up a bug fix I made to Mesa on June 22
> > (commit 82d2596: i965: Compute dFdy() correctly for FBOs). The bug
> > was that the i965 driver wasn't adjusting the dFdy() logic to a
On Don, 2012-07-19 at 01:15 -0600, Scott Moreau wrote:
> gbm_bo_get_pitch was renamed to gbm_bo_get_stride. eglkms fails
> to build against mesa master without this.
> ---
> src/egl/opengl/eglkms.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/egl/opengl/eglkms.
gbm_bo_get_pitch was renamed to gbm_bo_get_stride. eglkms fails
to build against mesa master without this.
---
src/egl/opengl/eglkms.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/egl/opengl/eglkms.c b/src/egl/opengl/eglkms.c
index 1006317..6ba0f12 100644
--- a/src/eg
Hi Kristian:
These changes mostly work for wayland-drm, do you think we'd better have this
simple test for wayland-drm?
If yes, do you have better idea to create YUYV buffer from gbm? Or just let it
be to use GR88 to get buffer with same size.
Thanks
> -Original Message-
> From: Zhao, H
https://bugs.freedesktop.org/show_bug.cgi?id=52250
--- Comment #3 from Olivier Galibert 2012-07-19 09:18:04
PDT ---
(In reply to comment #2)
> > Mesa warning: failed to remap index 173
>
> FWIW, that kind of message is usually a sign of an inconsistent build.
The bug is perfectly real though.
https://bugs.freedesktop.org/show_bug.cgi?id=52140
Björn Rask changed:
What|Removed |Added
CC||lajva...@gmail.com
--- Comment #10 from Bjö
https://bugs.freedesktop.org/show_bug.cgi?id=52140
--- Comment #9 from Björn Rask 2012-07-19 08:55:05 PDT ---
Created attachment 64378
--> https://bugs.freedesktop.org/attachment.cgi?id=64378
Björns dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You a
https://bugs.freedesktop.org/show_bug.cgi?id=52140
--- Comment #8 from Björn Rask 2012-07-19 08:54:32 PDT ---
Created attachment 64377
--> https://bugs.freedesktop.org/attachment.cgi?id=64377
Björns glxinfo
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=52140
--- Comment #7 from Björn Rask 2012-07-19 08:53:54 PDT ---
Created attachment 64376
--> https://bugs.freedesktop.org/attachment.cgi?id=64376
Björns xorg log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
Presumably the function didn't exist when we wrote this code.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast_to_hir.cpp | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index bbe8f05..5ad754c 100644
--- a/src/
On 07/19/2012 12:35 AM, Eric Anholt wrote:
> This thread count is only supposed to be enabled when "WIZ Hashing Disable in
> GT_MODE register enabled." I've always been confused whether that means the
> bit in the register should be 1 or 0. For my IVB GT2's register 0x7008 value
> of 0x0, this ap
This thread count is only supposed to be enabled when "WIZ Hashing Disable in
GT_MODE register enabled." I've always been confused whether that means the
bit in the register should be 1 or 0. For my IVB GT2's register 0x7008 value
of 0x0, this appears to work fine.
Improves l4d2 performance at 6
https://bugs.freedesktop.org/show_bug.cgi?id=52250
--- Comment #2 from Michel Dänzer 2012-07-19 06:09:56 PDT
---
> Mesa warning: failed to remap index 173
FWIW, that kind of message is usually a sign of an inconsistent build.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?ta
83 matches
Mail list logo
