It will be useful for the nouveau DRI driver and IMHO there's no
reason to keep it private.
---
src/mesa/main/bitset.h | 25 -
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/bitset.h b/src/mesa/main/bitset.h
index 8bd4526..f2709ab 100644
This should make things easier for drivers wanting to work with a
subclass of gl_framebuffer.
The complementary _mesa_initialize_framebuffer function is now
called _mesa_initialize_unnamed_framebuffer for the sake of
symmetry.
---
src/mesa/drivers/directfb/idirectfbgl_mesa.c |2 +-
The in-place splitting code wasn't dealing with index buffers at all
(and it was being called from vbo_split_prims for too big index
buffers, causing some occasional corruption).
Additionally, it wasn't taking into account primitives arrays with
non-contiguous indices (e.g. given prim[0].start =
Francisco,
It seems like this adds code to split too-long indexed primitives, but
still doesn't address the issue of splitting too-large vertex buffers
referenced by indexed primitives, right?
IE. the generated, smaller index buffers will still be applied to the
same set of unsplit vertex
On Tue, 2010-02-02 at 03:01 -0800, Francisco Jerez wrote:
For a long time the gallium pipe drivers for nvidia fixed function cards
(nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and
godforsaken -- especially nv0x and nv1x had seen almost no progress
since their creation.
Keith Whitwell kei...@vmware.com writes:
Francisco,
It seems like this adds code to split too-long indexed primitives, but
still doesn't address the issue of splitting too-large vertex buffers
referenced by indexed primitives, right?
Yeah, that's right, IMHO vbo_split_copy is the way to go
Roland Scheidegger wrote:
On 01.02.2010 20:23, Brian Paul wrote:
Speaking of texture formats and texture sampling, one area of Gallium
that's under-specified is what (x,y,z,w) values are returned by TEX
instructions when sampling from each of the various texture formats.
A while back I
Luca Barbieri wrote on 2010-02-01 21:42:
1. All the semantic indices in OpenGL are limited, according to the
ARB specification
2. All the sematic indices in DirectX 9/10 are limited, according to
http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx
At least for SM3.0, one can
Francisco Jerez wrote:
It will be useful for the nouveau DRI driver and IMHO there's no
reason to keep it private.
Committed. Thanks.
-Brian
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Francisco Jerez wrote:
This should make things easier for drivers wanting to work with a
subclass of gl_framebuffer.
The complementary _mesa_initialize_framebuffer function is now
called _mesa_initialize_unnamed_framebuffer for the sake of
symmetry.
I think I'd prefer
Brian Paul bri...@vmware.com writes:
Francisco Jerez wrote:
This should make things easier for drivers wanting to work with a
subclass of gl_framebuffer.
The complementary _mesa_initialize_framebuffer function is now
called _mesa_initialize_unnamed_framebuffer for the sake of
symmetry.
I
On Tue, Feb 2, 2010 at 3:54 PM, michal mic...@vmware.com wrote:
Luca Barbieri wrote on 2010-02-01 21:42:
1. All the semantic indices in OpenGL are limited, according to the
ARB specification
2. All the sematic indices in DirectX 9/10 are limited, according to
Hi,
On Tue, Feb 02, 2010 at 09:45:32AM +0200, Pauli Nieminen wrote:
I bisected the rendering problem to commit adding xmm0 zeroing code to
transform functions.
Unfortunately, xmm0 happens to be undefined at least sometimes, for
example on one SDL + OpenGL game I tried. It made the game
At least for SM3.0, one can specify a vertex shader output semantic like
COLOR15 and have it running as long as one has also a pixel shader with a
matching input semantic. Though I agree with you we don't really want to go
this route and have something more sensible.
Do you know of any
Personally I'm
going to take a break from this thread, spend a couple of days looking
at i965, etc, to see what can be done to improve things there, and
maybe come back with an alternate proposal.
Yes, I think that the most important step is to precisely determine
how both hardware (and
On Tue, Feb 02, 2010 at 07:09:12PM +0100, Luca Barbieri wrote:
Otherwise, we will need to recompile either of the shaders at link
time, so that foo is assigned the same slot in both shaders, which
is what we do now in GLSL linking, but is somewhat inefficient and in
particular can lead to
On Tue, Feb 2, 2010 at 1:16 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Personally I'm
going to take a break from this thread, spend a couple of days looking
at i965, etc, to see what can be done to improve things there, and
maybe come back with an alternate proposal.
Yes, I think that
PXOR user in code were causing the lowest SP float register to have NaN
values which made all math operations in that slot fail. Correct istruction
to clear float registers is XORPS which handles single precission floats
correctly.
Fixes progs/tests/fog in swrast SSE mode.
Signed-off-by: Pauli
On 10-02-02 10:18 AM, Brian Paul wrote:
I've added this table to the gallium docs, with the LA format. Maybe
someone else more familiar with Sphinx can fix up the formatting.
The attached patch does so, though unfortunately the latex-pdf
conversion[1] does a pretty bad job on the table.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pauli Nieminen wrote:
PXOR user in code were causing the lowest SP float register to have NaN
values which made all math operations in that slot fail. Correct istruction
to clear float registers is XORPS which handles single precission floats
On Tue, Feb 2, 2010 at 2:04 PM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pauli Nieminen wrote:
PXOR user in code were causing the lowest SP float register to have NaN
values which made all math operations in that slot fail. Correct istruction
to
On Tue, Feb 2, 2010 at 9:21 PM, Matt Turner matts...@gmail.com wrote:
On Tue, Feb 2, 2010 at 2:04 PM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pauli Nieminen wrote:
PXOR user in code were causing the lowest SP float register to have NaN
values
On Tue, Feb 2, 2010 at 7:38 PM, Olivier Galibert galib...@pobox.com wrote:
On Tue, Feb 02, 2010 at 07:09:12PM +0100, Luca Barbieri wrote:
Otherwise, we will need to recompile either of the shaders at link
time, so that foo is assigned the same slot in both shaders, which
is what we do now in
SM3 usages are arbitrary. For example, you could have some data with a
blendweight 5 semantic, where there is no hardware to support it and no
meaningful limit to the number.
From: Luca Barbieri [l...@luca-barbieri.com]
Sent: Tuesday, February 02, 2010
Great minds think alike, apparently: 516e7159aeb4
And yeah, the PDF output isn't the best; HTML looks a lot better:
http://people.freedesktop.org/~csimpson/gallium-docs/tgsi.html#texture-sampling-and-texture-formats
Thanks for the patch, sorry I beat you to it. :3
~ C.
On Tue, Feb 2, 2010 at
On Tue, Feb 2, 2010 at 12:01 PM, Francisco Jerez curroje...@riseup.net wrote:
For a long time the gallium pipe drivers for nvidia fixed function cards
(nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and
godforsaken -- especially nv0x and nv1x had seen almost no progress
since
Xavier Chantry wrote:
On Tue, Feb 2, 2010 at 12:01 PM, Francisco Jerez curroje...@riseup.net
wrote:
For a long time the gallium pipe drivers for nvidia fixed function cards
(nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and
godforsaken -- especially nv0x and nv1x had seen
On Tue, Feb 2, 2010 at 11:43 AM, Mike Stroyan m...@lunarg.com wrote:
On Mon, Feb 1, 2010 at 7:34 PM, Chia-I Wu olva...@gmail.com wrote:
On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan m...@lunarg.com wrote:
Here is a version of the patch that uses EGL_DRIVERS_PATH and checks
for setuid/setgid
On Tue, Feb 2, 2010 at 9:17 PM, Chia-I Wu olva...@gmail.com wrote:
On Tue, Feb 2, 2010 at 11:43 AM, Mike Stroyan m...@lunarg.com wrote:
On Mon, Feb 1, 2010 at 7:34 PM, Chia-I Wu olva...@gmail.com wrote:
On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan m...@lunarg.com wrote:
Here is a version of
On Wed, Feb 3, 2010 at 1:55 PM, Mike Stroyan m...@lunarg.com wrote:
The patch looks good. But when I tried to make EGL_DRIVER and the default
driver also honor EGL_DRIVERS_PATH, it turned out that I need to overhaul
both
the existing code and your patch.
I've attached my version in this
30 matches
Mail list logo
