Hi Brian,
On 3/14/13, Brian Paul bri...@vmware.com wrote:
On 03/13/2013 04:11 AM, jupiter wrote:
Hi Brian,
Sorry for not being clear, let me clarify it.
On 3/13/13, Brian Paulbri...@vmware.com wrote:
Well, the Xlib/swrast driver does everything in software, unlike a DRI
driver which does
On 03/14/2013 04:37 AM, jupiter wrote:
Hi Brian,
On 3/14/13, Brian Paulbri...@vmware.com wrote:
On 03/13/2013 04:11 AM, jupiter wrote:
Hi Brian,
Sorry for not being clear, let me clarify it.
On 3/13/13, Brian Paulbri...@vmware.com wrote:
Well, the Xlib/swrast driver does everything in
There were two different NUM_ENTRIES #defines for the framebuffer
tile cache and the texture tile cache. Rename the later to fix
the warnings:
In file included from sp_flush.c:40:0:
sp_tex_tile_cache.h:76:0: warning: NUM_ENTRIES redefined
sp_tile_cache.h:78:0: note: this is the location of the
Move the options into the proper section (Debug, Quality, Performance,
etc).
Update comments and add some whitespace to improve readability.
---
src/mesa/drivers/dri/common/xmlpool/t_options.h | 134 +--
1 files changed, 74 insertions(+), 60 deletions(-)
diff --git
This option is needed for some applications that neglect to request
a depth buffer when choosing a visual/fbconfig.
The Linux app Topogun is an example of this problem.
---
src/mesa/drivers/dri/common/xmlpool/t_options.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
This involved adding another driOptionCache to dri_screen. The
existing one just held the default values. But now we also need
to have the values from the DRI config file so that we can get at
the always_have_depth_buffer config option, which is per-screen.
---
Omit Z24+0S visuals when we've created Z24+S8 visuals. The
former offers no memory savings.
This reduces the number of advertised visuals and FBconfigs
but there still seem to be a fair number of duplicated modes.
---
src/gallium/state_trackers/dri/common/dri_screen.c | 10 +-
1 files
On Wed, Mar 13, 2013 at 09:57:22PM -0500, Aaron Watry wrote:
The python changes in this file look good to me. I haven't done a
line-by-line review of the SI changes.
I tested this patch and v2 of the related mesa series on r600g (radeon
6850) with a recent LLVM and fresh mesa master as of
Z24X8 actually does save memory, because Radeon HD 5000 and later
cards don't support combined depth stencil formats, therefore Z24S8 is
allocated internally as two separate buffers Z24X8 and S8.
Marek
On Thu, Mar 14, 2013 at 2:55 PM, Brian Paul bri...@vmware.com wrote:
Omit Z24+0S visuals when
From: Christian König christian.koe...@amd.com
Instead of emitting each temporary separately, emit them in a chunk.
v2: keep separate function for emitting temps
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 30
From: Christian König christian.koe...@amd.com
Don't bother with free temporaries, just allocate them at
the end and also emit them in their own declaration.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 55
Hello everyone,
this is the second round of this patchset.
Since the first round I made the following changes to it:
1. Add a new field ArrayID to the declaration instead of relaying on
referencing the N-th declaration.
2. Minor bugfix in glsl_to_tgsi and just like temps allocate arrays on
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
From: Christian König christian.koe...@amd.com
Instead of allocating everything as temporaries, use the
new array allocation functions.
v2: fix bug in simplify_cmp, declare arrays on demand
Signed-off-by: Christian König christian.koe...@amd.com
---
src/mesa/main/mtypes.h |
From: Christian König christian.koe...@amd.com
They shouldn't be necessary any more.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 36 +++-
1 file changed, 3 insertions(+), 33 deletions(-)
diff --git
From: Christian König christian.koe...@amd.com
Nobody seems to be using it, and only nv50 had a partial implementation.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_build.c| 19 -
src/gallium/auxiliary/tgsi/tgsi_dump.c
From: Christian König christian.koe...@amd.com
Remember which declarations are declared as arrays and so
can be indirectly addressed. ArrayIDs start at 1, cause for
compatibility reasons zero is treaded as no array present.
Signed-off-by: Christian König christian.koe...@amd.com
---
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/docs/source/tgsi.rst | 16
1 file changed, 16 insertions(+)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index
From: Christian König christian.koe...@amd.com
To further improve the optimization of source and destination
indirect addressing we need the ability to store a reference
to the declaration of the addressed operands.
Since most of the fields in tgsi_src_register doesn't apply for
an indirect
On 03/12/2013 05:44 PM, Brian Paul wrote:
On 03/11/2013 04:51 PM, Paul Berry wrote:
This patch series combines the enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib into a single enum.
These four enums serve very similar purposes: they all identify data
that flows
On 03/14/2013 08:18 AM, Marek Olšák wrote:
Z24X8 actually does save memory, because Radeon HD 5000 and later
cards don't support combined depth stencil formats, therefore Z24S8 is
allocated internally as two separate buffers Z24X8 and S8.
Ah, OK. I'll drop this patch then. Thanks.
However,
Looks good. Thanks.
I saw this warning transiently, but then couldn't see it again -- completely
forgot that I needed to rebuild in order to force a recompile.
Jose
- Original Message -
There were two different NUM_ENTRIES #defines for the framebuffer
tile cache and the texture tile
On Wed, Mar 13, 2013 at 02:59:07PM -0700, Vincent Lejeune wrote:
I fixed the coding style issue.
The iostream include was a debug leftover line, it shouldn't be there.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
- Mail original -
De : Tom Stellard t...@stellard.net
À :
On Thu, Mar 14, 2013 at 6:29 AM, Brian Paul bri...@vmware.com wrote:
Hmm, I guess autoconf still has some unneeded dependencies on DRI when it's
not needed. You might try adding --with-gallium-drivers=swrast so that no
DRI drivers are selected.
Don't think so. He's just not setting
---
src/gallium/auxiliary/draw/draw_pipe_wide_point.c | 46 +--
src/gallium/auxiliary/tgsi/tgsi_dump.c|1 +
src/gallium/auxiliary/tgsi/tgsi_strings.c |4 +-
src/gallium/docs/source/cso/rasterizer.rst|5 ++
src/gallium/docs/source/screen.rst
I was wondering if it was intented to change the version string in glxinfo
from
OpenGL version string: 3.0 Mesa 9.2-devel (git-42c1b33)
to
OpenGL version string: 3.0 Mesa 9.2.0 (git-439c3d4)
If someone builds from a 9.2 devel tarball instead from git
then there would be no difference in the
From: Christian König christian.koe...@amd.com
Cleanup the code and implement indirect addressing.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_llvm.h | 32 +--
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 241
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 34 +++-
src/gallium/drivers/radeonsi/si_state.c| 32 ++
2 files changed, 37
From: Christian König christian.koe...@amd.com
Fixing 16 piglit tests.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
src/gallium/drivers/radeonsi/radeonsi_shader.c |5 -
2 files changed, 1 insertion(+), 6
Since apps typically begin rendering with a call to glClear(), it is
likely that when brw_workaround_depthstencil_alignment() moves a
miplevel to a temporary buffer, it can avoid doing a blit, since the
contents of the miplevel are about to be erased.
This patch adds the necessary plumbing to
Tom Stellard t...@stellard.net writes:
From: Tom Stellard thomas.stell...@amd.com
This target string now contains four values instead of three. The old
processor field (which was really being interpreted as arch) has been split
into two fields: processor and arch. This allows drivers to
2013/3/11 Matt Turner matts...@gmail.com:
A step toward working make dist/distcheck.
---
configure.ac | 37 -
src/Makefile.am | 30 +++---
src/mapi/Makefile.am | 42 ++
3
This patch series adds a format-independent memcpy-based path for ReadPixels
(i.e. consolidates the existing memcpy paths), and it also
adds a blit-based path for ReadPixels to st/mesa.
The gallium drivers have the option to turn off the blit-based paths through a
CAP. Right now, only softpipe,
---
src/mesa/main/texgetimage.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 7299a4b..74b09ef 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -518,6 +518,7 @@ get_tex_rgba(struct gl_context
I'll need the _mesa_readpixels_needs_slow_path function for the blit-based
version, but it's also useful to have this memcpy-based path in one place
and not scattered across several functions.
---
src/mesa/main/readpix.c | 194 ++-
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to turn
them off.
---
src/gallium/docs/source/screen.rst |4
src/gallium/drivers/llvmpipe/lp_screen.c |2 ++
On 03/14/2013 11:41 AM, jfons...@vmware.com wrote:
From: José Fonsecajfons...@vmware.com
scons/llvm.py defines inline globally to workaround issues with LLVM C
binding headers, so the only way to is to avoid
aggravating xkeycheck.h errors is to set _ALLOW_KEYWORD_MACROS.
This fixes MSVC 2012
On 03/14/2013 12:45 PM, Marek Olšák wrote:
---
src/mesa/main/texgetimage.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 7299a4b..74b09ef 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@
On 03/14/2013 12:45 PM, Marek Olšák wrote:
I'll need both new functions for later. For now, it consolidates the code
for determining what the transfer ops should be and makes it a little bit
smarter.
---
src/mesa/main/readpix.c | 94 +--
1 file
On 03/14/2013 12:45 PM, Marek Olšák wrote:
I'll need the _mesa_readpixels_needs_slow_path function for the blit-based
version, but it's also useful to have this memcpy-based path in one place
and not scattered across several functions.
---
src/mesa/main/readpix.c | 194
With the old context creation mechanism, an application asked the GL to
give it a context. Failing to produce a context was a fatal error.
Now, with GLX_ARB_create_context, the application can request a specific
version. If it's higher than the maximum version we support, context
creation will
On 03/14/2013 12:45 PM, Marek Olšák wrote:
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to turn
them off.
---
For the rest of the series:
Reviewed-by: Brian Paul bri...@vmware.com
Can you give
https://bugs.freedesktop.org/show_bug.cgi?id=61919
Darxus dar...@chaosreigns.com changed:
What|Removed |Added
CC||dar...@chaosreigns.com
Paul Berry stereotype...@gmail.com writes:
On 12 March 2013 16:33, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
void
-brw_workaround_depthstencil_alignment(struct brw_context *brw)
+brw_workaround_depthstencil_alignment(struct brw_context *brw,
+
Paul Berry stereotype...@gmail.com writes:
The only format returned by _mesa_get_format_base_format() that
satisfies _mesa_is_depthstencil_format() is GL_DEPTH_STENCIL, so we
can simplify the check.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+),
On Mon, Mar 11, 2013 at 4:24 AM, Matt Turner matts...@gmail.com wrote:
s,mapi/mapi,mapi,g
This is a bit of a silly request, but mesa really sucks with tab completion,
getting to anything g* in src is a PITA, it would be really nice if at least
could fix the m* overload, by just calling the
Dot4 now uses 8 scalar operands instead of 2 vectors one which allows register
coalescer to remove some unneeded COPY.
This patch also defines some structures/functions that can be used to handle
every vector instructions (CUBE, Cayman special instructions...) in a similar
fashion.
---
https://bugs.freedesktop.org/show_bug.cgi?id=62357
Priority: medium
Bug ID: 62357
Assignee: mesa-dev@lists.freedesktop.org
Summary: llvmpipe: Fragment Shader with return in main causes
back output
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=62357
--- Comment #1 from Brian Paul bri...@vmware.com ---
Created attachment 76543
-- https://bugs.freedesktop.org/attachment.cgi?id=76543action=edit
piglit shader test to exercise the bug
Do you happen to know which version of Mesa this is
https://bugs.freedesktop.org/show_bug.cgi?id=62357
--- Comment #2 from Brian Paul bri...@vmware.com ---
(In reply to comment #1)
Run with:
bin/shader_runner
tests/spec/glsl-1.10/execution/fs-return-in-main.shader_test -auto
Err, just:
bin/shader_runner fs-return-in-main.shader_test -auto
If
Thanks for implementing this, I just have one comment.
On Thu, Mar 14, 2013 at 7:45 PM, Marek Olšák mar...@gmail.com wrote:
Initial version contributed by: Martin Andersson g02ma...@gmail.com
This is only used if the memcpy path cannot be used and if no transfer ops
are needed. It's pretty
On Thu, Mar 14, 2013 at 8:26 PM, Brian Paul bri...@vmware.com wrote:
On 03/14/2013 12:45 PM, Marek Olšák wrote:
---
src/mesa/main/texgetimage.c |1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 7299a4b..74b09ef 100644
On Thu, Mar 14, 2013 at 8:29 PM, Brian Paul bri...@vmware.com wrote:
On 03/14/2013 12:45 PM, Marek Olšák wrote:
The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very
fast with software rasterizer. Now Gallium drivers have the ability to
turn
them off.
---
For the
https://bugs.freedesktop.org/show_bug.cgi?id=62357
--- Comment #3 from drag...@gmail.com ---
(In reply to comment #1)
Created attachment 76543 [details]
piglit shader test to exercise the bug
Do you happen to know which version of Mesa this is happening with? I can't
tell from the gnome
https://bugs.freedesktop.org/show_bug.cgi?id=62357
--- Comment #4 from drag...@gmail.com ---
FWIW this was using LLVM 3.2 as well.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
Mesa source tree currently has 4 abstraction of threading primitives (in
gallium, glapi, mapi, and egl components).
I'd like to unify all them, and since now the C11 standard introduced a
threads.h header, I'd like to use that as model.
So for I've imported a C11 threads.h implementation from
Adds this function for both int and floating data types.
---
generic/include/clc/clc.h |2 ++
generic/include/clc/integer/max.h |2 ++
generic/include/clc/integer/max.inc |1 +
generic/include/clc/math/max.h |2 ++
generic/include/clc/math/max.inc|1 +
---
generic/lib/SOURCES |1 +
generic/lib/integer/abs_diff.inc |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/generic/lib/SOURCES b/generic/lib/SOURCES
index b593941..a97213b 100644
--- a/generic/lib/SOURCES
+++ b/generic/lib/SOURCES
@@ -4,6 +4,7 @@
This series depends on the one-off patch I just sent to add max().
1) Fix the broken abs_diff integer built-in.
2) Add clamp for both integer and floating types in a new shared/ dir in order
to reduce code duplication and improve maintainability.
3) Move the max() function into the shared/
Created under a new shared/ directory for functions which are available for
both integer and floating point types.
---
generic/include/clc/clc.h|3 +++
generic/include/clc/shared/clamp.h |5 +
generic/include/clc/shared/clamp.inc |1 +
generic/lib/SOURCES
Max(x,y) is available for all integer/floating types.
---
generic/include/clc/clc.h |3 +--
generic/include/clc/integer/max.h |2 --
generic/include/clc/integer/max.inc |1 -
generic/include/clc/math/max.h |2 --
generic/include/clc/math/max.inc|1 -
Note: I have tested all of these with the 32-bit signed integer data type
for scalar kernels only... r600g chokes on almost anything else due to a
missing vload/vstore implementation and buggy/incomplete handling of
char/short/long data types in CL kernels.
--Aaron
On Thu, Mar 14, 2013 at 10:01
62 matches
Mail list logo
