Sorry, forgot the subject.
2014-09-13 2:06 GMT-04:00 Nikolay Martynov :
> Hi.
>
> When I watch netflix it crashes with this:
>
> err:d3d:wined3d_debug_callback 0x10972478: "GL_OUT_OF_MEMORY in
> glTexSubImage".
> err:d3d_surface:surface_upload_data > GL_OUT_OF_MEMORY
> (0x505) f
Hi.
When I watch netflix it crashes with this:
err:d3d:wined3d_debug_callback 0x10972478: "GL_OUT_OF_MEMORY in glTexSubImage".
err:d3d_surface:surface_upload_data > GL_OUT_OF_MEMORY
(0x505) from glTexSubImage2D @ surface.c / 1559
err:d3d:wined3d_debug_callback 0x10972478: "GL_OU
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Forget this patch, xexaxo told me how this works. We'll try figure this
out differently.
Dne 2014-09-13 02:17, David Heidelberger napsal:
Without this fix ilo_get_shader_param returns negative value.
Tested on Gallium Nine state tracker.
Tested-by: Nick Sarnie
Signed-off-by: David Heidelberg
https://bugs.freedesktop.org/show_bug.cgi?id=78318
--- Comment #3 from Chia-I Wu ---
The test passes with the bisected commit here (after fixing the build error
Kenneth mentioned)
$ glxinfo | grep git-
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.2.0-devel
(git-ca21cff)
OpenGL
Commit afe3d1556f6b77031f7025309511a0eea2a3e8df (i965: Stop doing
remapping of "special" regs.) stopped remapping delta_x/delta_y, and
additionally stopped considering them always-live. We later realized
delta_x was used in register allocaiton, so we actually needed to remap
it, which was fixed in
On Friday, September 12, 2014 04:30:55 PM Ian Romanick wrote:
> On 09/12/2014 03:16 PM, Kenneth Graunke wrote:
> > ir_rvalue::constant_expression_value() recursively walks down an IR
> > tree, attempting to reduce it to a single constant value. This is
> > useful when you want to know whether a va
On 09/12/2014 03:16 PM, Kenneth Graunke wrote:
> ir_rvalue::constant_expression_value() recursively walks down an IR
> tree, attempting to reduce it to a single constant value. This is
> useful when you want to know whether a variable has a constant
> expression value at all, and if so, what it is
Without this fix ilo_get_shader_param returns negative value.
Tested on Gallium Nine state tracker.
Tested-by: Nick Sarnie
Signed-off-by: David Heidelberger
---
src/gallium/drivers/ilo/ilo_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo
https://bugs.freedesktop.org/show_bug.cgi?id=72326
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
Blocks|
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Vinson Lee changed:
What|Removed |Added
Depends on||72326
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Vinson Lee changed:
What|Removed |Added
Depends on||78318
--
You are receiving this mail becau
Reviewed-by: Jordan Justen
On Fri, Sep 12, 2014 at 3:16 PM, Kenneth Graunke wrote:
> ir_rvalue::constant_expression_value() recursively walks down an IR
> tree, attempting to reduce it to a single constant value. This is
> useful when you want to know whether a variable has a constant
> express
https://bugs.freedesktop.org/show_bug.cgi?id=78318
Vinson Lee changed:
What|Removed |Added
CC||olva...@gmail.com
Keywords|
https://bugs.freedesktop.org/show_bug.cgi?id=77288
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
--- Comment #4 from Vinson Lee --
Trivial patch to create the pipe loader for ilo. All the code was already there.
Signed-off-by: Nick Sarnie
---
src/gallium/targets/pipe-loader/Makefile.am | 14 ++
src/gallium/targets/pipe-loader/pipe_i965.c | 26 ++
2 files changed, 40 insertions(+)
create
ir_rvalue::constant_expression_value() recursively walks down an IR
tree, attempting to reduce it to a single constant value. This is
useful when you want to know whether a variable has a constant
expression value at all, and if so, what it is.
The constant folding optimization pass attempts to r
Ok, so I actually applied the patch and benchmarked it. It seems to have
improved performance in a lot of cases that were mysteriously slow! It
looks like breaking it up freed up GCC to optimize the inside better.
--Jason
On Fri, Sep 12, 2014 at 2:48 PM, Jason Ekstrand
wrote:
> One comment be
One comment below. Otherwise, both of these look good to me.
Reviewed-by: Jason Ekstrand
I haven't applied it and benchmarked it myself, but I don't see anything
that would hurt performance.
--Jason
On Fri, Sep 12, 2014 at 9:17 AM, Brian Paul wrote:
> This reduces gcc -O3 compile time to 1/4
On 09/12/2014 09:05 AM, Kenneth Graunke wrote:
> On Friday, September 12, 2014 08:35:03 AM Ian Romanick wrote:
>> On 09/10/2014 03:41 PM, Kenneth Graunke wrote:
>>> In the non-indirect draw case, we call intel_upload_data to upload
>>> gl_BaseVertex. It makes brw->draw.draw_params_bo point to the
Ken,
All looks pretty sensible to me. It won't break the sampler indexing stuff.
- Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Friday, September 12, 2014 08:37:11 AM Ian Romanick wrote:
> On 09/10/2014 03:41 PM, Kenneth Graunke wrote:
> > We always uploaded them together, mostly out of laziness - both required
> > an additional vertex element. However, gl_VertexID now also requires an
> > additional vertex buffer for s
This extremely slow compilation is not actually an infinite loop.
But the compile time does increase with every unrolled loop step in the
shader.
The time to complete is 2^N, where N is the number of loop iterations.
The call to
(*rvalue)->accept(this);
in ir_constant_folding_visitor::handle_rval
https://bugs.freedesktop.org/show_bug.cgi?id=83445
Lionel Landwerlin changed:
What|Removed |Added
CC||k...@bitplanet.net
--
You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=83445
--- Comment #1 from Lionel Landwerlin ---
Created attachment 106199
--> https://bugs.freedesktop.org/attachment.cgi?id=106199&action=edit
egl/drm: do not crash when swapping buffers without any rendering
Reproducing the bit in the swap_buffers
On Wed, Sep 10, 2014 at 8:45 AM, Emil Velikov wrote:
> Hello all,
>
> The original plan from Ian was to have four release candidates prior to the
> final release. From what I can see there has been no serious amount of patches
> nominated for 10.3-rc4, so I'm planning to keep with the plan and rel
Put macro code in do {} while loop and put semicolons on macro calls
so auto indentation works properly.
---
src/mesa/main/format_utils.c | 74 ++
1 file changed, 38 insertions(+), 36 deletions(-)
diff --git a/src/mesa/main/format_utils.c b/src/mesa/main/
On 09/12/2014 08:09 AM, Brian Paul wrote:
On 09/11/2014 04:58 PM, Jason Ekstrand wrote:
On Thu, Sep 11, 2014 at 3:53 PM, Dieter Nützel mailto:die...@nuetzel-hh.de>> wrote:
Am 12.09.2014 00:31, schrieb Jason Ekstrand:
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel
mailto:d
This reduces gcc -O3 compile time to 1/4 of what it was on my system.
Reduces MSVC release build time too.
---
src/mesa/main/format_utils.c | 1030 ++
1 file changed, 550 insertions(+), 480 deletions(-)
diff --git a/src/mesa/main/format_utils.c b/src/mesa/m
Forgot to reply-all.
On Sep 12, 2014 9:05 AM, "Jason Ekstrand" wrote:
> The teximage-colors test that I pushed to piglit a week or two ago takes a
> --benchmark flag that bumps the texture size and does the upload 1000 times
> and gives you the average time to upload.
> --Jason
> On Sep 12, 2014
On Friday, September 12, 2014 08:35:03 AM Ian Romanick wrote:
> On 09/10/2014 03:41 PM, Kenneth Graunke wrote:
> > In the non-indirect draw case, we call intel_upload_data to upload
> > gl_BaseVertex. It makes brw->draw.draw_params_bo point to the upload
> > buffer, and increments the upload BO re
On 09/10/2014 03:41 PM, Kenneth Graunke wrote:
> We always uploaded them together, mostly out of laziness - both required
> an additional vertex element. However, gl_VertexID now also requires an
> additional vertex buffer for storing gl_BaseVertex; for non-indirect
> draws this also means uploadi
On 09/10/2014 03:41 PM, Kenneth Graunke wrote:
> In the non-indirect draw case, we call intel_upload_data to upload
> gl_BaseVertex. It makes brw->draw.draw_params_bo point to the upload
> buffer, and increments the upload BO reference count.
>
> So, we need to unreference it when making brw->dra
On Friday, September 12, 2014 07:54:38 AM Ian Romanick wrote:
> On 09/11/2014 10:07 PM, Kenneth Graunke wrote:
> > Samplers take up zero slots and therefore don't exist in the params
> > array, nor are they included in stage_prog_data->nr_params. There's no
> > need to store their size in param_si
On 09/12/2014 07:54 AM, Ian Romanick wrote:
> On 09/11/2014 10:07 PM, Kenneth Graunke wrote:
>> Samplers take up zero slots and therefore don't exist in the params
>> array, nor are they included in stage_prog_data->nr_params. There's no
>> need to store their size in param_size, as it's only used
On 09/12/2014 12:36 AM, Tapani Pälli wrote:
> Remap table for uniforms may contain empty entries when using explicit
> uniform locations. If no active/inactive variable exists with given
> location, remap table contains NULL.
>
> v2: move remap table bounds check before existence check (Ian Romani
On 09/12/2014 06:12 AM, Brian Paul wrote:
> Unreference the ctx->_Shader object before we delete all the pipeline
> objects in the hash table. Before, ctx->_Shader could point to freed
> memory when _mesa_reference_pipeline_object(ctx, &ctx->_Shader, NULL)
> was called.
>
> Fixes crash when exiti
On 09/11/2014 10:07 PM, Kenneth Graunke wrote:
> Samplers take up zero slots and therefore don't exist in the params
> array, nor are they included in stage_prog_data->nr_params. There's no
> need to store their size in param_size, as it's only used for dealing
> with arrays of "real" uniforms (on
https://bugs.freedesktop.org/show_bug.cgi?id=82268
Andreas Boll changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
I've pushed this series.
Thanks!
Andreas.
2014-09-06 20:12 GMT+02:00 Connor Abbott :
> On Sat, Sep 6, 2014 at 3:23 AM, Kenneth Graunke wrote:
>> On Friday, September 05, 2014 08:59:32 PM Connor Abbott wrote:
>>> q_total should never go below 0 (which is why it's defined as unsigned),
>>> and if
On 09/11/2014 04:58 PM, Jason Ekstrand wrote:
On Thu, Sep 11, 2014 at 3:53 PM, Dieter Nützel mailto:die...@nuetzel-hh.de>> wrote:
Am 12.09.2014 00:31, schrieb Jason Ekstrand:
On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel
mailto:die...@nuetzel-hh.de>>
wrote:
Mesa doesn't have ready to use binaries for any platforms. Windows is
not a special case.
I think the typical thing done by software providers is to build it
themselves and package it with their software as required.
Tim
On Fri, 2014-09-12 at 13:08 +, Rob Conde wrote:
> It seems to me that
Have you considered turning all inline functions into macros, so that
the compiler doesn't have to inline them?
Marek
On Fri, Sep 12, 2014 at 12:58 AM, Jason Ekstrand wrote:
>
>
> On Thu, Sep 11, 2014 at 3:53 PM, Dieter Nützel wrote:
>>
>> Am 12.09.2014 00:31, schrieb Jason Ekstrand:
>>
>>> On
https://bugs.freedesktop.org/show_bug.cgi?id=83785
--- Comment #3 from Roland Scheidegger ---
(In reply to comment #2)
> Sorry - I'm talking about llvmpipe (Speaking of...what is the right bug
> component to choose for llvmpipe)?
There isn't any, so typically it's other.
>
> Seems not too simpl
Unreference the ctx->_Shader object before we delete all the pipeline
objects in the hash table. Before, ctx->_Shader could point to freed
memory when _mesa_reference_pipeline_object(ctx, &ctx->_Shader, NULL)
was called.
Fixes crash when exiting the piglit rendezvous_by_location test on
Windows.
Reviewed-by: Marek Olšák
Marek
On Fri, Sep 12, 2014 at 10:31 AM, Andreas Boll
wrote:
> Needed for assert.
> Fixes build on BE archs with -Werror=implicit-function-declaration.
>
> In file included from
> ../../../../../src/gallium/auxiliary/draw/draw_fs.c:30:0:
> ../../../../../src/gallium/auxi
It seems to me that Mesa llvmpipe is the best positioned to be a replacement
OpenGL software renderer on windows for the MS Driver stuck at 1.1. However,
seeing as the project doesn't release ready to use windows binaries, it seems
that the project doesn't see it that way. Is this a bad interpre
Reviewed-by: Marek Olšák
Marek
On Fri, Sep 12, 2014 at 2:47 PM, Rob Clark wrote:
> From: Rob Clark
>
> Because of render-to-alpha (000x) shenanigans, freedreno needs to do
> some special handling when rendering to alpha-only formats. And I
> noticed that while we had _is_luminance(), _is_inte
From: Rob Clark
Because of render-to-alpha (000x) shenanigans, freedreno needs to do
some special handling when rendering to alpha-only formats. And I
noticed that while we had _is_luminance(), _is_intensity(), etc, an
_is_alpha() helper was missing. So fix that.
Signed-off-by: Rob Clark
---
File specific optimization as used for src/mesa/main/streaming-load-memcpy.c
currently will cause problems with LTO in the future
(see: https://bugs.freedesktop.org/show_bug.cgi?id=83669). Replace it with
in-file target specification.
This only works for gcc for now. The intel compiler has
__attri
https://bugs.freedesktop.org/show_bug.cgi?id=83785
--- Comment #2 from rcond...@hotmail.com ---
Sorry - I'm talking about llvmpipe (Speaking of...what is the right bug
component to choose for llvmpipe)?
Seems not too simple to fix, but on the other hand some low hanging fruit
(conceptually) to si
On 11/09/14 23:21, Ian Romanick wrote:
> On 09/10/2014 05:45 AM, Emil Velikov wrote:
>> Hello all,
>>
>> The original plan from Ian was to have four release candidates prior to the
>> final release. From what I can see there has been no serious amount of
>> patches
>> nominated for 10.3-rc4, so I'
Needed for assert.
Fixes build on BE archs with -Werror=implicit-function-declaration.
In file included from
../../../../../src/gallium/auxiliary/draw/draw_fs.c:30:0:
../../../../../src/gallium/auxiliary/util/u_math.h: In function
'util_memcpy_cpu_to_le32':
../../../../../src/gallium/auxiliary/uti
Am Donnerstag, 11. September 2014, 08:52:39 schrieb Matt Turner:
> On Thu, Sep 11, 2014 at 6:58 AM, Marc Dietrich wrote:
> > File specific optimization as used for
> > src/mesa/main/streaming-load-memcpy.c currently will cause problems with
> > LTO in the future
> > (see: https://bugs.freedesktop.
Remap table for uniforms may contain empty entries when using explicit
uniform locations. If no active/inactive variable exists with given
location, remap table contains NULL.
v2: move remap table bounds check before existence check (Ian Romanick)
Signed-off-by: Tapani Pälli
Tested-by: Erik Faye
55 matches
Mail list logo
