The attached patch series relaxes precision requirements for 6 tests to pass
on r300g.
Please review/push.
Marek
From cf3ce2ffd3171fdefb4c9948d33353e0172499ce Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Tue, 24 Nov 2009 12:37:04 +0100
Subject: [PATCH 1/6] texture_srg
OK then, I attached another patch which fixes st/mesa to match the docs.
On Sat, Feb 6, 2010 at 9:57 PM, Corbin Simpson wrote:
> I addressed this in the docs already, see the note in flatshade_first in
> Rasterizer. In short, we should always provoke quads GL-style.
>
> Posting from a mobile, par
I addressed this in the docs already, see the note in flatshade_first in
Rasterizer. In short, we should always provoke quads GL-style.
Posting from a mobile, pardon my terseness. ~ C.
On Feb 6, 2010 12:39 PM, "Marek Olšák" wrote:
Hi,
I got some time to revisit the issue from December regardin
Hi,
I got some time to revisit the issue from December regarding quads not
following the first provoking vertex convention.
The attached patch adds PIPE_CAP_QUADS_DONT_FLATSHADE_FIRST to gallium,
which gets propagated to the return value of
glGet*(GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION, ...)
On Sun, Jan 31, 2010 at 1:37 AM, Roland Scheidegger wrote:
>
>
>>7) Is there more information on the dual-source blend modes? I'm not
>>sure if I can do them; might have to bug AMD for the register values.
>>
>> I bet R300 can't do these modes. It's only a Direct3D 10.0 feature, not
>> pres
It's not deeply, truly painful, but it's certainly annoying and it
would be nice to force buffers to be at least contiguously bound, if
not non-sparse. I know D3D permits sparse elements though, so I won't
hold my breath.
On Sat, Feb 6, 2010 at 3:04 AM, Keith Whitwell
wrote:
> On Fri, Feb 5, 2010
On 02/06/2010 05:05 PM, Christoph Bumiller wrote:
> On 02/05/2010 11:01 AM, Keith Whitwell wrote:
>> We've had a couple of cleanups that we've wanted to do in gallium for
>> as long as I can remember. One of which is to remove all the random
>> context-creation calls and funnel them through someth
On 02/05/2010 11:01 AM, Keith Whitwell wrote:
> We've had a couple of cleanups that we've wanted to do in gallium for
> as long as I can remember. One of which is to remove all the random
> context-creation calls and funnel them through something sensible like
> a context_create() call in pipe_scr
On Fri, Feb 05, 2010 at 07:24:00PM -0500, Kristian Høgsberg wrote:
> These two patches move things around in GLX a bit. To make it possible
> to use libGL with EGL on framebuffer without pulling in X dependencies
> this patch make the GLX entry points and all the indirect API a
> ./configure time
On Fri, Feb 05, 2010 at 10:01:13AM +, Keith Whitwell wrote:
> We've had a couple of cleanups that we've wanted to do in gallium for
> as long as I can remember. One of which is to remove all the random
> context-creation calls and funnel them through something sensible like
> a context_create(
On Sat, Feb 6, 2010 at 4:35 PM, Eric Anholt wrote:
> On Fri, 05 Feb 2010 13:01:50 -0800, Ian Romanick wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I'd like to remove a bunch of the visuals and fbconfigs exposed by the
>> Intel drivers. There are several categories of visuals
On Fri, 05 Feb 2010 13:01:50 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'd like to remove a bunch of the visuals and fbconfigs exposed by the
> Intel drivers. There are several categories of visuals that are likely
> not useful to anyone. A couple of our t
also update the cell config a bit
---
configs/linux-cell |6 ++--
src/gallium/drivers/cell/common.h |3 +-
src/gallium/drivers/cell/spu/spu_per_fragment_op.c | 36 ++--
3 files changed, 22 insertions(+), 23 deletions(-)
di
On Fri, Feb 5, 2010 at 5:29 PM, Brian Paul wrote:
> michal wrote:
>> michal wrote on 2010-02-05 11:05:
>>> Brian Paul wrote on 2010-02-04 22:07:
>>>
michal wrote:
> Brian Paul wrote on 2010-02-03 17:58:
>
>
>> Keith Whitwell wrote:
>>
>>
>>
> Mich
On Fri, Feb 5, 2010 at 2:46 PM, Joakim Sindholt wrote:
> Let's assume I have an array of vertex elements that indicate
> position/color in vertex buffer #3. Let's also for the sake of argument
> say that there is nothing else in my vertex elements. No other buffers
> are being pointed to. Is it le
15 matches
Mail list logo
