On Tue, Aug 13, 2013 at 07:39:10PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> If the vertex shader exports clip distances but not point size, use
> position exports 1/2 instead of 2/3 for the clip distances. Fixes
> geometry corruption in that case.
>
> Bugzilla: https://bugs.freedesk
On Tue, Aug 13, 2013 at 07:04:56PM +0200, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> Also use ordered comparisons for old cmp instructions. Untested.
This patch looks good to me, but I would like to do a piglit run on
radeonsi before you commit. I will try to do this tomorrow.
-T
On Tue, Aug 13, 2013 at 05:53:52PM +0200, Maarten Lankhorst wrote:
> Fixes a build failure of 9.2 on ubuntu, because libLLVM-3.3.so is not present
> in /usr/lib/llvm-3.2/lib.
>
I'm trying to understand the problem here, could you give a little more
information about how Ubuntu packages LLVM? Whe
On Tue, Aug 13, 2013 at 06:25:28PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
An identical patch was sent to the list a few days ago, and I've just
pushed it now.
-Tom
> ---
> diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
> b/src/gallium/drivers/radeon/rade
On Sun, Aug 11, 2013 at 07:37:01PM +0200, Jon Severinsson wrote:
> This fixes a compilation warning with -Wformat-security.
>
> CC: "9.2"
Reviewed-by: Tom Stellard
I've pushed this patch, thanks.
-Tom
> ---
> src/gallium/drivers/radeon/radeon_llvm_emit.c |2 +-
> 1 fil ändrad, 1 tillägg
It's the same as in r600g.
I can't merge si_atom with si_pm4_state, because the latter is too big and
isn't even driven by the dirty flag. Also I'm gonna share the whole streamout
state handling with r600g (just one atom though) and therefore I need the same
interface. The advantage is that almost
On 08/12/2013 06:07 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
According to HSW Bspec L3$ evictions may land in LLC regardless of
LLC MOCS/PTE settings. That means we shouldn't set scanout buffers
as L3 cacheable when writing to them.
So far I've been unable to observe this p
On 08/13/2013 05:49 PM, Ian Romanick wrote:
On 08/13/2013 04:47 PM, Kenneth Graunke wrote:
Sandybridge is the only platform that supports an IF instruction
with an embedded comparison. In this case, we need to emit a CMP
to go along with the SEL.
Fixes regressions in Piglit's glsl-fs-atan-3, f
On 08/12/2013 06:07 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
IVB/BYT also has the same L3 cacheability control in MOCS as HSW,
so let's make use of it.
pts/xonotic and pts/reaction @ 1920x1080 gain ~4% on my IVB GT2. Most
other things show less gains/no regressions, except
On 08/13/2013 05:47 PM, Chad Versace wrote:
On 08/13/2013 05:45 PM, Ian Romanick wrote:
On 08/13/2013 03:37 PM, Kenneth Graunke wrote:
128 bpp formats are not allowed to be Y-tiled on any architectures
except Gen7.
+11 Piglits on Sandybridge (mostly regression fixes since the
switch to Y-tilin
On 08/13/2013 04:47 PM, Kenneth Graunke wrote:
Sandybridge is the only platform that supports an IF instruction
with an embedded comparison. In this case, we need to emit a CMP
to go along with the SEL.
Fixes regressions in Piglit's glsl-fs-atan-3, fs-unpackHalf2x16,
fs-faceforward-float-float-
On 08/13/2013 05:45 PM, Ian Romanick wrote:
On 08/13/2013 03:37 PM, Kenneth Graunke wrote:
128 bpp formats are not allowed to be Y-tiled on any architectures
except Gen7.
+11 Piglits on Sandybridge (mostly regression fixes since the
switch to Y-tiling).
Bugzilla: https://bugs.freedesktop.org/s
On 08/13/2013 03:31 PM, Vedran Rodic wrote:
On Mon, Aug 12, 2013 at 3:07 PM, wrote:
From: Ville Syrjälä
IVB/BYT also has the same L3 cacheability control in MOCS as HSW,
so let's make use of it.
According to the discussion we had on #intel-gfx a few weeks ago, on
IVB all Mesa memory is alr
On 08/13/2013 03:37 PM, Kenneth Graunke wrote:
128 bpp formats are not allowed to be Y-tiled on any architectures
except Gen7.
+11 Piglits on Sandybridge (mostly regression fixes since the
switch to Y-tiling).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63867
Also https://bugs.free
From: Ville Syrjälä
Just spotted these unpopulated MOCS fields when comparing the code
against BSpec. Set the MOCS to the same as everywhere else in Haswell:
L3-cacheable.
v2: Annotate state packet fields (chadv).
Signed-off-by: Ville Syrjälä
Reviewed-by: Chad Versace
---
Ville, I added comm
On 08/13/2013 03:50 PM, Matt Turner wrote:
On Tue, Aug 13, 2013 at 1:35 PM, Ian Romanick wrote:
and the spec doesn't explicitly forbid it.
I was surprised by this, so I verified it.
In the GLSL ES 3.0 spec:
single_declaration
fully_specified_type
type_specifier
precision_qualifier
From: Roland Scheidegger
We need to put border color into texture format color space which
essentially means clamping for non-float, normalized formats (not entirely
sure if we're also meant to quantize the float but it's probably ok not to
do it thankfully).
For OpenGL we could do this easily ou
Maybe it's time let S3TC go away and think about something else. Like
BPTC. I've started something. Currently, this is very dirty.
Please, take a quick look at this :
https://docs.google.com/file/d/0B1BiksMm0x0GVjZPZHgyNm0xLVE/edit?usp=sharing
Yeah, I know. Ugly. But it basically works. I can n
Sandybridge is the only platform that supports an IF instruction
with an embedded comparison. In this case, we need to emit a CMP
to go along with the SEL.
Fixes regressions in Piglit's glsl-fs-atan-3, fs-unpackHalf2x16,
fs-faceforward-float-float-float, isinf-and-isnan fs_basic, and
isinf-and-is
On Fri, Aug 9, 2013 at 4:38 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> We never noticed this before because we previously didn't enfoce GLSL ES
> fragement shader requirements that precision be defined. There may also
> have been some interaction here with the addition of
> GL_ARB_shading_
On Tue, Aug 13, 2013 at 1:35 PM, Ian Romanick wrote:
> and the spec doesn't explicitly forbid it.
I was surprised by this, so I verified it.
In the GLSL ES 3.0 spec:
single_declaration
fully_specified_type
type_specifier
precision_qualifier type_specifier_no_prec
precision_qualifier
t
128 bpp formats are not allowed to be Y-tiled on any architectures
except Gen7.
+11 Piglits on Sandybridge (mostly regression fixes since the
switch to Y-tiling).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63867
Cc: Topi Pohjolainen
Cc: Chad Versace
Cc: Paul Berry
Cc: "9.2"
Signed
On Mon, Aug 12, 2013 at 3:07 PM, wrote:
> From: Ville Syrjälä
>
> IVB/BYT also has the same L3 cacheability control in MOCS as HSW,
> so let's make use of it.
According to the discussion we had on #intel-gfx a few weeks ago, on
IVB all Mesa memory is already marked as cached in DRM allocated PT
Armin K wrote:
> Link to internal libwayland-drm library if Wayland
> EGL platform is enabled. The library needs to be
> built before gbm.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67962
In going through the wayland manual build directions[1] the other day, I
hit this bug when tr
On Mon, Aug 12, 2013 at 3:05 PM, Marek Olšák wrote:
> On Mon, Aug 12, 2013 at 11:36 PM, Stéphane Marchesin
> wrote:
>>> Other than hybrid systems (of which
>>> there are none with i915 graphics), is there any case where
>>> __DRI_IMAGE_USE_SHARE can occur?
>>
>> You could do interesting things li
I don't think this is our problem. If a distro wants S3TC support, its
maintainers can package libtxc_dxtn. Some distros really do it. If a
distro doesn't want S3TC support, there is nothing we can do about it.
Marek
On Tue, Aug 13, 2013 at 8:53 PM, Uwe Schmidt
wrote:
> Hi,
>
> I have read about
Am 13.08.2013 23:38, schrieb Brian Paul:
> On 08/13/2013 11:04 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> 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 | 45
>>
On 08/13/2013 11:04 AM, srol...@vmware.com wrote:
From: Roland Scheidegger
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 | 45 ++--
1 file changed, 15 insertions
Erm... I'm wondering... why does the S3TC issue come up every few
> months out of it's grave and haunt the list (and your nerves) ?
>
>
I think it is because the issue looks deceptively simple. Hardware is
hardware, right? ASICs do the decompression, not software. Surely blindly
copying bits from o
On 08/13/2013 12:04 PM, Vedran Rodic wrote:
On Tue, Aug 13, 2013 at 7:19 PM, Kenneth Graunke wrote:
As far as I know, --enable-glx-tls just makes things more efficient.
Nothing should *rely* on it, or even be able to detect it...
Dota 2 crashes without that option when loading the actual g
On 08/13/2013 01:42 PM, Roland Mainz wrote:
On Tue, Aug 13, 2013 at 10:33 PM, Ian Romanick wrote:
On 08/13/2013 01:27 PM, Roland Mainz wrote:
On Tue, Aug 13, 2013 at 10:20 PM, Ian Romanick
wrote:
On 08/13/2013 11:53 AM, Uwe Schmidt wrote:
[snip]
Until S3 grants it's IP to OIN or the patent
The series is
Reviewed-by: Chad Versace
Yet another instance of the reason to unify blorp with normal draw.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Aug 13, 2013 at 10:33 PM, Ian Romanick wrote:
> On 08/13/2013 01:27 PM, Roland Mainz wrote:
>> On Tue, Aug 13, 2013 at 10:20 PM, Ian Romanick
>> wrote:
>>> On 08/13/2013 11:53 AM, Uwe Schmidt wrote:
[snip]
>>> Until S3 grants it's IP to OIN or the patents expire, this is going to be
>>> t
On 08/13/2013 12:04 PM, Vedran Rodic wrote:
On Tue, Aug 13, 2013 at 7:19 PM, Kenneth Graunke wrote:
As far as I know, --enable-glx-tls just makes things more efficient.
Nothing should *rely* on it, or even be able to detect it...
Dota 2 crashes without that option when loading the actual g
From: Ian Romanick
Previously we would emit a warning for empty declarations like
float;
We would also emit the same warning for things like
highp float;
However, this second case is most likely the application trying to set
the default precision. This makes the compiler generate a stronger
On 08/13/2013 01:27 PM, Roland Mainz wrote:
On Tue, Aug 13, 2013 at 10:20 PM, Ian Romanick wrote:
On 08/13/2013 11:53 AM, Uwe Schmidt wrote:
[snip]
SO MY PROPOSAL:
If 'format' is one of the S3TC types, and format!=internalFormat is true,
then set internalFormat:=format.
'format' cannot be
On 08/13/2013 01:41 PM, Kevin H. Hobbs wrote:
>
> Ha! I can move the segfault all the way back to :
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe0ba6d43 in osmesa_st_framebuffer_flush_front
> (stctx=0x1518ee0, stfbi=0x1520560,
> statt=ST_ATTACHMENT_FRONT_LEFT) at osme
On Tue, Aug 13, 2013 at 10:20 PM, Ian Romanick wrote:
> On 08/13/2013 11:53 AM, Uwe Schmidt wrote:
[snip]
>> SO MY PROPOSAL:
>>
>> If 'format' is one of the S3TC types, and format!=internalFormat is true,
>> then set internalFormat:=format.
>
> 'format' cannot be a compressed type. Compressed dat
On 08/13/2013 07:49 AM, Siarhei Siamashka wrote:
On Thu, 08 Aug 2013 16:19:28 -0700
Ian Romanick wrote:
On 08/06/2013 02:13 PM, Siarhei Siamashka wrote:
Hello,
Some months ago, the commit "configure.ac: Allow OpenGL ES1 and ES2 only
with enabled OpenGL" dropped support for the OpenGL-free co
On 08/13/2013 11:53 AM, Uwe Schmidt wrote:
Hi,
I have read about the issue of implementing the S3TC Extension in Mesa:
http://dri.freedesktop.org/wiki/S3TC/
As I understood, the problem is, that encoding and decoding S3TC in
software is covered by patents, while passing S3TC compressed data to
I've been hanging on this list for a while, and this isn't the first time
this has been suggested. The general thing that is repeated is basically
this: if you make an API (e.g. OpenGL) that supports S3TC without a
license, you're in trouble, even if it is a passthrough to the hardware,
which also
We emit these before configuring depth in the normal path, or actually
using the depth buffer in BLORP - we just failed to emit them when
disabling depth altogether.
On Sandybridge, this also requires the post_sync_nonzero flush.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen6
We emit these before configuring depth in the normal path, or actually
using the depth buffer in BLORP - we just failed to emit them when
disabling depth altogether.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/
Hi,
I have read about the issue of implementing the S3TC Extension in Mesa:
http://dri.freedesktop.org/wiki/S3TC/
As I understood, the problem is, that encoding and decoding S3TC in
software is covered by patents, while passing S3TC compressed data to the
GPU is still ok.
AS NOW:
If "force_s3tc
On Tue, Aug 13, 2013 at 7:19 PM, Kenneth Graunke wrote:
>
>
> As far as I know, --enable-glx-tls just makes things more efficient.
>
> Nothing should *rely* on it, or even be able to detect it...
Dota 2 crashes without that option when loading the actual game map. I
assumed it adds thread safety.
On 13.08.2013 19:04, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> untested.
Looks like it should work though, thanks.
nv50 only supported u32 result all along and on nvc0 both cases are
already handled by the rest of the code, too.
> ---
> .../drivers/nv50/codegen/nv50_ir_from_tgsi.
On 08/09/2013 04:38 PM, Ian Romanick wrote:
From: Ian Romanick
Previously we would emit a warning for empty declarations like
float;
We would also emit the same warning for things like
highp float;
However, this second case is most likely the application trying to set the
default precision.
On 08/13/2013 11:45 AM, Kevin H. Hobbs wrote:
> On 08/13/2013 09:50 AM, Brian Paul wrote:
>> On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
>>>
>>> --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV)
>>> - exiting
>>>
>> Well, that's not too helpful.
>
Ha! I can move the se
From: Michel Dänzer
If the vertex shader exports clip distances but not point size, use
position exports 1/2 instead of 2/3 for the clip distances. Fixes
geometry corruption in that case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66974
Cc: mesa-sta...@lists.freedesktop.org
Signed-o
From: Michel Dänzer
E.g. the Source engine seems to always write to gl_ClipVertex, but normally
doesn't enable any GL_CLIP_DISTANCEn states. This change removes some
irrelevant parts from the generated vertex shader code in such cases.
Signed-off-by: Michel Dänzer
---
v2: Adapt for the possibi
On 08/09/2013 10:27 AM, Paul Berry wrote:
In commit 8fc41df (glsl: Modify ir_set_program_inouts to handle
geometry shaders), when attempting to pattern match the "foo" part of
expressions such as:
foo[i][j]
foo[i]
I incorrectly called as_dereference_variable() on the subexpression
foo[i
On 08/09/2013 12:26 AM, Vedran Rodic wrote:
Hi,
I've been burned with the issue of GLX TLS not being enabled by
default in Mesa (Dota 2 seems to rely on it).
What's the rationale of not enabling it by default?
Thanks,
Vedran Rodic
As far as I know, --enable-glx-tls just makes things more ef
On 08/09/2013 12:33 AM, Eric Anholt wrote:
Mark Mueller writes:
On Thu, Aug 8, 2013 at 2:19 PM, Eric Anholt wrote:
Mark Mueller writes:
Signed-off-by: Mark Mueller
---
src/mesa/drivers/dri/i965/brw_draw.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --
I tested this for llvmpipe, but it would be good if the respective
driver authors could verify it works for their drivers, I have no idea
if I got it right there, just guessed how it might work based mostly on
how other comparison instructions are handled (and I hope I caught all
drivers, those sup
From: Roland Scheidegger
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 | 45 ++--
1 file changed, 15 insertions(+), 30 deletions(-)
diff --git a/src/mesa/state_trac
From: Roland Scheidegger
untested.
---
.../drivers/nv50/codegen/nv50_ir_from_tgsi.cpp | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/gallium/drivers/nv50/codegen/nv50_ir_from_tgsi.cpp
b/src/gallium/drivers/nv50/codegen/nv50_ir_from_tgsi.cpp
index 56eccac..a2ad9
From: Roland Scheidegger
Also use ordered comparisons for old cmp instructions. Untested.
---
src/gallium/drivers/r600/r600_shader.c | 18 ---
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 49
2 files changed, 48 insertions(+), 19 deletions(-)
dif
From: Roland Scheidegger
untested.
---
src/gallium/drivers/ilo/shader/toy_tgsi.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/ilo/shader/toy_tgsi.c
b/src/gallium/drivers/ilo/shader/toy_tgsi.c
index d5a3f2f..830aa57 100644
--- a/
On 08/13/2013 08:53 AM, Chad Versace wrote:
Move the arrays to the new header brw_multisample_state.h, which will be
shared with Broadwell code.
CC: Paul Berry
Signed-off-by: Chad Versace
Hmm. Looks like I botched my patches in a rebase, but I'm pretty sure
my new plan was to just put the
Signed-off-by: Maarten Lankhorst
---
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index 1a4d4fd..2dd7bf7 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -124,7 +124,7 @@
On 08/12/2013 03:15 PM, Stéphane Marchesin wrote:
On Mon, Aug 12, 2013 at 3:05 PM, Marek Olšák wrote:
On Mon, Aug 12, 2013 at 11:36 PM, Stéphane Marchesin
wrote:
Other than hybrid systems (of which
there are none with i915 graphics), is there any case where
__DRI_IMAGE_USE_SHARE can occur?
Fixes a build failure of 9.2 on ubuntu, because libLLVM-3.3.so is not present
in /usr/lib/llvm-3.2/lib.
Signed-off-by: Maarten Lankhorst
---
diff --git a/configure.ac b/configure.ac
index 35f6797..579d8d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1870,7 +1870,18 @@ if test "x$MESA_LLVM" !
Move the arrays to the new header brw_multisample_state.h, which will be
shared with Broadwell code.
CC: Paul Berry
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_multisample_state.h | 72 ++
src/mesa/drivers/dri/i965/gen6_multisample_state.c | 47 +--
Place each array in the brw namespace by renaming it:
sample_positions_4x -> brw_multisample_positions_4x
sample_positions_8x -> brw_multisample_positions_8x
This prepares for moving the arrays to a header shared by gen6 and gen8.
CC: Paul Berry
Signed-off-by: Chad Versace
---
src/mesa
From: Kenneth Graunke
We will reuse this for Broadwell.
v2: Prefix function name with 'gen7'. (chadv)
Reviewed-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_state.h | 4
src/mesa/drivers/dri/i965/gen7_sol_state.c | 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
dif
From: Kenneth Graunke
We will reuse these for Broadwell.
Reviewed-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_context.h | 5 +
src/mesa/drivers/dri/i965/brw_draw_upload.c | 16 +---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri
Here are some small refactors for Broadwell. I'd like to see them merged
upstream now to ease the maintenance of internal trees. There's nothing
exciting here, so I request your rubberstamp.
Chad Versace (2):
i965: Refactor names of sample_positions_8/4x arrays
i965: Move arrays brw_multisampl
On 08/13/2013 09:50 AM, Brian Paul wrote:
> On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
>>
>> --30166-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
>> exiting
>>
> Well, that's not too helpful.
I think it may have been helpful.
Before Valgrind crashed it mentions that
On Mon, 12 Aug 2013 14:09:39 -0700
Chad Versace wrote:
> On 08/06/2013 09:44 PM, Siarhei Siamashka wrote:
> > On Tue, 6 Aug 2013 15:54:57 -0700
> > Matt Turner wrote:
> >
> >> On Tue, Aug 6, 2013 at 2:13 PM, Siarhei Siamashka
> >> wrote:
>
> >>> But if upstream Mesa treats this configuration a
On Thu, 08 Aug 2013 16:19:28 -0700
Ian Romanick wrote:
> On 08/06/2013 02:13 PM, Siarhei Siamashka wrote:
> > Hello,
> >
> > Some months ago, the commit "configure.ac: Allow OpenGL ES1 and ES2 only
> > with enabled OpenGL" dropped support for the OpenGL-free configuration.
> >
> >
> > http:
I've finished running comparison tests on Cayman/Pitcairn. The
descriptors series and 8/16-bit load/store support series both look
like they're in good condition for the cards I was able to test: Cedar
(5400), A6-3500 Llano and Pitcairn (7850). No regressions spotted,
just improvements.
And as y
On 08/12/2013 11:30 AM, Kevin H. Hobbs wrote:
On 08/12/2013 10:29 AM, Brian Paul wrote:
Can you run with valgrind? That should give us some useful info if
there's a use-after-free.
Sure,
$ valgrind /home/kevin/kitware/VTK_OSMesa_Build/bin/vtkpython
"--enable-bt"
"/home/kevin/kitware/VTK_OSMe
On 08/12/2013 06:14 PM, Dave Airlie wrote:
From: Dave Airlie
This was broken when arrayid was added.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_build.c | 2 +-
src/gallium/renderer/virgl_hw.h | 39 +
2 files changed, 40 insertio
Am 09.08.2013 16:13, schrieb Zack Rusin:
> Calling the prepare outputs cleans up the slot assignments
> for outputs, unfortunately aapoint and aaline didn't have
> code to reset their slots after the initial setup, this
> was messing up our slot assignments. The unfilled stage
> was just missing th
On Mon, 2013-08-12 at 12:53 -0700, Tom Stellard wrote:
> Hi,
>
> The attached patches make the v1i32 type which was used for sample
> coordinates and the v16i8 type which was used for resource descriptors
> illegal. There is a new pass which will convert v1i32 to i32 and v16i8
> to i128 for all n
On Mon, Aug 12, 2013 at 10:09 PM, Chad Versace
wrote:
> On 08/06/2013 09:44 PM, Siarhei Siamashka wrote:
>>
>> On Tue, 6 Aug 2013 15:54:57 -0700
>> Matt Turner wrote:
>>
>>> On Tue, Aug 6, 2013 at 2:13 PM, Siarhei Siamashka
>>> wrote:
>
>
But if upstream Mesa treats this configuration as un
76 matches
Mail list logo
