---
docs/GL3.txt |4 +-
src/gallium/drivers/nvc0/nvc0_3d.xml.h |4 +
src/gallium/drivers/nvc0/nvc0_graph_macros.h | 121 ++
src/gallium/drivers/nvc0/nvc0_screen.c |6 ++
src/gallium/drivers/nvc0/nvc0_vbo.c |
On 31.01.2013 09:30, Michel Dänzer wrote:
On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
- Original Message -
On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote:
- Original Message -
On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote:
I've been looking at
On 28.01.2013 19:54, Ian Romanick wrote:
On 01/27/2013 12:19 PM, Eric Anholt wrote:
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
On 27.01.2013 00:58, Eric Anholt wrote:
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
diff --git a/src/mesa/main/teximage.c b/src/mesa/main
From: Christoph Bumiller christoph.bumil...@speed.at
Only the test of the extension enable should be relevant.
---
src/mesa/main/teximage.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 31a559e..5a27797 100644
On 28.01.2013 23:37, Chad Versace wrote:
On 01/28/2013 02:01 PM, Christoph Bumiller wrote:
From: Christoph Bumiller christoph.bumil...@speed.at
Only the test of the extension enable should be relevant.
I don't think this change is correct.
So, maybe I misinterpreted the advice in the mesa
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
On 27.01.2013 00:58, Eric Anholt wrote:
Christoph Bumiller e0425...@student.tuwien.ac.at writes:
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 31a559e..e71f6e1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
+/** GL_ARB_texture_buffer_object
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
On 23.01.2013 11:31, Christian König wrote:
On 23.01.2013 03:18, Tom Stellard wrote:
On Wed, Jan 23, 2013 at 02:20:21AM +0100, Christoph Bumiller wrote:
On 23.01.2013 02:07, Vadim Girlin wrote:
On 01/23/2013 04:42 AM, Christoph Bumiller wrote:
On 23.01.2013 01:21, Vadim Girlin wrote:
On 01
On 23.01.2013 01:21, Vadim Girlin wrote:
On 01/23/2013 03:59 AM, Vincent Lejeune wrote:
- Mail original -
De : Vadim Girlin vadimgir...@gmail.com
À : Christoph Bumiller e0425...@student.tuwien.ac.at
Cc : mesa-dev@lists.freedesktop.org
Envoyé le : Mercredi 23 janvier 2013 0h44
On 23.01.2013 01:47, Vadim Girlin wrote:
On 01/23/2013 04:07 AM, Dave Airlie wrote:
On Wed, Jan 23, 2013 at 9:44 AM, Vadim Girlin vadimgir...@gmail.com
wrote:
On 01/22/2013 10:59 PM, Christoph Bumiller wrote:
On 21.01.2013 21:10, Vadim Girlin wrote:
Provide the information about indirectly
On 23.01.2013 02:07, Vadim Girlin wrote:
On 01/23/2013 04:42 AM, Christoph Bumiller wrote:
On 23.01.2013 01:21, Vadim Girlin wrote:
On 01/23/2013 03:59 AM, Vincent Lejeune wrote:
- Mail original -
De : Vadim Girlin vadimgir...@gmail.com
À : Christoph Bumiller e0425
On 08.01.2013 18:06, Matt Turner wrote:
On Tue, Jan 8, 2013 at 5:00 AM, Andreas Boll andreas.boll@gmail.com
wrote:
From: Arvind R arvin...@gmail.com
applications cannot load libXvMC.so due to nv30_screen_create being
undefined.
This patch fixes that. And MPlayer successfully uses XvMC
On 31.12.2012 04:21, Johannes Obermayr wrote:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58879
---
On debug builds it is included:
nv50_ir.cpp:23 - nv50_ir.h:33 - nv50_ir_util.h:33 - typeinfo
And on non-debug builds it's supposed to *not* be included, because they
should work without
On 31.12.2012 14:01, Christoph Bumiller wrote:
On 31.12.2012 04:21, Johannes Obermayr wrote:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58879
---
On debug builds it is included:
nv50_ir.cpp:23 - nv50_ir.h:33 - nv50_ir_util.h:33 - typeinfo
And on non-debug builds it's supposed
---
src/gallium/docs/source/screen.rst |3 +++
src/gallium/include/pipe/p_defines.h |3 ++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index f4750e5..aea7542 100644
---
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
v2: Update to handle BufferSize being -1 and return a NULL sampler
view if the specified range would cause out of bounds access.
---
src/mesa/state_tracker/st_atom_texture.c | 22 +-
src/mesa/state_tracker/st_extensions.c |6 ++
2 files changed, 27 insertions(+), 1
v2: Record texObj.BufferSize as -1 in TexBuffer(non-Range) instead
of the buffer's current size so we know we always have to use the
full size of the buffer object (i.e. even if it changes without the
user calling TexBuffer again) for the texture.
Clarify invalid offset alignment error message.
---
src/mapi/glapi/gen/ARB_texture_buffer_range.xml | 22 ++
src/mapi/glapi/gen/Makefile.am |1 +
src/mapi/glapi/gen/gl_API.xml |2 +
src/mesa/main/context.c |1 +
src/mesa/main/extensions.c |1 +
---
src/gallium/docs/source/screen.rst |3 +++
src/gallium/include/pipe/p_defines.h |3 ++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 6c89171..f520704 100644
---
---
src/mesa/state_tracker/st_atom_texture.c | 15 ++-
src/mesa/state_tracker/st_extensions.c |6 ++
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index dba1d82..bd2135f
On 16.12.2012 18:10, Brian Paul wrote:
On Sun, Dec 16, 2012 at 9:50 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
---
src/mapi/glapi/gen/ARB_texture_buffer_range.xml | 22 ++
src/mapi/glapi/gen/Makefile.am |1 +
src/mapi/glapi/gen/gl_API.xml
On 04.12.2012 01:07, Marek Olšák wrote:
so that ReadPixels and various fallbacks work.
Err, shouldn't the state tracker do the resolve ? What if someone wants
to read back the individual samples ?
Yes, I know this adds a few complications, like how they are stored for
the transfer (maybe read
On 25.11.2012 23:31, Marek Olšák wrote:
On Thu, Nov 8, 2012 at 7:08 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
DCL TEMP[0..3] = array without indirect access (registers)
DCL TEMP[4..12] = indirectly accessed array
DCL TEMP[12..20] = another indirectly accessed array
DCL IMM
On 08.11.2012 16:03, Tom Stellard wrote:
On Thu, Nov 08, 2012 at 12:59:06PM +0100, Christoph Bumiller wrote:
On 08.11.2012 01:48, Brian Paul wrote:
On 11/05/2012 01:14 PM, Tom Stellard wrote:
From: Tom Stellardthomas.stell...@amd.com
---
src/gallium/docs/source/screen.rst | 2
On 08.11.2012 18:16, Tom Stellard wrote:
On Thu, Nov 08, 2012 at 05:45:00PM +0100, Christoph Bumiller wrote:
On 08.11.2012 16:03, Tom Stellard wrote:
On Thu, Nov 08, 2012 at 12:59:06PM +0100, Christoph Bumiller wrote:
On 08.11.2012 01:48, Brian Paul wrote:
On 11/05/2012 01:14 PM, Tom Stellard
On 08.09.2012 23:52, Marek Olšák wrote:
Hi everyone,
I'd like to move the BlitFramebuffer implementation into gallium
drivers. The pros are:
- allowing MSAA resource blitting to be accelerated on any hardware
- allowing stencil blitting to be accelerated on any hardware
- drivers are more
On 07.09.2012 12:30, Jose Fonseca wrote:
- Original Message -
On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca jfons...@vmware.com
wrote:
Matt,
I see you went ahead and just disabled it. Please remove it all
together.
Touching code that is not built nor tested ends just silently
On 07.09.2012 17:17, Matt Turner wrote:
On Fri, Sep 7, 2012 at 7:55 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 07.09.2012 12:30, Jose Fonseca wrote:
- Original Message -
On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca jfons...@vmware.com
wrote:
Matt,
I see you
On 01.08.2012 07:52, Kenneth Graunke wrote:
On 07/31/2012 06:04 PM, Eric Anholt wrote:
Prior to GL 4.2 spec, there was no guidance on how to implement
BlitFramebuffer for sRGB. Mesa chose to implement skipping decode and
encode,
providing a reasonable behavior for sRGB - sRGB or RGB - RGB,
On 01.08.2012 11:59, Christoph Bumiller wrote:
On 01.08.2012 07:52, Kenneth Graunke wrote:
On 07/31/2012 06:04 PM, Eric Anholt wrote:
Prior to GL 4.2 spec, there was no guidance on how to implement
BlitFramebuffer for sRGB. Mesa chose to implement skipping decode and
encode,
providing
The format member of pipe_surface may differ from that of the
pipe_resource, which is used to communicate, for instance, whether
sRGB encode should be enabled in the resolve operation or not.
Fixes resolve to sRGB surfaces in mesa/st when GL_FRAMEBUFFER_SRGB
is disabled.
---
sRGBEnabled should affect both textures and renderbuffers, so we need
to check/update the pipe_surface format for both.
Fixes, for instance, rendering appearing too bright in wine applications
using sRGB multisample renderbuffers.
---
src/mesa/state_tracker/st_atom_framebuffer.c |5 +++--
1
On 25.06.2012 08:37, Olivier Galibert wrote:
That capability requires integer handling and that's not yet active,
ending with a failure in draw-non-instanced unless you force it on.
See bug 51366.
Frankly, I'd rather have that patch rejected and integer/glsl 130
capability activated
On 06/12/2012 12:27 PM, Olivier Galibert wrote:
Hi all,
I'm getting a little lost in all the interactions between the
different parts of the GL standards and what I understand of the
expectations when it comes to MSAA. It would be nice if I could have
some clarifications.
I'll start
On 06/12/2012 02:25 PM, Olivier Galibert wrote:
On Tue, Jun 12, 2012 at 01:50:08PM +0200, Christoph Bumiller wrote:
First question: how many depths should be computed, and for which
coordinates? Which of these values is associated with which sample?
One for each sample point. The depth buffer
On 06/12/2012 06:52 PM, Jerome Glisse wrote:
On Tue, Jun 12, 2012 at 8:39 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 06/12/2012 02:25 PM, Olivier Galibert wrote:
On Tue, Jun 12, 2012 at 01:50:08PM +0200, Christoph Bumiller wrote:
First question: how many depths should
v2: use a define for the maximum sample count
While multisample renderbuffers are supported by mesa, MS visuals
are not, so we need a way to tell dri/st not to advertise them even
if the gallium driver does support multisampled surfaces.
Otherwise applications selecting these non-functional
v2: use a define for the maximum sample count
v3: also test odd sample counts (r300 supports MS3)
While multisample renderbuffers are supported by mesa, MS visuals
are not, so we need a way to tell dri/st not to advertise them even
if the gallium driver does support multisampled surfaces.
On 25.05.2012 13:24, Christoph Bumiller wrote:
v2: use a define for the maximum sample count
v3: also test odd sample counts (r300 supports MS3)
I'd only checked r500 docs which really doesn't support 3 samples (so it
seemed really no hw supported an odd number), but r300 seems to after
all, so
On 05/22/2012 04:23 PM, Brian Paul wrote:
On 05/21/2012 03:46 PM, Christoph Bumiller wrote:
---
src/gallium/include/state_tracker/st_api.h | 16 +
src/gallium/state_trackers/dri/common/dri_screen.c | 23
+++
src/gallium/state_trackers/vega
On 05/22/2012 04:23 PM, Brian Paul wrote:
On 05/21/2012 03:46 PM, Christoph Bumiller wrote:
---
src/gallium/include/state_tracker/st_api.h | 16 +
src/gallium/state_trackers/dri/common/dri_screen.c | 23
+++
src/gallium/state_trackers/vega
On 05/22/2012 05:58 PM, Brian Paul wrote:
On 05/22/2012 08:37 AM, Christoph Bumiller wrote:
On 05/22/2012 04:23 PM, Brian Paul wrote:
On 05/21/2012 03:46 PM, Christoph Bumiller wrote:
---
src/gallium/include/state_tracker/st_api.h | 16
+
src/gallium
On 21.05.2012 12:27, Rafał Miłecki wrote:
I'm trying to run Diablo III using wine git and Mesa git.
Right now game doesn't start with the following message:
Diablo 3 cannot run because this graphics card is missing required features.
Updating your driver may fix this.
I wonder if enabling
---
src/gallium/include/state_tracker/st_api.h | 16 +
src/gallium/state_trackers/dri/common/dri_screen.c | 23 +++
src/gallium/state_trackers/vega/vg_manager.c |1 +
src/mesa/state_tracker/st_manager.c|1 +
4 files changed, 31
On 14.05.2012 09:25, Jose Fonseca wrote:
Looks good. Thanks Vinson.
Joe
Actually, all the user_buffer pointers have a comment /** pointer to a
user buffer if buffer == NULL */, so you wouldn't actually have to
initialize them if buffer is guaranteed to be non-NULL, and checking for
user_buffer
---
src/mesa/state_tracker/st_cb_bufferobjects.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
b/src/mesa/state_tracker/st_cb_bufferobjects.c
index 6534a43..b47a2d8 100644
--- a/src/mesa/state_tracker/st_cb_bufferobjects.c
On 11.05.2012 16:03, Francisco Jerez wrote:
jfons...@vmware.com writes:
From: José Fonseca jfons...@vmware.com
For consistency.
I'm OK with this change, but, just so that you know, the only reason I
called it TGSI_BUFFER instead of TGSI_TEXTURE_BUFFER was to keep it
consistent with the
This is not necessarily the product of MAX_BLOCK_SIZE[i].
---
src/gallium/docs/source/screen.rst|5 +
src/gallium/include/pipe/p_defines.h |1 +
src/gallium/state_trackers/clover/api/device.cpp |3 ++-
src/gallium/state_trackers/clover/core/device.cpp
On 05/07/2012 08:34 PM, Eric Anholt wrote:
On Sat, 05 May 2012 14:43:44 +0200, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
Test case for the glsl_to_tgsi: use TGSI_OPCODE_CEIL for
ir_unop_ceil patch attached.
This wasn't caught by the generated test for ceil()? That seems
The implementation using FLR was buggy, the second negation could
get lost.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index
---
src/gallium/drivers/i915/i915_fpc_translate.c | 16
src/gallium/drivers/nv30/nvfx_fragprog.c |4
src/gallium/drivers/nv30/nvfx_vertprog.c |4
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git
Test case for the glsl_to_tgsi: use TGSI_OPCODE_CEIL for ir_unop_ceil
patch attached.
[require]
GLSL = 1.10
[vertex shader]
varying float a;
void main()
{
a = 1.0;
gl_Position = gl_Vertex;
}
[fragment shader]
varying float a;
void main()
{
float f = ceil(a);
On 30.04.2012 19:16, Lucas Stach wrote:
Fixes an assertion seen by users.
Signed-off-by: Lucas Stach d...@lynxeye.de
Tested-by: JohnDoe_71Rus on irc
---
src/mesa/drivers/dri/nouveau/nouveau_context.c |9 +
1 file changed, 9 insertions(+)
diff --git
On 30.04.2012 19:41, Eric Anholt wrote:
On Sun, 29 Apr 2012 21:29:39 +1200, Chris Forbes chr...@ijw.co.nz wrote:
Here is a simple patch which adds support for the
GL_AMD_seamless_cubemap_per_texture extension to the i965 driver. This may
actually work on pre-Gen6 devices as well, but I
On 10.04.2012 14:50, Francisco Jerez wrote:
Francisco Jerez curroje...@riseup.net writes:
This patch series is part of the ongoing work to put together a
compute stack on top of Gallium3D. What we have been doing until now
to that end could be divided in 6 building blocks:
1/ Gallium API
On 04/14/2012 01:45 PM, Marek Olšák wrote:
On Sat, Apr 14, 2012 at 10:03 AM, Jose Fonseca jfons...@vmware.com wrote:
Hi Marek,
- Original Message -
Hi everyone,
This series adds these optional features to st/mesa:
- uploading user vertex buffers
- translating unsupported vertex
On 11.04.2012 17:38, Marek Olšák wrote:
Hi everyone,
This series adds these optional features to st/mesa:
- uploading user vertex buffers
- translating unsupported vertex formats into floats
- vertex data with unaligned buffer_offset, src_offset, or stride is
transformed such that it's
Mesa doesn't actually support them, but some gallium drivers do.
Some applications react badly if we claim to support something and
then bail when it is requested.
---
src/gallium/state_trackers/dri/common/dri_screen.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
Do you fix tgsi_declaration to support per-component interpolation mode
anywhere ?
If you don't, or if you don't update the corresponding bits in the
driver code to handle that (which I don't expect you to), you have to
put NO_MIXED_INTERPOLATION everywhere.
On 02/23/2012 09:12 PM, Vincent
On 02/13/2012 05:19 PM, Brian Paul wrote:
---
src/gallium/include/pipe/p_state.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index f6486f0..72ec04a 100644
---
On 07.02.2012 13:47, Jose Fonseca wrote:
Makes sense.
Very much so ...
http://cgit.freedesktop.org/mesa/mesa/commit/?id=189e6c7e81ce35b89d9b52d4bd0d6271a7e9c10f
(of 26 hours ago).
Jose
- Original Message -
The assertion added in f09910f3 broke nv50 completely by asserting
that
On 02/07/2012 05:24 PM, Jose Fonseca wrote:
I'm not familiar enough with draw internals to tell whether your changes are
enough or not.
But I'm OK with this change as is, given that most drivers will not advertise
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, so only those that do
Just let the hardware do it if it can and avoid drivers having to
check for the special case on each draw call.
v2: update the draw module
---
src/gallium/auxiliary/draw/draw_context.c |7 -
src/gallium/auxiliary/draw/draw_decompose_tmp.h | 26 +++---
On 01.02.2012 15:23, Brian Paul wrote:
On 02/01/2012 03:40 AM, Jose Fonseca wrote:
Silences warnings and fixes potential bugs due to buffer overflow.
The nv50 maintainers could benefit from sprinkling a few asserts to
catch this early in the future, as it is bound to happen again.
Good
On 01.02.2012 16:21, Brian Paul wrote:
On 02/01/2012 08:14 AM, Christoph Bumiller wrote:
On 01.02.2012 15:23, Brian Paul wrote:
On 02/01/2012 03:40 AM, Jose Fonseca wrote:
Silences warnings and fixes potential bugs due to buffer overflow.
The nv50 maintainers could benefit from sprinkling
On 31.01.2012 09:49, Jose Fonseca wrote:
I don't oppose adding the cap.
But I think that the story for draw module should be figured out, as at least
nv50/nvc0 drivers will advertise
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION = 1 and are using the draw
module:
$ git grep
On 01/29/2012 06:26 PM, Brian Paul wrote:
On Sun, Jan 29, 2012 at 9:35 AM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This blocks blending in the simple path, need to look at the more
complicated paths.
Signed-off-by: Dave Airlie airl...@redhat.com
---
Just let the hardware do it if it can and avoid drivers having to
check for the special case on each draw call.
---
src/gallium/docs/source/cso/rasterizer.rst |7 ---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/i915/i915_screen.c |1 +
On 28.01.2012 01:38, Marek Olšák wrote:
Hi everyone,
the subject says it all. This series fixes gl_PointSize with transform
feedback. There is a new piglit test to verify that a driver does clamping
properly during rasterization: vs-point_size-zero
The piglit test is wrong.
GL spec
On 20.01.2012 12:45, Henri Verbeet wrote:
On 20 January 2012 03:24, Eric Anholt e...@anholt.net wrote:
So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow
to blit from RGBA8 to BGRA8 then, please ?
That's already allowed.
Yeah, but not for multisampled framebuffers,
On 19.01.2012 19:53, Ian Romanick wrote:
On 01/18/2012 12:31 PM, Chad Versace wrote:
--- snip
Supporting Z32 - Z32_FLOAT is a bad idea. So I've amended the patch
to avoid that.
--- end snip
This loosens the format validation in glBlitFramebuffer. When blitting
depth bits, don't require
On 01/12/2012 10:53 PM, Christoph Bumiller wrote:
The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used.
Going to push this soon if no one minds ... though maybe I should just
change the limit in the driver to 64
The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used since
the Outputs array was smaller than that maximum.
NOTE: This is a candidate for the 8.0 branch.
---
src/glsl/linker.cpp| 57
On 01/17/2012 05:50 PM, Christoph Bumiller wrote:
On 01/12/2012 10:53 PM, Christoph Bumiller wrote:
The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used.
Going to push this soon if no one minds ... though maybe I should
The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used since
the Outputs array was smaller than that maximum.
v2: added assertions
NOTE: This is a candidate for the 8.0 branch.
---
src/glsl/linker.cpp| 64
The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used.
The new size corresponds to the maximum number of possible unique
outputs when varying packing is used.
NOTE: This is a candidate for the 8.0 branch.
---
On 10.01.2012 04:52, Stéphane Marchesin wrote:
Hi Dave,
This regresses interpolation-none-gl_FrontColor-flat-vertex.shader_test
piglit test on i915g.
That's likely. You're probably not using the ClipVertex but instead
gl_Position for clipping since the prior was not identifiable before.
The
On 10.01.2012 12:29, Jose Fonseca wrote:
Still catching up on email traffic during holidays...
I agree that user buffer uploads should be moved out of drivers, but I don't
think this is the way to go.
I don't. If the state tracker uploads user buffers and presents them to
the driver as
On 01/10/2012 01:13 PM, Jose Fonseca wrote:
- Original Message -
On 10.01.2012 12:29, Jose Fonseca wrote:
Still catching up on email traffic during holidays...
I agree that user buffer uploads should be moved out of drivers,
but I don't think this is the way to go.
I don't. If the
On 01/10/2012 10:09 PM, Dave Airlie wrote:
On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt e...@anholt.net wrote:
On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
Things can get confused if you expose one without the other which can
Enabled only for nvc0 at the moment.
---
src/gallium/docs/source/screen.rst |2 ++
src/gallium/drivers/i915/i915_screen.c |1 +
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
src/gallium/drivers/nv50/nv50_screen.c |2 ++
src/gallium/drivers/nvc0/nvc0_screen.c |1 +
---
src/mesa/state_tracker/st_extensions.c |8
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 14 +++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index a9d4054..c8171ef
On 01/06/2012 04:35 PM, Brian Paul wrote:
On 01/06/2012 08:26 AM, Dave Airlie wrote:
On Fri, Jan 6, 2012 at 3:13 PM, Brian Paulbri...@vmware.com wrote:
On 01/06/2012 06:57 AM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
Brian mentioned that mesa-demos/reflect was broken on
On 01/06/2012 08:26 PM, Ian Romanick wrote:
On 01/06/2012 09:04 AM, Dave Airlie wrote:
Hi guys,
Just a quick note, I've just spent a week or so trying to see where
gallium and softpipe were w.r.t GL3.0 support.
I've pushed a branch to my repo called softpipe-gl3. It contains
patches in
Ping ...
Integer attributes shouldn't be exposed with any drivers that don't
support native integers, so there shouldn't be any extra checks necessary.
On 12/19/2011 04:45 PM, Christoph Bumiller wrote:
---
src/mesa/state_tracker/st_draw.c | 63
+++--
src
---
src/mesa/state_tracker/st_draw.c | 63 +++--
src/mesa/state_tracker/st_draw.h |2 +-
src/mesa/state_tracker/st_draw_feedback.c |3 +-
3 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c
On 19.12.2011 18:10, Dave Airlie wrote:
Hi guys,
So we have some piglit tests
generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test
that piglit fails
This seems to be due to its linear interpolation not producing the
correct answers
On 17.12.2011 20:54, Marek Olšák wrote:
On Sat, Dec 17, 2011 at 4:45 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at 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:
http://lists.freedesktop.org
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:
http://lists.freedesktop.org/archives/mesa-dev/2010-August/001810.html
src/gallium/include/pipe/p_defines.h |2 +-
src/gallium/include/pipe/p_state.h | 14
On 16.12.2011 19:27, Ian Romanick wrote:
On 12/13/2011 05:08 PM, Christoph Bumiller wrote:
On 12/14/2011 12:58 AM, Ian Romanick wrote:
On 12/13/2011 01:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12
On 15.12.2011 20:09, Jose Fonseca wrote:
- Original Message -
On 12/14/2011 12:58 AM, Ian Romanick wrote:
On 12/13/2011 01:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan
On 12/13/2011 09:29 PM, Christoph Bumiller wrote:
On 12/13/2011 09:11 PM, Jose Fonseca wrote:
- Original Message -
This is an updated version of the patch set I sent to the list a few
hours
ago.
There is now a TGSI property called
TGSI_PROPERTY_NUM_CLIP_DISTANCES
that drivers
On 12/13/2011 09:58 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 09:11 PM, Jose Fonseca wrote:
- Original Message -
This is an updated version of the patch set I sent to the list a
few
hours
ago.
There is now a TGSI property called
On 12/12/2011 05:37 PM, Jose Fonseca wrote:
- Original Message -
On 12/12/2011 02:49 PM, Jose Fonseca wrote:
- Original Message -
From: Marek Olšák mar...@gmail.com
It's like DrawArrays, but the count is taken from a transform
feedback
object.
This removes
On 12/13/2011 10:48 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02:11 PM, Jose
On 12/14/2011 12:24 AM, Marek Olšák wrote:
On Tue, Dec 13, 2011 at 11:22 PM, Jose Fonseca jfons...@vmware.com wrote:
Another approach would be just to add the property, and kill output mask.
Two ways of doing the same is what I'd like to avoid. I'll need a day (it's
late here) to think about
On 12/14/2011 12:58 AM, Ian Romanick wrote:
On 12/13/2011 01:25 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
- Original Message -
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02:11 PM, Jose Fonseca wrote:
-
101 - 200 of 317 matches
Mail list logo
