On 12.04.2010 21:48, Christoph Bumiller wrote:
> On 04/12/2010 08:52 PM, Roland Scheidegger wrote:
>> On 10.04.2010 19:52, Christoph Bumiller wrote:
>>> Hi,
>>> this might not be the best implementation, but I thought I'd add a patch
>>> to the suggestion.
>>>
>>> Basically I want nv50 to do be abl
In the direct rendered case, we need to convert DRI2 swap complete
events to GLX events for the client to consume. This path had what
looks like a stray "& 0x75" from some earlier debugging that prevented
clients from seeing the right event code.
However the GLX event code has bitten us a few tim
glMultiTexCoord4fv is available only if the GL version is 1.3 or
greater.
Signed-off-by: Xavier Chantry
---
tests/general/texunits.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/general/texunits.c b/tests/general/texunits.c
index 01a5e27..1a5f67e 100644
---
glActiveTexture is available only if the GL version is 1.3 or greater.
Signed-off-by: Xavier Chantry
---
tests/bugs/fdo25614-genmipmap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/bugs/fdo25614-genmipmap.c b/tests/bugs/fdo25614-genmipmap.c
index 6f8c60e..c
On 04/12/2010 08:52 PM, Roland Scheidegger wrote:
> On 10.04.2010 19:52, Christoph Bumiller wrote:
>> Hi,
>> this might not be the best implementation, but I thought I'd add a patch
>> to the suggestion.
>>
>> Basically I want nv50 to do be able to do hw clears in gallium even if
>> scissors or col
On 10.04.2010 19:52, Christoph Bumiller wrote:
> Hi,
> this might not be the best implementation, but I thought I'd add a patch
> to the suggestion.
>
> Basically I want nv50 to do be able to do hw clears in gallium even if
> scissors or color masks are active, since it's nicer than drawing a quad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Airlie wrote:
> So I've been trying to make r300g do point sprites for a few days now,
> and I've pulled out quite a lot of hair blaming pieces of hardware
> along with random r300g states.
>
> I finally noticed I was getting vertex emits for tex
On Mon, 12 Apr 2010 09:00:57 +0200
Michel Dänzer wrote:
> On Mon, 2010-04-12 at 08:00 +0200, Luca Barbieri wrote:
> > The Intel drivers also appear to be in the same situation, with
> > classic drivers not being dropped in favor of Gallium ones, also
> > indicating possible Gallium shortcomings
Hi,
I've been looking into the GLES1/2 support in mesa and trying to
figure out how to make it work for DRI drivers as well. The current
approach only works for gallium, and it works by compiling mesa core
as different state trackers. Each state tracker is just a thin filter
on top of the public
On Mon, 2010-04-12 at 07:56 -0700, Alex Deucher wrote:
> On Mon, Apr 12, 2010 at 10:17 AM, Roland Scheidegger
> wrote:
> > What's wrong with the stride zero concept?
> > I think most hw can handle this just fine (pretty sure all radeons
> > should, though of course driver might need some special
On Mon, Apr 12, 2010 at 10:17 AM, Roland Scheidegger wrote:
> What's wrong with the stride zero concept?
> I think most hw can handle this just fine (pretty sure all radeons
> should, though of course driver might need some special case code if it
> uses this to determine max index due to zero div
What's wrong with the stride zero concept?
I think most hw can handle this just fine (pretty sure all radeons
should, though of course driver might need some special case code if it
uses this to determine max index due to zero division). Apparently, you
could optimize it away on nv hardware, and so
On 04/12/2010 02:00 PM, Keith Whitwell wrote:
> On Mon, Apr 12, 2010 at 9:55 AM, Christoph Bumiller
> wrote:
>> On 04/12/2010 10:22 AM, Luca Barbieri wrote:
>>
> 4. More powerful and better defined clear interface with scissor/MRT
> support
I'm not sure how scissors fit in, othe
On Mon, Apr 12, 2010 at 9:55 AM, Christoph Bumiller
wrote:
> On 04/12/2010 10:22 AM, Luca Barbieri wrote:
>
4. More powerful and better defined clear interface with scissor/MRT
support
>>>
>>> I'm not sure how scissors fit in, other than that you probably have to
>>> hax them on your HW
This makes sense & looks good to me Dave.
Keith
On Mon, Apr 12, 2010 at 6:46 AM, Dave Airlie wrote:
> So I've been trying to make r300g do point sprites for a few days now,
> and I've pulled out quite a lot of hair blaming pieces of hardware
> along with random r300g states.
>
> I finally notice
FWIW, thinking about it a bit more, my opinion is that it might be
best to add both a flag to respect scissors and also explicitly pass
the MRT buffer/component writemask as well to clear().
Drivers can probably disable/enable scissors and change writemasks, if
necessary, in a faster way than the
Sorry, I didn't see it: seems like something went wrong for me in the
list switchover to freedesktop.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 04/12/2010 10:22 AM, Luca Barbieri wrote:
>>> 4. More powerful and better defined clear interface with scissor/MRT support
>>
>> I'm not sure how scissors fit in, other than that you probably have to
>> hax them on your HW to work with clears, but this isn't really a
>> problem any longer. If y
I managed to independently write the exact same patch: see
http://cgit.freedesktop.org/mesa/mesa/commit/?id=5060b99418ec3869df4cec5951658ce8e7546295
Thanks anyway!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mail
A lot of apps segfaulted due to this missing initialization (including 64
piglit tests :).
Signed-off-by: Xavier Chantry
---
src/gallium/drivers/nvfx/nvfx_miptree.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_miptree.c
b/src/gallium/dri
>> Well, there are a lot of things that Gallium doesn't do well compared
>> to other APIs, mostly OpenGL:
>> 1. Support for fixed function cards in some way, either:
>> 1a. (worse) New Gallium interfaces to pass fixed function pipeline
>> states, along with an auxiliary module to turn them into sha
On Mon, Apr 12, 2010 at 12:04 AM, Luca Barbieri wrote:
> Well, there are a lot of things that Gallium doesn't do well compared
> to other APIs, mostly OpenGL:
> 1. Support for fixed function cards in some way, either:
> 1a. (worse) New Gallium interfaces to pass fixed function pipeline
> states, a
> Do what r300g does: Delay VBO submission, and make a choice at render
> time as to whether immediate mode is going to pay off in performance.
nv50 and unpushed work on nvfx already do that, but that only works
well when the user specifies a pointer to an array of vertex
attributes.
If instead t
> You've kind of sparked my curiosity, though. What "larger class of
> features" are you wanting to address, specifically? Some things are
> simply not well-designated in the docs, like multisampling; others are
> intentionally not part of Gallium, like non-GL_RENDER modes.
Well, there are a lot o
On Mon, 2010-04-12 at 08:00 +0200, Luca Barbieri wrote:
>
> This includes all pre-R300 Radeon hardware, and since Radeon
> development hasn't yet moved to Gallium exclusively, maybe there are
> also some shortcomings in the Gallium interface affecting R300+ that
> are preventing r300 and r600 to
25 matches
Mail list logo
