On Fri, 2010-06-04 at 03:10 -0700, Dave Airlie wrote:
> On Tue, Apr 27, 2010 at 9:13 PM, Dave Airlie wrote:
> > Another trying to figure out gallium patch from me,
> >
> > This is in theory EXT_texture_swizzle support, r300g passes the glean
> > test with this now.
> >
> > Some caveats in the patc
On Wed, 2010-05-26 at 13:57 -0700, Eric Anholt wrote:
> On Sat, 22 May 2010 08:18:37 -0600, Brian Paul wrote:
> > On Thu, May 20, 2010 at 1:18 PM, Eric Anholt wrote:
> >
> > [...]
> >
> > > I think commit messages are hooked up, too.
> >
> > I'm not seeing commit messages on the mesa-commit li
On Fri, 2010-06-04 at 05:02 -0700, Kristian Høgsberg wrote:
> On Fri, Jun 4, 2010 at 7:13 AM, Keith Whitwell wrote:
> ...
> > checking dynamic linker characteristics... GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > checking wheth
On Fri, 2010-06-04 at 06:42 -0700, Dan Nicholson wrote:
> 2010/6/4 Kristian Høgsberg :
> > On Fri, Jun 4, 2010 at 7:13 AM, Keith Whitwell wrote:
> > ...
> >> checking dynamic linker characteristics... GNU/Linux ld.so
> >> checking how to hardcode library
On Sat, 2010-06-05 at 08:10 -0700, Roland Scheidegger wrote:
> On 04.06.2010 22:08, Patrice Mandin wrote:
> > Hello,
> >
> > progs/trivial/tri just segfaults now, because it does not setup a
> > context with depth/stencil, and src/gallium/auxiliary/util/u_clear.h
> > does not check if
> >
> > str
On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote:
> Jakob Bornecrantz wrote:
> > On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz
> > wrote:
> >> Since we don't have any progs in mesa that uses glew anymore is it
> >> okay if we drop it? I have attached a patch which drops it its a bit
> >> b
On Mon, 2010-06-07 at 12:17 -0700, Jakob Bornecrantz wrote:
> Also I need to figure out a good way to solve some of the target
> helpers code. The current wrapper code doesn't work since it gets
> compiled into the aux archive which gets linked in after identity,
> rbug and trace so it can't fi
On Thu, 2010-06-03 at 13:26 -0700, Roland Scheidegger wrote:
> Hi,
>
> I've created a new branch gallium-array-textures which has some more
> interface changes, this time to support array textures basically.
> Nothing has been adapted to these changes yet (I'll do that it should be
> mostly trivia
On Thu, 2010-06-10 at 07:08 -0700, Roland Scheidegger wrote:
> On 10.06.2010 11:30, Keith Whitwell wrote:
> > On Thu, 2010-06-03 at 13:26 -0700, Roland Scheidegger wrote:
> >> Hi,
> >>
> >> I've created a new branch gallium-array-textures which has some
On Thu, 2010-06-10 at 07:29 -0700, Brian Paul wrote:
> Keith Whitwell wrote:
> > On Thu, 2010-06-10 at 07:08 -0700, Roland Scheidegger wrote:
> >> On 10.06.2010 11:30, Keith Whitwell wrote:
> >>> On Thu, 2010-06-03 at 13:26 -0700, Roland Scheidegger wrote:
> >
On Thu, 2010-06-10 at 11:32 -0700, Roland Scheidegger wrote:
> On 10.06.2010 17:12, Keith Whitwell wrote:
> > On Thu, 2010-06-10 at 07:29 -0700, Brian Paul wrote:
> >> Keith Whitwell wrote:
> >>> On Thu, 2010-06-10 at 07:08 -0700, Roland Scheidegger wrote:
>
On Thu, 2010-06-10 at 12:23 -0700, Roland Scheidegger wrote:
> On 10.06.2010 21:14, Keith Whitwell wrote:
> > On Thu, 2010-06-10 at 11:32 -0700, Roland Scheidegger wrote:
> >> On 10.06.2010 17:12, Keith Whitwell wrote:
> >>> On Thu, 2010-06-10 at 07:29 -0700,
On Fri, 2010-06-11 at 06:04 -0700, Roland Scheidegger wrote:
> On 10.06.2010 20:32, Roland Scheidegger wrote:
> > On 10.06.2010 17:12, Keith Whitwell wrote:
> >> On Thu, 2010-06-10 at 07:29 -0700, Brian Paul wrote:
> >>> Keith Whitwell wrote:
> >>>&
On Wed, 2010-06-23 at 00:17 -0700, Corbin Simpson wrote:
> So I just pushed yet another silly little thing to mesa/mesa. This,
> however, I think might actually be useful.
>
> Galahad is an implementation of that "what if we had a sanity layer?"
> idea from way back when. It is more or less the id
>
> We currently allow partial specification of position, requiring only
> (x, y) and filling in z as 0 and w as 1 if missing. Is that still
> valid? Similarly, colors may be specified as (r, g, b) triplets with
> no alpha, and alpha defaults to 1. Is that still valid, or are there
> changes furt
On Sat, 2010-07-03 at 13:49 -0700, nobled wrote:
> This way there's fewer ifdef's *and* less busy-waiting.
> ---
> .../auxiliary/pipebuffer/pb_buffer_fenced.c| 19 +++
> 1 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/auxiliary/pipebuffer/p
On Thu, 2010-07-08 at 08:36 -0700, Brian Paul wrote:
> PIPE_MAX_SHADER_INPUTS/OUTPUTS are currently set to 16 in p_state.h
>
> That's actually not enough to accomodate OpenGL's needs. For example,
> a Mesa vertex shader has these inputs:
>
> typedef enum
> {
> VERT_ATTRIB_POS = 0,
> VER
On Fri, 2010-07-16 at 11:10 -0700, Chia-I Wu wrote:
> Hi all,
>
> This patch series replaces
>
> st_context::draw_arrays
> st_context::draw_elements,
> st_context::draw_arrays_instanced
> st_context::draw_elements_instanced
> st_context::draw_range_elements
>
> by a single
>
> st_co
On Wed, 2010-07-21 at 01:49 -0700, Marek Olšák wrote:
> Hi,
>
> there is a new branch gallium-depth-clamp in the main repository which
> implements ARB_depth_clamp in Gallium. Wine uses this extension to
> disable clipping when it's requested from a D3D9 app, so it's an
> important one.
>
> There
On Wed, 2010-07-21 at 06:54 -0700, Keith Whitwell wrote:
> On Wed, 2010-07-21 at 01:49 -0700, Marek Olšák wrote:
> > Hi,
> >
> > there is a new branch gallium-depth-clamp in the main repository which
> > implements ARB_depth_clamp in Gallium. Wine uses this extension t
On Mon, 2010-07-19 at 00:46 -0700, Chia-I Wu wrote:
> [change the subject because of typo and it is not about the patch]
>
> On Sun, Jul 18, 2010 at 7:31 PM, Keith Whitwell wrote:
> > If we're reorganising these interfaces, there are a couple of things I'd
> > li
On Mon, 2010-07-26 at 21:36 -0700, Chia-I Wu wrote:
> This is the second try for unified draw_vbo call. I again upload the
> patches as a branch here
>
> http://cgit.freedesktop.org/~olv/mesa/log/?h=gallium-unified-draw-2
>
> due to the size.
>
> Changes since v1:
>
> - make index buffer a
On Wed, 2010-07-28 at 01:00 -0700, Jakob Bornecrantz wrote:
> On Tue, Jul 27, 2010 at 10:25 PM, Zack Rusin wrote:
> > On Tuesday 27 July 2010 23:57:17 Jakob Bornecrantz wrote:
> >> First off, the Core TGSI instruction set includes a lot of
> >> instructions that not necessary all hardware can hand
On Mon, 2010-07-26 at 16:50 -0700, Segovia, Benjamin wrote:
> Hello all,
>
> i965 has today an issue with fp compilation. There are two passes: one for
> branch-free programs and one for the others.
>
> For "branch porograms", the code is generated by a _direct_ translation of
> the mesa gpu p
On Tue, 2010-07-27 at 20:05 -0700, Chia-I Wu wrote:
> On Tue, Jul 27, 2010 at 11:46 PM, Keith Whitwell wrote:
> > On Mon, 2010-07-26 at 21:36 -0700, Chia-I Wu wrote:
> >> This is the second try for unified draw_vbo call. I again upload the
> >> patches as a b
On Wed, 2010-07-28 at 03:26 -0700, Marek Olšák wrote:
>
> PS3.0 doesn't have address regs, that means there are no ARL/ARR/ARA
> opcodes. Are you sure these must be mandatory? Please see:
> http://msdn.microsoft.com/en-us/library/bb172920%28VS.85%29.aspx
Agree, though they are present in the ver
On Sun, 2010-08-01 at 00:55 -0700, Chia-I Wu wrote:
> On Sat, Jul 31, 2010 at 7:10 AM, Zack Rusin wrote:
> > On Friday 30 July 2010 17:51:21 Jakob Bornecrantz wrote:
> >> On 30 jul 2010, at 14.02, Jakob Bornecrantz wrote:
> >> > On 30 jul 2010, at 13.32, Brian Paul wrote:
> >> >> On 07/30/2010 12:
On Mon, Aug 2, 2010 at 5:33 PM, Chia-I Wu wrote:
> Hi,
>
> While studying the draw module, I noticed that multiple primitive
> decomposers exist: draw_pt_vcache_tmp.h, draw_gs_tmp.h,
> draw_so_emit_tmp.h, and draw_pt_decompose.h. The differences between
> them are small, yet some of them support
On Mon, Aug 2, 2010 at 3:53 PM, Brian Paul wrote:
> On 08/01/2010 01:55 AM, Chia-I Wu wrote:
>>
>> On Sat, Jul 31, 2010 at 7:10 AM, Zack Rusin wrote:
>>>
>>> On Friday 30 July 2010 17:51:21 Jakob Bornecrantz wrote:
On 30 jul 2010, at 14.02, Jakob Bornecrantz wrote:
>
> On 30 jul
On Fri, 2010-08-06 at 08:29 -0700, Marek Olšák wrote:
> On Mon, Jul 26, 2010 at 8:11 PM, Brian Paul wrote:
>
> On 07/23/2010 03:27 PM, Roland Scheidegger wrote:
> On 22.07.2010 01:27, Brian Paul wrote:
> On 07/21/2010 05:19 PM, Marek Olšák w
On Sat, 2010-08-07 at 08:01 -0700, Christian Authmann wrote:
> Hi,
>
> it all started with a harmless looking bug report for r300g on phoronix:
>
> > http://img227.imageshack.us/img227/8582/bugx.png
> > http://www.phoronix.com/forums/showthread.php?t=24950&page=13
>
> as I noticed, that bug was
On Mon, 2010-08-09 at 23:48 -0700, Eric Anholt wrote:
> On Mon, 09 Aug 2010 19:05:52 -0700, Ian Romanick wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Tom Stellard wrote:
> > > On Fri, Aug 06, 2010 at 03:24:50PM -0700, Ian Romanick wrote:
> > >> -BEGIN PGP SIGNED MESSAG
On Wed, 2010-08-11 at 04:47 -0700, Luca Barbieri wrote:
> util_framebuffer_copy was attempting to copy all elements of the
> source framebuffer state.
>
> However, this breaks if the user does not zero initialize the structure.
> Instead, only copy the elements up to nr_cbufs, and clear elements u
On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote:
> One of the items on the TODO list is proper support for GLSL ES. That
> work won't happen until the last couple weeks of August, so I don't
> think any sort of ES testing is suitable merge criteria. Unless, of
> course, the tests in questi
My preference for these constant elements would be to actually turn them
into constants, ie. bind the buffer as a constant buffer (rather than a
vertex buffer) and have the shader refer to them as CONST[], rather than
INPUT[].
This is based on a few considerations, but primarily a recognition that
On Tue, 2010-08-10 at 12:43 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Keith Whitwell wrote:
> > On Mon, 2010-08-09 at 23:48 -0700, Eric Anholt wrote:
> >> The previous compiler called _mesa_remove_output_reads unconditionally,
On Wed, 2010-08-11 at 10:44 -0700, Marek Olšák wrote:
> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning
> that all shaders use the TGSI_TEXTURE_RECT sampler type, it makes
> sense to use unnormalized coordinates. However if a texture is NPOT as
> in OpenGL, meaning that all s
On Thu, 2010-08-12 at 06:08 -0700, Brian Paul wrote:
> On 08/11/2010 09:40 PM, Luca Barbieri wrote:
> > [Apparently bri...@kemper.freedesktop.org is forwarded to
> > brian.p...@tungstengraphics.com, which is no longer valid.]
> >
> > I'd suggest to put it in struct pipe_index_buffer.
> >
> > Th
On Thu, 2010-08-12 at 06:28 -0700, Brian Paul wrote:
> On 08/12/2010 07:16 AM, Keith Whitwell wrote:
> > On Thu, 2010-08-12 at 06:08 -0700, Brian Paul wrote:
> >> On 08/11/2010 09:40 PM, Luca Barbieri wrote:
> >>> [Apparently bri...@kemper.freedesktop.org
On Thu, 2010-08-12 at 10:09 -0700, Luca Barbieri wrote:
> This commit adds minimal x86-64 support: only movs between registers
> are supported for r8-r15, and x64_rexw() must be used to ask for 64-bit
> operations.
Hey Luca -- I have to ask how far you're thinking of going with rtasm on
x86-64...
Luca,
In this change you've got an int value (copy_size) which has some
special meaning when negative -- can you add comments explaining what
the meaning of a negative size is? Is there a way to use some more
explicit flag value to indicate this condition?
Keith
On Thu, 2010-08-12 at 10:08 -070
On Thu, 2010-08-12 at 10:22 -0700, Luca Barbieri wrote:
> translate_sse is currently very limited to the point of
> being useless in essentially all cases.
>
> In particular, it only support some float32 and unorm8
> formats and doesn't work on x86-64.
>
> This commit rewrites it to support:
> 1.
On Fri, 2010-08-13 at 04:46 -0700, Luca Barbieri wrote:
> > Is it possible to use an explicit flag for the (out_chans == 5) case?
>
> Gave it the name CHANNELS_0001 and added a comment.
>
> > Is it possible to do this without all the #ifdefs? Even if statements
> > based on a preprocessor variab
On Fri, 2010-08-13 at 06:47 -0700, Luca Barbieri wrote:
> This is a new version of just the rtasm/translate_sse patches.
>
> This version has the Win64 support built-in.
>
> In addition, it follows Keith's idea to use constants instead of #ifs.
>
> To achieve this, u_cpu_detect.h is enhanced
On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
> Hi,
>
> There are two primitive transformations in gallium draw module. In
> varray, primitives are "split"ted. When a primitive has more vertices
> than the middle end can handle, varray splits the primitive and calls
> the middle end multip
On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote:
> On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell wrote:
> > On Fri, 2010-08-13 at 07:04 -0700, Chia-I Wu wrote:
> >> Hi,
> >>
> >> There are two primitive transformations in gallium draw module. In
&g
On Fri, 2010-08-13 at 08:09 -0700, Chia-I Wu wrote:
> On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell wrote:
> > On Fri, 2010-08-13 at 07:46 -0700, Chia-I Wu wrote:
> >> On Fri, Aug 13, 2010 at 10:14 PM, Keith Whitwell wrote:
> >> > On Fri, 2010-08-13 at 07:04 -070
On Fri, Aug 13, 2010 at 5:25 PM, Chia-I Wu wrote:
> On Fri, Aug 13, 2010 at 11:35 PM, Keith Whitwell wrote:
>> On Fri, 2010-08-13 at 08:09 -0700, Chia-I Wu wrote:
>>> On Fri, Aug 13, 2010 at 10:51 PM, Keith Whitwell wrote:
>>> > On Fri, 2010-08-13 at 07:46 -0700,
201 - 248 of 248 matches
Mail list logo
