Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
index e42b3f5..73ad205 100644
--- a/src/g
Implement guest-backed surface sharing using prime fds. Previously only
legacy surfaces could use this functionality. Also use the vmwgfx 2.6
single-ioctl prime fd reference if available.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmw_screen.h | 4 +-
src/
On Mon, Apr 7, 2014 at 11:50 AM, Thomas Hellstrom wrote:
> Cc: "10.1"
> Signed-off-by: Thomas Hellstrom
>
> ---
> src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
Both patches are:
Reviewed-by: Jakob Bornecrantz
Cheers, Jakob.
>
Binding a new destination may cause the svga driver to emit draw calls
while propagating the surface. Make sure this doesn't happen in the middle
of sampler state setup where state may be incosistent.
In practice, surface propagation should never happen here and even if it did,
it wouldn't be a va
Ping.
Richard Sandiford writes:
> Ping (with fixed subject)
>
> Richard Sandiford writes:
>> This is a refresh of:
>>
>>http://lists.freedesktop.org/archives/mesa-dev/2013-June/040594.html
>>
>> At the moment the python code uses sys.byteorder to decide whether
>> u_format_table.c should be
op 03-04-14 18:19, Marek Olšák schreef:
Acked-by: Marek Olšák
Nacked by self btw, the alternative fix below doesn't break other testcases.
The original fix did..
No idea why it is legal to move a constant struct/array here, but it appears to
pass all tests...
---
diff --git a/src/mesa/stat
On Mon, Apr 7, 2014 at 12:32 PM, Thomas Hellstrom wrote:
> Binding a new destination may cause the svga driver to emit draw calls
> while propagating the surface. Make sure this doesn't happen in the middle
> of sampler state setup where state may be incosistent.
>
> In practice, surface propagati
On 06/04/2014 17:45, Emil Velikov wrote:
> Sorry about this breakage. I assumed that the library extensions are handled
> consistently across mesa. Seems like I was wrong.
>
> Guessing that you meant to send this to the mesa-dev ?
Yes, sorry about that.
> On 06/04/14 15:59, Jon TURNEY wrote:
>>
On Mon, Apr 7, 2014 at 2:49 AM, Kenneth Graunke wrote:
> The i965 MUL instruction doesn't natively support 32-bit by 32-bit
> integer multiplication; additional instructions (MACH/MOV) are required.
> However, we can avoid those if we know one of the operands can be
> represented in 16 bits or les
Previously the version was specified in configure.ac as well as
one of the xa headers. Thus incleasing the risk of discrepancies
when a developer bumps one but forgets about the other.
Currently only automake builds the xa state-tracker + targets,
and we should move the version definitions to a bu
Parsing source files through build systems is never a good idea.
Especially when the issue can be resolved by adding a couple of
definitions to CPPFLAGS via the build system.
This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c.
Cc: Thomas Hellstrom
---
Seems like I was a bit too quick
The kernel driver expects the class to be based on chipset generation
rather than VP generation. Make sure to pass 90b1 for NVDX chipsets
instead of 95b1.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77102
Fixes: 40dd777b33073
Signed-off-by: Ilia Mirkin
Cc: "10.1 10.0"
---
src/gallium
On 07/04/14 10:50, Thomas Hellstrom wrote:
> Cc: "10.1"
> Signed-off-by: Thomas Hellstrom
Rather silly question:
Why do you guys pull this header inside mesa and over using the one provided
by libdrm ? AFAICS every other driver seems to do the latter.
-Emil
> ---
> src/gallium/winsys/svga/drm/
On 04/07/2014 02:44 PM, Emil Velikov wrote:
> Parsing source files through build systems is never a good idea.
> Especially when the issue can be resolved by adding a couple of
> definitions to CPPFLAGS via the build system.
I've nothing against reverting the commit, but the log message is incorre
On 04/07/2014 02:44 PM, Emil Velikov wrote:
> Previously the version was specified in configure.ac as well as
> one of the xa headers. Thus incleasing the risk of discrepancies
> when a developer bumps one but forgets about the other.
>
> Currently only automake builds the xa state-tracker + target
On 04/04/2014 05:52 PM, Matt Turner wrote:
> On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote:
>> Fast forwarding 3 months from the 10.1 release (March 4th, planned for
>> February 28th) is May 30th. I'd like to propose the following set of dates:
>>
>> May 2nd: Feature freeze / 10.2 branch cre
On 04/06/2014 09:31 PM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> Given
>
> mov vgrf7, vgrf9.xyxz
> add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
> add vgrf10.x, vgrf6.xyzw, vgrf7.
>
> the last instruction would be wrongly changed to
>
> add vgrf10.x, vgrf6.xyzw, vgrf9.
>
> during copy p
On 04/07/2014 02:49 PM, Emil Velikov wrote:
> On 07/04/14 10:50, Thomas Hellstrom wrote:
>> Cc: "10.1"
>> Signed-off-by: Thomas Hellstrom
> Rather silly question:
>
> Why do you guys pull this header inside mesa and over using the one provided
> by libdrm ? AFAICS every other driver seems to do t
On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
> The i965 MUL instruction doesn't natively support 32-bit by 32-bit
> integer multiplication; additional instructions (MACH/MOV) are required.
> However, we can avoid those if we know one of the operands can be
> represented in 16 bits or less. The v
On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 3bf2789..d8edc95 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -2298,7 +2298,7 @@ link_shaders(struct gl_context *ctx, struct
> gl_shader_program *prog)
>
>
This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c.
As the header is the one defining the API/ABI and is distributed
during installation, we should be using it rather than re-defining
the XA version in configure.ac.
Bump the version in the header to 2.2.0, to reflect what was the
origin
On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
> Integer shifts are basically always well supported and efficient; that
> isn't always true of integer division, and sometimes even integer
> multiplication isn't without issues.
>
> On some Intel hardware, INTDIV can't be used in SIMD16 mode. It al
I made a couple random comments on several patches. I also like Ilia's
suggestion on patch 3.
Patches 1 through 8 (with Ilia's suggestion on 3) are
Reviewed-by: Ian Romanick
I think patch 9 still needs some work for signed numerator handling in
division.
On 04/06/2014 11:49 PM, Kenneth Graunk
On 04/06/2014 10:27 PM, Tapani Pälli wrote:
> On 04/05/2014 12:58 AM, Ian Romanick wrote:
>> On 04/04/2014 02:42 PM, Ian Romanick wrote:
>>> On 03/27/2014 11:45 PM, Tapani Pälli wrote:
Patch adds a preprocessor define for the extension and stores
explicit location data for uniforms during
On 07/04/14 13:05, Jon TURNEY wrote:
> On 06/04/2014 17:45, Emil Velikov wrote:
>> IMHO if we're starting from scratch we should use the platform specific
>> extensions consistently but neither suggestion matter in this case :'(
>
> Can you explain your reasoning? This seems to me to be a foolish
While linux uses .so as a default extension of a shared library that is
not the case for other platforms. The loader in libGL (and others) assume
that the dri module will always have a .so extension, thus it will fail
to load it on some platforms.
Spotted-by: Jon TURNEY
Signed-off-by: Emil Veliko
On 04/05/2014 03:50 PM, Brian Paul wrote:
> Rename functions to match format names.
>
> sed commands:
> s/signed_rgba_rev/R8G8B8A8_SNORM/g
> s/signed_rgba/A8B8G8R8_SNORM/g
> s/f_rgba_rev/R8G8B8A_UNORM/g
> s/f_rgba/A8B8G8R8_UNORM/g
> s/f_rgbx_rev/R8G8B8X8_UNORM/g
> s/f_rgbx/
The series is
Reviewed-by: Ian Romanick
On 04/05/2014 03:50 PM, Brian Paul wrote:
> So the function names match the format names.
> ---
> src/mesa/main/format_unpack.c | 80
> -
> 1 file changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/src/
On 04/07/2014 09:17 AM, Ian Romanick wrote:
On 04/05/2014 03:50 PM, Brian Paul wrote:
Rename functions to match format names.
sed commands:
s/signed_rgba_rev/R8G8B8A8_SNORM/g
s/signed_rgba/A8B8G8R8_SNORM/g
s/f_rgba_rev/R8G8B8A_UNORM/g
s/f_rgba/A8B8G8R8_UNORM/g
s/f_rgbx_rev/R
https://bugs.freedesktop.org/show_bug.cgi?id=61750
--- Comment #4 from Will Wagner ---
This appears to be a duplicate of bug 75098?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.free
On 03/13/2014 08:15 AM, Mika Kuoppala wrote:
> Ian Romanick writes:
>
>> On 03/12/2014 01:43 AM, Kenneth Graunke wrote:
>>> arekm reported that using Chrome with GPU acceleration enabled on GM45
>>> triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.
>>>
>>> We definitely do
Kenneth Graunke writes:
> On 04/04/2014 03:28 PM, Matt Turner wrote:
>> The generator uses its destination as a source implicitly, which breaks
>> some assumptions in dead code elimination. Giving the instruction a
>> source allows us to reason about it better.
>> ---
>> src/mesa/drivers/dri/i96
Ian Romanick writes:
> On 04/04/2014 05:52 PM, Matt Turner wrote:
>> On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote:
>>> Fast forwarding 3 months from the 10.1 release (March 4th, planned for
>>> February 28th) is May 30th. I'd like to propose the following set of dates:
>>>
>>> May 2nd: Fe
Iago Toral Quiroga writes:
> Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression when
> switching a single context between multiple drawables.
>
> The problem is that we check whether we have a viewport set to decide if we
> need to generate buffers for the drawble, but the view
Matt Turner writes:
> It's more likely that we won't find writes to all channels than one will
> interfere, and calculating interference is more expensive. This change
> will also help prepare for coalescing load_payload instructions'
> operands.
>
> Also update the live intervals for all channel
Notice our multiple values for M_PI_2, which rounded ...32 up to
...4 and ...5.
---
The float casts are ugly. I tried to define M_PI_2f using the
preprocessor -- something like
#define M_PI_2f M_PI_2##f
but no luck.
src/glsl/builtin_functions.cpp | 14 +++---
1 file changed, 7 insertio
On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
> Notice our multiple values for M_PI_2, which rounded ...32 up to
> ...4 and ...5.
> ---
> The float casts are ugly. I tried to define M_PI_2f using the
> preprocessor -- something like
>#define M_PI_2f M_PI_2##f
> but no luck.
>
> src/glsl
On Mon, Apr 7, 2014 at 10:28 AM, Aaron Watry wrote:
> On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
>> Notice our multiple values for M_PI_2, which rounded ...32 up to
>> ...4 and ...5.
>> ---
>> The float casts are ugly. I tried to define M_PI_2f using the
>> preprocessor -- something like
Am 07.04.2014 15:52, schrieb Ian Romanick:
> On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
>> Integer shifts are basically always well supported and efficient; that
>> isn't always true of integer division, and sometimes even integer
>> multiplication isn't without issues.
>>
>> On some Intel hard
Iago Toral Quiroga writes:
> glClearBuffer() is currently clearing all active draw color buffers (all
> buffers that have not been set to GL_NONE when calling glDrawBuffers) instead
> of only clearing the one it receives as parameter. Altough brw_clear()
> receives a bit mask indicating the color
Kenneth Graunke writes:
> These are clearly needed---the comments in the function are even present
> for each one of them. I originally had two separate state atoms for
> 3DSTATE_SBE and 3DSTATE_SBE_SWIZ. When I combined the functions, I must
> have forgotten to add the atoms for 3DSTATE_SBE_S
Iago Toral Quiroga writes:
> When doing software rendering (i.e. rendering to the selection buffer) we need
> to make sure that we have valid index bounds before calling _tnl_draw_prims(),
> otherwise we can crash.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59455
> ---
> src/mesa
Fixes failures in Khronos OpenGL CTS test conditional_render_test9
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/intel_fbo.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index d0e1349..b5b93a
On Sun, Apr 6, 2014 at 11:49 PM, Kenneth Graunke wrote:
> Integer shifts are basically always well supported and efficient; that
> isn't always true of integer division, and sometimes even integer
> multiplication isn't without issues.
>
> On some Intel hardware, INTDIV can't be used in SIMD16 mod
On Sun, Apr 6, 2014 at 11:49 PM, Kenneth Graunke wrote:
> Performance warnings are logged via KHR_debug in addition to when the
> INTEL_DEBUG=perf environment variable is set. Without this, messages in
> debug contexts would have "(null)" for the reason.
>
> Signed-off-by: Kenneth Graunke
> ---
https://bugs.freedesktop.org/show_bug.cgi?id=77152
Priority: medium
Bug ID: 77152
Keywords: regression
CC: matts...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: libglapi.so: undefined reference to `entry_get_public
On 04/07/2014 10:28 AM, Aaron Watry wrote:
> On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
>> Notice our multiple values for M_PI_2, which rounded ...32 up to
>> ...4 and ...5.
>> ---
>> The float casts are ugly. I tried to define M_PI_2f using the
>> preprocessor -- something like
>>#de
On 04/07/2014 09:14 AM, Eric Anholt wrote:
> Ian Romanick writes:
>
>> On 04/04/2014 05:52 PM, Matt Turner wrote:
>>> On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote:
Fast forwarding 3 months from the 10.1 release (March 4th, planned for
February 28th) is May 30th. I'd like to prop
I thought I was seeing a bug in the code while reviewing, but it's not
there.
---
src/mesa/drivers/dri/i965/.gitignore | 1 +
src/mesa/drivers/dri/i965/Makefile.am | 7 +
.../dri/i965/test_vec4_copy_propagation.cpp| 156 +
3 files changed,
Chia-I Wu writes:
> From: Chia-I Wu
>
> Given
>
> mov vgrf7, vgrf9.xyxz
> add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
> add vgrf10.x, vgrf6.xyzw, vgrf7.
>
> the last instruction would be wrongly changed to
>
> add vgrf10.x, vgrf6.xyzw, vgrf9.
>
> during copy propagation.
>
> The issue
From: Marek Olšák
This replaces u_gen_mipmap with an extremely simple implementation based
on pipe->blit. st/mesa is also cleaned up.
Pros:
- less code
- correct mipmap generation for NPOT 3D textures (u_blitter uses a better
formula)
- queries are not affected by mipmap generation if drivers
Signed-off-by: Anuj Phogat
---
src/mesa/swrast/s_blit.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c
index 1ba188c..e3b45f1 100644
--- a/src/mesa/swrast/s_blit.c
+++ b/src/mesa/swrast/s_blit.c
@@ -29,6 +29,7 @@
#include "main/mac
Updated patch to include reference to bug that it resolves.
Since this fixes a buffer overrun in the driver (found running GLBenchmark's
Manhattan test) I think it would be a good candidate for the stable branch.
___
mesa-dev mailing list
mesa-dev@list
Just a trivial comment, otherwise looks good to me.
Thanks!
Roland
Am 07.04.2014 21:05, schrieb Marek Olšák:
> From: Marek Olšák
>
> This replaces u_gen_mipmap with an extremely simple implementation based
> on pipe->blit. st/mesa is also cleaned up.
>
> Pros:
> - less code
> - correct mipmap
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Matt Turner
---
src/mesa/tnl/t_vertex.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/mesa/tnl/t_vertex.c b/src/mesa/tnl/t_vertex.c
index b3deac0..5a4bb0b 100644
--- a/src/mesa/tnl/t_vertex.c
+++ b/src/mesa
Set of patches which mostly were here earlier, hope I did not this time miss
any comments. #12 is new to the set. These pass Piglit quick tests with no
regression on my Ivybridge.
/Juha-Pekka
Ian Romanick (1):
mesa: Add _mesa_error_no_memory for logging out-of-memory messages
Juha-Pekka Heikki
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Matt Turner
---
src/mesa/vbo/vbo_rebase.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/mesa/vbo/vbo_rebase.c b/src/mesa/vbo/vbo_rebase.c
index f3fe5f7..374d129 100644
--- a/src/mesa/vbo/vbo_rebase.c
+++ b/src/mesa/vb
From: Ian Romanick
This can be called from locations that don't have a context pointer
handy. This patch also adds enough infrastructure so that the unit
tests for the GLSL compiler and the stand-alone compiler will build and
function.
This patch was originally signed off by Ian Romanick, now v
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/link_varyings.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index c925c00..c3cc509 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/glsl/link_varyings.cpp
@@ -278,6 +278,11 @@ t
Check calloc return values in hash_table_insert() and
hash_table_replace()
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/program/prog_hash_table.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/program/prog_hash_table.c
b/src/mesa/program/prog_hash_table.c
index f45ed46.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/hash.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/main/hash.c b/src/mesa/main/hash.c
index 4c92005..976f7b8 100644
--- a/src/mesa/main/hash.c
+++ b/src/mesa/main/hash.c
@@ -115,10 +115,20 @@ _mesa_NewHashTable(void
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/intel_resolve_map.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_resolve_map.c
b/src/mesa/drivers/dri/i965/intel_resolve_map.c
index 04b5c94..c5a4cd7 100644
--- a/src/mesa/drivers/dri/i
On 04/07/2014 11:47 AM, Ian Romanick wrote:
> On 04/07/2014 09:14 AM, Eric Anholt wrote:
>> Ian Romanick writes:
>>
>>> On 04/04/2014 05:52 PM, Matt Turner wrote:
On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote:
> Fast forwarding 3 months from the 10.1 release (March 4th, planned for
On 04/07/2014 11:51 AM, Eric Anholt wrote:
> I thought I was seeing a bug in the code while reviewing, but it's not
> there.
One observation below. Regardless,
Reviewed-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/.gitignore | 1 +
> src/mesa/drivers/dri/i965/Makefile.am
On 04/07/2014 12:19 PM, Courtney Goeltzenleuchter wrote:
> Updated patch to include reference to bug that it resolves.
Where?
The proper way to do this is to send the path with git-send-mail, and
include extra verbage in the commit message like:
v3: Updated patch to include reference to bug that
Hmm... Wonder where my patches 9..12 vanished. They show in git
send-email as "Result: 250 ok: Message ### accepted". If they don't
magically show up here I will resend entire set tomorrow from better
connection.
/Juha-Pekka
On Mon, Apr 7, 2014 at 10:48 PM, Juha-Pekka Heikkila
wrote:
> Set of p
On 07/04/14 21:06, Juha-Pekka Heikkilä wrote:
> Hmm... Wonder where my patches 9..12 vanished. They show in git
> send-email as "Result: 250 ok: Message ### accepted". If they don't
> magically show up here I will resend entire set tomorrow from better
> connection.
>
An innocent bystander type o
On Mon, Apr 7, 2014 at 11:39 AM, Ian Romanick wrote:
> On 04/07/2014 10:28 AM, Aaron Watry wrote:
>> On Mon, Apr 7, 2014 at 12:19 PM, Matt Turner wrote:
>>> Notice our multiple values for M_PI_2, which rounded ...32 up to
>>> ...4 and ...5.
>>> ---
>>> The float casts are ugly. I tried to define
renderer_copy_prepare was setting the first sampler but never telling
the cso code how many samplers were actually used. Fix this.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_renderer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/
On 04/07/2014 02:48 PM, Thomas Hellstrom wrote:
renderer_copy_prepare was setting the first sampler but never telling
the cso code how many samplers were actually used. Fix this.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_renderer.c | 5 +++--
1 file cha
On Mon, Apr 7, 2014 at 11:21 PM, Emil Velikov wrote:
> On 07/04/14 21:06, Juha-Pekka Heikkilä wrote:
>> Hmm... Wonder where my patches 9..12 vanished. They show in git
>> send-email as "Result: 250 ok: Message ### accepted". If they don't
>> magically show up here I will resend entire set tomorro
On 12.03.2014 10:43, Kenneth Graunke wrote:
> arekm reported that using Chrome with GPU acceleration enabled on GM45
> triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.
>
> We definitely do not want to advertise reset notification support on
> Gen4-5 systems, since it needs
On 07/04/14 22:10, Juha-Pekka Heikkilä wrote:
> On Mon, Apr 7, 2014 at 11:21 PM, Emil Velikov
> wrote:
>> On 07/04/14 21:06, Juha-Pekka Heikkilä wrote:
>>> Hmm... Wonder where my patches 9..12 vanished. They show in git
>>> send-email as "Result: 250 ok: Message ### accepted". If they don't
>>>
Type mismatch caused random memory to be copied when casted
memory area was smaller than expected type.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/ff_fragment_shader.cpp | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/ff_fragment_shad
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/program/symbol_table.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/mesa/program/symbol_table.c b/src/mesa/program/symbol_table.c
index 9462978..5b22745 100644
--- a/src/mesa/program/symbol_table.c
+++ b/sr
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/link_uniform_blocks.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/glsl/link_uniform_blocks.cpp b/src/glsl/link_uniform_blocks.cpp
index 72d6c53..add3ef4 100644
--- a/src/glsl/link_uniform_blocks.cpp
+++ b/src/glsl/link_uniform_blo
check variable_storage() found the requested fs_reg.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index ce
Check return value from hash_table_find before using it as a pointer
Signed-off-by: Juha-Pekka Heikkila
---
src/glsl/loop_analysis.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
index d6a9ac7..78ac300 100644
-
Ian Romanick writes:
> On 04/07/2014 09:14 AM, Eric Anholt wrote:
>> Ian Romanick writes:
>>
>>> On 04/04/2014 05:52 PM, Matt Turner wrote:
On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick wrote:
> Fast forwarding 3 months from the 10.1 release (March 4th, planned for
> February 28th)
https://bugs.freedesktop.org/show_bug.cgi?id=77152
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Ian,
I didn't think this even got out. I was getting a weird error from
git-send-mail when it tried to send to the gmail server and I got
distracted with other things.
Here's log:
Send this email? ([y]es|[n]o|[q]uit|[a]ll): y
Password for 'smtp://court...@lunarg.com@smtp.gmail.com:587':
OK. Lo
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more explanatory comments
v3: add bugzilla
On 08/04/14 01:18, Courtney Goeltzenleuchter wrote:
> Hi Ian,
>
> I didn't think this even got out. I was getting a weird error from
> git-send-mail when it tried to send to the gmail server and I got
> distracted with other things.
>
> Here's log:
> Send this email? ([y]es|[n]o|[q]uit|[a]ll): y
https://bugs.freedesktop.org/show_bug.cgi?id=77161
Priority: medium
Bug ID: 77161
Keywords: regression
CC: mar...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1
Thanks Emil, I've got it sorted out I think. The format of the cc: was
incorrect, it shouldn't have the piece. Should look like: Cc:
"9.2 10.0 10.1"
I'll send out updated patch.
Courtney
On Mon, Apr 7, 2014 at 6:28 PM, Emil Velikov wrote:
> On 08/04/14 01:18, Courtney Goeltzenleuchter wrote:
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more explanatory comments
v3: add bugzilla
Hi!
Thanks, This looks good to me.
Reviewed-by: Thomas Hellstrom
/Thomas
On 04/07/2014 03:45 PM, Emil Velikov wrote:
> This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c.
>
> As the header is the one defining the API/ABI and is distributed
> during installation, we should be using i
On 04/07/2014 06:24 AM, Ian Romanick wrote:
> On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
>> The i965 MUL instruction doesn't natively support 32-bit by 32-bit
>> integer multiplication; additional instructions (MACH/MOV) are required.
>> However, we can avoid those if we know one of the operand
On 04/07/2014 05:41 AM, Ilia Mirkin wrote:
> On Mon, Apr 7, 2014 at 2:49 AM, Kenneth Graunke wrote:
>> The i965 MUL instruction doesn't natively support 32-bit by 32-bit
>> integer multiplication; additional instructions (MACH/MOV) are required.
>> However, we can avoid those if we know one of the
This extension is a huge grab-bag of "stuff that's in DX11". Break it
apart to make it clear what still needs to be done.
Signed-off-by: Chris Forbes
---
docs/GL3.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index bf51e3a..0688977 100644
--- a/
90 matches
Mail list logo
