The meta code was setting a default depth range for all viewports
and 'restoring' all viewports to depth range values saved from viewport 0.
---
src/mesa/drivers/common/meta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/
June 26, 2015 03:15:46 PM Mike Stroyan wrote:
> > The meta code was setting a default depth range for all viewports
> > and 'restoring' all viewports to depth range values saved from viewport
> 0.
> > ---
> > src/mesa/drivers/common/meta.c | 4 ++--
>
When there are no color buffer render targets, gen6 and gen7 still
use the first BLEND_STATE element to determine alpha test.
gen6_upload_blend_state was allocating zero elements when
ctx->Color.AlphaEnabled was false.
That left _3DSTATE_CC_STATE_POINTERS or _3DSTATE_BLEND_STATE_POINTERS
pointing t
Fixes: (Flickering shadows in unreleased title trace)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80500
<https://bugs.freedesktop.org/show_bug.cgi?id=91173>
On Wed, Jul 1, 2015 at 10:16 AM, Mike Stroyan wrote:
> When there are no color buffer render targets, gen6 and gen7 st
5 10:16:28 AM Mike Stroyan wrote:
> > When there are no color buffer render targets, gen6 and gen7 still
> > use the first BLEND_STATE element to determine alpha test.
> > gen6_upload_blend_state was allocating zero elements when
> > ctx->Color.AlphaEnabled was false.
>
gt; mat->flags |= MAT_FLAG_ROTATION;
> > > @@ -1255,9 +1255,9 @@ static void analyse_from_scratch( GLmatrix *mat )
> > >mat->type = MATRIX_3D_NO_ROT;
> > >
> > >/* Check for scale */
> > > - if (SQ(m[0]-m[5]) < SQ(1e-6) &&
> > > -
eight *
>> mt->mcs_mt->region->pitch);
>> > intel_miptree_unmap_raw(brw, mt->mcs_mt);
>> > mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_CLEAR;
>>
>> This does seem to fix the KWin problem, as well as the glxgears problem.
>>
>> I agree
ote:
> > From: Mike Stroyan
> >
> > Putting NoDDClr and NoDDChk dependency control on instruction
> > sequences that include math opcodes can cause corruption of channels.
> > Treat math opcodes like send opcodes and suppress dependency hinting.
>
> Since y
Matt,
You haven't replied to my mail with an updated shader test that shows the
math instructions alone causing trouble.
Do you now agree that my patch avoiding math instructions in
opt_set_dependency_control is the appropriate fix?
On Fri, Feb 21, 2014 at 11:30 AM, Mike Stroyan
Commit 6e8d04a caused a leak by allocating ctx->Debug but never freeing it.
Release the memory in _mesa_free_errors_data when destroying a context.
Use FREE to match CALLOC_STRUCT from _mesa_get_debug_state.
---
src/mesa/main/errors.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
Brian,
Please push that. I haven't gotten commit access for myself yet.
On Tue, Mar 11, 2014 at 5:42 PM, Brian Paul wrote:
> On 03/11/2014 05:07 PM, Mike Stroyan wrote:
>
>> Commit 6e8d04a caused a leak by allocating ctx->Debug but never freeing
>> it
g4<1>.xyzF g8<4,4,1>.xyzzF 0.99F
{ align16 WE_normal 1Q };
On Tue, Mar 18, 2014 at 4:05 PM, Kenneth Graunke wrote:
> On 02/28/2014 02:35 PM, Mike Stroyan wrote:
> > Matt,
> >
> > You haven't replied to my mail with an updated shader test that s
m occurs for
math with exp2, log, rsq, sqrt, and sin.
I didn't create test cases for the two operand opcodes. But I am not
optimistic about them.
--
Mike Stroyan - Software Architect
LunarG, Inc. - The Graphics Experts
Cell: (970) 219-7905
Email: m...@lunarg.com
Website:
A fragment program can change because of Non-Orthogonal-State changes.
brw_update_texture_surfaces needs to run because of changed surface offsets.
Set BRW_NEW_FRAGMENT_PROGRAM dirty bit in brw_upload_wm_prog to signal that.
---
src/mesa/drivers/dri/i965/brw_wm.c | 9 -
1 file changed, 8 i
This patch fixes a problem I reported as
[Bug 87619] Changes to state such as render targets change fragment shader
without marking it dirty.
I sent a test that demonstrates the problem to the piglit mailing list as
fbo: Changing mrt binding with same shader source
The root cause of problem is r
Reviewed-by: Mike Stroyan
On Mon, Dec 22, 2014 at 9:28 PM, Chris Forbes wrote:
>
> Reviewed-by: Chris Forbes
>
> On Tue, Dec 23, 2014 at 3:58 PM, Kenneth Graunke
> wrote:
> > This was probably missed when moving from a fixed binding table layout
> > to a dynamic on
instead of adding BRW_NEW_FS_PROG_DATA to the brw mask.
On Mon, Dec 22, 2014 at 8:09 PM, Kenneth Graunke
wrote:
> On Monday, December 22, 2014 05:22:06 PM Mike Stroyan wrote:
> > This patch fixes a problem I reported as
> > [Bug 87619] Changes to state such as render targets change
g
> when we only have a few iterations in the loop, but I don't know why we
> generate different code in that case and I am not familiar enough with
> all the optimization and lowering passes to assess what would make sense
> to do here... so, any suggestions?
>
> Iago
>
ies of adds of constants instead of
one add with the sum.
That is a separate issue that could still be investigated.
On Thu, Sep 11, 2014 at 1:53 PM, Mike Stroyan wrote:
> I have looked at this problem quite a bit but never got to the bottom of
> it.
> This problem really started to show
19 matches
Mail list logo
