According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515, the element buffer object is listed in vertex array object.
So, move the ElementArrayBufferObj inside gl_array_object to make
element buffer object per-vao.
This would fix most of(3 left) intel oglc vao test fail
S
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
Signed-off-by: Yuanhan Liu
---
tests/all.tests |1 +
tests/general/CMakeLists.gl.txt |
On Tue, Nov 22, 2011 at 11:16:26AM -0700, Brian Paul wrote:
> On 11/22/2011 01:38 AM, Yuanhan Liu wrote:
> >This would make ElementArrayBufferObj data per vertex array object. I did't
> >find something to support this at the spec page[0]. But I did find
> >something that somehow support this at ope
On Wed, Nov 23, 2011 at 05:27:32PM +0800, Yuanhan Liu wrote:
> According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
> page 515: the element buffer object is listed in vertex array object.
>
> Add a testcase to test that.
>
> Signed-off-by: Yuanhan Liu
> ---
> tests/all.tests
https://bugs.freedesktop.org/show_bug.cgi?id=43143
Giovanni Mariani changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Determining software rendering by the string is unreliable.
And the glXIsDirect just duplicates information listed before.
Furthermore, printing these warnings to stdout would be a very bad idea --
scripts which run glxinfo and parse could easily get confused by these messages.
Overall, I real
glxgears is a benchmark, just doesn't benchmark what people often expect. I
often use it as a present/swapbuffers benchmark. So the whole blurb about not
using glxgears as a benchmark is false.
Again, detecting software rendering by the string is unreliable.
Maybe it help if you could provide s
Looks good.
Jose
- Original Message -
> ---
> src/egl/eglut/CMakeLists.txt |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/egl/eglut/CMakeLists.txt
> b/src/egl/eglut/CMakeLists.txt
> index b97caa6..45208d6 100644
> --- a/src/egl/eglut/CMakeLists.txt
>
Looks good to me.
Jose
- Original Message -
> ---
> CMakeLists.txt |4
> src/egl/eglut/CMakeLists.txt |6 ++
> src/util/CMakeLists.txt |4
> src/xdemos/CMakeLists.txt|4
> 4 files changed, 18 insertions(+), 0 deletions(-)
>
> dif
Looks good to me FWIW.
But it might be worth to wait a little more for somebody familiar with autoconf
to review that part well.
Jose
- Original Message -
> It introduces following variables (as prefixes):
> (-D)BINDIR - default: none, ${BINDIR}/${subdir}
> (-D)DATADIR - default: n
https://bugs.freedesktop.org/show_bug.cgi?id=43094
Ingo Theiss changed:
What|Removed |Added
CC||e...@anholt.net
--- Comment #1 from Ingo T
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke wrote:
> On 11/22/2011 07:27 PM, Marek Olšák wrote:
>> On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
>>> All of this discussion is largely moot. The failure that you're so angry
>>> about was caused by a bug in the check, not by the check
https://bugs.freedesktop.org/show_bug.cgi?id=41221
--- Comment #2 from ondrej.pla...@seznam.cz 2011-11-23 06:50:40 PST ---
Hello I have the same problem from the same application like minti
To download the application
svn checkout http://opengles-book-samples.googlecode.com/svn/trunk/LinuxX11
open
https://bugs.freedesktop.org/show_bug.cgi?id=41221
--- Comment #3 from ondrej.pla...@seznam.cz 2011-11-23 06:55:10 PST ---
I forget my hardware set up
-Computer-
Processor: 2x Intel(R) Atom(TM) CPU N270 @ 1.60GHz
Memory: 2050MB (900MB used)
Operating System: Ubuntu 11.10
I agree. I'd rather not see glxinfo and glxgears cluttered with this
kind of output.
I suspect the motivation here is to help diagnose end-user GL issues.
If so, I think it would be better to have a program designed for
that purpose. Such a program could set LIBGL_DEBUG=verbose, query DRI
On 11/23/2011 02:26 AM, Yuanhan Liu wrote:
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515, the element buffer object is listed in vertex array object.
So, move the ElementArrayBufferObj inside gl_array_object to make
element buffer object per-vao.
This would fi
On 11/23/2011 02:34 AM, Yuanhan Liu wrote:
On Wed, Nov 23, 2011 at 05:27:32PM +0800, Yuanhan Liu wrote:
According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
page 515: the element buffer object is listed in vertex array object.
Add a testcase to test that.
Signed-off-by: Yuan
The source array elements are 8-bytes (float + uint) so we need
to multiply the src index by 2 to get the right array stride.
---
src/mesa/main/format_unpack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
in
On 11/23/2011 12:28 AM, zhigang gong wrote:
Hi guys,
I have a question about the internal implementation of glDrawArrays or
any rendering functions.
In the code path, it calls to _mesa_update_texture(), and if there is
really a complete texture,
it will call _mesa_reference_texobj to set it to _C
On 11/21/2011 03:01 PM, Vincent Lejeune wrote:
ureg_DECL_constant2D does not return anything.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ure
On 11/21/2011 03:01 PM, Vincent Lejeune wrote:
This patch adds a 2d ureg_src constructor, and add a field in
st_src_reg inside glsl_to_tgsi that hold potential 2d index.
2d indexing is required at least for uniform buffer object
support
---
src/gallium/auxiliary/tgsi/tgsi_ureg.h
https://bugs.freedesktop.org/show_bug.cgi?id=43122
Kai changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 11/11/2011 10:07 AM, Mathias Fröhlich wrote:
Introduce a set of defines for VERT_ATTRIB_* and VERT_BIT_*
that will be used in the followup patches.
---
src/mesa/main/context.c | 29 ++
src/mesa/main/mtypes.h | 60 --
2 f
On 11/11/2011 10:09 AM, Mathias Fröhlich wrote:
---
src/mesa/main/context.c|2 +-
src/mesa/main/ff_fragment_shader.cpp |2 +-
src/mesa/main/ffvertex_prog.c | 18 +-
src/mesa/main/mtypes.h |
On 11/11/2011 10:10 AM, Mathias Fröhlich wrote:
Replace the distinct struct gl_client_array members in gl_array_object by
an array of gl_client_arrays indexed by VERT_ATTRIB_*.
Renumber the vertex attributes slightly to keep the old semantics of the
distinct array members. Make use of the upper
On 11/11/2011 10:11 AM, Mathias Fröhlich wrote:
The NV_vertex_program generic attributes should alias the legacy
attributes. Simplify aliasing by using the same gl_client_arrays
for legacy and NV_vertex_program attributes.
The same is already done for the current state values.
Are you changing
On 11/11/2011 10:11 AM, Mathias Fröhlich wrote:
Now the gl_array_object's layout matches the one used in
recalculate_input_bindings. Make use of this and remove the
bind_array_obj function.
---
src/mesa/vbo/vbo_exec.h |6
src/mesa/vbo/vbo_exec_array.c | 53 +++
On 11/23/2011 05:42 AM, Marek Olšák wrote:
> On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke
> wrote:
>> On 11/22/2011 07:27 PM, Marek Olšák wrote:
>>> On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
All of this discussion is largely moot. The failure that you're so angry
about
On 11/23/2011 07:40 AM, Brian Paul wrote:
> The source array elements are 8-bytes (float + uint) so we need
> to multiply the src index by 2 to get the right array stride.
> ---
> src/mesa/main/format_unpack.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa
On 11/22/2011 06:47 AM, Jose Fonseca wrote:
- Original Message -
NAK with extreme prejudice. Technically speaking, these are app
bugs.
I absolutely will not disable all correct behavior to work around
broken
apps. The problem is the following shaders will correctly link, but
completel
On 11/23/2011 07:30 AM, Kenneth Graunke wrote:
> See intel_vertical_texture_alignment_unit() in intel_tex_layout.c;
> certain surface types require setting this to VALIGN_4.
>
> Analogous to commit dd0e46c4102976b7d317104ecd1bb565ac34613a on Gen6.
>
> Fixes piglit test fbo-generatemipmap-formats
Set the "Tiled Surface" bit in 3DSTATE_DEPTH_BUFFER. From the BSpec:
[DevGT+]: This field must be set to TRUE.
Fixes GPU hangs on following the Piglit tests:
hiz-stencil-test-fbo-d0-s8
hiz-stencil-read-fbo-d0-s8
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_misc_state.c
On 11/23/2011 10:11 AM, Chad Versace wrote:
> Set the "Tiled Surface" bit in 3DSTATE_DEPTH_BUFFER. From the BSpec:
I believe you mean
"From the Sandybridge PRM, Volume 2, Part 1, section 7.5.5.1.1:"
>[DevGT+]: This field must be set to TRUE.
Also, do we want to set this bit when emitting 3DS
On 11/22/2011 07:27 PM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick wrote:
All of this discussion is largely moot. The failure that you're so angry
about was caused by a bug in the check, not by the check itself. That bug
has already been fixed (commit 151867b).
The exac
On 11/23/2011 05:42 AM, Marek Olšák wrote:
On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke wrote:
So, again, if the interest is in making more apps succeed, we should
start with varying packing. That's useful all around, and I doubt
anyone can dispute that it's necessary.
No, that's not the
See intel_vertical_texture_alignment_unit() in intel_tex_layout.c;
certain surface types require setting this to VALIGN_4.
Analogous to commit dd0e46c4102976b7d317104ecd1bb565ac34613a on Gen6.
Fixes piglit test fbo-generatemipmap-formats with the
GL_ARB_depth_texture and GL_EXT_packed_depth_stenc
- Original Message -
> On 11/22/2011 06:47 AM, Jose Fonseca wrote:
> > - Original Message -
> >> There's over a month before what is currently master will be
> >> released.
> >> People that don't like this bug can use a stable release.
> >
> > This will drive testers affected by thi
On Tue, 22 Nov 2011 18:07:01 -0700, Brian Paul wrote:
> This will replace the soon-to-be-removed _DD_NEW_SEPARATE_SPECULAR flag.
> ---
> src/mesa/main/mtypes.h |6 ++
> src/mesa/main/state.c |4 ++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/m
On 11/23/2011 10:26 AM, Kenneth Graunke wrote:
> On 11/23/2011 10:11 AM, Chad Versace wrote:
>> Set the "Tiled Surface" bit in 3DSTATE_DEPTH_BUFFER. From the BSpec:
>
> I believe you mean
> "From the Sandybridge PRM, Volume 2, Part 1, section 7.5.5.1.1:"
>
>>[DevGT+]: This field must be set t
On 11/23/2011 11:58 AM, Eric Anholt wrote:
On Tue, 22 Nov 2011 18:07:01 -0700, Brian Paul wrote:
This will replace the soon-to-be-removed _DD_NEW_SEPARATE_SPECULAR flag.
---
src/mesa/main/mtypes.h |6 ++
src/mesa/main/state.c |4 ++--
2 files changed, 8 insertions(+), 2 deletio
On Wed, 23 Nov 2011 17:34:30 +0800, Yuanhan Liu
wrote:
> From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001
> From: Yuanhan Liu
> Date: Wed, 23 Nov 2011 17:37:33 +0800
> Subject: [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY_BUFFER
> is per vao
>
> According o
On 11/23/2011 12:12 PM, Eric Anholt wrote:
On Wed, 23 Nov 2011 17:34:30 +0800, Yuanhan Liu
wrote:
From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001
From: Yuanhan Liu
Date: Wed, 23 Nov 2011 17:37:33 +0800
Subject: [PATCH] Add a simple testcase to test that GL_ELEMENT_ARRAY
On 11/23/2011 06:34 PM, Kenneth Graunke wrote:
> See intel_vertical_texture_alignment_unit() in intel_tex_layout.c;
> certain surface types require setting this to VALIGN_4.
>
> Analogous to commit dd0e46c4102976b7d317104ecd1bb565ac34613a on Gen6.
>
> Fixes piglit test fbo-generatemipmap-formats
For the non-separate-stencil-only case, we've been using a NULL
surface for depth, so we didn't have to care. However, to support
separate stencil with no depthbuffer, we have to make the depth
surface non-NULL or the stencil test always fails thanks to separate
stencil inheriting the surface type
This looks to have been confused with pitch setup, which does have to
be doubled. The width is inherited by separate stencil, and it should
naturally look like the setup in the block below involving a valid
depthbuffer.
---
src/mesa/drivers/dri/i965/brw_misc_state.c |2 +-
1 files changed, 1
It is useful to have this option for shader-db, and it was also good
at the time where we were rejecting shaders due to various internal
limits we hadn't supported yet. However, at this point the precompile
step takes extra time (since not all NOS is known at link time) and
spews misleading debug
In the refactor for handling user-defined out params, we failed to set
up the new color output tracking when there was no color drawbuffer in
place but alpha testing was on. Just always set up at least one when
handling gl_FragColor, since we won't make use of its value unless we
need to.
Bugzill
In 6d874d0ee18b3694c49e0206fa519bd8b746ec24, I checked whether a
register that had been stored was BAD_FILE (as opposed to a legitimate
GRF), but actually the unset register was ARF NULL because it had been
memset to 0. Finding BAD_FILE for unset values in debugging was my
intention with that file
On Mon, 21 Nov 2011 16:27:57 +0800, Yuanhan Liu
wrote:
> Add a draw-pixel-with-texture testcase to check if texture
> sampling is happened while drawing pixels by glDrawPixels.
>
> v2: use piglit_probe_rect_rgba instead of just sampling a
> set of pixels(comments from Eric)
>
> Signed-off-b
I tripped over this bug in the next commit, relying on our
EXT_texture_swizzle to do some shadow sampler-related swizzling. If a
writemask was masking out a channel of the destination that was a live
channel of the texture swizzle, it would read undefined values.
---
src/mesa/drivers/dri/i965/brw
We were already doing it through the shader (layered underneath
GL_EXT_texture_swizzle) in the shadow compare case. This avoids
having per-format logic for switching out the surface format dependent
on the depth mode.
---
src/mesa/drivers/dri/i965/brw_wm.c | 38 +++
Asking for the datatype of MESA_FORMAT_Z32_FLOAT_X24S8 is a bit funny
-- there's a float depth channel, and a stencil channel that doesn't
have a particular GLenum associated with its type, so what's the correct
response?
Because there is no query for stencil, just make this format's
datatype be
This is required by GL 3.0's Required Texture Formats section. All
the other code for this format in hardware was already in place.
---
src/mesa/drivers/dri/i965/brw_vtbl.c |3 ++-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |1 +
2 files changed, 3 insertions(+), 1 delet
This will make handling new formats (like actually exposing Z32F)
easier and more reliable.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 53 +--
src/mesa/drivers/dri/i965/brw_state.h |9 +++--
src/mesa/drivers/dri/i965/gen7_misc_state.c | 30 +
The MESA_FORMAT_Z32_FLOAT_X24S8 support will come later, and involves
a bunch of trickery with hiz. Also, Z32_FLOAT will fail for swrast
paths until they change to MapRenderbuffer.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |5 +
src/mesa/drivers/dri/intel/intel_extensions.c
There was only one consumer of this API, meta.c, which was intending
to ask "is this format just stencil index (and nothing else)?".
Instead, if one tried to glDrawPixels of GL_DEPTH_STENCIL-type
formats, it would just try to draw the stencil parts. Nothing good
came of this.
This function looks
On 11/23/2011 01:37 PM, Eric Anholt wrote:
Asking for the datatype of MESA_FORMAT_Z32_FLOAT_X24S8 is a bit funny
-- there's a float depth channel, and a stencil channel that doesn't
have a particular GLenum associated with its type, so what's the correct
response?
Because there is no query for
On 11/23/2011 01:37 PM, Eric Anholt wrote:
There was only one consumer of this API, meta.c, which was intending
to ask "is this format just stencil index (and nothing else)?".
Instead, if one tried to glDrawPixels of GL_DEPTH_STENCIL-type
formats, it would just try to draw the stencil parts. Not
https://bugs.freedesktop.org/show_bug.cgi?id=41221
--- Comment #4 from Ian Romanick 2011-11-23 13:25:47 PST
---
The examples from the Orange book use desktop OpenGL. OpenGL ES 2.0 has the
added restriction (compared to desktop OpenGL 2.x) that there *must* be both a
vertex shader and a fragment
https://bugs.freedesktop.org/show_bug.cgi?id=41221
Ian Romanick changed:
What|Removed |Added
CC||i...@freedesktop.org
--
Configure bugmai
On 11/23/2011 06:34 PM, Kenneth Graunke wrote:
See intel_vertical_texture_alignment_unit() in intel_tex_layout.c;
certain surface types require setting this to VALIGN_4.
Analogous to commit dd0e46c4102976b7d317104ecd1bb565ac34613a on Gen6.
Fixes piglit test fbo-generatemipmap-formats with the
G
---
src/mesa/main/fbobject.c | 45 -
src/mesa/main/texparam.c | 25 +
src/mesa/main/texparam.h |3 +++
3 files changed, 28 insertions(+), 45 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
in
Use the _mesa_base_format_has_channel() helper as we do for the
other texture format component queries.
---
src/mesa/main/texparam.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index 4c30a36..
This is where other format-related functions live.
---
src/mesa/main/fbobject.c |2 +-
src/mesa/main/image.c| 87 ++
src/mesa/main/image.h|3 ++
src/mesa/main/texparam.c | 84 +---
src/mesa/main
This simplifies a few callers. And it adds a bit of robustness.
---
src/mesa/main/bufferobj.c|6 +++---
src/mesa/main/bufferobj.h|2 +-
src/mesa/state_tracker/st_draw.c | 10 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/bufferob
If alpha test is enabled and there's no color buffers we still need the
fragment shader to emit a color.
Fixes piglit fbo-alphatest-nocolor-ff failures with Gallium drivers.
---
src/mesa/main/ff_fragment_shader.cpp |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/
On Wed, Nov 23, 2011 at 7:27 PM, Ian Romanick wrote:
> On 11/23/2011 05:42 AM, Marek Olšák wrote:
>>
>> On Wed, Nov 23, 2011 at 6:59 AM, Kenneth Graunke
>> wrote:
>>>
>>> So, again, if the interest is in making more apps succeed, we should
>>> start with varying packing. That's useful all around
On 11/23/2011 02:35 PM, Brian Paul wrote:
If alpha test is enabled and there's no color buffers we still need the
fragment shader to emit a color.
Fixes piglit fbo-alphatest-nocolor-ff failures with Gallium drivers.
It looks like this an Eric's recent patch
(http://lists.freedesktop.org/archi
From: Anuj Phogat
This is an updated patch to allow glTexImage2D with a depth component cube map.
Patch
was producing an expected ouput with depth-cube-map test (posted on piglit
mailing list).
But i'm getting an incorrect output since i updated my mesa branch with
git://anongit.freedesktop.or
On Wed, Nov 23, 2011 at 08:25:59AM -0700, Brian Paul wrote:
> On 11/23/2011 02:26 AM, Yuanhan Liu wrote:
> >According opengl spec 4.2.pdf table 6.12 (Vertex Array Object State) at
> >page 515, the element buffer object is listed in vertex array object.
> >
> >So, move the ElementArrayBufferObj insi
On Wed, Nov 23, 2011 at 11:12:19AM -0800, Eric Anholt wrote:
> On Wed, 23 Nov 2011 17:34:30 +0800, Yuanhan Liu
> wrote:
> > From 9a1da8748f0faa23f34398213ff7ee45fda6bf36 Mon Sep 17 00:00:00 2001
> > From: Yuanhan Liu
> > Date: Wed, 23 Nov 2011 17:37:33 +0800
> > Subject: [PATCH] Add a simple tes
On Wed, Nov 23, 2011 at 08:33:00AM -0700, Brian Paul wrote:
> On 11/23/2011 02:34 AM, Yuanhan Liu wrote:
> >+GLuint element;
> >+GLfloat vertics[] = {
>
> minor nit: s/vertics/vertices/
>
>
> >+-1, -1, 0,
> >+ 1, -1, 0,
> >+ 1, 1, 0,
> >+-
On Wed, Nov 23, 2011 at 11:58:36AM -0800, Eric Anholt wrote:
> On Mon, 21 Nov 2011 16:27:57 +0800, Yuanhan Liu
> wrote:
> > Add a draw-pixel-with-texture testcase to check if texture
> > sampling is happened while drawing pixels by glDrawPixels.
> >
> > v2: use piglit_probe_rect_rgba instead of
On Wed, Nov 23, 2011 at 03:35:23PM -0700, Brian Paul wrote:
> This simplifies a few callers. And it adds a bit of robustness.
> ---
> src/mesa/main/bufferobj.c|6 +++---
> src/mesa/main/bufferobj.h|2 +-
> src/mesa/state_tracker/st_draw.c | 10 +-
> 3 files chang
Hi Brian,
Thanks for looking into the changes.
On Wednesday, November 23, 2011 17:24:23 Brian Paul wrote:
> I think there's a few places where we need to map GLenums for vertex
> arrays to VERT_ATTRIB_x values. Maybe there should be a helper
> function for that:
>
> gl_vert_attrib
> array_enum
https://bugs.freedesktop.org/show_bug.cgi?id=43138
--- Comment #6 from sunyi 2011-11-23 22:58:02 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > This problem only exists in 7.11,correct?
> > >
> > The issue still exists in master branch.
> >
> > >
Hi,
On Wednesday, November 23, 2011 17:27:12 Brian Paul wrote:
> On 11/11/2011 10:11 AM, Mathias Fröhlich wrote:
> > The NV_vertex_program generic attributes should alias the legacy
> > attributes. Simplify aliasing by using the same gl_client_arrays
> > for legacy and NV_vertex_program attribute
77 matches
Mail list logo
