I don't have the code handy (and haven't looked at it in a while), but wonder
if finer-grained tracking of dirtiness would help? Or more generally trying to
preserve more computed results across state changes?
Keith
- Original Message -
Hi,
I did some profiling with perf under
On Fri, 2011-12-02 at 08:14 -0700, Brian Paul wrote:
This hook was added many years ago to allow using an alternative
implementation of memcpy() for glTexImage() that was faster under some
circumstances.
The code is still present in the state tracker in st_cb_texture.c
The hook is only
- Original Message -
On 11/18/2011 11:27 AM, Marek Olšák wrote:
Only i965g does not enable GLSL, but that driver has been
unmaintained and
bitrotting for quite a while anyway.
It doesn't even do GLSL? I'm pretty shocked, I figured it at least
did
that. Is it even worth
On Sun, 2011-11-13 at 14:43 -0600, Bryan Cain wrote:
On 11/13/2011 09:06 AM, Dave Airlie wrote:
Hi guys,
Just been looking at llvmpipe integer support and it seems like we
lose some information about the type of data stored into temporaries,
after st_glsl_to_cpp we no longer know what
On Mon, 2011-11-14 at 09:42 +, Keith Whitwell wrote:
On Sun, 2011-11-13 at 14:43 -0600, Bryan Cain wrote:
On 11/13/2011 09:06 AM, Dave Airlie wrote:
Hi guys,
Just been looking at llvmpipe integer support and it seems like we
lose some information about the type of data stored
On Tue, 2011-11-08 at 07:47 -0800, Jose Fonseca wrote:
tgsi_exec is simple; llvm is fast; and tgsi_sse2 ends up being neither. So
really serves no purpose and is currently broken.
Sounds good to me!
Keith
___
mesa-dev mailing list
Looks good to me.
Keith
On Sun, 2011-10-30 at 20:05 +0800, Chia-I Wu wrote:
From: Chia-I Wu o...@lunarg.com
It is a typo went unnoticed.
---
src/gallium/drivers/llvmpipe/lp_rast_tri.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On Wed, 2011-10-05 at 20:14 +1100, Christopher James Halse Rogers wrote:
On Wed, 2011-10-05 at 09:24 +0200, Joakim Sindholt wrote:
On Tue, 2011-10-04 at 17:58 +0200, Fabio wrote:
Can the patches at
http://lists.freedesktop.org/archives/mesa-dev/2011-August/011099.html
be considered for
I'm suprised that fragile code lasted as long as it did...
Looks good to me.
Keith
On Wed, 2011-09-21 at 10:15 -0700, Eric Anholt wrote:
There were notes about the possibility of slowdowns due to zcopy from
a PBO due to thrashing around of the region. Slowdowns are even more
likely now that
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some months ago about using -fno-builtin-memcmp for
improving memcmp performance:
http://lists.freedesktop.org/archives/mesa-dev/2011-June/009078.html
Since then, was it properly addressed in mesa or the flag is still
On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
Am 20.09.2011 12:35, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some months ago about using -fno-builtin-memcmp for
improving memcmp performance:
http://lists.freedesktop.org
On Tue, 2011-09-20 at 16:35 +0200, Roland Scheidegger wrote:
Am 20.09.2011 16:15, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 16:02 +0200, Roland Scheidegger wrote:
Am 20.09.2011 12:35, schrieb Keith Whitwell:
On Tue, 2011-09-20 at 10:59 +0200, Fabio wrote:
There was a discussion some
On Wed, 2011-08-31 at 04:55 -0700, Jose Fonseca wrote:
I haven't tested but the whole patch series looks good AFAICT.
I'm really happy to see this work completed, as it was excluding the
llvmpipe/softpipe from a very big class of apps. Thanks for taking the
initiative!
Likewise! Thanks
On Wed, 2011-08-24 at 20:46 -0400, Kristian Høgsberg wrote:
On Wed, Aug 24, 2011 at 3:11 PM, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to propose giving the ax to a bunch of old, unmaintained
drivers. I've been doing a bunch of
On Thu, 2011-08-25 at 07:28 -0600, Brian Paul wrote:
How would the TXQ instruction be implemented for a hardware driver?
Is there really a HW GPU instruction that returns the size of a texture?
Yes, that's correct.
Otherwise, this seems like something we could implement in the state
On Thu, 2011-08-25 at 15:00 +0100, Dave Airlie wrote:
On Thu, Aug 25, 2011 at 2:43 PM, Keith Whitwell kei...@vmware.com wrote:
On Thu, 2011-08-25 at 07:28 -0600, Brian Paul wrote:
How would the TXQ instruction be implemented for a hardware driver?
Is there really a HW GPU instruction
this as
GL_READ_WRITE because it's not GL_READ_ONLY and it's not
GL_WRITE_ONLY. However, my guess is that this code actually wants to
use GL_WRITE_ONLY.
Cc: Eric Anholt e...@anholt.net
Cc: Keith Whitwell kei...@vmware.com
---
src/mesa/drivers/dri/i965/brw_draw_upload.c |4 +---
src/mesa
On Wed, 2011-08-17 at 09:36 -0500, Bryan Cain wrote:
The usual commit message prefix for changes to glsl_to_tgsi is
glsl_to_tgsi, not st/mesa.
On 08/16/2011 05:33 PM, Brian Paul wrote:
The array of src regs is of size 3, not 4.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |2 +-
I'm not sure it makes a lot of sense to be optimizing swrast at this
stage. Take a look at llvmpipe and perhaps consider improving the
multithreading already in place in that rasterizer, which is far better
optimized than swrast already.
Keith
On Wed, 2011-08-10 at 08:07 +, Andreas Fänger
On Mon, 2011-07-11 at 18:24 +0200, Christian König wrote:
Hi guys,
as the subject already indicates: I'm about to merge pipe-video to
master and just wanted to ask if anybody has still any objections?
After following Jose and Younes discussion on mesa-dev about how to
design such an
On Tue, 2011-07-12 at 11:13 -0400, Younes Manton wrote:
2011/7/12 Keith Whitwell kei...@vmware.com:
I'm a bit unsure about what's the best approach here, though at this
stage I'm happy with your approach and don't think it needs to be
changed before any merge.
But speaking in general
On Fri, 2011-07-01 at 02:29 +0200, Marek Olšák wrote:
The suffix of 64 means it returns uint64_t.
It might be slightly clearer to call these functions util_pack64_{xxx}
-- currently it reads as if it is packing 64-bit source data.
Keith
---
src/gallium/auxiliary/util/u_pack_color.h | 64
This looks good to me -- Jose?
Keith
On Thu, 2011-06-30 at 03:33 +0100, Micael Dias wrote:
---
src/gallium/auxiliary/draw/draw_llvm.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
On Fri, 2011-07-01 at 14:42 +0200, Marek Olšák wrote:
On Fri, Jul 1, 2011 at 10:49 AM, Keith Whitwell kei...@vmware.com wrote:
On Fri, 2011-07-01 at 02:29 +0200, Marek Olšák wrote:
The suffix of 64 means it returns uint64_t.
It might be slightly clearer to call these functions
On Wed, 2011-06-29 at 16:16 -0700, Corbin Simpson wrote:
Okay, so maybe I'm failing to recognize the exact situation here, but
wouldn't it be possible to mark the FS state with a serial number and
just compare those? Or are these FS states not CSO-cached?
No, the struct being compared is
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame and loses to glibc's
memcmp (including call overhead, no knowledge about alignment etc.) even
On Thu, 2011-06-30 at 03:27 -0700, Jose Fonseca wrote:
- Original Message -
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin is totally lame
On Thu, 2011-06-30 at 17:53 +0200, Roland Scheidegger wrote:
Am 30.06.2011 16:14, schrieb Adam Jackson:
On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote:
Ok in fact there's a gcc bug about memcmp:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
In short gcc's memcmp builtin
On Wed, 2011-06-29 at 13:19 -0400, Adam Jackson wrote:
Perversely, do this by eliminating the comparison between stored and
current fs state. On ipers, a perf trace showed try_update_scene_state
using 31% of a CPU, and 98% of that was in 'repz cmpsb', ie, the memcmp.
Taking that out takes
On Mon, 2011-06-27 at 15:32 +0200, Marek Olšák wrote:
On Mon, Jun 27, 2011 at 2:38 PM, Roland Scheidegger
srol...@vmware.com wrote:
Am 25.06.2011 00:22, schrieb Vadim Girlin:
On 06/24/2011 11:38 PM, Jerome Glisse wrote:
On Fri, Jun 24, 2011 at 12:29 PM, Vadim
Girlinvadimgir...@gmail.com
On Tue, 2011-06-14 at 09:39 -0600, Brian Paul wrote:
Good question. I was thinking that the interleaved vs.
non-interleaved paths could probably be merged with a little work. I
don't remember the original reason for doing things as they are.
I think it enabled an easier upload path within
On Wed, 2011-05-25 at 09:32 -0400, Jerome Glisse wrote:
On Tue, May 24, 2011 at 8:09 PM, Bryan Cain bryanca...@gmail.com wrote:
Hi,
In the past few days, I've been working on native integer support in my
GLSL to TGSI translator. Something that's come to my attention is that
supporting
On Mon, 2011-04-11 at 10:30 -0700, Ian Romanick wrote:
The first patch fixes an issue that Ken and I discovered last week
with the ROUND_DOWN_TO macro in the i965 driver. The best fix is
probably to pull this macro up into higher-level Mesa code. I'd like
some review that changing this macro
Looks good to me, Jose.
Keith
On Thu, 2011-03-31 at 14:45 +0100, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Based on some code and ideas from Keith Whitwell.
---
src/gallium/auxiliary/Makefile |1 +
src/gallium/auxiliary/SConscript
Looks good.
Keith
On Thu, 2011-03-31 at 14:46 +0100, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Not added to the standard test lists given that ARB_vertex_buffer_object
allows program termination out-of-bounds vertex buffer object fetches
occur.
---
On Wed, 2011-03-30 at 14:33 +0200, Marek Olšák wrote:
From: Luca Barbieri l...@luca-barbieri.com
Disclaimer:
I will not push this code if this patch does not get any attention,
because I cannot say if it is 100% correct (the code is not mine).
However last time I checked, it passed
On Wed, Mar 30, 2011 at 2:45 PM, Keith Whitwell kei...@vmware.com
wrote:
diff --git a/src/gallium/auxiliary/draw/draw_llvm.h
b/src/gallium/auxiliary/draw/draw_llvm.h
index e8623e7..643a9ef 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.h
+++ b/src/gallium/auxiliary/draw
On Mon, 2011-03-21 at 19:55 +0100, Tilman Sauerbeck wrote:
Keith Whitwell [2011-03-21 18:43]:
On Mon, 2011-03-21 at 19:28 +0100, Tilman Sauerbeck wrote:
Signed-off-by: Tilman Sauerbeck til...@code-monkey.de
---
update_samplers() showed up in a profile of Heroes of Newerth
On Sat, 2011-03-12 at 00:48 +0100, Marek Olšák wrote:
On Fri, Mar 11, 2011 at 2:56 PM, Keith Whitwell kei...@vmware.com wrote:
So my suggestion would be to name this something else, perhaps taking
language from the NV extension.
Alright.
There are two patches attached in this email
On Mon, 2011-03-21 at 02:12 +0100, Marek Olšák wrote:
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index cf6c5b5..f6ad456 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -81,6 +81,8 @@ struct
On Mon, 2011-03-21 at 16:23 +0100, Christoph Bumiller wrote:
On 03/21/2011 02:12 AM, Marek Olšák wrote:
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index cf6c5b5..f6ad456 100644
--- a/src/gallium/include/pipe/p_state.h
+++
On Fri, 2011-03-11 at 06:05 +0100, Marek Olšák wrote:
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
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
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 OpenGL
On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
Hi,
I have several questions about Gallium. Some of them are about
undocumented
stuff, others are just little things from the top of my head. Please
consider these as things I may do when time allows.
1) Flush flags
Which
Isn't this PIPE_USAGE_STREAM ?
Keith
On Sat, 2011-03-05 at 17:54 +0100, Jakob Bornecrantz wrote:
Hi all
Short and simple patch series attached.
Some drivers can treat one shot resources differently then resources
that are expected to be used several times. Add a usage flag to allow
the
On Mon, 2011-03-07 at 18:52 +0100, Marek Olšák wrote:
6) Pixel buffer objects
It woud be nice to have hardware-accelerated PBO copy in Gallium.
Would
resource_copy_region be a good candidate for this, where one of
the
arguments would be PIPE_BUFFER and the other one would be
On Fri, 2011-03-04 at 07:02 -0800, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=6838c9ce74f16c765474c0d2b4ae1469dd4a64d5
Author: José Fonseca jfons...@vmware.com
Date: Fri Mar
On Tue, 2011-03-01 at 13:18 +0100, Blaž Tomažič wrote:
On Mon, 2011-02-28 at 16:39 -0800, Brian Paul wrote:
On Mon, Feb 28, 2011 at 4:13 PM, Blaž Tomažič blaz.toma...@gmail.com
wrote:
Hi Mesa developers,
I am really interested in Gallium3D and I'm thinking about a project for
my
Looks good Marek.
Keith
On Wed, 2011-02-23 at 07:44 +0100, Marek Olšák wrote:
From: Wiktor Janas wixorp...@gmail.com
Ptr can be very well NULL, so when there are two arrays, with one having
offset 0 (and thus NULL Ptr), and the other having a non-zero offset,
the non-zero value is taken as
I've always wondered why freeGLUT gives such poor numbers for gears and
similar high-framerate demos relative to the original.
It looks like one reason is the code added for Spaceball handling which
tries to initialize the Spaceball device every frame, even if it
previously failed. The trouble
Looks good Marek.
Keith
On Sun, 2011-02-20 at 16:52 +0100, Marek Olšák wrote:
This fixes the game Tiny and Big.
---
src/mesa/state_tracker/st_cb_clear.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_clear.c
I certainly have no objection for i965... Dave and Jakob probably need
to comment also.
Keith
On Wed, 2011-02-16 at 13:35 -0500, Kristian Høgsberg wrote:
They're not maintained and gets in the way when loading EGL drivers.
The doc string even says it's disabled by default.
---
I think it
On Sun, 2011-02-13 at 22:04 +0100, Marek Olšák wrote:
Keith,
Yes, they will. If vertex buffers are not re-set in st_draw_vbo,
redefine_user_buffer is called for each user buffer which is set and that
tells a driver which buffer ranges need to be re-uploaded. This can be found
in the last
Marek,
These patches look good, but have you covered the case where the application is
changing the contents of vertex arrays without rebinding/notifying GL in any
way?
eg. an app could do:
memcpy(varray, foo, ...);
glDrawArrays(...);
memcpy(varray, bar, ...);
glDrawArrays(...);
On Tue, 2011-02-08 at 22:29 +0100, Marek Olšák wrote:
Keith,
redefine_user_buffer() would be a good compromise and I believe the
performance hit wouldn't be so noticable. It would also allow partial
uploads of constants in a user buffer, which is something we'd like to
have
too.
On Tue, 2011-02-08 at 22:51 +0100, Marek Olšák wrote:
void redefine_user_buffer(
struct pipe_context*,
struct pipe_resource*,
unsigned offset,
unsigned size);
and new width0 would implicitly be offset+size;
I think this is a great place to start, if
...@gmail.com
To: Keith Whitwell kei...@vmware.com
Cc: mesa-dev@lists.freedesktop.org
Sent: Sunday, 6 February, 2011 12:01:01 PM
Subject: Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource
Hi Keith,
1) Recreating user buffers is very expensive, even though it's only
On Mon, 2011-01-31 at 10:46 -0800, Marek Olšák wrote:
Hi Keith,
From my point of view, user buffers are just pointers passed through
the Gallium interface and are well-defined from what I can see. They
might be owned by the application (e.g. set via glVertexPointer etc.),
therefore using
On Sat, 2011-01-29 at 15:12 -0800, Marek Olšák wrote:
Hi,
I am proposing to add a pointer to a user buffer in pipe_resource.
There are two reasons for this:
1) I would like to have a way to query outside of a driver whether a
buffer is a user buffer. Simply comparing the pointer with
On Fri, Dec 24, 2010 at 4:12 AM, Christopher James Halse Rogers
christopher.halse.rog...@canonical.com wrote:
On Tue, 2010-12-21 at 08:58 +, Keith Whitwell wrote:
This promotes a private interface to a public one, right? If so that
isn't really doing us any favours as next people
Dave,
This all looks good to me (modulo the glitch Tilman pointed out).
Keith
On Thu, 2010-12-23 at 00:43 -0800, Dave Airlie wrote:
For GL fragColor semantics we need to tell the pipe drivers that the fragment
shader color result is to be replicated to all bound color buffers, this
adds the
Marek,
This series looks good to me.
Keith
On Tue, 2010-12-21 at 19:00 -0800, Marek Olšák wrote:
And also check if the formats are supported to return something meaningful
if compression cannot be used.
---
src/mesa/state_tracker/st_format.c | 20
1 files changed,
This promotes a private interface to a public one, right? If so that
isn't really doing us any favours as next people will complain when that
newly public interface varies between releases.
If you want to save disk space by sharing components, what about an
alternate approach -- investigate
Looks good, Marek.
Keith
On Sun, 2010-12-19 at 04:02 -0800, Marek Olšák wrote:
---
src/gallium/auxiliary/util/u_index_modify.c | 12 ++--
src/gallium/auxiliary/util/u_inlines.h |3 +--
src/gallium/auxiliary/util/u_upload_mgr.c|4 ++--
On Fri, 2010-12-17 at 00:49 -0800, Dave Airlie wrote:
On Tue, Apr 27, 2010 at 7:10 AM, Dave Airlie airl...@gmail.com wrote:
buffers.
But you'll have more shader instructions for writing to all these
outputs right? I think that could still make a difference, though it
might be more
On Wed, 2010-12-15 at 09:19 -0800, Kristian Høgsberg wrote:
On Wed, Dec 15, 2010 at 10:10 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
...
Given this, I would advise strongly against building spinlocks into any code
that might be run on a uni-processor system. Particularly gallium
Looks good to me.
Keith
On Tue, 2010-12-14 at 05:15 -0800, Marek Olšák wrote:
---
src/gallium/auxiliary/os/os_thread.h | 51
++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/os/os_thread.h
On Sat, 2010-12-11 at 04:22 -0800, Jose Fonseca wrote:
Looks good to me FWIW.
Usually one uses a union for avoid breaking strict-aliasing rules, but your
memcpy approach should produce just as good code with less typing.
The only proper fix here would be to make struct tgsi_token an union
On Mon, 2010-12-13 at 07:09 -0800, Brian Paul wrote:
On 12/10/2010 03:27 PM, Vinson Lee wrote:
Module: Mesa
Branch: master
Commit: ef3f7e61b314236cbb7ed2cf24d34c6f90d9cfca
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ef3f7e61b314236cbb7ed2cf24d34c6f90d9cfca
Author:
On Tue, 2010-11-30 at 18:07 -0800, Roland Scheidegger wrote:
Am 30.11.2010 21:23, schrieb Ian Romanick:
It seems that new development in master has slowed a bit, so how does
a 7.10 release on January 7th sound? If we're going to do that,
we'll want to make the 7.10 branch on, say, December
On Tue, 2010-11-30 at 01:51 -0800, Chia-I Wu wrote:
Hi list,
I have spent the weekend adding OpenVG 1.1 support to Vega state
tracker. The new features added include mask layer support, text
support, and a new color transformation stage. The work can be found
at
On Mon, 2010-11-22 at 20:06 -0800, Dave Airlie wrote:
Hi Marek,
So I was looking at some perf traces from r600g, and I see a stall on
the blitter quad vbuf, every clear will cause the CPU to block on the
mapping of the vbuf to upload the new coords. On r300g I can see this
not mattering as
On Tue, 2010-11-16 at 13:40 -0800, Roland Scheidegger wrote:
On 16.11.2010 22:15, Jerome Glisse wrote:
On Tue, Nov 16, 2010 at 3:27 PM, Roland Scheidegger srol...@vmware.com
wrote:
On 16.11.2010 20:59, Jerome Glisse wrote:
On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger
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
On Fri, 2010-11-12 at 20:32 -0800, Jerome Glisse wrote:
I think r600c is just a bit too naive and so it end up being very
expensive to change any states with it. But i haven't took a closer
look. I don't think we should look too much at relative cost of
changing state. I think fglrx
On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
Eric just checked in a test into piglit that tests that the
gl_FragCoord works the right way up for FBOs,
Now all the gallium drivers fail this currently and fixing it creates
an ugly linkage between the currently bound buffer and the
On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
Eric just checked in a test into piglit that tests that the
gl_FragCoord works the right way up for FBOs,
Now all the gallium drivers fail this currently and fixing it creates
On Mon, 2010-11-15 at 01:32 -0800, Keith Whitwell wrote:
On Mon, 2010-11-15 at 01:28 -0800, Keith Whitwell wrote:
On Sun, 2010-11-14 at 20:18 -0800, Dave Airlie wrote:
Eric just checked in a test into piglit that tests that the
gl_FragCoord works the right way up for FBOs,
Now all
On Thu, 2010-11-11 at 14:59 -0800, Jerome Glisse wrote:
2010/11/11 Keith Whitwell kei...@vmware.com:
There is still more to do there. Currently r600g treats buffer and texture
uploads separately, and I've only attempted to improve texture uploads.
Buffer is just as important however
Looks good, committed. Thanks for fixing this.
Keith
On Wed, Nov 3, 2010 at 9:14 PM, Guillermo S. Romero
gsrom...@infernal-iceberg.com wrote:
Commit 8dfafbf0861fe3d2542332658dd5493851053c78 forgot to update r300g.
There is a buf == NULL check, but buf is used before for var init.
Tested-by:
Michal - it looks like this will mean that these tests now always try to create
populate a result.bmp file? Would it be possible to guard this behaviour
with some sort of option, eg an environment var?
Keith
From:
On Tue, 2010-11-02 at 11:21 -0700, Francisco Jerez wrote:
Keith Whitwell kei...@vmware.com writes:
Francisco,
This looks good - my only comment is that there seem to be two distinct
changes in this patch -- the modification to VBO behaviour when adding a
new attribute being one
---
src/gallium/drivers/r600/r600_texture.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 4ebd5b7..7222b43 100644
---
This opens the question of what interface the winsys layer should
really have for talking about these concepts.
For now I'm using the existing gallium resource usage concept, but
there is no reason not use terms closer to what the hardware
understands - eg. the domains themselves.
---
Generalize the existing tiled_buffer path in texture transfers for use
in some non-tiled up and downloads.
Use a staging buffer, which the winsys will restrict to GTT memory.
GTT buffers have the major advantage when they are mapped, they are
cachable, which is a very nice property for
These were being set but not used anywhere.
---
src/gallium/drivers/r600/r600_buffer.c | 27 ---
src/gallium/drivers/r600/r600_resource.h |5 -
src/gallium/drivers/r600/r600_texture.c |1 -
3 files changed, 0 insertions(+), 33 deletions(-)
diff --git
Hmm, after cleaning these patches up to mail out, I'm now seeing some
problems with this one... sigh. I'll resend shortly.
Keith
On Tue, 2010-11-02 at 11:40 -0700, Keith Whitwell wrote:
This opens the question of what interface the winsys layer should
really have for talking about
Restore lost hunk in patch 2.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
---
src/gallium/drivers/r600/r600_texture.c | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_texture.c
b/src/gallium/drivers/r600/r600_texture.c
index 4ebd5b7..7222b43 100644
---
This opens the question of what interface the winsys layer should
really have for talking about these concepts.
For now I'm using the existing gallium resource usage concept, but
there is no reason not use terms closer to what the hardware
understands - eg. the domains themselves.
---
Generalize the existing tiled_buffer path in texture transfers for use
in some non-tiled up and downloads.
Use a staging buffer, which the winsys will restrict to GTT memory.
GTT buffers have the major advantage when they are mapped, they are
cachable, which is a very nice property for
These were being set but not used anywhere.
---
src/gallium/drivers/r600/r600_buffer.c | 27 ---
src/gallium/drivers/r600/r600_resource.h |5 -
src/gallium/drivers/r600/r600_texture.c |1 -
3 files changed, 0 insertions(+), 33 deletions(-)
diff --git
On Tue, Nov 2, 2010 at 7:54 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell kei...@vmware.com wrote:
These were previously being left in the default (D3D) mode. This mean
that triangles were drawn slightly incorrectly, but also because this
state
Tilman,
This looks good - it makes sense to also reset the constant buffers,
etc, at the same point...
Keith
On Sun, Oct 31, 2010 at 4:38 PM, Tilman Sauerbeck til...@code-monkey.de wrote:
Signed-off-by: Tilman Sauerbeck til...@code-monkey.de
---
src/mesa/state_tracker/st_context.c | 2 ++
On Mon, Oct 18, 2010 at 9:18 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Fri, Oct 15, 2010 at 7:44 PM, John Kessenich jo...@lunarg.com wrote:
Hi,
LunarG has decided to work on an open source, long-term, highly-functional,
and modular shader and kernel compiler stack. Attached is our
Isn't this a quite similar concept to tests/texfilt?
Keith
On Thu, Oct 14, 2010 at 3:55 PM, Brian Paul
bri...@kemper.freedesktop.org wrote:
Module: Demos
Branch: master
Commit: 4d981d192bcff29fd85c794415148988518c6eae
URL:
Would try to destroy radeon-cman, radeon-kman both which were still
NULL.
---
src/gallium/winsys/r600/drm/r600_drm.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/winsys/r600/drm/r600_drm.c
b/src/gallium/winsys/r600/drm/r600_drm.c
index
Tested with demos/pixeltest - line rasterization doesn't seem to be
set up for GL conventions yet, but at least width is respected now.
---
src/gallium/drivers/r600/r600_state.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
Statetrackers can unbind a constant buffer slot by calling
pipe-set_constant_buffer(pipe, shader, slot, NULL)
The driver should unbind the buffer and potentially allow its storage
to be released.
---
src/gallium/drivers/r600/r600_state.c | 20
1 files changed, 16
1 - 100 of 173 matches
Mail list logo
