On Wed, Feb 3, 2010 at 1:55 PM, Mike Stroyan 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 mail. It
On Tue, Feb 2, 2010 at 9:17 PM, Chia-I Wu wrote:
> On Tue, Feb 2, 2010 at 11:43 AM, Mike Stroyan wrote:
>> On Mon, Feb 1, 2010 at 7:34 PM, Chia-I Wu wrote:
>>> On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan wrote:
Here is a version of the patch that uses EGL_DRIVERS_PATH and checks
for
On Tue, Feb 2, 2010 at 11:43 AM, Mike Stroyan wrote:
> On Mon, Feb 1, 2010 at 7:34 PM, Chia-I Wu wrote:
>> On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan wrote:
>>> Here is a version of the patch that uses EGL_DRIVERS_PATH and checks
>>> for setuid/setgid
>>> before using EGL_DRIVER or EGL_DRIVER
Xavier Chantry wrote:
> On Tue, Feb 2, 2010 at 12:01 PM, 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 prog
On Tue, Feb 2, 2010 at 12:01 PM, 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.
>
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 10
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 10:
On Tue, Feb 2, 2010 at 7:38 PM, Olivier Galibert 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 GLSL linkin
On Tue, Feb 2, 2010 at 9:21 PM, Matt Turner wrote:
> On Tue, Feb 2, 2010 at 2:04 PM, Ian Romanick 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 opera
On Tue, Feb 2, 2010 at 2:04 PM, Ian Romanick 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 clear floa
-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
> c
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.
-N
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 Ni
On Tue, Feb 2, 2010 at 1:16 PM, Luca Barbieri 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 the most impo
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
> 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 e
> 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 off
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 gam
On Tue, Feb 2, 2010 at 3:54 PM, michal 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
>> http://msdn.microsoft.com/en-us/library
Brian Paul 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.
>
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 _mesa_init
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
S
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
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
On Mon, Feb 1, 2010 at 8:42 PM, Luca Barbieri wrote:
>> Where the semantic indicates some relationship to actual system resources, I
>> agree that the number is constrained by the number of those system
>> resources. In the case of the gallium "GENERIC" semantic, there is
>> explicitly no syst
Keith Whitwell 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 for too large
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.
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 buffers
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 = 0
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 +-
src/
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
---
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.
They've recently grown a classic mesa driver which implements man
32 matches
Mail list logo
