On 03/11/2011 12:03 AM, Marek Olšák wrote:
On Thu, Mar 10, 2011 at 11:45 PM, Thomas Hellstrom
mailto:thellst...@vmware.com>> wrote:
Hi,
I've been working a bit on optimizing uploads of non-vbo vertex
arrays on the svga device.
Since we have no knowledge of the vertex array size
---
src/gallium/docs/source/context.rst | 14 ++
src/gallium/include/pipe/p_context.h |3 +
src/mesa/SConscript |1 +
src/mesa/sources.mak |1 +
src/mesa/state_tracker/st_cb_texturebarrier.c | 60
---
src/mapi/glapi/gen/Makefile |1 +
src/mapi/glapi/gen/NV_texture_barrier.xml | 13 +++
src/mapi/glapi/gen/gl_API.xml |2 +
src/mesa/SConscript |1 +
src/mesa/drivers/common/driverfuncs.c |3 ++
src/mesa/main/api_exec.c
Hi,
these 2 patches add GL_NV_texture_barrier to Mesa and Gallium,
respectively. The extension can be used for programmable
blending, where the same texture can be bound as both a sampler
and renderbuffer. The same feature exists in Direct10 and
the entry point is:
VOID APIENTRY ResourceReadAfter
It's not nice to see this implemented for r300 and not enable it.
I guess this is something the other drivers needn't care about.
---
src/gallium/include/pipe/p_defines.h |1 +
src/gallium/include/pipe/p_state.h |1 +
src/mesa/state_tracker/st_atom_sampler.c |1 +
src/mesa/st
Hi,
I have done some of the changes in the gallium interface we discussed in the
thread called "7 questions...".
There are 4 patches in total:
1) gallium: kill is_resource_referenced
The function is_resource_referenced is removed. Considering that only
st/xorg used it, I don't think this can ca
Kenneth Graunke writes:
> On Thursday, March 10, 2011 01:17:04 PM Alexander Neundorf wrote:
> > While at it (sorry for newbie questions), do I need gallium (maybe
> > swrast) when I want only osmesa rendering into a software buffer ?
>
> I don't think OSMesa requires Gallium, but I've never used i
On Thursday, March 10, 2011 01:17:04 PM Alexander Neundorf wrote:
> Hi,
>
> I'm trying to build current git mesa with under Linux, 32bit, gcc 4.2.3
> with the following configure-call:
> ./configure --with-driver=osmesa --enable-static --disable-gallium
> --disable-egl --disable-glu
>
> This runs
https://bugs.freedesktop.org/show_bug.cgi?id=35178
Rui Tiago Matos changed:
What|Removed |Added
Summary|SIGSEGV in brw_draw_init at |SIGSEGV in brw_draw_init at
...by copying support for gl_InstanceIDARB, but without "#extension" check,
because EXT_draw_instanced spec does not say anything about it (as opposed
to ARB_draw_instanced / gl_InstanceIDARB) and NVIDIA driver already allow it
---
I'm not sure this is correct.
With this patch applied (+ merged fl
On 03/10/2011 03:46 PM, Marek Olšák wrote:
Hi,
The specification of GL_EXT_texture_snorm says:
OpenGL 3.0 is required.
This extension is written against the OpenGL 3.0 specification.
which simply means we cannot advertise the extension on GL2.1. Would
anyone be against violating the requireme
On Thu, Mar 10, 2011 at 11:45 PM, Thomas Hellstrom wrote:
> Hi,
>
> I've been working a bit on optimizing uploads of non-vbo vertex arrays on
> the svga device.
> Since we have no knowledge of the vertex array size before a draw call and
> the vertex array may change values in between subsequent d
Hi,
The specification of GL_EXT_texture_snorm says:
OpenGL 3.0 is required.
This extension is written against the OpenGL 3.0 specification.
which simply means we cannot advertise the extension on GL2.1. Would anyone
be against violating the requirement?
The thing is even some of GL2 ha
Hi,
I've been working a bit on optimizing uploads of non-vbo vertex arrays
on the svga device.
Since we have no knowledge of the vertex array size before a draw call
and the vertex array may change values in between subsequent draw calls
it's pretty pointless to upload the whole array to gpu m
On Thu, Mar 10, 2011 at 12:56 PM, Brian Paul wrote:
> On 03/10/2011 12:25 PM, Marek Olšák wrote:
>
>> Hi,
>>
>> I have reviewed where we call flush() and why and some of them
>> seem unnecessary to me. Those flushes may slightly decrease
>> performance, depending on each driver, and may hide driv
Pushed, thanks.
Marek
On Thu, Mar 10, 2011 at 10:34 PM, Christoph Bumiller <
e0425...@student.tuwien.ac.at> wrote:
> Patch attached.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-d
Patch attached.
>From bff36009e5bc2bd5aca467b8777b37f46d9f45fb Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Thu, 10 Mar 2011 22:26:16 +0100
Subject: [PATCH] early-z: add test to check for early depth testing bugs
If early fragment tests cause the depth buffer to be also updated
before
Hi,
I'm trying to build current git mesa with under Linux, 32bit, gcc 4.2.3 with
the following configure-call:
./configure --with-driver=osmesa --enable-static --disable-gallium
--disable-egl --disable-glu
This runs, but then the build fails:
hammer:~/src/packages/Mesa-git$ make
make[1]: Enteri
The attached patches are preliminary, and I didn't try very hard to fix
most drivers yet, as I did not want to invest too much time yet only to
get shot down later.
I'd like to add 2 new TGSI semantics so that nvc0 can identify
gl_TexCoord and gl_PointCoord.
The reason for this is that nvc0 hardw
On 03/10/2011 12:25 PM, Marek Olšák wrote:
Hi,
I have reviewed where we call flush() and why and some of them
seem unnecessary to me. Those flushes may slightly decrease
performance, depending on each driver, and may hide driver bugs.
glFlush doesn't have to be called in OpenGL so often, and
I
On Thu, 2011-03-10 at 20:25 +0100, Marek Olšák wrote:
> Hi,
>
> I have reviewed where we call flush() and why and some of them
> seem unnecessary to me. Those flushes may slightly decrease
> performance, depending on each driver, and may hide driver bugs.
>
> glFlush doesn't have to be called in
---
src/gallium/auxiliary/draw/draw_pipe_pstipple.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
b/src/gallium/auxiliary/draw/draw_pipe_pstipple.c
index ea62c97..fe3627b 100644
--- a/src/gallium/auxiliary/draw/draw_
I don't see a reason we need them.
---
src/gallium/state_trackers/vega/api_images.c |4
src/gallium/state_trackers/vega/image.c |8
src/gallium/state_trackers/vega/mask.c |2 --
3 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/src/gallium/state_t
The framebuffer cache flush should be implicit when calling
set_framebuffer_state.
There is no need to flush the command stream either.
---
src/gallium/auxiliary/util/u_gen_mipmap.c |2 --
src/mesa/state_tracker/st_cb_fbo.c|3 ---
2 files changed, 0 insertions(+), 5 deletions(-)
Hi,
I have reviewed where we call flush() and why and some of them
seem unnecessary to me. Those flushes may slightly decrease
performance, depending on each driver, and may hide driver bugs.
glFlush doesn't have to be called in OpenGL so often, and
I think state trackers should follow suit.
The
2011/3/9 Christian König :
> So please take a look at the attached patch, it shouldn't change the
> generated bytecode a bit, but just makes the code more readable (at
> least I think so) and easier to extend.
>
The general approach makes sense to me. Having flags may be nicer than
having separate
This looks good to me.
Marek
On Wed, Mar 9, 2011 at 9:31 PM, Henri Verbeet wrote:
> Blits between sRGB and linear formats should happen in linear color space.
> This fixes piglit fbo/fbo-srgb-blit.
> ---
> src/gallium/auxiliary/util/u_blit.c| 57
>
> src/
https://bugs.freedesktop.org/show_bug.cgi?id=35178
--- Comment #1 from Rui Tiago Matos 2011-03-10 09:47:34
PST ---
BTW, hardware is Intel(R) Ironlake Mobile.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
https://bugs.freedesktop.org/show_bug.cgi?id=35178
Summary: SIGSEGV in brw_draw_init at brw_draw.c:471
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
On Thu, 2011-03-10 at 06:01 -0800, Thomas Hellstrom wrote:
> Make sure that the upload manager doesn't upload data that's not
> dirty. This speeds up the viewperf test proe-04/1 a factor 5 or so on svga.
Sweet!
A few comments inline
> Also introduce an u_upload_unmap() function that can be used
Make sure that the upload manager doesn't upload data that's not
dirty. This speeds up the viewperf test proe-04/1 a factor 5 or so on svga.
Also introduce an u_upload_unmap() function that can be used
instead of u_upload_flush() so that we can pack
even more data in upload buffers. With this we c
31 matches
Mail list logo
