From: Kenneth Graunke
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
b/src/mesa/drivers/dri/i965/
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 269 +
1 file changed, 161 insertions(+), 108 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 0ae3f2d..7e08d1d 100644
--- a/src/mesa/drivers/dri/i9
---
src/mesa/drivers/dri/i965/brw_eu.c | 2 +-
src/mesa/drivers/dri/i965/brw_eu.h | 5 ++--
src/mesa/drivers/dri/i965/brw_eu_compact.c | 42 -
src/mesa/drivers/dri/i965/brw_inst.h| 6 ++---
src/mesa/drivers/dri/i965/brw_structs.h | 26 -
---
src/mesa/drivers/dri/i965/brw_structs.h | 630 +---
1 file changed, 1 insertion(+), 629 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_structs.h
b/src/mesa/drivers/dri/i965/brw_structs.h
index 803dc6e..385bb3c 100644
--- a/src/mesa/drivers/dri/i965/brw_st
---
src/mesa/drivers/dri/i965/brw_context.h | 4 +--
src/mesa/drivers/dri/i965/brw_disasm.c | 54 ++---
src/mesa/drivers/dri/i965/brw_eu.c | 2 +-
src/mesa/drivers/dri/i965/brw_eu_compact.c | 4 +--
src/mesa/drivers/dri/i965/test_eu_compact.c | 2 +-
---
src/mesa/drivers/dri/i965/brw_eu_compact.c | 82 --
1 file changed, 44 insertions(+), 38 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
b/src/mesa/drivers/dri/i965/brw_eu_compact.c
index 3814657..769056d 100644
--- a/src/mesa/drivers/dri/i965
From: Kenneth Graunke
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/br
From: Kenneth Graunke
We're going to use fs_generator/vec4_generator for Gen8+ code soon,
thanks to the new brw_instruction API. When we do, we'll generally
want to take the Haswell paths on Gen8+ as well.
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/
---
src/mesa/drivers/dri/i965/brw_disasm.c | 649 -
1 file changed, 310 insertions(+), 339 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/drivers/dri/i965/brw_disasm.c
index 11f53eb..0da05a2 100644
--- a/src/mesa/drivers/dri/i965/brw_d
---
src/mesa/drivers/dri/i965/brw_gs_emit.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_gs_emit.c
b/src/mesa/drivers/dri/i965/brw_gs_emit.c
index cb9dd7b..320d59c 100644
--- a/src/mesa/drivers/dri/i965/brw_gs_emit.c
+++ b/src/mesa/drive
For now nothing uses this, but we can incrementally convert.
---
src/mesa/drivers/dri/i965/brw_inst.h | 90
1 file changed, 90 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_inst.h
b/src/mesa/drivers/dri/i965/brw_inst.h
index c2dda5d..83a64fe 100644
From: Kenneth Graunke
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/test_eu_compact.c | 41 +
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/test_eu_compact.c
b/src/mesa/drivers/dri/
From: Kenneth Graunke
The new brw_inst API is going to require a brw pointer in order
to access fields (so it can do generation checks). Plumb it in now.
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_eu.h | 2 +-
src/mesa/drivers/dri/i965/
From: Kenneth Graunke
This is similar to gen8_instruction, and will replace it
For now nothing uses this, but we can incrementally convert.
The new API takes the existing brw_instruction pointers to ease
conversion; when done, we can simply drop the old structure and rename
struct brw_instructio
From: Kenneth Graunke
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_eu.c | 30 +++---
src/mesa/drivers/dri/i965/brw_eu.h | 3 ++-
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_
From: Kenneth Graunke
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_clip_line.c | 21 +++--
src/mesa/drivers/dri/i965/brw_clip_tri.c | 44 +++
src/mesa/drivers/dri/i965/brw_clip_unfilled.c | 26 +--
From: Kenneth Graunke
Reviewed-by: Matt Turner
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_sf_emit.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sf_emit.c
b/src/mesa/drivers/dri/i965/brw_sf_emit.c
index 8f26e41.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
This reverts commit 20be3ff57670529a410b30a1008a71e768d08428.
No evidence of ever being used.
---
src/mesa/drivers/dri/i965/brw_eu.h | 2 --
src/mesa/drivers/dri/i965/brw_eu_emit.c | 16
src/mesa/drivers/dri/i965/brw_reg.h | 16
3 files changed, 34 dele
Neil,
I've been thinking about this same thing. My one comment is that it might
be good to call that function after the driver has installed its
extensions. That way you can make meta extensions dependant on driver
extensions. Not sure how useful that is though.
--Jason Ekstrand
On Jun 13, 2014
This patch fixes several clang constant-logical-operand warnings such as
the following.
../../../../../src/mesa/tnl_dd/t_dd_tritmp.h:130:32: warning: use of logical
'||' with constant operand [-Wconstant-logical-operand]
if (DO_TWOSIDE || DO_OFFSET || DO_UNFILLED || DO_TWOSTENCIL)
On Fri, Jun 13, 2014 at 8:59 PM, Neil Roberts wrote:
> Here is a second attempt at implementing the GL_ARB_clear_texture
> extension. I've split up the patch into serveral smaller patches. They
> are based on top of the first patch in Ilia's series which is
> available here:
>
> https://github.com
From: Marek Olšák
This was wrong for a very long time. I wonder if the array size has any
effect on anything.
---
src/gallium/drivers/radeonsi/si_shader.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeo
On Fri, Jun 13, 2014 at 8:59 PM, Neil Roberts wrote:
> This adds the driver entry point for glClearTexSubImage and fills in the
> _mesa_ClearTexImage and _mesa_ClearTexSubImage functions that call it.
> ---
> src/mesa/main/dd.h | 14 +++
> src/mesa/main/teximage.c | 241
>
On Fri, Jun 13, 2014 at 8:59 PM, Neil Roberts wrote:
> Adds an implmentation of the ClearTexSubImage driver entry point that just
> maps the texture and writes the values in. This should work as a reliable
> fallback on any driver.
Will it? What about the MS case? I thought that for generic you h
https://bugs.freedesktop.org/show_bug.cgi?id=80012
Priority: medium
Bug ID: 80012
Keywords: have-backtrace
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] draw/draw_gs.c:113:tgsi_fetch_gs_outputs:
Assertion `!uti
https://bugs.freedesktop.org/show_bug.cgi?id=79472
Vinson Lee changed:
What|Removed |Added
Summary|[llvmpipe] SIGSEGV |[llvmpipe] [softpipe]
|sr
https://bugs.freedesktop.org/show_bug.cgi?id=80011
Priority: medium
Bug ID: 80011
Keywords: have-backtrace
Assignee: mesa-dev@lists.freedesktop.org
Summary: [softpipe] tgsi/tgsi_exec.c:2023:exec_txf: Assertion
`0' failed.
Adds an implmentation of the ClearTexSubImage driver entry point that just
maps the texture and writes the values in. This should work as a reliable
fallback on any driver.
---
src/mesa/drivers/common/driverfuncs.c | 2 +
src/mesa/main/texstore.c | 70
Adds an implementation of the ClearTexSubImage driver entry point that tries
to set up an FBO to render to the texture and then calls glClear with a
scissor to perform the actual clear. If an FBO can't be created for the
texture then it will fall back to using _mesa_store_ClearTexSubImage.
---
src
This adds the driver entry point for glClearTexSubImage and fills in the
_mesa_ClearTexImage and _mesa_ClearTexSubImage functions that call it.
---
src/mesa/main/dd.h | 14 +++
src/mesa/main/teximage.c | 241 ++-
src/mesa/main/teximage.h | 12 +++
In texture_error_check() there was a snippet of code to check whether the
given format and internal format are basically compatible. This has been split
out into its own static helper function so that it can be used by an
implementation of glClearTexImage too.
---
src/mesa/main/teximage.c | 63 +++
Here is a second attempt at implementing the GL_ARB_clear_texture
extension. I've split up the patch into serveral smaller patches. They
are based on top of the first patch in Ilia's series which is
available here:
https://github.com/imirkin/mesa/commit/9c2467020a8a3895a1debbad06561f37
I think I'
This adds a function called _mesa_init_driver_extensions that is called by all
DRI-based drivers. The intention is that any extensions that are implemented
directly by _mesa_init_driver_functions without any driver-specific
entrypoints will be enabled here.
---
src/mesa/drivers/common/driverfuncs.
We only enable HiZ for miplevels which are aligned on 8x4 blocks. When
debugging HiZ failures, it's useful to know whether a particular
miplevel is using HiZ or not.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 ++
1 file changed, 2 insertions(+)
diff --
Like on Haswell, we need to use 8x4 aligned rectangle primitives for
hierarchical depth buffer resolves and depth clears. See the comments
in brw_blorp.cpp's brw_hiz_op_params() constructor. (The Broadwell
documentation confirms that this is still necessary.)
This patch makes the Broadwell code
On Friday, June 13, 2014 04:04:44 PM Carl Worth wrote:
> The lexer was insisting that there be at least one character after "#pragma"
> and before the end of the line. This caused an error for a line consisting
> only of "#pragma" which volates at least the following sentence from the
GLSL
> ES Sp
On Friday, June 13, 2014 04:04:43 PM Carl Worth wrote:
> We've always warned about this case, but a recent confromance test expects
> this to be an error that causes compilation to fail. Make it so.
>
> Also add a "make check" test to ensure these errors are generated.
>
> This fixes at least the
On Friday, June 13, 2014 03:27:13 PM Carl Worth wrote:
> This continues my ongoing series to make the preprocessor conform more
> precisely to the specifications.
>
> I am sprinkling these patches out as I write and test them because they are
> each logically independent. If people would prefer th
So these last two, (very self-explanatory), patches complete my series based
on an initial pass over preprocessor-related failures I saw in the Khronos
GLES3 CTS.
There is at least one more failure caused by a test case that has a non-ASCII
character (decimal 129) in the name given to a #extension
We've always warned about this case, but a recent confromance test expects
this to be an error that causes compilation to fail. Make it so.
Also add a "make check" test to ensure these errors are generated.
This fixes at least the following Khronos GLES3 conformance tests:
invalid_condit
The lexer was insisting that there be at least one character after "#pragma"
and before the end of the line. This caused an error for a line consisting
only of "#pragma" which volates at least the following sentence from the GLSL
ES Specification 3.00.4:
The scope as well as the effect of
On Friday, June 13, 2014 03:11:00 PM Kenneth Graunke wrote:
> On Friday, June 13, 2014 12:38:43 PM Topi Pohjolainen wrote:
> > This fixes framebuffer_blit_functionality_scissor_blit.test in
> > gles3 cts.
> >
> > Signed-off-by: Topi Pohjolainen
> > ---
> > src/mesa/drivers/dri/i965/gen8_depth_st
This continues my ongoing series to make the preprocessor conform more
precisely to the specifications.
I am sprinkling these patches out as I write and test them because they are
each logically independent. If people would prefer that I batch them up and
submit them as a single series, I can do t
The GLSL ES Specification 3.00.4 says:
#if, #ifdef, #ifndef, #else, #elif, and #endif are defined to operate
as for C++ except for the following:
...
• Undefined identifiers not consumed by the defined operator do not
default to '0'. Use of such identifier
While writing the previous commit message, I just felt bad documenting the
shortcoming of the change, (that undefined macro names would not be reported
in error messages).
Fix this by preserving the first-encounterd undefined macro name and reporting
that in any resulting error message.
---
src/g
On Friday, June 13, 2014 12:38:43 PM Topi Pohjolainen wrote:
> This fixes framebuffer_blit_functionality_scissor_blit.test in
> gles3 cts.
>
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/gen8_depth_state.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff -
---
src/gallium/drivers/r600/compute_memory_pool.c | 140 +++--
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
2 files changed, 87 insertions(+), 58 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_poo
With this we can assure that mapped buffers will never change
its position when relocating the pool.
This patch should finally solve the mapping bug.
---
src/gallium/drivers/r600/evergreen_compute.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers
This function will be used when we want to map an item
that it's already in the pool.
---
src/gallium/drivers/r600/compute_memory_pool.c | 45 ++
src/gallium/drivers/r600/compute_memory_pool.h | 3 ++
2 files changed, 48 insertions(+)
diff --git a/src/gallium/drivers/r600
Hi,
This is my latest attempt to fix the mapping bug and, so far,
it seems that it is resolved.
This series changes completely how OpenCL buffers are handled
by the r600g driver. Before this, we would add them directly to
a pool, and this pool would grow whenever we needed more space.
But this pr
---
src/gallium/drivers/r600/compute_memory_pool.c | 158 -
1 file changed, 78 insertions(+), 80 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 624b50d..26b9f98 100644
--- a/src/gallium/drive
These statuses will help track whether the items are mapped
or if they should be promoted to or demoted from the pool
---
src/gallium/drivers/r600/compute_memory_pool.h | 7 ++-
src/gallium/drivers/r600/evergreen_compute.c | 12
2 files changed, 18 insertions(+), 1 deletion(-)
Now we will have a list with the items that are in the pool
(item_list) and the items that are outside it (unallocated_list)
---
src/gallium/drivers/r600/compute_memory_pool.c | 99 +-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 49 insertions(+),
Acording to the OpenCL spec, it is possible to have a buffer mapped
for reading and at read from it using commands or buffers.
With this we can keep the mapping (that exists against the
temporary item) and read with a kernel (from the item we have
just added to the pool) without problems.
---
src
This patch changes completely the way buffers are added to the
compute_memory_pool. Before this, whenever we were going to
map a buffer or write to or read from it, it would get placed
into the pool. Now, every unallocated buffer has its own
r600_resource until it is allocated in the pool.
NOTE: T
All the *Enqueue* functions that read/write buffers (except
clEnqueueCopyBuffer) would map the associated resource, making
it to be demoted if it was in the pool.
But we possitively know that this transfer will end before
any kernel is launched, so there's no need to demote it.
NOTE: As a proof o
Right, this happens because ir_emit_vertex doesn't take a proper
operand, so it can't keep it alive.
What I think you want to do is change the stream in ir_emit_vertex and
ir_end_primitive to be a pointer to ir_rvalue (and apply the various
tweaks required to consider it alive; have rvalue visitor
On Fri, Jun 13, 2014 at 12:47 PM, Jason Ekstrand wrote:
> On Fri, Jun 13, 2014 at 12:20 PM, Brian Paul wrote:
>> On 06/13/2014 01:17 PM, Jason Ekstrand wrote:
>>>
>>> ---
>>> src/mesa/drivers/common/meta_blit.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/
On Fri, Jun 13, 2014 at 12:20 PM, Brian Paul wrote:
> On 06/13/2014 01:17 PM, Jason Ekstrand wrote:
>
>> ---
>> src/mesa/drivers/common/meta_blit.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/common/meta_blit.c
>> b/src/mesa/drivers/common/meta_
Hi,
Looks good to me.
-Bruno
On Fri, 2014-06-13 at 12:58 -0400, Tom Stellard wrote:
> Some apps will abort if they detect 0 compute units. This fixes
> crashes in some OpenCV tests.
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Nice find.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 06/13/2014 01:17 PM, Jason Ekstrand wrote:
---
src/mesa/drivers/common/meta_blit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index aa12e04..2b99b99 100644
--- a/src/mesa/drivers/common/meta_
---
src/mesa/drivers/common/meta_blit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index aa12e04..2b99b99 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@
We were serializing the binaries once when clGetProgramInfo was called
with CL_PROGRAM_BINARY_SIZES and then again when it was called with
CL_PROGRAM_BINARIES. This was slowing down some OpenCV tests which were
building binary kernel caches.
This improves the run-time of OpenCV's OCL_ImgProc/CvtC
On Thu, Jun 12, 2014 at 11:42 PM, Tapani Pälli wrote:
> On 06/07/2014 02:57 AM, Anuj Phogat wrote:
>> Fixes gles3 Khronos CTS tests:
>> tokens_after_else_vertex
>> tokens_after_else_fragment
>>
>> Cc:
>> Signed-off-by: Anuj Phogat
>> ---
>> src/glsl/glcpp/glcpp-lex.l | 4
>> 1 file changed
On Fri, Jun 13, 2014 at 12:38:43PM +0300, Topi Pohjolainen wrote:
> This fixes framebuffer_blit_functionality_scissor_blit.test in
> gles3 cts.
>
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/gen8_depth_state.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> d
Some apps will abort if they detect 0 compute units. This fixes
crashes in some OpenCV tests.
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe
Brian Paul writes:
> Reviewed-by: Brian Paul
>
> Do you need someone to commit/push this?
Thanks for the review. I do have commit access for Mesa so I've just
pushed it.
As an aside, I don't have commit access for Piglit and I haven't been
able to find someone who can grant me access. If you a
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 13, 2014 at 5:23 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> This way, the compiler warns about unhandled caps.
>
> Signed-off-by: Michel Dänzer
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
> 1 file changed, 3 insertions
On 06/12/2014 10:52 AM, Neil Roberts wrote:
The comment for _mesa_is_type_integer is confusing because it says that it
returns whether the type is an “integer (non-normalized)” format. I don't
think it makes sense to say whether a type is normalized or not because it
depends on what format it is
https://bugs.freedesktop.org/show_bug.cgi?id=74010
--- Comment #10 from Brian Paul ---
Just FYI: There are some GL apps out there that use depth buffering but don't
bother to request a GLX visual with a depth buffer. Topogun is one example.
There's a DRI config option called "always_have_depth
On Fri, 2014-06-13 at 10:28 +0200, Iago Toral wrote:
> I forgot to add an important piece of info. I also had to add this in
> the opt_dead_code.cpp, do_dead_code():
>
> if (strcmp(entry->var->name, "stream") == 0)
> continue;
>
> without that, the variable referenced by ir_emit_vertex() gets
https://bugs.freedesktop.org/show_bug.cgi?id=74010
--- Comment #9 from Tapani Pälli ---
The problem is with the glxconfig that gets chosen. The application queries for
compatible list of configs with glXChooseFBConfig and then blindly selects the
first one. Although attributes for config query st
This fixes framebuffer_blit_functionality_scissor_blit.test in
gles3 cts.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/gen8_depth_state.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c
b/src/mesa/drivers/dri/i96
v2:
Add RADEON_INFO_ACTIVE_CU_COUNT as a define, as suggested by
Tom Stellard
---
src/gallium/drivers/radeon/r600_pipe_common.c | 7 +++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 7 +++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 1 +
3 files changed, 15 inser
https://bugs.freedesktop.org/show_bug.cgi?id=74010
Tapani Pälli changed:
What|Removed |Added
CC||lem...@gmail.com
--- Comment #8 from Tapa
I forgot to add an important piece of info. I also had to add this in
the opt_dead_code.cpp, do_dead_code():
if (strcmp(entry->var->name, "stream") == 0)
continue;
without that, the variable referenced by ir_emit_vertex() gets trashed
anyway, whether the ralloc context in link_shaders is detr
After debugging I have more information about what is going on. There
are two problems, one is that the stream variable in ir_emit_vertex gets
trashed and the other one is that even if we manage to avoid that it
won't get its value assigned. I explain how these two come to happen
below and maybe so
79 matches
Mail list logo
