Hi, this is a new series of patches for dynamic eu instruction store
size. The first 4 is from Eric. I just grabed it to make it rebase to
current repo. The last 4 patch is from mine which some are based on
those patches from Eric.
Please help to review it.
BTW, I checked those patches with all o
From: Eric Anholt
The branch distances get patched up later at the WHILE instruction.
Reviewed-by: Yuanhan Liu
---
src/mesa/drivers/dri/i965/brw_eu_emit.c |3 +--
src/mesa/drivers/dri/i965/brw_fs_emit.cpp |2 +-
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp |2 +-
src/mesa/driv
From: Eric Anholt
This is a similar cleanup to what we did for brw_IF(), brw_ELSE(),
brw_ENDIF() handling.
Reviewed-by: Yuanhan Liu
---
src/mesa/drivers/dri/i965/brw_clip_line.c |5 +--
src/mesa/drivers/dri/i965/brw_clip_tri.c | 15 +---
src/mesa/drivers/dri/i965/brw_cli
From: Eric Anholt
The EU code itself can just do this work, since all the consumers were
duplicating it.
Reviewed-by: Yuanhan Liu
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 36 +-
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 33 +++-
src/
From: Eric Anholt
The codegen backends all had this same tracking, so just do it at the
EU level.
Reviewed-by: Yuanhan Liu
---
src/mesa/drivers/dri/i965/brw_eu.c |1 +
src/mesa/drivers/dri/i965/brw_eu.h | 10 --
src/mesa/drivers/dri/i965/brw_eu_emit.c | 13
If dynamic instruction store size is enabled, while after
the brw_IF/ELSE() and before the brw_ENDIF() function, the
eu instruction store base address(p->store) may change.
Thus let if_stack just store the instruction index. This is
somehow more flexible and safe than store the instruction
memory
If dynamic instruction store size is enabled, while after the brw_JMPI()
and before the brw_land_fwd_jump() function, the eu instruction store
base address(p->store) may change. Thus, the safe way to reference the
jmp instruction is by index instead of by the instruction address.
Signed-off-by: Yu
A single next_insn may change the base address of instruction store
memory(p->store), so call it first before referencing the instruction
store pointer from an index.
This the final prepare work to enable the dynamic store size.
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/i965/brw_eu_em
Here is the final patch to enable dynamic eu instruction store size:
increase the brw eu instruction store size dynamically instead of just
allocating it statically with a constant limit. This would fix something
that 'GL_MAX_PROGRAM_INSTRUCTIONS_ARB was 16384 while the driver would
limit it to 100
Looks good to me Brian.
I assume it is already impossible for the arrays to change in such subtle
manner within a single draw method, without provoking _NEW_ARRAY to be set.
Jose
- Original Message -
> This fixes a regression seen with the isosurf demo when switching
> between
> glBegi
Looks good to me.
Jose
- Original Message -
> From: Brian Paul
>
> This just splits one big function into two smaller ones for better
> readability.
> ---
> src/mesa/main/texgetimage.c | 322
> +++---
> 1 files changed, 176 insertions(+), 146 delet
On Wed, 21 Dec 2011 17:33:41 +0800, Yuanhan Liu
wrote:
> If dynamic instruction store size is enabled, while after the brw_JMPI()
> and before the brw_land_fwd_jump() function, the eu instruction store
> base address(p->store) may change. Thus, the safe way to reference the
> jmp instruction is b
On Tue, 20 Dec 2011 23:30:29 -0800, Kenneth Graunke
wrote:
> X8 depth formats weren't supported until Ironlake (Gen 5).
>
> Fixes GPU hangs introduced in d84a180417d1eabd680554970f1eaaa93abcd41e.
> One example test case was "fbo-missing-attachment-blit from".
>
> Signed-off-by: Kenneth Graunke
On Wed, Dec 21, 2011 at 4:16 AM, Jose Fonseca wrote:
> Looks good to me Brian.
>
> I assume it is already impossible for the arrays to change in such subtle
> manner within a single draw method, without provoking _NEW_ARRAY to be set.
I believe so.
When the VBO module builds arrays out of glBeg
- Original Message -
> On 17.12.2011 20:54, Marek Olšák wrote:
> > On Sat, Dec 17, 2011 at 4:45 PM, Christoph Bumiller
> > wrote:
> >> On 17.12.2011 15:45, Marek Olšák wrote:
> >>> ---
> >>>
> >>> This was suggested by Keith Whitwell in this email addressed to
> >>> me on 8/6/2010:
> >>> h
Series looks good to me.
Jose
- Original Message -
> From: Brian Paul
>
> For 1D arrays, map each slice separately. Note that this was handled
> correctly in _mesa_store_teximage2d() but not here.
> ---
> src/mesa/main/texstore.c | 67
> ++---
The series looks good AFAICT.
Jose
- Original Message -
> v2: use _mesa_pack_colormask() helper and fix incorrect masking
> arithmetic
> ---
> src/mesa/swrast/s_clear.c | 225
> +++--
> 1 files changed, 113 insertions(+), 112 deletions(-)
>
> di
Signed-off-by: Maarten Lankhorst
---
src/egl/drivers/dri2/platform_x11.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index a00e3fe..6ca7838 100644
--- a/src/egl/drivers/dri2/platform_x11.c
Looks a sensible thing to do.
I assume no DRI driver will ever want to hook vtable->destroy. If that may
eventually happen, then may be it is useful to add an assert(vtable->destroy ==
dri2_destroy_context) when the context is created.
Jose
- Original Message -
> From: Ian Romanick
>
Hey Christian,
On 12/20/2011 09:08 PM, Lucas Stach wrote:
> Hi all!
> Just jumping in with regard to the assert.
>
> Am Dienstag, den 20.12.2011, 19:20 +0100 schrieb Maarten Lankhorst:
> [snip]
return vlc->buffer>> (64 - num_bits);
}
@@ -130,7 +132,7 @@ vl_vlc_peekbits(struc
On 20.12.2011 19:20, Maarten Lankhorst wrote:
Hey Christian,
On 12/20/2011 02:16 PM, Christian König wrote:
Why do you want to change that anyway?
The search for start codes was especially split out of the VLC stuff, because start
codes start are byte aligned anyway and it doesn't make much
Hey Christian,
On 12/21/2011 04:41 PM, Christian König wrote:
> On 20.12.2011 19:20, Maarten Lankhorst wrote:
>> Hey Christian,
>>
>> On 12/20/2011 02:16 PM, Christian König wrote:
>>>
>>> Why do you want to change that anyway?
>>>
>>> The search for start codes was especially split out of the VLC
2011/12/21 Maarten Lankhorst :
> Hey Christian,
>
> On 12/21/2011 04:41 PM, Christian König wrote:
>> Those functions are called a couple of million times a second, so even if
>> the assertion is only tested in debug builds it has quite an effect on
>> performance, sometimes even masquerading rea
Also a remark about your patch, wish you had inlined it..
On 12/21/2011 04:41 PM, Christian König wrote:
> On 20.12.2011 19:20, Maarten Lankhorst wrote:
>> Hey Christian,
>>
>> On 12/20/2011 02:16 PM, Christian König wrote:
>>>
>>> Why do you want to change that anyway?
>>>
>>> The search for star
Maarten Lankhorst wrote:
Well, I found a video that appears to fail in a similar way to one of your
failure modes, they could both be the same but showing in different ways.
I've found a small mpeg1 vid that causes
mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl->length' failed
at
Hi Brian,
Is there a reason to set _NEW_ARRAY when transitioning between
DrawArrays and DrawElements?
Marek
On Wed, Dec 21, 2011 at 1:58 AM, Brian Paul wrote:
> This fixes a regression seen with the isosurf demo when switching between
> glBegin/End and glDrawArrays (do it several times). The p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/21/2011 05:52 AM, Eric Anholt wrote:
> On Tue, 20 Dec 2011 23:30:29 -0800, Kenneth Graunke
> wrote:
>> X8 depth formats weren't supported until Ironlake (Gen 5).
>>
>> Fixes GPU hangs introduced in d84a180417d1eabd680554970f1eaaa93abcd41e.
>> O
On 12/21/2011 07:29 AM, Jose Fonseca wrote:
Looks a sensible thing to do.
I assume no DRI driver will ever want to hook vtable->destroy. If
that may eventually happen, then may be it is useful to add an
assert(vtable->destroy == dri2_destroy_context) when the context is created.
This particul
* Doesn't reintroduce legacy drivers
* Adds Haiku mklib code
* Removes some broken PIPE_OS_HAIKU defines
* Removes an NDEBUG ifdef in link_uniforms.cpp,
there is an item that uses the union without
checking NDEBUG below.
* Haiku has a opengl kit that will wrap all of
these build binaries(pr
Hi guys,
On 21.12.2011 17:27, Maarten Lankhorst wrote:
Also a remark about your patch, wish you had inlined it..
Sorry, not at home right now and I can't get this Thunderbird here to
inline the patches correctly.
diff --git a/src/gallium/auxiliary/vl/vl_vlc.h
b/src/gallium/auxiliary/vl/vl_v
On 12/21/2011 09:56 AM, Chad Versace wrote:
> On 12/21/2011 05:52 AM, Eric Anholt wrote:
>> On Tue, 20 Dec 2011 23:30:29 -0800, Kenneth Graunke
>> wrote:
>>> X8 depth formats weren't supported until Ironlake (Gen 5).
>>>
>>> Fixes GPU hangs introduced in d84a180417d1eabd680554970f1eaaa93abcd41e.
Hey Christian,
On 12/21/2011 07:25 PM, Christian König wrote:
> Hi guys,
>
> On 21.12.2011 17:27, Maarten Lankhorst wrote:
>> Also a remark about your patch, wish you had inlined it..
> Sorry, not at home right now and I can't get this Thunderbird here to inline
> the patches correctly.
>
>> diff
Looks like a nice cleanup.
I wonder if it wouldn't be more future proof to explicit add cases for
GL_TEXTURE_2D, cube face, etc., and have default be an assertion failure.
Jose
- Original Message -
> From: Brian Paul
>
> The code for storing 1D, 2D and 3D tex images (whole or sub-imag
On 12/20/2011 04:41 PM, Paul Berry wrote:
Previously we were storing the RasterDiscard flag (for
GL_RASTERIZER_DISCARD) in gl_context::TransformFeedback. This was
confusing, because we use the _NEW_TRANSFORM flag (not
_NEW_TRANSFORM_FEEDBACK) to track state updates to it, and because
rasterizer
> - temp = malloc(width * MAX_PIXEL_BYTES);
> - if (!temp) {
> - _mesa_error(ctx, GL_OUT_OF_MEMORY, "glCopyPixels");
> - return GL_FALSE;
> + /* different src/dst buffers */
> + ctx->Driver.MapRenderbuffer(ctx, srcRb, srcX, srcY,
> + width, h
On Sun, 18 Dec 2011 20:08:13 -0700, Brian Paul wrote:
> Use format pack/unpack functions instead of deprecated renderbuffer
> GetRow/PutRow functions.
> ---
> src/mesa/swrast/s_stencil.c | 31 ++-
> 1 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/
Hi,
On Wednesday, December 21, 2011 01:58:08 Brian Paul wrote:
> This fixes a regression seen with the isosurf demo when switching between
> glBegin/End and glDrawArrays (do it several times). The problem was the
> driver wasn't getting _NEW_ARRAY when the arrays were subtly changed:
> (vertex3f
On Sun, 18 Dec 2011 20:08:16 -0700, Brian Paul wrote:
> ---
> src/mesa/swrast/s_context.h | 12
> src/mesa/swrast/s_depth.c | 18 --
> src/mesa/swrast/s_stencil.c | 18 +++---
> 3 files changed, 19 insertions(+), 29 deletions(-)
I was thinking of
On Sun, 18 Dec 2011 20:08:19 -0700, Brian Paul wrote:
> The functions that read depth/stencil values understand all (packed)
> depth/stencil buffer formats now so there's no reason to use the
> wrappers.
>
> Also, improve the format checks in fast_copy_pixels() to catch mismatched
> depth/stencil
On Sun, 18 Dec 2011 20:08:21 -0700, Brian Paul wrote:
> Stop using deprecated renderbuffer PutRow() function. Note that we
> aren't using Map/UnmapRenderbuffer() yet because this call is inside
> a swrast_render_start/finish() pair.
> ---
> src/mesa/swrast/s_drawpix.c | 64
> +
On Sun, 18 Dec 2011 20:08:23 -0700, Brian Paul wrote:
> Use Map/UnmapRenderbuffer() for the special, optimized cases we care about.
I note that this happens to drop the fast paths for zooming (and
CI8->RGBA, lol). Totally reasonable, just something that would be worth
noting in the commit messag
On 12/21/2011 08:25 PM, Maarten Lankhorst wrote:
> Hey Christian,
>
> On 12/21/2011 07:25 PM, Christian König wrote:
>> Hi guys,
>>
>> On 21.12.2011 17:27, Maarten Lankhorst wrote:
>>> Also a remark about your patch, wish you had inlined it..
>> Sorry, not at home right now and I can't get this Thu
On Sun, 18 Dec 2011 20:08:22 -0700, Brian Paul wrote:
> We don't want to call these functions if where we'll be using
"if where"? Code looks good, though.
pgp58mXlPfrlE.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesk
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Dec 21, 2011 at 1:41 AM, Paul Berry wrote:
> This makes it easier to keep track of which dirty bits correspond to
> which pieces of context, since it makes _NEW_RASTERIZER_DISCARD
> correspond with ctx->RasterDiscard.
> ---
> src/mesa/dri
This patch series ensures that meta-ops (such as glClear or
glGenerateMipmapEXT) function properly when transform feedback or
rasterizer discard is enabled.
Most of the code changes necessary to make this work are in core mesa:
patches 1/5 and 5/5 ensure that meta ops properly pause transform
feed
During meta-operations (such as _mesa_meta_GenerateMipmap()), we need
to be able to draw even if GL_RASTERIZER_DISCARD is enabled. This
patch causes _mesa_meta_begin() to save the state of
GL_RASTERIZER_DISCARD and disable it (so that drawing can be done
during the meta-op), and causes _mesa_meta_
If a client calls BeginTransformFeedback(), then
PauseTransformFeedback(), then EndTransformFeedback(), we need to make
sure that the transform feedback object is not left in a "paused"
state, otherwise the next call to BeginTransformFeedback() will leave
transform feedback paused.
---
src/mesa/ma
When transform feedback is paused, it is legal to change programs or
to perform drawing operations using a drawing mode that doesn't match
the transform feedback mode.
---
src/mesa/main/shaderapi.c |5 +++--
src/mesa/main/transformfeedback.c |3 ++-
2 files changed, 5 insertions(+)
Although i965 gen6 does not yet support ARB_transform_feedback2 or
NV_transform_feedback2, it needs to support pause/resume functionality
so that meta-ops will work correctly.
---
src/mesa/drivers/dri/i965/brw_draw.c |3 ++-
src/mesa/drivers/dri/i965/brw_gs.c |3 ++-
src/mesa/drivers/dri
On Sun, 18 Dec 2011 20:08:26 -0700, Brian Paul wrote:
> The only consequence is we can only use the occlusion_zless_16_triangle()
> function with MESA_FORMAT_Z16.
I'm not following that conclusion, probably due to ignorance of swrast
spans code. I would think that Z32 would still work for that o
Fixes piglit tests "EXT_transform_feedback/generatemipmap buffer" and
"EXT_transform_feedback/generatemipmap prims_written" on i965 Gen6.
---
src/mesa/drivers/common/meta.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/me
On 11/27/2011 12:54 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> fixing these makes piglit fbo-integer pass on softpipe.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/main/format_unpack.c | 135
> +
> 1 files changed, 135 insertions(+), 0 deletions(-
https://bugs.freedesktop.org/show_bug.cgi?id=43864
Vinson Lee changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Vinson Lee 2011
Since the refactor in d7b33309fe160212f2eb73f471f3aedcb5d0b5c1, depth
in the miptree changed from 1 to 6, so we always decided it didn't
match, and we would relayout to something that would still not
"match".
Improves performance 23.8% (+/- 1.1%, n=4)
Bugzilla: https://bugs.freedesktop.org/show_b
We would have done a relayout at validate time, but it's senseless to
store into a miptree if it's going to force relayout.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |3 +++
src/mesa/drivers/dri/intel/intel_tex_validate.c |1 -
2 files changed, 3 insertions(+), 1 deletions(-)
di
We were printing out the line triggering the flush, but a variety of
different causes just printed the line number for intel_flush()'s call
of intel_batchbuffer_flush(). Plumb the line numbers from the caller
of intel_flush() on through.
---
src/mesa/drivers/dri/intel/intel_context.c |4 ++--
There's nothing batchbuffer-related here. State updates by the caller
will trigger re-emitting of any new hardware state.
---
src/mesa/drivers/dri/intel/intel_fbo.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers
There should be nothing special about this call compared to other
callers of intel_draw_buffer().
---
src/mesa/drivers/dri/intel/intel_fbo.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
in
This saves a couple of instructions on most programs with control
flow. More interestingly, 6 shaders from unigine sanctuary now fit
into 16-wide without register spilling.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/d
X8 depth formats weren't supported until Ironlake (Gen 5).
Fixes GPU hangs introduced in d84a180417d1eabd680554970f1eaaa93abcd41e.
One example test case was "fbo-missing-attachment-blit from".
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_misc_state.c |5 -
1 files ch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/21/2011 04:36 PM, Kenneth Graunke wrote:
> X8 depth formats weren't supported until Ironlake (Gen 5).
>
> Fixes GPU hangs introduced in d84a180417d1eabd680554970f1eaaa93abcd41e.
> One example test case was "fbo-missing-attachment-blit from".
>
On Wed, Dec 21, 2011 at 05:57:35AM -0800, Eric Anholt wrote:
> On Wed, 21 Dec 2011 17:33:41 +0800, Yuanhan Liu
> wrote:
> > If dynamic instruction store size is enabled, while after the brw_JMPI()
> > and before the brw_land_fwd_jump() function, the eu instruction store
> > base address(p->store)
This series adds a mock implementation of GL_OES_EGL_image_external that
enables SurfaceFlinger to provide a home screen.
Chad Versace (2):
meta: Disable GL_TEXTURE_EXTERNAL_OES in meta_begin()
i965: Create mock implementation of GL_OES_EGL_image_external
src/mesa/drivers/common/meta.c
If the meta flag MESA_META_TEXTURE is present, then disable the texture
target GL_TEXTURE_EXTERNAL_OES.
Signed-off-by: Chad Versace
---
src/mesa/drivers/common/meta.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/commo
In Android IceCreamSandwich, SurfaceFlinger requires GL_OES_image_external
for basic compositing tasks. Without the extension, SurfaceFlinger fails
to start.
Despite the incompleteness of the extension's implementation introduced by
this patch, it is good enough to enable SurfaceFlinger and to unb
From: Jian Zhao
Reported-by: Anuj Phogat
Signed-off-by: Jian Zhao
Reviewed-by: Yuanhan Liu
---
src/mesa/main/texgetimage.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 3f24187..6ead871 10064
https://bugs.freedesktop.org/show_bug.cgi?id=44039
Bug #: 44039
Summary: Mesa 7.12-devel implementation error: unexpected
format 0x822e in _mesa_choose_tex_format()
Classification: Unclassified
Product: Mesa
Version: git
https://bugs.freedesktop.org/show_bug.cgi?id=44039
Nikita changed:
What|Removed |Added
Severity|major |blocker
--
Configure bugmail: https://bugs.fre
On Wed, Dec 21, 2011 at 6:50 AM, Brian Paul wrote:
> On 12/20/2011 01:31 PM, Ian Romanick wrote:
>>
>> From: Ian Romanick
>>
>> There seems to have been two different ways to communicate the
>> profile. There were flags and there were profiles. I've opted to
>> remove the profile flags and use S
On Wed, Dec 21, 2011 at 4:31 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> This won't be used in the client-side libGL, but the xserver has to
> generate a different protocol error depending on the reason context
> creation failed.
>
> Signed-off-by: Ian Romanick
> ---
> src/gallium/include/
70 matches
Mail list logo
