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 n
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
- 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
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
> >
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 long
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
mesa-dev@list
Looks good to me.
Keith
On Sun, 2011-10-30 at 20:05 +0800, Chia-I Wu wrote:
> From: Chia-I Wu
>
> It is a typo went unnoticed.
> ---
> src/gallium/drivers/llvmpipe/lp_rast_tri.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_rast
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 con
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 th
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, F
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 me
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 stil
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! Than
On Thu, 2011-08-25 at 15:00 +0100, Dave Airlie wrote:
> On Thu, Aug 25, 2011 at 2:43 PM, Keith Whitwell 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 th
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
> t
On Wed, 2011-08-24 at 20:46 -0400, Kristian Høgsberg wrote:
> On Wed, Aug 24, 2011 at 3:11 PM, Ian Romanick 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 refactoring an
; 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
> Cc: Keith Whitwell
> ---
> src/mesa/drivers/dri/i965/brw_draw_upload.c |4 +---
> s
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.cp
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 wr
On Tue, 2011-07-12 at 11:13 -0400, Younes Manton wrote:
> 2011/7/12 Keith Whitwell :
> > 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 mer
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 Fri, 2011-07-01 at 14:42 +0200, Marek Olšák wrote:
> On Fri, Jul 1, 2011 at 10:49 AM, Keith Whitwell 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 th
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
> b/src/gallium/auxiliary/d
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
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 memcm
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 t
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.) ev
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 poo
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
> 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
> Girlin
> >>> wrote:
> Fixes htt
On Wed, 2011-06-15 at 11:29 +0200, Thomas Hellstrom wrote:
> Hi!
>
> I just pushed an initial commit of an X Acceleration state tracker to
> the xa_branch.
>
> The idea is that in the long run it will be replacing the Xorg state
> tracker, which can then move back to a modular xf86-video-modese
On Tue, 2011-06-14 at 18:25 +0200, Marek Olšák wrote:
> Hi,
>
> This series reworks some of our configure options to make Gallium easier to
> configure.
>
> First, there is a new option --with-gallium-drivers=DIRS, which replaces the
> current heap of options --enable-gallium-DRIVER. --disable-
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 withi
Andreas,
This looks very interesting. Ultimately llvmpipe would want to have aniso as
well, but performance would be much more important there. Do you have a
feeling for what shortcuts the hardware implementations are taking?
Keith
- Original Message -
From: "Andreas Faenger"
To: me
On Wed, 2011-05-25 at 09:32 -0400, Jerome Glisse wrote:
> On Tue, May 24, 2011 at 8:09 PM, Bryan Cain 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 Gallium ta
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
Looks good.
Keith
On Thu, 2011-03-31 at 14:46 +0100, jfons...@vmware.com wrote:
> From: José Fonseca
>
> Not added to the standard test lists given that ARB_vertex_buffer_object
> allows program termination out-of-bounds vertex buffer object fetches
> occur.
> ---
> tests/general/CMakeLists.gl
Looks good to me, Jose.
Keith
On Thu, 2011-03-31 at 14:45 +0100, jfons...@vmware.com wrote:
> From: José Fonseca
>
> Based on some code and ideas from Keith Whitwell.
> ---
> src/gallium/auxiliary/Makefile |1 +
> src/gallium/au
> On Wed, Mar 30, 2011 at 2:45 PM, Keith Whitwell
> 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_llv
On Wed, 2011-03-30 at 14:33 +0200, Marek Olšák wrote:
> From: Luca Barbieri
>
> 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 all the related tes
On Mon, 2011-03-28 at 17:54 -0400, Jerome Glisse wrote:
> Hi,
>
> One short coming of macro has keep entertaining me until i figure out
> what was wrong, here is
> a simple scenario :
>
> Macro can lead to hard to debug list bugs. For instance consider
> the following :
> LIST_ADD(item, list->pre
On Mon, 2011-03-28 at 17:54 -0400, Jerome Glisse wrote:
> Hi,
>
> One short coming of macro has keep entertaining me until i figure out
> what was wrong, here is
> a simple scenario :
>
> Macro can lead to hard to debug list bugs. For instance consider
> the following :
> LIST_ADD(item, list->pre
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
> > > ---
> > >
> > > update_samplers() showed up
On Mon, 2011-03-21 at 19:28 +0100, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
>
> update_samplers() showed up in a profile of Heroes of Newerth;
> this patch pushes it down the profile by ~3%.
>
> Does this seem plausible?
>
> src/mesa/state_tracker/st_atom_sampler.c |
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
> > +++ b/src/gal
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 pipe_raster
On Sat, 2011-03-12 at 00:48 +0100, Marek Olšák wrote:
> On Fri, Mar 11, 2011 at 2:56 PM, Keith Whitwell wrote:
> >
> > So my suggestion would be to name this something else, perhaps taking
> > language from the NV extension.
> >
>
> Alright.
>
> There
>
> 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'
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
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
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
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
On Mon, 2011-03-07 at 20:47 +1000, Dave Airlie wrote:
> On Mon, Mar 7, 2011 at 3:42 AM, 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 thin
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
>
>
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
> Date: Fri Mar 4 14:54:24 2
On Tue, 2011-03-01 at 12:32 -0800, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/01/2011 05:36 AM, Keith Whitwell wrote:
>
> > Create an automated bug-finder for gallium drivers.
> >
> > Step one: create a "split and com
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č
> > wrote:
> > > Hi Mesa developers,
> > >
> > > I am really interested in Gallium3D and I'm thinking about a project for
> > > my diplo
Looks good Marek.
Keith
On Wed, 2011-02-23 at 07:44 +0100, Marek Olšák wrote:
> From: Wiktor Janas
>
> 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 minimum (becau
Looks good to me.
Keith
On Sun, 2011-02-20 at 18:14 +0100, Marek Olšák wrote:
> If two buffers had the same stride where one buffer is a user one and
> the other is a vbo, it was considered to be one interleaved buffer,
> resulting in incorrect rendering and crashes.
>
> This patch makes sure th
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
> b/
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 be
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
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 la
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(...);
wi
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
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
Keith
- Original Message -
From: "Marek Olšák"
To: "Keith Whitwell"
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 buffe
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 usi
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 point
On Fri, Dec 24, 2010 at 4:12 AM, Christopher James Halse Rogers
wrote:
> On Tue, 2010-12-21 at 08:58 +0000, 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 will complain when
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 th
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 change
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 metho
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 ++--
> src/galliu
On Fri, 2010-12-17 at 00:49 -0800, Dave Airlie wrote:
> On Tue, Apr 27, 2010 at 7:10 AM, Dave Airlie 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 theoret
On Wed, 2010-12-15 at 09:19 -0800, Kristian Høgsberg wrote:
> On Wed, Dec 15, 2010 at 10:10 AM, Thomas Hellstrom
> wrote:
> ...
> > Given this, I would advise strongly against building spinlocks into any code
> > that might be run on a uni-processor system. Particularly gallium utility
> > code.
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
> b/src/gallium/aux
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
> >
>
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
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, De
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
>
> http://cgit.fr
On Wed, 2010-11-24 at 18:28 -0800, Roland Scheidegger wrote:
> From:
> Roland Scheidegger
>
>To:
> mesa-dev@lists.freedesktop.org
> ,
> Keith Whitwell
> Subject:
> RFC: gal
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 matterin
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
> > wrote:
> >> On 16.11.2010 20:59, Jerome Glisse wrote:
> >>> On Tue, Nov 16, 2010 at 2:38 PM, Roland Scheidegger
> >>> wrote:
> >>>
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 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 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 work
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 t
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 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 opt
On Thu, 2010-11-11 at 14:59 -0800, Jerome Glisse wrote:
> 2010/11/11 Keith Whitwell :
> > 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 impo
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.
The change needed is likely to be one of two:
a) Allow newly created vertex buffers to be in the GTT domain, w
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: mesa-dev-bounces+keithw=vmware@l
Looks good, committed. Thanks for fixing this.
Keith
On Wed, Nov 3, 2010 at 9:14 PM, Guillermo S. Romero
wrote:
> Commit 8dfafbf0861fe3d2542332658dd5493851053c78 forgot to update r300g.
> There is a buf == NULL check, but buf is used before for var init.
>
> Tested-by: Guillermo S. Romero
> --
Looks good Tillman.
Keith
On Tue, Nov 2, 2010 at 9:17 PM, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
>
> v2: Also call into the pipe driver to make it release its reference.
>
> src/mesa/state_tracker/st_context.c | 5 +
> 1 files changed, 5 insertions(+), 0 deletio
On Tue, Nov 2, 2010 at 7:54 PM, Alex Deucher wrote:
> On Tue, Nov 2, 2010 at 3:40 PM, Keith Whitwell wrote:
>> These were previously being left in the default (D3D) mode. This mean
>> that triangles were drawn slightly incorrectly, but also because this
>> state is relie
These were previously being left in the default (D3D) mode. This mean
that triangles were drawn slightly incorrectly, but also because this
state is relied on by the u_blitter code, all blits were half a pixel
off.
---
src/gallium/drivers/r600/r600_state.c |5 +
src/gallium/driver
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 a/src
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 downloads,
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.
---
src/gallium
1 - 100 of 248 matches
Mail list logo
