Am 02.08.2013 08:28, schrieb Zack Rusin:
clipping would drop the extra outputs because it always
used the number of standard vertex shader outputs, without
geometry shader or extra outputs. The commit makes sure
that clipping with geometry shaders which have more outputs
than the current
Am 02.08.2013 08:28, schrieb Zack Rusin:
Inject front face only if the fragment shader uses it and
propagate through all channels because otherwise we'll
need to figure out the exact swizzle that the fs expects and
it's just simpler to make sure all the components within
the front face
Am 02.08.2013 08:28, schrieb Zack Rusin:
we used to have a face primitive assembler that we ran after if
the gs was missing but we had adjacency primitives in the pipeline,
lets convert it to a pipeline stage, which allows us to use it
to inject outputs (primitive id) into the vertices. it's
Am 06.08.2013 08:56, schrieb Zack Rusin:
Nowadays -1 for slots means that the semantic is not present, so
we need to store it in a signed variables, otherwise 0 comparisons
are pointless. Fixes
http://bugzilla.eng.vmware.com/show_bug.cgi?id=67811 (at least
with softpipe, edgeflags don't work
Am 07.08.2013 00:35, schrieb Tom Stellard:
On Wed, Aug 07, 2013 at 12:05:25AM +0200, Laurent Carlier wrote:
Since llvm -3.4svn r187618, TargetOptions doesn't provide
anymore RealignStack, so only enable it with llvm3.4
Thanks, I've committed this patch.
To the llvmpipe developers: You
Am 08.08.2013 21:46, schrieb Zack Rusin:
We can't be injecting the primitive id's in the pipeline because
by that time the primitives have already been decomposed. To
properly number the primitives we need to handle the adjacency
primitives by hand. This patch moves the prim id injection into
Am 09.08.2013 00:40, schrieb Zack Rusin:
Series looks good though I'm unsure why the pipeline stage doesn't work.
Where does that decomposition happen? Is that something like GS
outputting multiple prims in the same topology which all need the same id?
No, it's because the pipeline stage
Am 09.08.2013 01:05, schrieb Dieter Nützel:
After git pull 8. Aug 19:18 compilation fails in
src/gallium/auxiliary/util/u_cpu_detect.c
gmake[3]: Entering directory `/opt/mesa/src/gallium/auxiliary'
CC util/u_cpu_detect.lo
util/u_cpu_detect.c: In function 'sse2_has_daz':
for d3d10/glsl but for hw as well.
Roland
Am 09.08.2013 20:40, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
The old float comparison opcodes always return floats 0.0 and 1.0 (clarified
in docs these were really floats, was always the case) for legacy graphics
PIPE_SHADER_CAP_ flag so the driver can tell
the state tracker which kind of comparison instructions it wants?
-Brian
On 08/09/2013 12:42 PM, Roland Scheidegger wrote:
This is a proposal for new comparison instructions, as the old ones
don't really fit modern (graphic or opencl I guess
Am 09.08.2013 21:00, schrieb Christoph Bumiller:
On 09.08.2013 20:42, Roland Scheidegger wrote:
This is a proposal for new comparison instructions, as the old ones
don't really fit modern (graphic or opencl I guess for that matter)
languages well.
If you've got objections, think the naming
Am 09.08.2013 21:31, schrieb Roland Scheidegger:
Am 09.08.2013 21:00, schrieb Christoph Bumiller:
On 09.08.2013 20:42, Roland Scheidegger wrote:
This is a proposal for new comparison instructions, as the old ones
don't really fit modern (graphic or opencl I guess for that matter)
languages
= unfilled_destroy;
+ unfilled-face_slot = -1;
+
if (!draw_alloc_temp_verts( unfilled-stage, 0 ))
goto fail;
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org
supporting integers), but if not glsl will probably break
quite badly I suppose.
Roland
Am 13.08.2013 19:04, schrieb srol...@vmware.com:
From: Roland Scheidegger srol...@vmware.com
Should get rid of some float-to-int conversions (with negation).
No piglit regressions (with llvmpipe
Am 13.08.2013 23:38, schrieb Brian Paul:
On 08/13/2013 11:04 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Should get rid of some float-to-int conversions (with negation).
No piglit regressions (with llvmpipe).
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp
Am 14.08.2013 07:40, schrieb Zack Rusin:
If the fragment shader is null then pixel shader invocations have
to be equal to zero. And if we're running a null ps then clipper
invocations and primitives should be equal to zero but only
if both stancil and depth testing are disabled.
Am 15.08.2013 00:54, schrieb Zack Rusin:
- lp_build_sample_compare(bld, newcoords[4], texel_out);
+ if (0)
+ lp_build_sample_compare(bld, newcoords[4], texel_out);
}
What does this do?
The rest looks good to me!
Reviewed-by: Zack Rusin za...@vmware.com
Yeah
Am 15.08.2013 10:16, schrieb Michel Dänzer:
On Mit, 2013-08-14 at 18:35 +0200, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
This makes things a bit nicer, and more importantly it fixes an issue
where a downgraded array texture (due to view reduced to 1 layer
Am 15.08.2013 19:12, schrieb Zack Rusin:
If clipdistance for one of the vertices is nan (or inf) then the
entire primitive should be discarded.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_cliptest_tmp.h |2 +-
src/gallium/auxiliary/draw/draw_llvm.c
Am 15.08.2013 20:27, schrieb Zack Rusin:
I realize this function isn't used but it looks unnecessarily
complicated - two constants one AND plus one comparison when you
could simply do a single comparison (compare x with x with
unordered not equal). This is actually doubly bad with AVX because
in the sample
build context, which would only leave the per-channel logic of doing
clamp/application of border color in fetch. Not sure though what's better.
Roland
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Turns out it is actually very complicated to figure
Am 21.08.2013 01:28, schrieb Roland Mainz:
On Wed, Aug 21, 2013 at 1:12 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The (complicated!) math is all identical, there's just minimal differences
how
sign bit is calculated plus there's an additional subtraction
Am 21.08.2013 02:05, schrieb Roland Mainz:
On Wed, Aug 21, 2013 at 1:45 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 21.08.2013 01:28, schrieb Roland Mainz:
On Wed, Aug 21, 2013 at 1:12 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
[snip]
Can you check
= 252,
+ PIPE_FORMAT_R10G10B10A2_UINT= 253,
PIPE_FORMAT_COUNT
};
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
Am 21.08.2013 18:30, schrieb Jose Fonseca:
Series looks good.
You might want to promote XXX to FIXME. Fixing wouldn't be hard --
just need to pass some additional parameters to this function, so
that we can check that MIN/MAG filter are same.
Ok I'll make it FIXME. I thought it would cause
Not that I'm qualified to review r600 code, but couldn't you create
different shader variants depending on whether you need alpha test? At
least I would assume shader exports aren't free.
Roland
Am 27.08.2013 19:56, schrieb Vadim Girlin:
We need to export at least one color if the shader writes
for any shader
without that property. I expect app developers to do the right thing
and not write outputs they don't need.
Marek
On Tue, Aug 27, 2013 at 9:00 PM, Roland Scheidegger
srol...@vmware.com wrote:
Not that I'm qualified to review r600 code, but couldn't you create
different shader
-sprite_coord_enable draw-pipeline.point_sprite)
return TRUE;
}
-
-
- if (triangles(prim))
- {
+ else if (reduced_prim == PIPE_PRIM_TRIANGLES) {
/* polygon stipple */
if (rasterizer-poly_stipple_enable draw-pipeline.pstipple)
return TRUE;
Reviewed-by: Roland
Hmm I don't think the math works out here actually, which may explain
why it's faster.
I believe the derivatives need to be transformed to cube coord system
and I don't see that being done here (this is actually something I
haven't figured out the math yet how to do with reasonable effort for
Wouldn't it be easier (and more efficient) if you could just reuse the
sampler code which does mipmap minification, i.e. get the texture sizes
from bld.int_size and do a lp_build_minify (followed by extract shuffles)?
Also, is it on purpose that the non-explicit lod path doesn't handle all
cases
Am 16.05.2012 09:50, schrieb Olivier Galibert:
On Wed, May 16, 2012 at 01:51:14AM +0200, Roland Scheidegger wrote:
Wouldn't it be easier (and more efficient) if you could just reuse the
sampler code which does mipmap minification, i.e. get the texture sizes
from bld.int_size and do
This looks good to me. Minor nitpicks below.
Am 17.05.2012 10:34, schrieb Olivier Galibert:
Piglits test for fragment shaders pass, vertex shaders fail. The
actual failure seems to be in the interpolators, and not the
textureSize query.
Signed-off-by: Olivier Galibert galib...@pobox.com
Am 17.05.2012 16:41, schrieb Olivier Galibert:
On Thu, May 17, 2012 at 04:34:31PM +0200, Roland Scheidegger wrote:
+ bld_int_vec.zero = lp_build_zero(gallivm, bld_int_vec.type);
+ bld_int_vec.one = lp_build_one (gallivm, bld_int_vec.type);
This is unnecessary. build_context_init
Still have a comment, but it's really trivial and either way it's fine so:
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 17.05.2012 16:48, schrieb Olivier Galibert:
Piglits test for fragment shaders pass, vertex shaders fail. The
actual failure seems to be in the interpolators
Am 18.05.2012 18:41, schrieb Patrick Baggett:
On Fri, May 18, 2012 at 11:28 AM, Brian Paul bri...@vmware.com
mailto:bri...@vmware.com wrote:
On 05/18/2012 10:11 AM, Jose Fonseca wrote:
- Original Message -
A while back I noticed that the piglit
Looks ok though I wonder if we really need our own assembly here?
In particular if the compiler decides to use sse we really shouldn't use
the fp stack for converting floats to ints. fistp is just twice as slow
as sse conversion on newer cpus, and additionally it might potentially
involve moving
Am 19.05.2012 00:35, schrieb Brian Paul:
On 05/18/2012 03:54 PM, Roland Scheidegger wrote:
Looks ok though I wonder if we really need our own assembly here?
In particular if the compiler decides to use sse we really shouldn't use
the fp stack for converting floats to ints. fistp is just twice
Am 18.05.2012 23:55, schrieb Kurt Roeckx:
On Fri, May 18, 2012 at 09:11:38AM -0700, Jose Fonseca wrote:
It sounds a sensible plan, but I wonder if the multiple iround
versions are really worth it: SSE2 is guaranteed in x64, so we
could just start requiring SSE2 on x86, and only use the C for
Am 19.05.2012 02:43, schrieb Kurt Roeckx:
On Sat, May 19, 2012 at 02:19:36AM +0200, Roland Scheidegger wrote:
Am 18.05.2012 23:55, schrieb Kurt Roeckx:
On Fri, May 18, 2012 at 09:11:38AM -0700, Jose Fonseca wrote:
It sounds a sensible plan, but I wonder if the multiple iround
versions
= util_format_description(key-cbuf_format[0]);
+
+ lp_build_alpha_test(gallivm, key-alpha.func, type,
cbuf_format_desc,
mask, alpha, alpha_ref_value,
(depth_mode LATE_DEPTH_TEST) != 0);
}
Reviewed-by: Roland
Am 22.05.2012 18:12, schrieb Christoph Bumiller:
On 05/22/2012 05:58 PM, Brian Paul wrote:
On 05/22/2012 08:37 AM, Christoph Bumiller wrote:
On 05/22/2012 04:23 PM, Brian Paul wrote:
On 05/21/2012 03:46 PM, Christoph Bumiller wrote:
---
src/gallium/include/state_tracker/st_api.h |
Am 07.06.2012 01:27, schrieb Paul Berry:
In my current implementation of MSAA for i965, I'm facing a choice in
how to perform MSAA resolves when sRGB is in use. Should I:
(a) always combine samples using a linear average. For example, if
multisampling by a factor of 4, and the 4 samples
Am 14.06.2012 15:07, schrieb Paul Berry:
On 14 June 2012 05:10, Jose Fonseca jfons...@vmware.com
mailto:jfons...@vmware.com wrote:
lp_build_utrunc() doesn't exists yet. For now, please use
lp_build_itrunc() and add a /* FIXME: implement and use
lp_build_utrunc() */ comment.
Am 14.06.2012 18:55, schrieb Paul Berry:
On 14 June 2012 09:02, Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com wrote:
Am 14.06.2012 15:07, schrieb Paul Berry:
On 14 June 2012 05:10, Jose Fonseca jfons...@vmware.com
mailto:jfons...@vmware.com
mailto:jfons
On 06/19/2012 08:01 PM, Olivier Galibert wrote:
This patch churns a lot because it needs to change 4-wide filters into
single pixel filters, since each fragment may use a different filter.
The only case not entirely supported is the anisotropic filtering.
Not sure what we want to do there,
On 06/20/2012 05:43 AM, Olivier Galibert wrote:
On Tue, Jun 19, 2012 at 02:46:35PM -0700, Jose Fonseca wrote:
Could you give more background on why is this necessary?
This will make software renderering slower, so I'd really like to avoid it on
llvmpipe if at all possible.
Well, given the
On 06/21/2012 08:30 AM, Olivier Galibert wrote:
On Wed, Jun 20, 2012 at 01:44:14PM +0100, Roland Scheidegger wrote:
A lot of code I just glossed over it, but seems to look ok other than
the (performance) implications this might have.
Actually whether there's a performance implication
Does this fix the test because lp_build_brilinear_lod produces bogus
values in this case or just because the test is strict about such
filtering optimizations? In the latter case I'm not sure I really see
much point.
I'm surprised it can actually pass in either case since we drop all but
the
Am 17.07.2012 16:02, schrieb Tom Stellard:
On Tue, Jul 17, 2012 at 09:26:49AM -0400, Kristian Høgsberg wrote:
On Tue, Jul 17, 2012 at 05:57:37AM -0700, Jose Fonseca wrote:
- Original Message -
FYI, I've just pushed a branch named llvmpipe-wider-regs, which
allows llvmpipe to leverage
Am 17.07.2012 23:49, schrieb Stéphane Marchesin:
On Mon, Jul 16, 2012 at 11:43 AM, Jose Fonseca jfons...@vmware.com wrote:
FYI, I've just pushed a branch named llvmpipe-wider-regs, which allows
llvmpipe to leverage SIMD registers wider than 128bits.
Unfortunately, performance-wise this
Am 18.07.2012 07:59, schrieb Olivier Galibert:
On Tue, Jul 17, 2012 at 03:41:44PM -0600, Brian Paul wrote:
On 07/13/2012 10:30 AM, Olivier Galibert wrote:
On Wed, Jun 20, 2012 at 08:33:38AM -0600, Brian Paul wrote:
Yeah, I think it's pretty clear that we need to support per-pixel LOD
Am 18.07.2012 07:11, schrieb Marek Olšák:
On Wed, Jul 18, 2012 at 1:58 AM, Roland Scheidegger srol...@vmware.com
wrote:
Am 17.07.2012 23:49, schrieb Stéphane Marchesin:
On Mon, Jul 16, 2012 at 11:43 AM, Jose Fonseca jfons...@vmware.com wrote:
FYI, I've just pushed a branch named llvmpipe
This patches are just some cleanups and fixes however only compile tested
(my r100 got broken and the r200 isn't in a useful box right now) so testers
would be great.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
There were several problems with these functions (which are a remnant
of dri1 hyperz mostly - should bring it back somehow someday).
First, it would always do a swrast clear if the buffer to clear was a fbo.
Second, for buffers we wouldn't handle the clear (I guess aux/accum?) we
would actually
Noone was interested in the number of cliprects, and noone cared
about the intersect result neither. So just nuke this.
---
src/mesa/drivers/dri/radeon/radeon_common.c| 56 +--
src/mesa/drivers/dri/radeon/radeon_common.h|1 -
Those functions are SO dead.
---
src/mesa/drivers/dri/r200/r200_ioctl.c | 26 --
src/mesa/drivers/dri/r200/r200_ioctl.h |6 --
2 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_ioctl.c
no point in emitting aux scissor values if we
a) never enable them
b) never set the actual values
plus it is enough to have that aux scissor enable reg (which we never set to
enable) in one place not two.
---
src/mesa/drivers/dri/r200/r200_context.h| 35 +++---
This addresses one issue raised in bug #51658 discovered by Eugene St Leger.
The assert is bogus since there's no problem with texture width/height being
2048 (the width/height programmed is width/height minus one).
OTOH though the programmed size for scissor rect should be width/height
minus one
Looks certainly good to me though maybe one of the intel guys should
take a look as they are the main user of this.
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 27.07.2012 16:26, schrieb Brian Paul:
Remove the check for pixel transfer ops. If any RGB/depth scale/bias
is in effect
Thanks for testing, I pushed those.
Roland
Am 30.07.2012 11:06, schrieb Barto:
I did the tests in piglit (glean tests ) with my radeon 9000 ( rv250 ),
all is Ok, I have the same results with Roland's patches and without
Roland's patches,
I see no regressions, these patches for the r200
I'm not convinced this is a good idea.
That dilutes the meaning of a box quite a bit (and I don't think x/y/z
can actually be negative?). There are presumably also quite a lot of
uses of pipe_box which might not be able to deal with such boxes.
Roland
Am 09.08.2012 18:07, schrieb Marek Olšák:
, Roland Scheidegger srol...@vmware.com
wrote:
I'm not convinced this is a good idea.
That dilutes the meaning of a box quite a bit (and I don't think x/y/z
can actually be negative?). There are presumably also quite a lot of
uses of pipe_box which might not be able to deal with such boxes
Am 10.08.2012 03:42, schrieb Ian Romanick:
On 08/08/2012 10:53 AM, Brian Paul wrote:
On 08/08/2012 11:38 AM, Ian Romanick wrote:
From: Ian Romanickian.d.roman...@intel.com
Signed-off-by: Ian Romanickian.d.roman...@intel.com
---
src/mesa/main/extensions.c | 24
Am 05.11.2012 18:45, schrieb Adhemerval Zanella:
Hi all,
This patch adds PPC Altivec support for pack/unpack operations using Altivec
supported vector type (8xi8, 16xi16, 4xi32, 4xf32). I focused my work on the
lp_test_conv testcase for llvmpipe and this patch corrects all the failing
Am 05.11.2012 19:06, schrieb Adhemerval Zanella:
This patch add correct vector addition and subtraction intrisics when
using Altivec with PPC. Current code uses default path and LLVM backend
ends up issuing carry-out arithmetic instruction while it is expected
saturated ones.
It also
I think that probably needs a test to make sure the right vertices are
used, I can't quite tell if it's right. This is hit when adjacent
primitives are used but not geometry shader is active right?
The rest of the series looks good to me.
Roland
Am 07.11.2012 16:26, schrieb jfons...@vmware.com:
Am 18.11.2012 09:19, schrieb Dave Airlie:
so I've been reading trying to figure out what msaa is and how it
works (I've read it about 30 times now and still have only a passing
idea!!)
So softipipe has some coverage info it stores per quad and passes in
as an input,
just wondering what
Am 22.11.2012 21:35, schrieb Adhemerval Zanella:
This patch adds two more functions in type conversions header:
* lp_build_bswap: construct a call to llvm.bswap intrinsic for an
element
* lp_build_bswap_vec: byte swap every element in a vector base on the
input and output types.
Am 22.11.2012 21:35, schrieb Adhemerval Zanella:
This patch fixes various format manipulation for big-endian
architectures. Basically it works on two fronts: 1) by adjusting
some algorithms that do shifts/mask on vector or integers and 2)
by correct loading floating-point in memory.
Also,
rounding
[PATCH 5/8] PowerPC: clear Altivec NJ bit
[PATCH 6/8] llvmpipe: Fix vector constant for shuffle
[PATCH 7/8] llvmpipe: Add byte-swap construct calls
[PATCH 8/8] llvmpipe: Fix format manipulation for big-endian
I made some separate comments, but this series is:
Reviewed-by: Roland
Am 22.11.2012 21:34, schrieb Adhemerval Zanella:
Mostly PowerPC system sets the Altivec NJ bit to 1 so denormal number
are handled as 0. Initially it was a performance configuration, since
denormal handling tended to be costly. However it is not the case on
more recent PowerPC chips (POWER6
Am 28.11.2012 13:47, schrieb Adhemerval Zanella:
On 11/22/2012 07:33 PM, Roland Scheidegger wrote:
Am 22.11.2012 21:34, schrieb Adhemerval Zanella:
Mostly PowerPC system sets the Altivec NJ bit to 1 so denormal number
are handled as 0. Initially it was a performance configuration, since
Am 28.11.2012 21:57, schrieb jfons...@vmware.com:
From: José Fonseca jfons...@vmware.com
It is buggy (it was giving wrong results for some of the formats with
padding), and util_format_description::is_array already does precisely
what's intended.
---
Am 28.11.2012 21:57, schrieb jfons...@vmware.com:
From: José Fonseca jfons...@vmware.com
Now dead code.
Also had to remove the show_tiles/show_subtiles because now the color
buffers are always stored in their native format, so there is no longer
an easy way to paint the tile sizes.
Am 29.11.2012 16:50, schrieb Jose Fonseca:
- Original Message -
On 11/29/2012 08:32 AM, jfons...@vmware.com wrote:
From: José Fonsecajfons...@vmware.com
The current implementation was close by not fully correct: several
operations that should be done in floating point were being
Am 30.11.2012 18:43, schrieb jfons...@vmware.com:
From: José Fonseca jfons...@vmware.com
Tell LLVM the exact alignment we can guarantee, based on the fs block
dimensions, pixel format, and the alignment of the resource base pointer
and stride.
---
, dst_type,
dst, src_count, dst);
+ convert_from_blend_type(gallivm, out_format_desc, row_type, dst_type,
dst, src_count);
/* Split the blend rows back to memory rows */
if (dst_count src_count) {
Reviewed-by: Roland Scheidegger srol...@vmware.com
Am 08.12.2012 07:02, schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
Noticed would fail, we were doing two things wrong
a) 1d arrays require the layers in height
b) minifying the layers field.
Signed-off-by: Dave Airlie airl...@redhat.com
---
Am 10.12.2012 21:22, schrieb Marek Olšák:
On Mon, Dec 10, 2012 at 5:28 PM, Brian Paul bri...@vmware.com wrote:
On 12/08/2012 07:40 AM, Marek Olšák wrote:
It doesn't work and it's not clear how it's supposed to work.
---
src/mesa/state_tracker/st_atom_rasterizer.c |3 +--
a bit unnecessary you
could simply do the minify just before the (if has_array) clause like it
was before (and inserting the array layers into size seems unnecessary
too could just use lp_build_broadcast_scalar directly) but either way
Reviewed-by: Roland Scheidegger srol...@vmware.com
thinking about implementing it for llvmpipe...
I didn't check the next face math, but
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
: Roland Scheidegger srol...@vmware.com
Since we don't call lp_build_sample_common() in the texel fetch path
we missed
the layer fixup code. If someone would have tried to do texelFetch
with array
textures it would have crashed for sure.
Not really tested (no overlap of texelFetch and array
?), but anyway this is just a
minor nitpick.
Reviewed-by: Roland Scheidegger srol...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Oops sorry that was totally the wrong commit message, ignore it...
Roland
On 01/10/2013 06:22 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
Change the texel type to int/uint instead of float throughout the sampling
code which makes it easier to catch errors
Oh pretty sure I wrote that bug ages ago :-).
I think you would hit it iff you'd use 12 generic vertex attributes in a
vertex program - I guess noone ever did on that hardware...
Reviewed-by: Roland Scheidegger srol...@vmware.com
On 01/11/2013 06:23 PM, Johannes Obermayr wrote:
From: Adam
On 01/14/2013 09:44 AM, Brian Paul wrote:
IIRC, we can have a mixture of color buffer formats when there's
multiple render targets. This change doesn't effect that, right?
Well it does - it should fix some edge cases there.
We actually did some changes to the color mask of the blend state
Am 16.01.2013 17:52, schrieb Milan Kostić:
No, no regress in piglit i've seen at all, only better... i even
played whole Drawn 2 game:
http://www.drawngame.com/games/dark-flight
under wine in OpenGL mode, it works perfectly now, needs culling under
fbo which is fixed now and this fix to
On 15.04.2010 19:07, Luca Barbieri wrote:
So, since one layout requires pot sizes, I guess the problem you have is
if a texture rectangle just happens to be POT you don't know that in the
driver upon texture creation time?
Yes, exactly.
It's quite common for hw to have different layouts
On 02.05.2010 13:08, José Fonseca wrote:
On Sun, 2010-05-02 at 02:36 -0700, Dave Airlie wrote:
On Sun, May 2, 2010 at 7:30 PM, Jose Fonseca jfons...@vmware.com
wrote:
I read the extension and it is not crystal clear, but it seems to
imply the swizzles are orthogonal to the format, and applied
On 04.05.2010 23:25, Marek Olšák wrote:
This fixes FDO bug #27343.
---
src/mesa/state_tracker/st_mesa_to_tgsi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index
On 14.05.2010 16:34, Roland Scheidegger wrote:
On 14.05.2010 14:10, Keith Whitwell wrote:
I'm considering modifying the gallium rasterizer state to remove most of
the cw/ccw flags and replace them with front/back or other concepts
closer to what GL is using.
This is primarily motivated
On 18.05.2010 22:23, Dave Airlie wrote:
On Wed, May 19, 2010 at 3:04 AM, Roland Scheidegger srol...@vmware.com
wrote:
Hi,
I plan to merge the gallium-msaa branch to master soon.
It's actually a bit of a misnomer since the conceptually more important
changes in there are about blits
On 21.05.2010 22:16, Brian Paul wrote:
Roland Scheidegger wrote:
On 11.05.2010 20:08, Kristian Høgsberg wrote:
2010/5/11 Brian Paul bri...@vmware.com:
Kristian Høgsberg wrote:
2010/5/6 Kristian Høgsberg k...@bitplanet.net:
Hi,
Ok, I suppose this is not the most pressing issue in mesa
On 02.06.2010 19:04, Marek Olšák wrote:
On Wed, Jun 2, 2010 at 3:02 PM, Roland Scheidegger srol...@vmware.com
mailto:srol...@vmware.com wrote:
Together with a PIPE_CAP_CLEAR_WITH_MASK_AND_SCISSOR.
That would be all interface changes needed (so mask and scissor would
On 03.06.2010 13:51, Nicolai Haehnle wrote:
On Thu, Jun 3, 2010 at 7:45 AM, Tom Stellard tstel...@gmail.com wrote:
On Wed, Jun 02, 2010 at 11:39:57AM +0200, Nicolai Haehnle wrote:
On Wed, Jun 2, 2010 at 6:53 AM, Tom Stellard tstel...@gmail.com wrote:
On Tue, Jun 01, 2010 at 12:00:16PM +0200,
or even mesa state tracker), but now would be a good time if
you have some comments for the proposed interface changes.
Roland
From 4a4d927609b62b4d7fb9dffa35158afe282f277b Mon Sep 17 00:00:00 2001
From: Roland Scheidegger srol...@vmware.com
Date: Thu, 3 Jun 2010 22:02:44 +0200
Subject: [PATCH] gallium
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
struct pipe_surface *ps = framebuffer-zsbuf;
is NULL or not before calling
On 07.06.2010 10:46, Dave Airlie wrote:
On Sun, Jun 6, 2010 at 8:55 PM, Dave Airlie airl...@gmail.com wrote:
On Sun, Jun 6, 2010 at 5:02 PM, Dave Airlie airl...@gmail.com wrote:
Since we ignore internal format TFP no longer works with the RGB case.
So when you said it needs a sane fix, you
On 07.06.2010 21:21, Marek Olšák wrote:
On Mon, Jun 7, 2010 at 8:53 PM, Corbin Simpson
mostawesomed...@gmail.com mailto:mostawesomed...@gmail.com wrote:
This is for vert feedback, not render-to-VBO, correct? Do we have a
list of HW that can do it? Is there a trivial way to emulate
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 more
interface changes, this time to support array textures basically.
Nothing has been adapted to these changes yet
201 - 300 of 2156 matches
Mail list logo
