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 opengl wiki page[1].
NOTE: with my test, both NV and ATI's closed source opengl
implementation would attach the
BindBuffer* functions are part of tfb extension. They are however
used by others extensions such as uniform buffer object.
This patch moves the BindBuffer* definition to to bufferobj.c
where it acts as a dispatcher calling original tfb function ;
BindBuffer* functions can be used by
- Original Message -
If the gallium driver doesn't support PIPE_FORMAT_R16G16B16A16_SNORM
the call to st_choose_renderbuffer_format() would fail and we'd
generate
an GL_OUT_OF_MEMORY error. We'd never get to the subsequent code
that
handles software/malloc-based renderbuffers.
The linker now adds color varyings to the number of used varyings and checks
against that limit.
---
src/mesa/state_tracker/st_extensions.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
These are different from hardware limits, because some drivers can correctly
handle higher values than they report in most cases, either due
to driver-specific compiler optimizations, or due to just how the hardware
works internally.
The problem with the linker is that it artifically reduces
On Mon, Nov 21, 2011 at 7:54 PM, Ian Romanick i...@freedesktop.org wrote:
NAK with extreme prejudice. Technically speaking, these are app bugs. I
absolutely will not disable all correct behavior to work around broken apps.
You are picturing a perfect world that doesn't exist. The world
doesn't
- 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
completely explode:
uniform float array[1234];
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while advertising to
the app the pipe driver ones
- or detect the wine process and advertise bigger limits in
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface changes:
- e.g., provide to GLSL compiler infinite/huge limits, while advertising to
the app the
On 11/22/2011 07:20 AM, Marek Olšák wrote:
On Mon, Nov 21, 2011 at 7:54 PM, Ian Romanicki...@freedesktop.org wrote:
NAK with extreme prejudice. Technically speaking, these are app bugs. I
absolutely will not disable all correct behavior to work around broken apps.
You are picturing a
- Original Message -
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com
wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium interface
changes:
- e.g., provide to GLSL compiler infinite/huge
On Tue, Nov 22, 2011 at 6:04 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
On Tue, Nov 22, 2011 at 4:05 PM, Jose Fonseca jfons...@vmware.com
wrote:
Marek,
I think we should take one of two approaches here:
- aim for a short-term workaround, without gallium
On Mon, Nov 21, 2011 at 8:01 PM, Ian Romanick i...@freedesktop.org wrote:
On 11/19/2011 07:42 AM, Marek Olšák wrote:
On Fri, Nov 18, 2011 at 9:44 PM, Ian Romanicki...@freedesktop.org wrote:
On 11/18/2011 11:27 AM, Marek Olšák wrote:
This patch also needs to change the
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 opengl wiki page[1].
NOTE: with my test, both NV and ATI's closed
From: Anuj Phogat anuj.pho...@gmail.com
Hi Brian,
I think something like this would be simpler:
@@ -1629,7 +1629,9 @@ texture_error_check( struct gl_context *ctx,
target != GL_TEXTURE_2D_ARRAY
target != GL_PROXY_TEXTURE_2D_ARRAY
target != GL_TEXTURE_RECTANGLE_ARB
- target !=
https://bugs.freedesktop.org/show_bug.cgi?id=42930
Niels P. nill...@freenet.de changed:
What|Removed |Added
Status|NEW |RESOLVED
From: Dave Airlie airl...@redhat.com
A later error prints this properly, fix this case to do the same.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/glsl/linker.cpp |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43122
---
src/mesa/main/format_unpack.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index 6e2ce7a..52f224a 100644
---
On Tue, Nov 22, 2011 at 2:07 PM, Marek Olšák mar...@gmail.com wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43122
---
src/mesa/main/format_unpack.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/format_unpack.c
On Tue, Nov 22, 2011 at 9:13 PM, Patrick Baggett
baggett.patr...@gmail.com wrote:
On Tue, Nov 22, 2011 at 2:07 PM, Marek Olšák mar...@gmail.com wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43122
---
src/mesa/main/format_unpack.c | 10 ++
1 files changed, 10
On 11/22/2011 11:57 AM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
A later error prints this properly, fix this case to do the same.
Signed-off-by: Dave Airlieairl...@redhat.com
Other than the one additional change suggested below,
Reviewed-by: Ian Romanick
On 11/22/2011 01:21 PM, Kenneth Graunke wrote:
On 11/22/2011 11:42 AM, Anuj Phogat wrote:
[snip]
I agree. This is simpler to read and _mesa_is_cube_map_face() can be reused
in mesa. Posting an updated patch with your suggestions.
I haven't tested this so the logic might be incorrect.
2011/11/21 Christian König deathsim...@vodafone.de:
On 16.11.2011 15:38, Maarten Lankhorst wrote:
If the decode_bitstream interface is changed to get all bitstream buffers
at the same time,
there wouldn't be overhead to doing it like this. For a single picture
it's supposed to stay constant,
---
There are regressions that look hiz-related on gm45 as well. On 915,
while this gets things building, it'still in bad shape. Glean
pixelformats, for example, segfaults at:
759 colorRegion = irb ? irb-mt-region : NULL;
of i915_vtbl.c. Tossing in some assertion, it's that irb-mt
Dear Marek,
Marek Olšák schrieb am 22.11.2011 21:07:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43122
---
src/mesa/main/format_unpack.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
[...]
I saw your patch and as I reported the referenced bug, I went
https://bugs.freedesktop.org/show_bug.cgi?id=43122
--- Comment #7 from Kai deb...@carbon-project.org 2011-11-22 13:32:50 PST ---
Just for reference: a fix has been proposed:
http://lists.freedesktop.org/archives/mesa-dev/2011-November/014968.html
--
Configure bugmail:
From: Ian Romanick ian.d.roman...@intel.com
Page 77 (page 91 of the PDF) says about glGetActiveAttrib:
The returned attribute name can be the name of a generic
attribute or a conventional attribute (which begin with the prefix
gl_, see the OpenGL Shading Language specification for a
https://bugs.freedesktop.org/show_bug.cgi?id=43138
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment
v2:Big cleanup of data structures used
---
src/mesa/main/config.h|4 ++
src/mesa/main/mtypes.h| 18
src/mesa/main/shaderobj.c | 29 -
src/mesa/program/prog_parameter.h |1 +
src/mesa/program/prog_uniform.c |4 ++
On Tue 22 Nov 2011 12:21:09 PM PST, Kenneth Graunke wrote:
On 11/22/2011 11:42 AM, Anuj Phogat wrote:
[snip]
I agree. This is simpler to read and _mesa_is_cube_map_face() can be reused
in mesa. Posting an updated patch with your suggestions.
I haven't tested this so the logic might be
On 11/17/2011 08:24 AM, Eric Anholt wrote:
On Wed, 16 Nov 2011 11:08:23 -0800, Ian Romanicki...@freedesktop.org wrote:
From: Ian Romanickian.d.roman...@intel.com
Previously the fixed-function fragment shader was tracked as a
gl_program. This means that it shows up in the driver as a Mesa IR
On 11/22/2011 03:34 PM, Anuj Phogat wrote:
On Tue 22 Nov 2011 12:21:09 PM PST, Kenneth Graunke wrote:
On 11/22/2011 11:42 AM, Anuj Phogat wrote:
[snip]
I agree. This is simpler to read and _mesa_is_cube_map_face() can
be reused
in mesa. Posting an updated patch with your suggestions.
On 11/22/2011 10:00 PM, Younes Manton wrote:
2011/11/21 Christian König deathsim...@vodafone.de:
On 16.11.2011 15:38, Maarten Lankhorst wrote:
If the decode_bitstream interface is changed to get all bitstream buffers
at the same time,
there wouldn't be overhead to doing it like this. For a
---
src/mesa/main/uniform_query.cpp |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 33ba53c..dbaeacb 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -648,7
---
src/mesa/main/mtypes.h |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 96a4426..e8866c6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1342,15 +1342,6 @@ struct gl_texture_object
Just use the corresponding _NEW_x flags intead. The _DD_NEW_x flags
will be removed in a following patch.
---
src/mesa/drivers/dri/i915/intel_tris.h | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_tris.h
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/mtypes.h b/src/mesa/main/mtypes.h
index e8866c6..c94a065 100644
---
---
src/mesa/swrast/s_context.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
index 98702f0..310c315 100644
--- a/src/mesa/swrast/s_context.c
+++ b/src/mesa/swrast/s_context.c
@@ -309,7 +309,7 @@
---
src/mesa/tnl/t_vertex.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/tnl/t_vertex.c b/src/mesa/tnl/t_vertex.c
index 6582949..580f95d 100644
--- a/src/mesa/tnl/t_vertex.c
+++ b/src/mesa/tnl/t_vertex.c
@@ -269,7 +269,8 @@ void *_tnl_get_vertex( struct
They're no longer used anywhere.
---
src/mesa/main/mtypes.h | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index c94a065..2b47147 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org 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 exact same check was
On 11/22/2011 07:27 PM, Marek Olšák wrote:
On Tue, Nov 22, 2011 at 11:11 PM, Ian Romanick i...@freedesktop.org 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
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
43 matches
Mail list logo
