https://bugs.freedesktop.org/show_bug.cgi?id=31255
Pavel Ondračka changed:
What|Removed |Added
Summary|Unigine Sanctuary v 2.2:|Unigine Sanctuary v2.2:
On Mon, Nov 15, 2010 at 9:46 PM, Alex Deucher wrote:
> On Mon, Nov 15, 2010 at 4:41 PM, Tilman Sauerbeck
> wrote:
>> piglit/fbo-readpixels still passes for me.
>>
>> Signed-off-by: Tilman Sauerbeck
>> ---
>>
>> Please review. And someone please tell me where those 512 and 256 bytes
>> are comin
On Tue, Nov 16, 2010 at 11:35 AM, Keith Whitwell
wrote:
> On Mon, Nov 15, 2010 at 9:46 PM, Alex Deucher wrote:
>> On Mon, Nov 15, 2010 at 4:41 PM, Tilman Sauerbeck
>> wrote:
>>> piglit/fbo-readpixels still passes for me.
>>>
>>> Signed-off-by: Tilman Sauerbeck
>>> ---
>>>
>>> Please review. An
On Wed, 2010-11-10 at 16:04 -0800, Jakob Bornecrantz wrote:
> Hi all
>
> We have a bunch of redundant target helpers to wrap screens with debug
> drivers and for creating the various software drivers. This series removes
> all but the inline one, I picked it since it gives more flexibility for
Hi,
So i looked a bit more at what path we should try to optimize in the
mesa/gallium/pipe infrastructure. Here are some number gathers from
games :
drawcall / ps constant vs constant ps samplervs sampler
doom31.45 1.39 9.24 9.86
nex
On 16.11.2010 20:21, Jerome Glisse wrote:
> Hi,
>
> So i looked a bit more at what path we should try to optimize in the
> mesa/gallium/pipe infrastructure. Here are some number gathers from
> games :
> drawcall / ps constant vs constant ps samplervs sampler
> doom31.45
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/2010 05:48 PM, Brian Paul wrote:
> case ir_unop_b2f:
>assert(op[0]->type->base_type == GLSL_TYPE_BOOL);
>for (unsigned c = 0; c < op[0]->type->components(); c++) {
> - data.f[c] = op[0]->value.b[c] ? 1.0 : 0.0;
> +
On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger wrote:
> On 16.11.2010 20:21, Jerome Glisse wrote:
>> Hi,
>>
>> So i looked a bit more at what path we should try to optimize in the
>> mesa/gallium/pipe infrastructure. Here are some number gathers from
>> games :
>> drawcall / ps constant
>>Why do you think it's faster to create and use a new state rather than search
>>in the hash cache and reuse this? I was under the impression (this being a
>>dx10 paradigm) even hw is quite optimized for this (that is, you just keep
>>all the state objects on the hw somewhere and switch between
Signed-off-by: Robert Hooker
---
src/egl/drivers/dri2/egl_dri2.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 6db44c7..a83f32b 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl
On 16.11.2010 20:59, Jerome Glisse wrote:
> On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger
> wrote:
>> On 16.11.2010 20:21, Jerome Glisse wrote:
>>> Hi,
>>>
>>> So i looked a bit more at what path we should try to optimize in the
>>> mesa/gallium/pipe infrastructure. Here are some number gat
On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse wrote:
> Hi,
>
> So i looked a bit more at what path we should try to optimize in the
> mesa/gallium/pipe infrastructure. Here are some number gathers from
> games :
> drawcall / ps constant vs constant ps sampler vs sampler
> doom3
On Tue, 2010-11-16 at 11:55 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/15/2010 05:48 PM, Brian Paul wrote:
>
> > case ir_unop_b2f:
> >assert(op[0]->type->base_type == GLSL_TYPE_BOOL);
> >for (unsigned c = 0; c < op[0]->type->componen
>>I'm really not sure of that. I think one reason dx10 did this is because
applications mostly did that anyway - at least for subsequent frames
pretty much all the state they are using is going to be the same one as
used on the previous frame.
That is probably an important point -- there may not
On 11/16/2010 12:55 PM, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/2010 05:48 PM, Brian Paul wrote:
case ir_unop_b2f:
assert(op[0]->type->base_type == GLSL_TYPE_BOOL);
for (unsigned c = 0; c< op[0]->type->components(); c++) {
-data.
On Tue, Nov 16, 2010 at 3:27 PM, Roland Scheidegger wrote:
> On 16.11.2010 20:59, Jerome Glisse wrote:
>> On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger
>> wrote:
>>> On 16.11.2010 20:21, Jerome Glisse wrote:
Hi,
So i looked a bit more at what path we should try to optimize i
On Tue, Nov 16, 2010 at 3:51 PM, Jakob Bornecrantz wrote:
> On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse wrote:
>> Hi,
>>
>> So i looked a bit more at what path we should try to optimize in the
>> mesa/gallium/pipe infrastructure. Here are some number gathers from
>> games :
>> drawcall / p
On 16.11.2010 22:15, Jerome Glisse wrote:
> On Tue, Nov 16, 2010 at 3:27 PM, Roland Scheidegger
> wrote:
>> On 16.11.2010 20:59, Jerome Glisse wrote:
>>> On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger
>>> wrote:
On 16.11.2010 20:21, Jerome Glisse wrote:
> Hi,
>
> So i look
On Tue, Nov 16, 2010 at 9:17 PM, Jerome Glisse wrote:
> On Tue, Nov 16, 2010 at 3:51 PM, Jakob Bornecrantz
> wrote:
>> On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse wrote:
>>> Hi,
>>>
>>> So i looked a bit more at what path we should try to optimize in the
>>> mesa/gallium/pipe infrastructure.
> On Tue, Nov 16, 2010 at 9:17 PM, Jerome Glisse wrote:
>> On Tue, Nov 16, 2010 at 3:51 PM, Jakob Bornecrantz
>> wrote:
>>> On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse wrote:
Hi,
So i looked a bit more at what path we should try to optimize in the
mesa/gallium/pipe infras
https://bugs.freedesktop.org/show_bug.cgi?id=31673
Summary: GL_FRAGMENT_PRECISION_HIGH preprocessor macro
undefined in GLSL ES
Product: Mesa
Version: git
Platform: All
OS/Version: All
Status: NEW
Severity:
On Tue, Nov 16, 2010 at 6:06 PM, Corbin Simpson
wrote:
>> On Tue, Nov 16, 2010 at 9:17 PM, Jerome Glisse wrote:
>>> On Tue, Nov 16, 2010 at 3:51 PM, Jakob Bornecrantz
>>> wrote:
On Tue, Nov 16, 2010 at 7:21 PM, Jerome Glisse wrote:
> Hi,
>
> So i looked a bit more at what path
On Tuesday 16 November 2010 20:26:03 Jerome Glisse wrote:
> Anyway my point is that here the gl state tracker is not to blame,
> it's only the fact that real application lead to a lot of cso
> activities and i am not convinced that what we might possibly win with
> cso is more important than what
On Tue, Nov 16, 2010 at 9:15 PM, Zack Rusin wrote:
> On Tuesday 16 November 2010 20:26:03 Jerome Glisse wrote:
>> Anyway my point is that here the gl state tracker is not to blame,
>> it's only the fact that real application lead to a lot of cso
>> activities and i am not convinced that what we mi
On Tue, Nov 16, 2010 at 9:43 PM, Jerome Glisse wrote:
> On Tue, Nov 16, 2010 at 9:15 PM, Zack Rusin wrote:
>> On Tuesday 16 November 2010 20:26:03 Jerome Glisse wrote:
>>> Anyway my point is that here the gl state tracker is not to blame,
>>> it's only the fact that real application lead to a lot
This patch passes the texture image format to the
_mesa_init_teximage_fields() function to make sure the texture image's
format is always set (see fd.o bug 31544).
I'd appreciate it if someone could apply this patch and test on r200,
r300 or r600. I'll commit it later then.
-Brian
diff --gi
Hi,
On Tuesday, November 16, 2010 20:21:26 Jerome Glisse wrote:
> So i looked a bit more at what path we should try to optimize in the
> mesa/gallium/pipe infrastructure. Here are some number gathers from
> games :
> drawcall / ps constant vs constant ps samplervs sampler
> doom3
Zack Rusin [2010-11-16 21:15]:
> Anyway what I think is of no consequence, what matters is what you can prove.
> It'd be trivial to see:
> 1) what exactly changes that caching fails,
Maybe I'm totally missing the point but:
* In OpenArena (running a random demo), context.create_sampler_state is
28 matches
Mail list logo
