https://bugs.freedesktop.org/show_bug.cgi?id=49125
Bug #: 49125
Summary: sp_tex_sample.c:802:get_texel_2d_array: Assertion
`layer < texture->array_size' failed.
Classification: Unclassified
Product: Mesa
Version: git
P
Hi,
2012/4/25 Chad Versace :
> On 04/24/2012 08:21 AM, Gwenole Beauchesne wrote:
>> 2012/4/23 Rob Clark :
>>> On Mon, Apr 23, 2012 at 4:54 AM, Gwenole Beauchesne
>>> wrote:
>
>> It's not intended for Wayland only but rather for anybodoy willing to
>> import foreign DRM buffers which could have Y
https://bugs.freedesktop.org/show_bug.cgi?id=49124
Bug #: 49124
Summary: swrast/s_texfetch.c:1156: set_fetch_functions:
Assertion `texImage->FetchTexel' failed.
Classification: Unclassified
Product: Mesa
Version: git
P
On 04/24/2012 08:21 AM, Gwenole Beauchesne wrote:
> Hi,
>
> 2012/4/23 Rob Clark :
>> On Mon, Apr 23, 2012 at 4:54 AM, Gwenole Beauchesne
>> wrote:
> It's not intended for Wayland only but rather for anybodoy willing to
> import foreign DRM buffers which could have YUV layout. This indeed
> impl
On Tue, 24 Apr 2012 14:09:13 -0700, Kenneth Graunke
wrote:
> A little analysis shows that the worst-case value for "nr" is 17:
> - base_mrf = 2 ... 2
> - header present (say gen == 5) ... 4
> - aa_dest_stencil_reg (stencil test) ... 5
> - SIMD16 mode: += 4 * reg_width
On 04/24/2012 07:49 AM, Sean V Kelley wrote:
> Enabled MESA_FORMAT_RGBX_REV for RGBX. Android software
> requires RGBX format to be supported for software rendering.
> That requires EGL to be capable of generating images from this
> format.
>
> Signed-off-by: Sean V Kelley
> ---
> src/m
On 04/24/2012 07:49 AM, Sean V Kelley wrote:
> Add new format __DRI_IMAGE_FORMAT_XBGR to __DRI_IMAGE.
> HAL_PIXEL_FORMAT_RGBX_ now maps to __DRI_IMAGE_FORMAT_XBGR.
>
> Signed-off-by: Sean V Kelley
> ---
> include/GL/internal/dri_interface.h |1 +
> src/egl/drivers/dri2/platfo
The vbo module recomputes its states if _NEW_ARRAY is set, so it shouldn't use
the same flag to notify the driver. Since we've run out of bits in NewState
and NewState is for core Mesa anyway, we need to find another way.
This patch is the first to start decoupling the state flags meant only
for c
In the future we'd like to treat vertex arrays as a state and
not as a parameter to the draw function. This is the first step
towards that goal.
This commit adds:
const struct gl_client_array **gl_context::Array::Arrays.
The pointer is changed in:
* vbo_draw_method
* vbo_rebase_prims - unused by
I'll need vbo_context in that function soon.
---
src/mesa/vbo/vbo_context.h| 35 +++
src/mesa/vbo/vbo_exec.h | 36
src/mesa/vbo/vbo_exec_api.c |2 +-
src/mesa/vbo/vbo_exec_array.c |2 +-
src/mesa/vbo/vbo_s
Adapted drivers: i915, llvmpipe, r300, r600, radeonsi, softpipe.
User index buffers have been disabled in nv30, nv50, nvc0 and svga to keep
things working.
---
src/gallium/auxiliary/util/u_index_modify.c | 83 ++
src/gallium/auxiliary/util/u_index_modify.h | 16 +
---
src/gallium/auxiliary/util/u_transfer.c|8 --
src/gallium/auxiliary/util/u_transfer.h|5
src/gallium/drivers/galahad/glhd_context.c | 14 ---
src/gallium/drivers/i915/i915_state.c |1 -
src/gallium/drivers/identity/id_
This reduces CPU overhead in st_draw_vbo and removes a lot of unnecessary code
in that function which was required only to comply with the gallium interface,
but wasn't any useful really.
Adapted drivers: i915, llvmpipe, r300, softpipe.
No changes required in: r600, radeonsi.
User vertex buffers
---
src/mesa/state_tracker/st_atom_constbuf.c | 19 +--
src/mesa/state_tracker/st_context.c | 13 +
src/mesa/state_tracker/st_context.h |2 +-
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_constbuf.c
---
src/gallium/auxiliary/postprocess/pp_mlaa.c|4 +-
src/gallium/auxiliary/util/u_inlines.h | 15 ++
src/gallium/auxiliary/vl/vl_compositor.c |2 +-
src/gallium/drivers/galahad/glhd_context.c | 13 +--
src/gallium/drivers/i915/
This is required for any serious constant buffer support.
Constant buffer offsets on ATI and NVIDIA DX10 and DX11 GPUs must be
a multiple of 256.
In OpenGL, this can be queried via GL_UNIFORM_BUFFER_OFFSET_ALIGNMENT.
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/
---
src/mesa/state_tracker/st_context.c|4 +++-
src/mesa/state_tracker/st_context.h|1 +
src/mesa/state_tracker/st_draw.c |5 +
src/mesa/state_tracker/st_extensions.c |4
4 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/s
and restructure the code a bit
---
src/mesa/state_tracker/st_draw.c | 46 +
1 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index edab76b..c24ae75 100644
--- a/src/mesa/state_
---
src/gallium/docs/source/screen.rst |6 ++
src/gallium/drivers/i915/i915_screen.c |2 ++
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
src/gallium/drivers/nv30/nv30_screen.c |2 ++
src/gallium/drivers/nv50/nv50_screen.c |2 ++
src/galliu
On Tue, Apr 24, 2012 at 11:48:14AM +0100, Ian Romanick wrote:
> On 04/20/2012 08:20 AM, Olivier Galibert wrote:
> > Guys, it's a bugfix, it's five lines changed, and it's falling through
> > the cracks... Can someone have a look?
>
> From my reply on 4/13:
>
> Do you have a specific test ca
A little analysis shows that the worst-case value for "nr" is 17:
- base_mrf = 2 ... 2
- header present (say gen == 5) ... 4
- aa_dest_stencil_reg (stencil test) ... 5
- SIMD16 mode: += 4 * reg_width ... 13
- source_depth_to_render_target ... 15
- dest_depth_reg
On 04/24/2012 10:12 AM, Eric Anholt wrote:
On Tue, 24 Apr 2012 00:34:00 -0700, Kenneth Graunke
wrote:
A little analysis shows that the worst-case value for "nr" is 16:
- base_mrf = 2 ... 2
- header present (say gen == 5) ... 4
- SIMD16 mode: += 4 * reg_width ... 12
- source
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #16 from zebulon 2012-04-24 13:01:13 PDT ---
using
nouveau-dri 8.0.2-1
xf86-video-nouveau 0.0.16_git20120210-1
on archlinux 32 bits
DRAW_USE_LLVM=0 gnome-control-center
crashes too
but
MALLOC_CHECK_=1 gnome-control-center
works
--
https://bugs.freedesktop.org/show_bug.cgi?id=48441
Pascal S changed:
What|Removed |Added
CC||pascal.sch...@gmail.com
--- Comment #15 from
When the user attaches a texture to one of the depth/stencil
attachment points (GL_STENCIL_ATTACHMENT or GL_DEPTH_ATTACHMENT), we
check to see if the same texture is also attached to the other
attachment point, and if so, we re-use the existing texture
attachment. This is necessary to ensure that
When rendering to a miplevel other than 0 within a color, depth,
stencil, or HiZ buffer, we need to tell the GPU to render to an offset
within the buffer, so that the data is written into the correct
miplevel. We do this using a coarse offset (in pages), and a fine
adjustment (the so-called "tile_
On 04/24/2012 03:41 AM, Ian Romanick wrote:
On 04/22/2012 11:47 PM, Kenneth Graunke wrote:
On 04/22/2012 01:43 AM, nobled wrote:
As noted in commit be4e46b21a60cfdc826bf89d1078df54966115b1,
this was missing before.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/version.c | 1 +
I only considered var->assigned for FragColor and FragData, but
ignored when it was false for out vars. Fixes piglit
write-gl_FragColor-and-not-user-output.frag
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49068
---
src/glsl/ast_to_hir.cpp |6 +++---
1 file changed, 3 insertions(+)
I had fixed up the logic ops for delayed ANDing, but not equality
comparisons on bools. Fixes new piglit fs-bool-less-compare-true.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48629
---
src/mesa/drivers/dri/i965/brw_fs.h |1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
I thought this might be _NEW_COLOR, but it isn't.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |7 +--
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
---
src/mesa/main/extensions.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 5f2c74a..a843a40 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -754,7 +754,7 @@ get_extension_override(
When doing the var->assigned change in
f2475ca424f7e001be50f64dafa5700f6603d684, I overzealously indented the
second block of code into the "if (var)" test. Revert these blocks to
the way they were before, just taking advantage of "var" to avoid
re-calling variable_referenced().
Bugzilla: https:/
On Tue, 24 Apr 2012 00:34:00 -0700, Kenneth Graunke
wrote:
> A little analysis shows that the worst-case value for "nr" is 16:
> - base_mrf = 2 ... 2
> - header present (say gen == 5) ... 4
> - SIMD16 mode: += 4 * reg_width ... 12
> - source_depth_to_render_target ... 14
> -
Add EGL_DRM_BUFFER_OFFSET_MESA to specify an offset (in bytes) relative
to the start of the DRM buffer. Likewise, add an EGL_DRM_BUFFER_PLANE_ID_MESA
attribute to specify (name) a plane identifier associated with the generated
image.
Add new image formats:
- EGL_DRM_BUFFER_FORMAT_R8_MESA: 8-bit re
MESA_drm_image spec mentions that the EGL_DRM_BUFFER_STRIDE_MESA
attribute is expressed in bytes. However, the eglCreateImageKHR()
implementation assumes the attribute is expressed in pixels, which
is what the DRI create image API expects.
---
src/egl/drivers/dri2/egl_dri2.c |3 ++-
1 files ch
Add helper to invoke CreateImageFromName() or CreateImageImageFromName2().
---
src/egl/drivers/dri2/egl_dri2.c | 60 ---
1 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 4a
Hi,
This implements the DRI image v4 extensions to MESA_drm_image. This is
useful for testing submission of individual planes.
Patch 2 fixes an independent bug, that existed before those changes.
In particular, there was a mismatch between what the spec says and
what is effectively implemented. T
---
src/mesa/drivers/dri/intel/intel_screen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index a5ac80c..14296a5 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mes
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 +
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |1 +
src/mesa/drivers/dri/intel/intel_regions.c|7 +--
src/mesa/drivers/dri/intel/intel_regions.h|5 +
src/mesa/drivers/dri/intel/intel_screen.c
---
src/mesa/drivers/dri/i965/brw_defines.h |2 +
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 22 -
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 15 -
src/mesa/drivers/dri/intel/intel_regions.c|5
src/mesa/drivers/dr
Add mappings for:
- DRI_IMAGE_FORMAT_R8
- DRI_IMAGE_FORMAT_RG88
- DRI_IMAGE_FORMAT_L8
- DRI_IMAGE_FIRLAT_LA88
---
src/mesa/drivers/dri/intel/intel_screen.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/
Add basic implementation for createImageFromName2() as the default
entry-point. i.e. wrap the older createImageFromName() into the new
function.
---
src/mesa/drivers/dri/intel/intel_screen.c | 38 ++--
1 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/src/me
Allow regions to be hashed from a single key (name) and plane id. This
is preparatory work to support multitexturing from a single YUV buffer.
---
src/mesa/drivers/dri/intel/intel_regions.c | 98 ++--
src/mesa/drivers/dri/intel/intel_regions.h |9 +++
src/mesa/drivers
This is an extended version of the original intel_region_alloc_for_handle()
function but with extra attributes for future usage. e.g. picture structure,
offset to bo base, etc.
---
src/mesa/drivers/dri/intel/intel_regions.c | 42 +--
src/mesa/drivers/dri/intel/intel_regio
Hi,
This patch series implements the proposed DRI image extension v4
changes to Intel GenX. To be honest, I have not tested the picture
structure patch, as I directly adapted it from the VA driver, where
interlaced surfaces are correctly handled already.
I simplified the hashing stuff to the mini
Hi,
2012/4/23 Rob Clark :
> On Mon, Apr 23, 2012 at 4:54 AM, Gwenole Beauchesne
> wrote:
>> This patch series corresponds to the DRI2 changes needed for my new
>> refactored Wayland and VA/EGL proposals to handle YUV buffers and also
>> a means to differentiate progressive/interlaced contents.
Enabled MESA_FORMAT_RGBX_REV for RGBX. Android software
requires RGBX format to be supported for software rendering.
That requires EGL to be capable of generating images from this
format.
Signed-off-by: Sean V Kelley
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |2 ++
src/me
Add new format __DRI_IMAGE_FORMAT_XBGR to __DRI_IMAGE.
HAL_PIXEL_FORMAT_RGBX_ now maps to __DRI_IMAGE_FORMAT_XBGR.
Signed-off-by: Sean V Kelley
---
include/GL/internal/dri_interface.h |1 +
src/egl/drivers/dri2/platform_android.c |2 ++
2 files changed, 3 insertions(+)
d
On 04/24/2012 01:57 AM, Eric Anholt wrote:
On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacob
wrote:
- Original Message -
On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob
wrote:
conformance/programs/program-test.html: 1 tests failed
PASS linking should fail with in-us
On 04/22/2012 09:44 AM, nobled wrote:
Though not explicit in the GL_ARB_robustness extension,
the GL standard says:
If a negative number is provided where an argument of type sizei or
sizeiptr is specified, the error INVALID_VALUE is generated.
While the extension says that GL_INVALID_OPE
- Original Message -
> On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacob
> wrote:
> >
> >
> > - Original Message -
> > > On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob
> > > wrote:
> > > > > > conformance/programs/program-test.html: 1 tests failed
> > > > >
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=48441
nobled changed:
What|Removed |Added
Attachment #60515|text/x-log |text/plain
mime type|
Hi,
2012/4/24 Ian Romanick :
> On 04/20/2012 04:59 PM, Gwenole Beauchesne wrote:
>> Those patches implement the optional GL_EXT_texture_rg extension for
>> OpenGL ES 2.x on Intel GenX.
>
> Do we have ES2-specific test cases for this? Since there are extra layers
> of enum filtering for ES, we rea
On 04/20/2012 08:20 AM, Olivier Galibert wrote:
Guys, it's a bugfix, it's five lines changed, and it's falling through
the cracks... Can someone have a look?
From my reply on 4/13:
Do you have a specific test case in mind that fails without this
patch but passes with?
OG.
On Wed,
On 04/20/2012 04:59 PM, Gwenole Beauchesne wrote:
Hi,
Those patches implement the optional GL_EXT_texture_rg extension for
OpenGL ES 2.x on Intel GenX.
Do we have ES2-specific test cases for this? Since there are extra
layers of enum filtering for ES, we really need test cases for ES2
befor
On 04/22/2012 11:47 PM, Kenneth Graunke wrote:
On 04/22/2012 01:43 AM, nobled wrote:
As noted in commit be4e46b21a60cfdc826bf89d1078df54966115b1,
this was missing before.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/version.c | 1 +
1 files changed, 1 insertions(+), 0 deletion
On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacob
wrote:
>
>
> - Original Message -
> > On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob
> > wrote:
> > > > > conformance/programs/program-test.html: 1 tests failed
> > > >
> > > > > PASS linking should fail with in-use former
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #14 from Serg Sergiu 2012-04-24 02:15:53 PDT
---
Created attachment 60515
--> https://bugs.freedesktop.org/attachment.cgi?id=60515
valgrind log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #13 from raphael.roc...@gmail.com
2012-04-24 01:40:04 PDT ---
(In reply to comment #12)
> try MALLOC_CHECK_=1 gnome-control-center
Damned. Worked, got 10+ errors like this :
*** glibc detected *** gnome-control-center: free(): inval
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #12 from Alen Skondro 2012-04-24 01:21:29 PDT
---
try MALLOC_CHECK_=1 gnome-control-center
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #11 from raphael.roc...@gmail.com
2012-04-24 01:06:05 PDT ---
(In reply to comment #9)
> FWIW, the environment variable DRAW_USE_LLVM=0 should work around the crash at
> a potential performance penalty.
Tried to run "DRAW_USE_LLVM=0
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #10 from raphael.roc...@gmail.com
2012-04-24 01:02:29 PDT ---
Stange enough, I experience this crash with ati driver.
And there's no crash if using clutter-gtk-1.0.4-1.
That's not a fix of course ... just wanted to note it here in
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #8 from Ionut Biru 2012-04-24 00:51:09 PDT
---
We have couples of valgrid logs
https://bugs.archlinux.org/task/29202?getfile=8642
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=48441
--- Comment #9 from Michel Dänzer 2012-04-24 00:53:34 PDT
---
FWIW, the environment variable DRAW_USE_LLVM=0 should work around the crash at
a potential performance penalty.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
On 04/23/2012 03:11 PM, Eric Anholt wrote:
It seems silly that GL lets you allocate these given that they're
framebuffer attachment incomplete, but the webgl conformance tests
actually go looking to see if the getters on 0-width/height
depth/stencil renderbuffers return good values. By failing o
https://bugs.freedesktop.org/show_bug.cgi?id=48441
Michel Dänzer changed:
What|Removed |Added
CC||obi12...@googlemail.com
--- Comment #7 f
A little analysis shows that the worst-case value for "nr" is 16:
- base_mrf = 2 ... 2
- header present (say gen == 5) ... 4
- SIMD16 mode: += 4 * reg_width ... 12
- source_depth_to_render_target ... 14
- dest_depth_reg ... 16
This resulted in us setting base_m
If we accidentally create a message long enough that base_mrf + mlen >
BRW_MAX_MRF, instruction scheduling would access past the end of the
last_mrf_write array.
Add assertions to catch cases where we would do that. Use the Elements
macro rather than using BRW_MAX_MRF directly since we may rework
68 matches
Mail list logo
