On Friday 03 January 2014, Marek Olšák wrote:
On Fri, Jan 3, 2014 at 2:04 PM, Marek Olšák mar...@gmail.com wrote:
On Fri, Jan 3, 2014 at 1:27 AM, Maxence Le Doré
maxence.led...@gmail.com wrote:
---
src/mesa/main/texobj.c | 52
++
Fixes a bug where then branch operates with ivec4 while else uses vec4.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72379
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git
Not sure this is 100% the correct way to do this, since it may be a change
at the glsl-tgsi level that is required, either way open discussions!
fixes piglit tests/spec/glsl-1.50/execution/geometry/primitive-id-in.shader_test
with llvmpipe with fake MSAA
Signed-off-by: Dave Airlie
On Tue, 7 Jan 2014 00:22:08 +0100
Marek Olšák mar...@gmail.com wrote:
Is the logging really needed apart from initial debugging and
validation of the code? I don't see a reason to have this in master.
Yes, it's there to allow users to submit traces, which then means much
better coverage
On Tue, 7 Jan 2014 01:44:28 +0100
Marek Olšák mar...@gmail.com wrote:
On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen c...@gmx.com wrote:
These will be used later on for optimizing the VRAM placement.
No measurable overhead (glxgears).
I recommend testing torcs (the Forza track) next
Commit 9119269ca14ed42b51c7d8e2e662500311b29fa3 moved the texel
buffer allocation to _swrast_texture_span(), however, when compiled
with OpenMP support this code already runs multi-threaded so a
critical section is required to prevent multiple allocations and
rendering errors.
---
Hi,
This patch fixes a bug in swrast OpenMP code which was introduced with the
delayed buffer allocation. It caused rendering errors and a memory leak.
Andreas Fänger (1):
swrast: fix delayed texel buffer allocation regression for OpenMP
src/mesa/swrast/s_texcombine.c | 12
1
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #12 from Alexander Mezin mezin.alexan...@gmail.com ---
I see only comments about intel+radeon here.
It would be interesting to know if there are same problems with intel+nouveau
or radeon+radeon
--
You are receiving this mail
On Tue, Jan 7, 2014 at 11:14 AM, Lauri Kasanen c...@gmx.com wrote:
On Tue, 7 Jan 2014 01:44:28 +0100
Marek Olšák mar...@gmail.com wrote:
On Mon, Jan 6, 2014 at 12:17 PM, Lauri Kasanen c...@gmx.com wrote:
These will be used later on for optimizing the VRAM placement.
No measurable
On 6 January 2014 17:05, Chad Versace chad.vers...@linux.intel.com wrote:
In solving a HiZ hang before Christmas vacation, I discovered that Mesa
wasn't
emitting sufficient workaround flushes. That bug was solved in commit
1a92881.
This series, prompted by Ken, adds some more carefully
On 6 January 2014 17:05, Chad Versace chad.vers...@linux.intel.com wrote:
Set brw-need_workaround_flush immediately after each 3D_CMD_PRIM. This
may prevent undiscovered difficult-to-diagnose gpu hangs, according to
Ken.
The art of emitting workaround flushes on Sandybridge is mysterious and
On 6 January 2014 17:05, Chad Versace chad.vers...@linux.intel.com wrote:
Unconditionally set brw-need_workaround_flush at the top of gen6 blorp
state emission. This is an extra safety measure to prevent undiscovered
difficult-to-diagnose gpu hangs.
The art of emitting workaround flushes on
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #13 from Armin K kre...@email.com ---
(In reply to comment #5)
And without DRI_PRIME=1 everything works everywhere, with or without
compositing, windowed or fullscreen.
I would imagine this is because you're not offloading
On 6 January 2014 17:05, Chad Versace chad.vers...@linux.intel.com wrote:
Commit 1a92881 added extra flushes to fix a HiZ hang in
WebGL Google Maps. With the extra flushes emitted by the previous two
patches, the flushes added by 1a92881 are redundant.
Tested with the same criteria as in
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #14 from Alex Deucher ag...@yahoo.com ---
Prime only works with compositing, so you have to have compositing enabled.
--
You are receiving this mail because:
You are the assignee for the bug.
On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul bri...@vmware.com wrote:
Evidently, there's some other definition of min and max that
causes MSVC to choke on these function names. Renaming to min2()
and max2() fixes things.
Wouldn't it be easier to
On 01/07/2014 03:10 AM, Andreas Fänger wrote:
Commit 9119269ca14ed42b51c7d8e2e662500311b29fa3 moved the texel
buffer allocation to _swrast_texture_span(), however, when compiled
with OpenMP support this code already runs multi-threaded so a
critical section is required to prevent multiple
On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul bri...@vmware.com wrote:
On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul bri...@vmware.com wrote:
Evidently, there's some other definition of min and max that
causes MSVC to choke on these function names.
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #15 from Jan Vesely jano.ves...@gmail.com ---
(In reply to comment #12)
I see only comments about intel+radeon here.
It would be interesting to know if there are same problems with
intel+nouveau or radeon+radeon
On my nvd9 + snb
https://bugs.freedesktop.org/show_bug.cgi?id=69101
--- Comment #16 from Mike Lothian m...@fireburn.co.uk ---
If you're running the lastest verion of Heaven or running Valley on drivers
that don't yet have OpenGL 3.2 it'll fail to render (SNB doesn't) - try passing
MESA_GL_VERSION_OVERRIDE=3.2
On 01/07/2014 08:03 AM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul bri...@vmware.com wrote:
On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul bri...@vmware.com wrote:
Evidently, there's some other definition of min and max that
On 01/07/2014 12:49 AM, Fredrik Höglund wrote:
Maxence, while I think it's great that you're interested in working
on this extension, I'm afraid I have another implementation in
a branch in my mesa tree:
- Original Message -
On Tue, Jan 7, 2014 at 3:59 PM, Brian Paul bri...@vmware.com wrote:
On 01/06/2014 05:22 PM, Erik Faye-Lund wrote:
On Tue, Jan 7, 2014 at 12:12 AM, Brian Paul bri...@vmware.com wrote:
Evidently, there's some other definition of min and max that
causes MSVC
From section 4.4.4 (Framebuffer Completeness) of the GL 3.2 spec:
If any framebuffer attachment is layered, all populated
attachments must be layered. Additionally, all populated color
attachments must be from textures of the same target.
We weren't checking that the attachments were
Previously, Mesa enforced the following rule (from
ARB_geometry_shader4's list of criteria for framebuffer completeness):
* If any framebuffer attachment is layered, all attachments must have
the same layer count. For three-dimensional textures, the layer count
is the depth of the
On Tue, Jan 7, 2014 at 4:11 PM, Brian Paul bri...@vmware.com wrote:
On 01/07/2014 08:03 AM, Erik Faye-Lund wrote:
Why was this pushed out prematurely, then? Reviewing within two hours
seems to be reasonable, no?
I got Kenneth's R-b so I pushed it. I saw no reason to wait. Also, I don't
We have talked on IRC meanwhile:
Everywhere was supposed to mean file names and data structures.
I have made a patch series (git link because file renames produce huge
diffs) that renames *everything* away from r600 (and also radeonsi)
to si, where it is actually about SI. In the such modified
You are absolutly right. I followed the way specification illustrate
implementation for simplicity reasons but had always in mind that this
was not the way to get any performance
benefit and hoped that I are somebody else could improve this later.
That's a great thing you already did this and
This packed floating point format only stores positive values.
---
src/mesa/main/formats.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index eb2a07e..7e0ec23 100644
--- a/src/mesa/main/formats.c
+++
Don't worry to much about history keeping, anybody who really needs that
should be capable of digging that up anyway.
I would just squash together the changes Apply si_ file naming scheme
in src/gallium/drive… and Fix up file renaming: change file names in
commen…. Also please change the
If a channel has zero bits it's not signed.
---
src/mesa/main/get.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index c45a8d1..bb138c8 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@
Thanks Fredrik,
I was nearly sure this was ok from what I read of the specs. And
you're also right again : I totally forget a case where a texture has
never been bound !
2014/1/7 Maxence Le Doré maxence.led...@gmail.com:
Thanks Fredrik,
I was nearly sure this was ok from what I read of the
I agree with everything except these two:
Rename the commonly occurring rctx/r600 to now more suitable sctx.
Rename the commonly occurring rscreen to now more suitable sscreen.
It's too much for my eye to handle.
Marek
On Tue, Jan 7, 2014 at 5:27 PM, Andreas Hartmetz ahartm...@gmail.com wrote:
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Tue, Jan 7, 2014 at 5:35 PM, Brian Paul bri...@vmware.com wrote:
This packed floating point format only stores positive values.
---
src/mesa/main/formats.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
On Tue, Jan 7, 2014 at 5:37 PM, Christian König deathsim...@vodafone.de wrote:
Don't worry to much about history keeping, anybody who really needs that
should be capable of digging that up anyway.
I would just squash together the changes Apply si_ file naming scheme in
src/gallium/drive… and
Thanks Ian, I got this after a rebase. Didn't know were it comes from.
2014/1/6 Ian Romanick i...@freedesktop.org:
On 01/02/2014 05:18 PM, Maxence Le Doré wrote:
---
src/mesa/drivers/dri/i915/i830_state.c | 12
src/mesa/drivers/dri/i965/brw_util.c | 24 +---
On Tuesday 07 January 2014 17:37:07 Christian König wrote:
Don't worry to much about history keeping, anybody who really needs that
should be capable of digging that up anyway.
I would just squash together the changes Apply si_ file naming scheme
in src/gallium/drive… and Fix up file
Indeed, this patch compiles on linux but may break complilation at
least on MSVC version 1400.
I'm planing to install visual studio 2005 on a ms xp or seven virtual
machine to check the behavior when compiling in microsoft windows
environment.
2014/1/6 Erik Faye-Lund kusmab...@gmail.com:
On
Do you think it's too much change in general or that the patches are
too large? They were honestly simple find / sed jobs, so I could fairly
easily redo them file by file.
I'm not sure how to even argue about that, but I think suitable names
are very important. rctx goes as mysterious name /
Thanks Brian.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
v2: Moved the high priority check to r600_texture_create_object
Signed-off-by: Lauri Kasanen c...@gmx.com
---
src/gallium/drivers/r600/r600_state_common.c| 2 +-
src/gallium/drivers/radeon/r600_buffer_common.c | 6 --
src/gallium/drivers/radeon/r600_pipe_common.h | 3 ++-
No measurable overhead when off (glxgears within 0.5%).
v2: Cosmetic changes.
v3: Moved file handling into winsys
Signed-off-by: Lauri Kasanen c...@gmx.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 5
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
These will be used later on for optimizing the VRAM placement.
No measurable overhead (glxgears, torcs).
v2: Get accurate stats by taking dirty_masks into account
Marek: I'm not sure I was testing torcs right; I started a race on Forza, drove
around, and looked at the fps. Doesn't seem to do
v2: Move to a timing thread to minimize overhead.
Signed-off-by: Lauri Kasanen c...@gmx.com
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 25 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 10 +
2 files changed, 35 insertions(+)
diff --git
For this reason, GLSL 4.0 introduces the 'precise' qualifier. I invite
you to take a look at this article.
2014/1/6 Roland Scheidegger srol...@vmware.com:
Am 05.01.2014 01:34, schrieb Maxence Le Doré:
FMA(a,b,c) keeps extra precision (usually 1 more bit of mantissa,
afaik) for the result a*b
I forgot the link :
http://www.geeks3d.com/20120106/precise-qualifier-in-glsl-and-nvidia-geforce-cards/
2014/1/7 Maxence Le Doré maxence.led...@gmail.com:
For this reason, GLSL 4.0 introduces the 'precise' qualifier. I invite
you to take a look at this article.
2014/1/6 Roland Scheidegger
Well we were using a system value for prim id in gs, hence this was not
necessary. I'm always confused though about system value / normal
semantic usage though, Zack might know better.
Roland
Am 07.01.2014 09:55, schrieb Dave Airlie:
Not sure this is 100% the correct way to do this, since it
Am 07.01.2014 17:35, schrieb Brian Paul:
If a channel has zero bits it's not signed.
---
src/mesa/main/get.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index c45a8d1..bb138c8 100644
---
On Tue, Jan 07, 2014 at 05:41:56AM -0800, Paul Berry wrote:
On 6 January 2014 17:05, Chad Versace chad.vers...@linux.intel.com wrote:
In solving a HiZ hang before Christmas vacation, I discovered that Mesa
wasn't
emitting sufficient workaround flushes. That bug was solved in
Yes that is certainly related. I'm actually not entirely sure what is
allowed in glsl by default as OpenGL seems to have some lax rules
regarding precision in any case (float calculations not required but
allowed to use denorms, at least earlier versions weren't required to
support Infs neither
On Tue, Jan 7, 2014 at 6:46 PM, Maxence Le Doré
maxence.led...@gmail.com wrote:
Indeed, this patch compiles on linux but may break complilation at
least on MSVC version 1400.
I'm planing to install visual studio 2005 on a ms xp or seven virtual
machine to check the behavior when compiling in
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Priority: medium
Bug ID: 73371
Assignee: mesa-dev@lists.freedesktop.org
Summary: EGL_NOK_texture_from_pixmap is advertised but not
properly set.
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Gustavo Sverzut Barbieri barbi...@gmail.com changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Gustavo Sverzut Barbieri barbi...@gmail.com changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Gustavo Sverzut Barbieri barbi...@gmail.com changed:
What|Removed |Added
URL|
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=73371
Iván Briano sachi...@gmail.com changed:
What|Removed |Added
CC||sachi...@gmail.com
---
On 01/07/2014 08:35 AM, Brian Paul wrote:
If a channel has zero bits it's not signed.
---
src/mesa/main/get.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
Series is:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Very nice. I originally thought about conditionnaly defining a fmaf
for MSVC 1400 like Cygwin and opensource apple code, but I think
this is pushing the problem to later, with double fma(double), that
will be required with ARB_gpu_shader_fp64 : In that case, we'll have
to use long doubles (80
On Tue, Jan 7, 2014 at 12:25 AM, Tapani Pälli tapani.pa...@intel.com wrote:
Fixes a bug where then branch operates with ivec4 while else uses vec4.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72379
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
FYI, Evergreen has dedicated instructions for both MAD and FMA. FMA
seems to be available on DX11 chips only.
Marek
On Tue, Jan 7, 2014 at 8:20 PM, Roland Scheidegger srol...@vmware.com wrote:
Yes that is certainly related. I'm actually not entirely sure what is
allowed in glsl by default as
From: Marek Olšák marek.ol...@amd.com
Copied from the i965 driver, including the big comment.
Cc: 9.2 10.0 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_cb_blit.c | 32
1 file changed, 32 insertions(+)
diff --git
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
This fixes the following compile error:
src\glsl\ir_constant_expression.cpp(1405) : error C2666: 'copysign' : 3
overloads have similar conversions
---
src/glsl/ir_constant_expression.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_constant_expression.cpp
MSVC 2013 version of math.h includes an fma() function.
---
src/glsl/builtin_functions.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 10127f3..b3e407a 100644
--- a/src/glsl/builtin_functions.cpp
+++
On 01/07/2014 01:31 PM, Thomas Sondergaard wrote:
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
On 2014-01-07 22:37, Brian Paul wrote:
On 01/07/2014 01:31 PM, Thomas Sondergaard wrote:
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
memory access order.
Can you explain this better? As far as I can tell, this just changes
the order the indices are visited (and has a spurious, incorrect
whitespace
In my early preparations for working on compute shaders, I've run into
some stumbling blocks due to the way the GLSL compiler keeps track of
which pipeline stage a given shader is being compiled for.
In some places, it uses a GLenum to store values like
GL_VERTEX_SHADER, GL_GEOMETRY_SHADER, or
---
src/glsl/glsl_parser_extras.cpp| 29 -
src/glsl/glsl_parser_extras.h | 3 ---
src/mesa/main/uniform_query.cpp| 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
4 files changed, 2 insertions(+), 34 deletions(-)
diff
---
src/glsl/lower_clip_distance.cpp | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/glsl/lower_clip_distance.cpp b/src/glsl/lower_clip_distance.cpp
index bb4f6ab..2d6138d 100644
--- a/src/glsl/lower_clip_distance.cpp
+++ b/src/glsl/lower_clip_distance.cpp
---
src/glsl/link_varyings.cpp | 48 +++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index da97e9f..eefd725 100644
--- a/src/glsl/link_varyings.cpp
+++
Previously, we had an enum called gl_shader_type which represented
pipeline stages in the order they occur in the pipeline
(i.e. MESA_SHADER_VERTEX=0, MESA_SHADER_GEOMETRY=1, etc), and several
inconsistently named functions for converting between it and other
representations:
-
---
src/glsl/glsl_parser_extras.cpp | 12 +---
src/glsl/glsl_parser_extras.h| 2 +-
src/glsl/main.cpp| 2 +-
src/glsl/test_optpass.cpp| 2 +-
src/glsl/tests/builtin_variable_test.cpp | 2 +-
---
src/glsl/ir.h | 2 +-
src/glsl/ir_set_program_inouts.cpp | 29 +++--
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 +-
src/mesa/program/ir_to_mesa.cpp| 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
5
This reduces confusion since gl_shader::Type is sometimes
GL_SHADER_PROGRAM_MESA but is more frequently
GL_SHADER_{VERTEX,GEOMETRY,FRAGMENT}. It also has the advantage that
when switching on gl_shader::Stage, the compiler will alert if one of
the possible enum types is unhandled. Finally, many
Hi Marek,
Since it seems no one else have any comments on this, maybe you could
commit it for me?
//Martin
On Thu, Dec 26, 2013 at 1:15 PM, Marek Olšák mar...@gmail.com wrote:
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Thu, Dec 26, 2013 at 10:33 AM, Martin Andersson
On Tue, Jan 7, 2014 at 2:05 PM, Ian Romanick i...@freedesktop.org wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
memory access order.
Can you explain this better? As far as I can tell, this just changes
On 01/07/2014 02:22 PM, Thomas Sondergaard wrote:
On 2014-01-07 23:05, Ian Romanick wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a
better
memory access order.
Can you explain this better? As far as I can tell,
There are fixes on top of this fix. When they get picked over to the
stable branch, I think at least this and the one from 050961.html should
get squashed together.
http://lists.freedesktop.org/archives/mesa-dev/2014-January/050961.html
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
MSVC 2013 version of math.h includes an fma() function.
---
src/glsl/builtin_functions.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index
On 01/07/2014 02:13 PM, Paul Berry wrote:
Previously, we had an enum called gl_shader_type which represented
pipeline stages in the order they occur in the pipeline
(i.e. MESA_SHADER_VERTEX=0, MESA_SHADER_GEOMETRY=1, etc), and several
inconsistently named functions for converting between it
On 01/07/2014 03:13 PM, Paul Berry wrote:
This reduces confusion since gl_shader::Type is sometimes
GL_SHADER_PROGRAM_MESA but is more frequently
GL_SHADER_{VERTEX,GEOMETRY,FRAGMENT}. It also has the advantage that
when switching on gl_shader::Stage, the compiler will alert if one of
the
On 01/07/2014 03:13 PM, Paul Berry wrote:
Previously, we had an enum called gl_shader_type which represented
pipeline stages in the order they occur in the pipeline
(i.e. MESA_SHADER_VERTEX=0, MESA_SHADER_GEOMETRY=1, etc), and several
inconsistently named functions for converting between it and
On 01/07/2014 03:13 PM, Paul Berry wrote:
---
src/glsl/glsl_parser_extras.cpp | 12 +---
src/glsl/glsl_parser_extras.h| 2 +-
src/glsl/main.cpp| 2 +-
src/glsl/test_optpass.cpp| 2 +-
On 01/07/2014 03:13 PM, Paul Berry wrote:
---
src/glsl/link_varyings.cpp | 48 +++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index da97e9f..eefd725 100644
---
On 01/07/2014 03:30 PM, Ian Romanick wrote:
On 01/07/2014 02:22 PM, Thomas Sondergaard wrote:
On 2014-01-07 23:05, Ian Romanick wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a
better
memory access order.
Can you
MSVC 2013 version of math.h includes an fma() function.
---
src/glsl/builtin_functions.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 10127f3..b3e407a 100644
--- a/src/glsl/builtin_functions.cpp
+++
On 2014-01-07 23:45, Kenneth Graunke wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
MSVC 2013 version of math.h includes an fma() function.
---
src/glsl/builtin_functions.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/builtin_functions.cpp
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
memory access order.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
This fixes the following compile error:
src\glsl\ir_constant_expression.cpp(1405) : error C2666: 'copysign' : 3
overloads have similar conversions
---
src/glsl/ir_constant_expression.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/ir_constant_expression.cpp
On 2014-01-07 23:05, Ian Romanick wrote:
On 01/07/2014 12:31 PM, Thomas Sondergaard wrote:
This small rearrangement avoids MSVC 2013 ICE. Also, this should be a better
memory access order.
Can you explain this better? As far as I can tell, this just changes
the order the indices are visited
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 1d618e6..22c1725 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
On 01/07/2014 02:13 PM, Paul Berry wrote:
This reduces confusion since gl_shader::Type is sometimes
GL_SHADER_PROGRAM_MESA but is more frequently
GL_SHADER_{VERTEX,GEOMETRY,FRAGMENT}. It also has the advantage that
when switching on gl_shader::Stage, the compiler will alert if one of
the
https://bugs.freedesktop.org/show_bug.cgi?id=73371
--- Comment #2 from Carsten Haitzler ras...@rasterman.com ---
oh - thanks gustavo. someone else was filing a bug too.
i've also prepared a workaround for now where we blacklist mesa + intel drvires
in egl mode from detecting this extension. i
Unconditionally set brw-need_workaround_flush at the top of gen6 blorp
state emission.
The art of emitting workaround flushes on Sandybridge is mysterious and
not fully understood. Ken and I believe that
intel_emit_post_sync_nonzero_flush() may be required when switching from
regular drawing to
In solving a HiZ hang before Christmas vacation, I discovered that Mesa wasn't
emitting sufficient workaround flushes. That bug was solved in commit 1a92881.
This series, prompted by Ken, adds some more carefully placed flushes to
pre-emptively fix undiscovered gpu hangs. Gpu hangs are
This patch makes the workaround code in gen6 blorp follow the pattern
established in the regular draw path. It shouldn't result in any
behavioral change.
On gen6, there are two places where we emit 3D_CMD_PRIM: brw_emit_prim()
and gen6_blorp_emit_primitive(). brw_emit_prim() sets
1 - 100 of 107 matches
Mail list logo
