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
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 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 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 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 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
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 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
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 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
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 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
> >
- 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 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
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 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
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 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 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-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 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 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 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 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 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
> b/src/gallium/auxiliary/d
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
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 :
> > 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
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 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
; 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-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
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 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
I think this is fine. It's been a very long time since we had to worry
about this.
Keith
On Mon, 2010-08-16 at 01:17 -0700, Vinson Lee wrote:
> I am proposing to remove the check_os_katmai_support function from
> u_cpu_detect.
>
> util: Remove check_os_katmai_support.
>
> check_os_katmai_supp
On Mon, 2010-08-16 at 04:54 -0700, Luca Barbieri wrote:
> I added the two patchsets I posted to the list to the two branches
> named in the subject.
>
> The version pushed contain slight changes over the ones sent to the ML:
> 1. In translate, Win64 support has been further fixed to use the
> prop
Luca,
It seems like there is an alternate fix possible -- modify the mesa
fixed-function vertex program generator to put these constant values in
the constant buffer, rather than passing them as vertex data. That
would remove the need for us to have this unique capability at the
gallium level tha
On Tue, 2010-08-17 at 00:09 -0700, Luca Barbieri wrote:
> -#define PIPE_BIND_STREAM_OUTPUT(1 << 11) /*
> set_stream_output_buffers */
> +
> +/* Sampler views can be created based on this texture. Only the
> + * normalization preferred by the driver can be used, unless the
> other
> + * flag
On Tue, 2010-08-17 at 00:09 -0700, Luca Barbieri wrote:
> +
> +/* State trackers should support using either normalization in all
> internal drawing
> + * code, using these flag to tell which one to use.
> + *
> + * If they do not have such support, then they should indicate the
> + * normalization
-
In terms of the unnormalized change, I think I'd like to go over it one
more time.
It looks like there are a few things happening at once:
a) The state tracker is informing the driver whether it will use
normalized texcoords, unnormalized texcoords or both for a given
texture.
On Tue, 2010-08-17 at 13:16 -0700, Luca Barbieri wrote:
> > Using a flag instead of a new texture target allows to avoid hundreds of
> > changes to existing code, and allows drivers for modern hardware to
> > just ignore this flag.
> I grepped a bit through the code, and a new texture target seems
On Wed, 2010-08-18 at 08:01 -0700, Luca Barbieri wrote:
> > I appreciate all the work you've put into looking at alternatives, but
> > at this stage I'm going to be firm - if PIPE_TEXTURE_RECT can be made to
> > work, that's the direction we should be taking. I haven't seen anything
> > so far tha
On Wed, 2010-08-18 at 09:08 -0700, Luca Barbieri wrote:
> > I have a feeling that CL performance will not matter that much for
> > nvfx and r300, compared to nv50 and r600.
>
> Sure.
> The point is that if you can't use normalized coordinates at all on
> PIPE_TEXTURE_RECT, you can't implement Open
On Wed, 2010-08-18 at 10:27 -0700, Luca Barbieri wrote:
> I pushed a first version on the gallium-rect-textures branch (not
> tested beyond compilation).
>
> As a consequence of the decisions made in this thread, the interface
> is exactly identical to OpenGL, and internal drawing code works
> exa
On Wed, Aug 18, 2010 at 7:03 PM, Luca Barbieri wrote:
>> Couple of minor comments:
>> - You've documented FLEXIBLE_SAMPLING in the main part of the docs, I
>> think I'd prefer to keep forward-looking/todo items separate from the
>> documentation of the interface as it currently stands. Can these
On Fri, 2010-08-20 at 00:59 -0700, Luca Barbieri wrote:
> gallium-rect-textures adds the PIPE_TEXTURE_RECT target as discussed
> in the "gallium & texture rectangles" thread.
> I tested nv30, nv40, softpipe and "softpipe with NPOT disabled" using piglit.
Yes, definitely. Thanks again for your ef
On Fri, 2010-08-20 at 00:45 -0700, Corbin Simpson wrote:
> I can't find the email where we were discussing TGSI sanity. Did we
> want to move the sanity checker to galahad?
It only makes sense to move it there if galahad will end up being the
only user of it -- I'm not sure we're ready to make tha
On Fri, 2010-08-20 at 01:58 -0700, Luca Barbieri wrote:
> There is also another small issue: a new tool is necessary to
> post-process the traces, to resolve function names and line numbers.
> I put it a new directory called "src/gallium/tools" since none of the
> existing places seem appropriate.
On Fri, 2010-08-20 at 03:01 -0700, Luca Barbieri wrote:
> I pushed a new version as debug-refcnt-2, which uses os_stream instead of
> FILE*.
> A new commit adds a printf facility to os_stream to support this.
>
> It still uses the sprintf functions from stdio.h, but I suppose this is OK.
> If a p
On Fri, 2010-08-20 at 04:11 -0700, Luca Barbieri wrote:
> > Hasn't this already happened somewhere - util/u_snprintf.c ?
> Indeed, I'll fix it to use those.
>
> There's something (independent from this) that bugs me though.
>
> Why does Gallium feel the need to implement all this stuff with ad-ho
On Fri, 2010-08-20 at 06:35 -0700, José Fonseca wrote:
> On Fri, 2010-08-20 at 06:17 -0700, Luca Barbieri wrote:
> > > And define magic is very brittle. Especially with C++: you #define
> > > printf to be something else, but nothing prevents a class or a namespace
> > > to have the printf symbol in
On Fri, 2010-08-20 at 07:40 -0700, Luca Barbieri wrote:
> Does debug-refcnt-2 look good now?
Yes, looks good to me.
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, 2010-08-23 at 14:09 -0700, José Fonseca wrote:
> On Sun, 2010-08-22 at 02:35 -0700, nobled wrote:
> > The first three attached patches make it possible to compile Mesa with
> > LLVM/Clang:
> > 1. Add -lstdc++ when linking glsl_compiler and glcpp
> > 2. Move -lstdc++ from the Gallium-specifi
The point state is complex, there are actually a lot of variations
built into GL itself which aren't obvious on first reading of the
spec. Probably the most obscure is that wide points and point sprites
are specified to actually be rasterized differently, ie color
different pixels. I'm doing this
On Wed, Sep 1, 2010 at 7:14 AM, Dave Airlie wrote:
> I was looking at glsl-vs-point-size in piglit today and it doesn't
> work on gallium.
>
> void main()
> {
> gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
> gl_PointSize = 16.0;
> gl_FrontColor = vec4(1.0, 1.0, 1.0, 1.0);
> }
>
> S
On Wed, 2010-09-01 at 09:24 -0700, Luca Barbieri wrote:
> > It's an impressive amount of work you did here. I'll comment only on the
> > llvmpipe of the changes for now.
>
> Thanks for your feedback!
>
> > Admittedly, always using a floating point is not ideal. A better
> > solution would be to c
On Wed, Sep 1, 2010 at 7:54 PM, Luca Barbieri wrote:
>> It still sounds that you're referring to sampling from a texture and not
>> rendering/blending to it. Of course the are related (we only want one
>> swizzled layout at most), but the current swizzled layout was chosen to
>> make blending easy
On Wed, Sep 1, 2010 at 8:34 PM, tom fogal wrote:
> Luca Barbieri writes:
>> > It's an impressive amount of work you did here. I'll comment only
>> > on the llvmpipe of the changes for now.
>>
>> Thanks for your feedback!
>
> While we're on the topic: yes, this is great to see Luca. Thank you!
>
On Wed, 2010-09-08 at 21:30 -0700, Marek Olšák wrote:
> On Thu, Sep 9, 2010 at 2:35 AM, Eric Anholt wrote:
> However, the fact that when I ask about performance nobody
> says "OMG the
> texture upload/download/copy/etc. support in gallium is so
> great and is
>
On Sat, 2010-09-11 at 15:48 -0700, Luca Barbieri wrote:
> Jose Fonseca seemed open to accepting this, but no final go ahead was given.
>
> > We need this to enable full loop unrolling for r3xx->r4xx fragment shaders,
> > which don't support loops. It's needed for the blur shader in KWin to work.
>
Hey Kristian,
The first question is whether this is necessary - from vague memory I
have an idea that current attributes need not be updated by vertex
buffer rendering - ie. it's optional/implementation-dependent.
I assume you're concerned with the case where you have something like
// ctx->C
On Tue, 2010-09-14 at 08:18 -0700, Chia-I Wu wrote:
> 2010/9/14 Kristian Høgsberg :
> > 2010/9/14 Chia-I Wu :
> >> 2010/9/14 Kristian Høgsberg :
> >>> 2010/9/13 keith whitwell :
> >>>> Hey Kristian,
> >>>>
> >>>> The first
I saw these warnings also on scons builds. Vinson - if you set "quiet=no",
scons will print out the full gcc invocation, there may be a clue there what's
causing this.
Keith
From: mesa-dev-bounces+keithw=vmware@lists.freedesktop.org
[mesa-dev-bounce
Looks good, thanks Tilman.
Keith
On Sun, Sep 19, 2010 at 8:24 AM, Tilman Sauerbeck wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
> src/gallium/docs/source/tgsi.rst | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/docs/source/tgsi.rst
> b/src/gallium/
Luca,
This is an amazing achievement -- not least because even excluding
this you've been incredibly productive recently. I hope you haven't
got any more monster projects about to uncloak...
A couple of questions - it looks like this is a drop-in for the
d3d10/11 runtime, rather than an implemen
On Mon, 2010-09-20 at 16:28 -0700, Luca Barbieri wrote:
> > A couple of questions - it looks like this is a drop-in for the
> > d3d10/11 runtime, rather than an implementation of the DDI.
> Yes.
>
> > I think
> > that makes sense, but it could also be possible to split it into two
> > pieces imple
On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie wrote:
> So Evergreen hardware appears to have only completely separate depth
> and stencil buffers and doesn't natively support a combnined DS buffer
> from what I can see. I'm awaiting clarification from AMD.
>
> Now gallium and st/mesa seem to be qu
On Wed, Sep 22, 2010 at 11:15 AM, Dave Airlie wrote:
>>> I'm mainly posting just wondering if anyone else has considered this
>>> or any other hardware this might be useful for exists, or if anyone
>>> can speak to the pitfalls I'll face.
>>>
>>> I've got some initial done in 30 mins hacks
>>> ht
>From my point of view, I'd like to get a list of the specific issues the wine
>guys have, and work through that list resolving each issue in turn - either by
>modifying the code or demonstrating that the concern is unfounded. If neither
>of these is possible, then we need to make a call one wa
Looks good to me Marek -- good catch.
Keith
On Thu, 2010-09-23 at 17:42 -0700, Marek Olšák wrote:
> NOTE: This is a candidate for the 7.9 branch.
> ---
> src/gallium/auxiliary/util/u_pack_color.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/auxiliar
On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote:
> On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote:
> >
> > - use score for placing bo, bo placement will be recorded in bo structure
> > and
> > each time a state is bind bo score will be updated (bo bound as framebuffer
> > will get
On Wed, 2010-09-29 at 23:41 -0700, Dave Airlie wrote:
> some background:
>
> so on r600g, the only way to directly write to the stencil is via the
> shader, using a transfer would require an extra step to flush the DS
> buffer out via the pipe again to make it useable by the hw as a DS
> buffer. S
Hi Jerome,
I was playing with this driver on my new machine (rv710) & was
impressed with how well it worked. Unfortunately the next update
everything went black...
I traced it down to this commit - it basically seems like all the
vertex-buffer constants (at least) are ending up as zero, so most
(using the correct mesa3d-dev address)
-- Forwarded message --
From: Keith Whitwell
Date: Wed, Oct 6, 2010 at 9:07 AM
Subject: Re: Mesa (master): r600g: use constant buffer instead of
register for constant
To: mesa-dev@lists.freedesktop.org
Cc: mesa3d-dev
Hi Jerome,
I was
Hmm, same results on the machine's built-in rs880 (whatever that is...)
Keith
On Wed, Oct 6, 2010 at 9:08 AM, Keith Whitwell wrote:
> (using the correct mesa3d-dev address)
>
>
> -- Forwarded message ------
> From: Keith Whitwell
> Date: Wed, Oct 6, 2010 a
Yes, I belive so (at work now, so can't double-check). I started with
the top of tree last night, which is well past this commit.
Keith
On Wed, 2010-10-06 at 02:12 -0700, Dave Airlie wrote:
> On Wed, Oct 6, 2010 at 6:29 PM, Keith Whitwell
> wrote:
> > Hmm, same results on th
Hmm, this seems to have been transient issue - a few more package
updates & everything's working again... Sorry for the noise...
Keith
On Wed, Oct 6, 2010 at 2:25 PM, Jerome Glisse wrote:
> On Wed, Oct 6, 2010 at 5:19 AM, Keith Whitwell wrote:
>> Yes, I belive so (at work no
Looks good Kristian. This has been worthy of cleanup for some time...
Keith
2010/10/13 Kristian Høgsberg :
> 2010/10/13 Kristian Høgsberg :
>> Just always check for FLUSH_UPDATE_CURRENT and call Driver.BeginVertices
>> when necessary. By using the unlikely() macros, this ends up as
>> a 10% per
Isn't this a quite similar concept to tests/texfilt?
Keith
On Thu, Oct 14, 2010 at 3:55 PM, Brian Paul
wrote:
> Module: Demos
> Branch: master
> Commit: 4d981d192bcff29fd85c794415148988518c6eae
> URL:
> http://cgit.freedesktop.org/mesa/demos/commit/?id=4d981d192bcff29fd85c794415148988518c6e
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 5f175a4.
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
b/sr
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 inser
block->reloc[id].flush_flags,
I haven't really figured out the state emit mechanism in this driver
yet... Have you got any guidance what needs to be done here?
Keith
On Thu, Oct 14, 2010 at 4:42 PM, Keith Whitwell wrote:
> Statetrackers can unbind a constant buffer slot by ca
This was being classed as unsupported in one place but used in others.
Enabling it seems to work fine.
---
src/gallium/drivers/r600/r600_shader.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600
On Mon, Oct 18, 2010 at 9:18 AM, Jerome Glisse wrote:
> On Fri, Oct 15, 2010 at 7:44 PM, John Kessenich 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 high-level
>> proposal for this com
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 wrote:
> Signed-off-by: Tilman Sauerbeck
> ---
> src/mesa/state_tracker/st_context.c | 2 ++
> 1 files changed, 2 insertions(+), 0
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, but the changes to vbo_exec_draw.c seem to be
an unrelated cleanup. Is that correct?
Ordinarily I wouldn't bother p
On Tue, 2010-11-02 at 11:21 -0700, Francisco Jerez wrote:
> Keith Whitwell 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
> &
---
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
--- a/src/gallium/drivers/r600/r600_textu
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
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,
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
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
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 ha
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
--- a/src/gallium/drivers/r600/r600_textu
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
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,
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
1 - 100 of 248 matches
Mail list logo
