This is the same change as the previous commit to the FS. A very few VSes
are regressed by 1 or 2 instructions, which look recoverable with a bit
more dead code elimination.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 11 ++--
src/mesa/drivers/dri/i965/brw_vec4.h | 4 +
Previously, we would sometimes not consider a write to a register to
extend the end of the interval, nor would we consider a read before a
write to extend the start. This made for a bunch of complicated logic
related to how to treat the results when dead code might be present.
Instead, just extend
Matt Turner writes:
> ---
> Does this squashed in seem okay, Eric?
Yeah, though it seems like there could be a bit more ir_validation that
things stay the way we think -- that bfm's on scalars making a scalar,
and bfi's operands[0] is scalar.
pgpIR7hwIhr2b.pgp
Description: PGP signature
_
On Sat, Apr 27, 2013 at 10:33:29AM +0200, Mathias Fröhlich wrote:
>
> Hi,
>
> On Thursday, April 25, 2013 10:29:27 Jose Fonseca wrote:
> > - There are a bunch of options that need to be set via globals, (see
> > lp_set_target_options), so app/drivers could tamper with each other
> > options.
> >
Mesa 9.1.2 has been released. Mesa 9.1.2 is a bug fix release which
fixes bugs found since the 9.1.1 release.
The tag in the GIT repository for Mesa 9.1.2 is 'mesa-9.1.2'.
Mesa 9.1.1 is available for download at
ftp://freedesktop.org/pub/mesa/9.1.2/
md5sums:
df2aab86ff4a510ce5b0d074caa0a59f
---
Does this squashed in seem okay, Eric?
src/glsl/lower_instructions.cpp | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
index 6c70a4a..d32ec80 100644
--- a/src/glsl/lower_instructions.cpp
+++ b/src/gls
https://bugs.freedesktop.org/show_bug.cgi?id=64091
--- Comment #7 from Alex Deucher ---
(In reply to comment #6)
> Gallium is big endian safe at the moment. See these discussion threads for
> what needs to be done:
> http://lists.freedesktop.org/archives/mesa-dev/2013-January/033590.html
> http:
https://bugs.freedesktop.org/show_bug.cgi?id=64091
--- Comment #6 from Alex Deucher ---
Gallium is big endian safe at the moment. See these discussion threads for
what needs to be done:
http://lists.freedesktop.org/archives/mesa-dev/2013-January/033590.html
http://lists.freedesktop.org/archives/
https://bugs.freedesktop.org/show_bug.cgi?id=64091
--- Comment #5 from Jerome Glisse ---
For radeon my guess is that depth/stencil readback needs some fiddling with
texture format :
mesa/src/gallium/drivers/r600/r600_blit.c
r600_blit_decompress_depth()
surf_tmpl.format = flushed_depth_texture-
This is already set by intel_new_renderbuffer().
---
src/mesa/drivers/dri/intel/intel_fbo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index f037445..45424a9 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
Everyone was doing effectively the same thing, except for some funky code
reuse in Intel, and swrast mistakenly recomputing _BaseFormat instead of
using the texture's _BaseFormat. swrast's sRGB handling is left in place,
though it should be done by using _mesa_get_render_format() at render time
in
Every driver did the same thing.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 17 +--
src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 10 ---
src/mesa/drivers/dri/radeon/radeon_fbo.c | 14 -
src/mesa/main/fbobject.c | 48 ++
src/
We're looking for the logical width of our level, which is what
image->Width2/Height2 is. The previous code relied on MSAA textures being
only level 0.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dr
There was some comment about trying to avoid marking resolves in
updownsample, but if the downsample is never actually rendered to, then
the required resolve tracked in the downsample will never be executed, so
who cares?
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 12 +---
src/me
Now that depth resolves are handled there, we don't need to make the
temporary renderbuffer.
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 84 ++--
src/mesa/drivers/dri/intel/intel_fbo.c | 30 --
src/mesa/drivers/dri/intel/intel_fbo.h | 4 --
3 fil
MSVC doesn't like pointer arithmetic with void * so use GLubyte *.
---
src/mesa/swrast/s_texfetch_tmp.h |8
src/mesa/swrast/s_texfilter.c|2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/swrast/s_texfetch_tmp.h b/src/mesa/swrast/s_texfetch_tmp.h
in
https://bugs.freedesktop.org/show_bug.cgi?id=64091
Brian King changed:
What|Removed |Added
CC||brk...@linux.vnet.ibm.com
--
You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=64091
--- Comment #4 from Kleber Sacilotto de Souza ---
Created attachment 78664
--> https://bugs.freedesktop.org/attachment.cgi?id=78664&action=edit
readPixSanity output using software rasterizer
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=64091
--- Comment #3 from Kleber Sacilotto de Souza ---
Created attachment 78663
--> https://bugs.freedesktop.org/attachment.cgi?id=78663&action=edit
glxinfo using software rasterizer
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=64091
--- Comment #2 from Kleber Sacilotto de Souza ---
Created attachment 78662
--> https://bugs.freedesktop.org/attachment.cgi?id=78662&action=edit
readPixSanity output using the radeon driver
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=64091
--- Comment #1 from Kleber Sacilotto de Souza ---
Created attachment 78661
--> https://bugs.freedesktop.org/attachment.cgi?id=78661&action=edit
glxinfo using the radeon driver
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=64091
Priority: medium
Bug ID: 64091
Assignee: mesa-dev@lists.freedesktop.org
Summary: piglit glean/readPixSanity testcase fails on ppc64
with Radeon adapter
Severity: normal
C
On 04/29/2013 04:08 AM, Topi Pohjolainen wrote:
As specified in:
http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
Checking for the valid fourcc values is left for drivers avoiding
dependency to drm header files here.
v2:
- enforce EGL_NO_CONTEXT
Signed-o
On 04/29/2013 04:08 AM, Topi Pohjolainen wrote:
Signed-off-by: Topi Pohjolainen
---
include/GL/internal/dri_interface.h| 23 +++
src/egl/drivers/dri2/egl_dri2.c| 1 +
src/mesa/drivers/dri/intel/intel_regions.h | 7 +++
src/mesa/drivers/dri/intel
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 5a7eab6..bcd282e 100644
--- a/
On Tue, Apr 30, 2013 at 10:04 AM, Ian Romanick wrote:
> On 04/27/2013 04:37 PM, Jordan Justen wrote:
>>
>> Signed-off-by: Jordan Justen
>> ---
>> src/mapi/glapi/gen/GL3x.xml |2 +-
>> src/mesa/main/fbobject.c| 17 +
>> src/mesa/main/fbobject.h|4
>> 3 f
On 04/30/2013 01:52 AM, Kenneth Graunke wrote:
Consider the following shader:
vec4 f(vec4 v) { return v; }
vec4 f(vec4 v);
The prototype exactly matches the signature of the earlier definition,
so there's absolutely no point in it. However, it doesn't appear to
be illegal. The GLSL
On 04/27/2013 04:37 PM, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
src/mapi/glapi/gen/GL3x.xml |2 +-
src/mesa/main/fbobject.c| 17 +
src/mesa/main/fbobject.h|4
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/mapi/glapi/g
On Tue, Apr 30, 2013 at 9:57 AM, Ian Romanick wrote:
> On 04/27/2013 04:32 PM, Jordan Justen wrote:
>>
>> This GLSL extension requires that AMD_vertex_shader_layer be
>> enabled by the driver.
>
> Most (all?) extensions also add a preprocessor define. Can you poke at
> AMD's driver to see if GL_A
On 04/27/2013 04:32 PM, Jordan Justen wrote:
This GLSL extension requires that AMD_vertex_shader_layer be
enabled by the driver.
Most (all?) extensions also add a preprocessor define. Can you poke at
AMD's driver to see if GL_AMD_vertex_shader_layer is defined? If so,
then we need to add it
Reviewed-by: Jordan Justen
On Tue, Apr 30, 2013 at 1:52 AM, Kenneth Graunke wrote:
> Consider the following shader:
>
> vec4 f(vec4 v) { return v; }
> vec4 f(vec4 v);
>
> The prototype exactly matches the signature of the earlier definition,
> so there's absolutely no point in it. Howev
On 04/30/2013 01:52 AM, Kenneth Graunke wrote:
Consider the following shader:
vec4 f(vec4 v) { return v; }
vec4 f(vec4 v);
The prototype exactly matches the signature of the earlier definition,
so there's absolutely no point in it. However, it doesn't appear to
be illegal. The GLSL
On 04/20/2013 10:26 PM, Piyush Tiwari wrote:
Hello,
I am really interested in doing the GSOC 2013 project "Find common
patterns in real GLSL shaders".
Implementation:
Algorithm:- Max-miner algorithm as it uses the same data structure as
Apriori i.e. hash tree.
I've only skimmed the Bayardo pa
From: Christian König
Add an extra parameter to specify if we should clear the render target.
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_compositor.c|7 ---
src/gallium/auxiliary/vl/vl_compositor.h|3 ++-
src/gallium/state_trackers/vdpau/device.c
From: Christian König
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_compositor.c| 12 ++--
src/gallium/auxiliary/vl/vl_video_buffer.c | 23 ---
src/gallium/auxiliary/vl/vl_video_buffer.h |7 ---
src/gallium/drivers/r600/r600_uvd.c
From: Christian König
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/mixer.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/mixer.c
b/src/gallium/state_trackers/vdpau/mixer.c
index 1d2ae49..26db5c
On 04/19/2013 06:04 AM, pkucoin wrote:
Hi,
My name is Sida Li and I am a senior student from Peking University in
China. I am interested in the idea that
improved application of GLSL complier optimizations.
I have downloaded the source code and read some parts of the it. First
let me talk about m
On 04/18/2013 12:38 AM, Andreas Boll wrote:
This list appears in the fixed bugs section of the release notes.
v2: Add usage examples
NOTE: This is a candidate for the stable branches.
The series is
Reviewed-by: Ian Romanick
---
bin/bugzilla_mesa.sh | 52 +++
On 04/24/2013 04:30 PM, Fabian Bieler wrote:
Do not propagate a copy if source and destination are identical.
Otherwise code like
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].xyzw
is changed to
MOV TEMP[0].xyzw, TEMP[0].wzyx
MOV TEMP[1].xyzw, TEMP[0].wzyx
This fixes Piglit test s
About half of this is shareable with the VS code.
---
.../drivers/dri/i965/brw_schedule_instructions.cpp | 124
1 file changed, 75 insertions(+), 49 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_schedule_in
While this is ignorant of dependency control, it's still good for a 0.39%
+/- 0.08% performance improvement on GLBenchmark 2.7 (n=548)
v2: Rewrite as a subclass of the base class for the FS instruction
scheduler, inheriting the same latency information.
---
.../drivers/dri/i965/brw_schedule_i
These will get virtualized as we add VS scheduling support.
---
.../drivers/dri/i965/brw_schedule_instructions.cpp | 132
1 file changed, 77 insertions(+), 55 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_s
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 15 +++
src/mesa/drivers/dri/i965/brw_fs.h |3 +--
src/mesa/drivers/dri/i965/brw_shader.cpp | 11 +++
src/mesa/drivers/dri/i965/brw_shader.h |3 +++
src/mesa/drivers/dri/i965/brw_vec4.cpp | 15 +++---
I need this so I can look at vec4 and fs registers' files from the same
.cpp file without namespaces. As far as I can tell we never rely on the
particular numerical values of the files, though I thought it sounded like
a good idea when doing the VS (it turns out having 0 be BAD_FILE is nicer).
---
This will free instruction scheduling to make better choices. No
statistically significant performance difference on GLB2.7 (n=93).
---
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp |4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cp
> > What is "IA"?
>
> "Input Assembly", a D3D10 term that roughly matches pipe_vertex_elements /
> pipe_vertex_buffer state.
>
> BTW, I think that Chris Forbes makes a good point -- a GS might choose to
> not emit any vertices (e.g., that does fancy culling) -- so maybe this
> debugging message
On 04/30/2013 09:03 AM, Jose Fonseca wrote:
- Original Message -
On Mon, Apr 29, 2013 at 2:52 PM, Dave Airlie wrote:
I've been playing with a gallium driver, and started looking at some
wierd gears behaviour,
The vbo code maps the buffer with GL_MAP_FLUSH_EXPLICIT_BIT which to
me requ
- Original Message -
> On Mon, Apr 29, 2013 at 2:52 PM, Dave Airlie wrote:
> > I've been playing with a gallium driver, and started looking at some
> > wierd gears behaviour,
> >
> > The vbo code maps the buffer with GL_MAP_FLUSH_EXPLICIT_BIT which to
> > me requires that at some point
> >
On 04/22/2013 10:14 AM, Eric Anholt wrote:
34 files changed, 311 insertions(+), 889 deletions(-)
Also, swrast_dri.so now passes two FXT1 tests that failed before, and
i915's vertex shader texturing works. I haven't tested the radeon/nouveau
code, nor have I been as invasive as I could be, bec
On 04/22/2013 10:14 AM, Eric Anholt wrote:
Now that everything goes through ImageSlices[], we can rely on the
driver's existing texture mapping function.
A big block of code goes away on Radeon that looks like it was to deal with
the validate that happened at SpanRenderStart, which no longer occ
On 04/22/2013 10:14 AM, Eric Anholt wrote:
This is a step toward allowing drivers to use their normal mapping paths,
instead of requiring that all slice mappings come from an aligned offset
from the first slice's map.
This incidentally fixes missing slice handling in FXT1 swrast.
---
src/mesa/
On 04/22/2013 10:14 AM, Eric Anholt wrote:
---
src/mesa/swrast/s_texture.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
index 36a90dd..b6dd8cb 100644
--- a/src/mesa/swrast/s_texture.c
+++ b/src
On 04/22/2013 10:14 AM, Eric Anholt wrote:
This function going to get used a lot more in upcoming patches.
---
src/mesa/swrast/s_texture.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/mesa/swrast/s_texture.c b/src/mesa/swrast/s_texture.c
index 510
This is a port of "r600g:mask unused source components for SAMPLE"
patch from Vadim Girlin.
---
src/gallium/drivers/r600/r600_llvm.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_l
- Original Message -
> On 04/27/2013 06:57 AM, Zack Rusin wrote:
> > Technically it's legal for geometry shader to not emit any
> > vertices. It's silly, but perfectly legal, so lets make draw
> > stop crashing if it happens.
> >
> > Signed-off-by: Zack Rusin
> > ---
> > src/gallium/aux
On Tue, Apr 30, 2013 at 9:40 AM, Brian Paul wrote:
> On 04/27/2013 06:57 AM, Zack Rusin wrote:
>>
>> Technically it's legal for geometry shader to not emit any
>> vertices. It's silly, but perfectly legal, so lets make draw
>> stop crashing if it happens.
>>
>> Signed-off-by: Zack Rusin
>> ---
>>
Dear Mr Ian Romanick,
I am a third year undergraduate from National University of Singapore,
School of Computing. I am interested in this year Google Summer Program. As
this is my first time applying and also my first time seeing most of the
accepted organisations for this year program. After much
On 04/27/2013 06:57 AM, Zack Rusin wrote:
Technically it's legal for geometry shader to not emit any
vertices. It's silly, but perfectly legal, so lets make draw
stop crashing if it happens.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline.c |9
https://bugs.freedesktop.org/show_bug.cgi?id=64084
Priority: medium
Bug ID: 64084
Assignee: mesa-dev@lists.freedesktop.org
Summary: Requesting git commit access to mesa
Severity: normal
Classification: Unclassified
OS: All
On 04/30/2013 11:52 AM, Kenneth Graunke wrote:
Consider the following shader:
vec4 f(vec4 v) { return v; }
vec4 f(vec4 v);
The prototype exactly matches the signature of the earlier definition,
so there's absolutely no point in it. However, it doesn't appear to
be illegal. The GLSL
Consider the following shader:
vec4 f(vec4 v) { return v; }
vec4 f(vec4 v);
The prototype exactly matches the signature of the earlier definition,
so there's absolutely no point in it. However, it doesn't appear to
be illegal. The GLSL 4.30 specification offers two relevant quotes:
"If
On 04/29/2013 07:15 PM, Kristian Høgsberg wrote:
On Tue, Apr 23, 2013 at 9:54 AM, Ander Conselvan de Oliveira
wrote:
Linux kernel 3.8 shipped with a bug in the prime fd passing code that
makes it unreliable. As of this writing, it seems unlikely that 3.9
will contain the fix for the issue.
Thi
v2:
- upon success close the given file descriptors
Signed-off-by: Topi Pohjolainen
---
src/egl/drivers/dri2/egl_dri2.c | 276
1 file changed, 276 insertions(+)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 10fdc
63 matches
Mail list logo
