Signed-off-by: Maarten Lankhorst
---
src/gallium/drivers/nouveau/nouveau_fence.c | 76 -
src/gallium/drivers/nouveau/nouveau_fence.h | 22 +--
src/gallium/drivers/nouveau/nouveau_screen.c| 9 +++
src/gallium/drivers/nouveau/nouveau_screen.h| 14 ++---
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 124 -
1 file changed, 57 insertions(+), 67 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 015f139..c09a8c6 10
Commit ad4dc772 fixed an issue with the viewport not being restored
correctly. However it's rather hackish and confusing. Instead just mark
the viewport dirty and let the viewport validation take care of it.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nvc0/nvc0_context.h|
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 112 +++--
1 file changed, 51 insertions(+), 61 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 3fdb6ae..52a067e 10
Hi,
I am new to mesa and interested in working on open source project.
I have good knowledge about OpenGL and GLSL functionality. From the list, I
want to work on "Improved application of GLSL compiler optimization" .
What should I do to pick it? Can you help me with some documentation whi
Is there any specific reason for using SDNodes for everything?
Using intrinsics directly in patterns seems to result in a smaller
amount of code, which is always good.
Marek
On Mon, Jun 16, 2014 at 8:12 PM, Matt Arsenault
wrote:
> On 06/16/2014 08:45 AM, Tom Stellard wrote:
>>
>> You don't need
From: Ian Romanick
There are no texture borders in any version of OpenGL ES or desktop
OpenGL core profile.
Fixes piglit's gl-3.2-texture-border-deprecated.
Signed-off-by: Ian Romanick
Cc: "10.2
---
src/mesa/main/texparam.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/mai
From: Ian Romanick
There are no queries for GL_TEXTURE_LUMINANCE_SIZE,
GL_TEXTURE_INTENSITY_SIZE, GL_TEXTURE_LUMINANCE_TYPE, or
GL_TEXTURE_INTENSITY_TYPE in any version of OpenGL ES or desktop OpenGL
core profile.
NOTE: Without changes to piglit, this regresses
required-sized-texture-formats.
S
From: Ian Romanick
Previously, calling
glGenTextures(1, &t);
glBindTexture(GL_TEXTURE_2D, t);
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, 0xDEADBEEF, &value);
would not generate an error.
Signed-off-by: Ian Romanick
Cc: "10.2"
---
src/mesa/main/texparam.c | 63 +++
On 17.06.2014 00:08, Marek Olšák wrote:
> From: Marek Olšák
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=80115
--- Comment #1 from jpsinthe...@verizon.net ---
oops, pasted in description twice; sorry about that..
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=80115
Priority: medium
Bug ID: 80115
Assignee: mesa-dev@lists.freedesktop.org
Summary: MESA_META_DRAW_BUFFERS induced GL_INVALID_VALUE errors
Severity: normal
Classification: Unclassified
On 06/16/2014 08:45 AM, Tom Stellard wrote:
You don't need to add new SDNodes for all these instructions, you can just use
the intrinsic directly in the pattern.
The only reason to add SDNodes, is if there are optimizations / special lowering
we can do for these instructions.
I kind of like hav
2014-06-16 7:47 GMT+02:00 Pekka Paalanen :
> On Sun, 15 Jun 2014 13:49:48 +0200
> Giovanni Campagna wrote:
>
>> Hello all,
>>
>> This is the third attempt at swrast/llvmpipe support for DRM
>> drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.)
>>
>> I hope I addressed all of
2014-06-16 14:47 GMT+02:00 Marek Olšák :
> Does the new CAP cover resource_from_handle or resource_get_handle or both?
It covers both.
Giovanni
> Marek
>
> On Sun, Jun 15, 2014 at 1:49 PM, Giovanni Campagna
> wrote:
>> From: Giovanni Campagna
>>
>> The kms-dri swrast driver cannot share buffer
Since LLVM 3.5 will be released in August and my radeon patches adding
ARB_draw_indirect depend on it, I will commit ARB_draw_indirect
support for Gallium with softpipe and llvmpipe support earlier. My
plan is for patches 3,4,5,6 to get committed in one week from now, or
sooner if somebody reviews
https://bugs.freedesktop.org/show_bug.cgi?id=80034
charlie changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=80034
--- Comment #5 from charlie ---
Solved. Mesa compiled fine after I fixed the typo in CPPFLAGS but I removed
CPPFLAGS as suggested anyway.
>I use a simple 10-liner script that sets the options that I need from mesa.
People, your time was not a t
It's only for the state tracker. Drivers don't have to be concerned
about this and should just expose a fixed number of writable shader
resources that can be used with all types.
Marek
On Tue, Jun 17, 2014 at 1:26 AM, Ilia Mirkin wrote:
> On Mon, Jun 16, 2014 at 7:21 PM, Marek Olšák wrote:
>> [
On Mon, Jun 16, 2014 at 7:21 PM, Marek Olšák wrote:
> [Cc: Aditya]
>
> Aditya Avinash was interested in doing this as his first task in Mesa.
Oh awesome. Actually I think someone may have mentioned this fact to
me but then I forgot :) I'll look at other stuff then.
>
> But what you describe soun
[Cc: Aditya]
Aditya Avinash was interested in doing this as his first task in Mesa.
But what you describe sounds good. If we use set_shader_resources for
atomic counter buffer objects, we should also have a plan for how we
will bind shader storage buffers objects and images. I suggest we use
a di
On Fri, Jun 13, 2014 at 5:26 PM, Kenneth Graunke wrote:
> 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 tha
On 06/16/2014 04:45 PM, Marek Olšák wrote:
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index e2d26ee..f34a598 100644
--- a/src/mesa/state_tr
---
src/mesa/state_tracker/st_atom_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index e2d26ee..f34a598 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tr
Series is
Reviewed-by: Ian Romanick
On 06/15/2014 10:15 AM, Matt Turner wrote:
> ---
> src/glsl/opt_dead_builtin_varyings.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/glsl/opt_dead_builtin_varyings.cpp
> b/src/glsl/opt_dead_builtin_varyings.cpp
> index 6612
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 2b65056..6f87c78 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pip
Hello,
I've been toying with the idea of adding gallium support for the
atomic counters extension in gallium. Nouveau already largely supports
it, so it's mostly a question of plumbing. (One piece that's missing
in nouveau is _actually_ binding resources, but that can't be too
difficult... I hope.
No, 0423513c will fail to compile on stable branches.
Marek
On Sat, Jun 7, 2014 at 3:10 AM, Ian Romanick wrote:
> This patch didn't apply cleanly to 10.2. It appears that 0423513c also
> hits some code in this area. I picked d2261918 over, but should
> 0423513c also get picked?
>
> On 06/03/20
I haven't read the hardware docs on this, so I can't say if it's correct.
Acked-by: Marek Olšák
Marek
On Thu, May 1, 2014 at 4:55 AM, Tom Stellard wrote:
> v2:
> - Write RASTER_CONFIG for all SEs
>
> https://bugs.freedesktop.org/show_bug.cgi?id=60879
> ---
> src/gallium/drivers/radeonsi/si_
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Andreas Boll changed:
What|Removed |Added
Depends on||80069
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=80069
Andreas Boll changed:
What|Removed |Added
Blocks||79706
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=80069
Andreas Boll changed:
What|Removed |Added
Version|unspecified |10.2
--
You are receiving this mail beca
Yeah, that looks right.
Reviewed-by: Ian Romanick
Did you notice if other drivers have the same off-by-one issue?
On 06/16/2014 11:22 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Fix an off by one in the texture unit walk during texblend
> setup on gen2. This caused the
On 04/21/2014 04:38 AM, Iago Toral Quiroga wrote:
> Currently it only considers the cases of gl_ModelViewProjectionMatrix and
> gl_TextureMatrix. The same optimization can be done also for
> gl_ModelViewMatrix, gl_ProjectionMatrix and the corresponding inverses.
I've been looking at some thing sim
Why are there SDNodes for the other "sample" intrinsics then?
Marek
On Mon, Jun 16, 2014 at 5:45 PM, Tom Stellard wrote:
> On Thu, Jun 12, 2014 at 02:11:10AM +0200, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This adds a new type of intrinsic and SDNode: SampleRaw.
>> All fields of the MIMG o
From: Ville Syrjälä
Fix an off by one in the texture unit walk during texblend
setup on gen2. This caused the last enabled texunit to be
skipped resulting in totally messed up texturing.
This is a regression introduced here:
commit 1ad443ecdd694dd9bf3c4a5050d749fb80db6fa2
Author: Eric Anholt
On Mon, 16 Jun 2014 17:15:47 +0200
Giovanni Campagna wrote:
> 2014-06-16 7:47 GMT+02:00 Pekka Paalanen :
> > On Sun, 15 Jun 2014 13:49:48 +0200
> > Giovanni Campagna wrote:
> >
> >> Hello all,
> >>
> >> This is the third attempt at swrast/llvmpipe support for DRM
> >> drivers that don't have use
On Wed, Jun 11, 2014 at 6:11 PM, Carl Worth wrote:
> Previously, the test suite was expecting the compiler to allow a redefintion
> of a macro with whitespace added, but gcc is more strict and allows only for
> changes in the amounts of whitespace, (but insists that whitespace exist or
> not in ex
On Wed, Jun 11, 2014 at 5:32 PM, Carl Worth wrote:
> Currently verifying that an #undef of __FILE__, __LINE__, or __VERSION__ will
> generate an error.
> ---
> src/glsl/glcpp/tests/120-undef-builtin.c | 3 +++
> src/glsl/glcpp/tests/120-undef-builtin.c.expected | 7 +++
> 2 files cha
On Mon, Jun 16, 2014 at 1:20 PM, Jordan Justen wrote:
> On Mon, Jun 16, 2014 at 1:05 AM, Samuel Iglesias Gonsálvez
> wrote:
>> On Sun, 2014-06-15 at 19:18 -0400, Ilia Mirkin wrote:
>>> On Wed, Jun 11, 2014 at 12:31 PM, Jordan Justen wrote:
>>> > On Wed, Jun 11, 2014 at 2:49 AM, Iago Toral wrote
On Mon, Jun 16, 2014 at 1:05 AM, Samuel Iglesias Gonsálvez
wrote:
> On Sun, 2014-06-15 at 19:18 -0400, Ilia Mirkin wrote:
>> On Wed, Jun 11, 2014 at 12:31 PM, Jordan Justen wrote:
>> > On Wed, Jun 11, 2014 at 2:49 AM, Iago Toral wrote:
>> >> Hi Chris,
>> >>
>> >> thanks for the quick review!
>>
On Mon, Jun 16, 2014 at 8:49 AM, Neil Roberts wrote:
> Ilia Mirkin writes:
>
>> Will it? What about the MS case? I thought that for generic you had to
>> do a shader-based approach.
>
> Ah yes, you're right the commit message is nonsense. I guess I should
> also avoid enabling the extension at al
Not sure what you did with these patches, but the spacing is all
off... makes them hard to read (for me) and also they won't apply for
testing. Mind regenerating them? Perhaps you were doing a 2-way merge?
On Mon, Jun 16, 2014 at 12:00 PM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhor
Signed-off-by: Maarten Lankhorst
---
src/gallium/drivers/nouveau/nouveau_fence.c | 76 -
src/gallium/drivers/nouveau/nouveau_fence.h | 22 +--
src/gallium/drivers/nouveau/nouveau_screen.c| 9 +++
src/gallium/drivers/nouveau/nouveau_screen.h| 14 ++---
Am 16.06.2014 17:02, schrieb Marek Olšák:
> From: Marek Olšák
>
> The extension is always supported if GLSL 1.30 is supported.
>
> Softpipe and llvmpipe support is also added (trivial).
> Radeon and nouveau support is already done.
> ---
> docs/GL3.txt| 2 +-
On Thu, Jun 12, 2014 at 02:11:11AM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
LGTM.
> ---
> test/CodeGen/R600/llvm.SI.gather4.ll | 508
> +++
> 1 file changed, 508 insertions(+)
> create mode 100644 test/CodeGen/R600/llvm.SI.gather4.ll
>
> diff --git a/t
On Thu, Jun 12, 2014 at 02:11:10AM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> This adds a new type of intrinsic and SDNode: SampleRaw.
> All fields of the MIMG opcodes are exposed and can be set by Mesa,
> even DMASK. All GATHER4 variants are added and there are a lot of them.
>
> v2: doc
https://bugs.freedesktop.org/show_bug.cgi?id=79949
Alberto González changed:
What|Removed |Added
CC||luis6...@yahoo.com
--
You are receiv
On Fri, Jun 13, 2014 at 10:35:38PM +0200, Bruno Jiménez wrote:
> 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
po
On Fri, Jun 13, 2014 at 10:35:37PM +0200, Bruno Jiménez wrote:
> ---
> src/gallium/drivers/r600/compute_memory_pool.c | 158
> -
> 1 file changed, 78 insertions(+), 80 deletions(-)
>
There are double linked list helper functions in gallium util, which we
should use rathe
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 21 -
src/gallium/drivers/radeonsi/si_shader.h | 1 +
src/gallium/drivers/radeonsi/si_state_draw.c | 4
src/gallium/drivers/radeonsi/sid.h | 4
4 files changed, 29 insertions(+), 1
On Fri, Jun 13, 2014 at 10:35:36PM +0200, Bruno Jiménez wrote:
> 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 fi
From: Dave Airlie
Marek: also handle cube arrays
Signed-off-by: Marek Olšák
---
src/mesa/state_tracker/st_texture.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_tracker/st_texture.c
index 92035e8..c148821 100644
--- a/src/mes
From: Marek Olšák
The extension is always supported if GLSL 1.30 is supported.
Softpipe and llvmpipe support is also added (trivial).
Radeon and nouveau support is already done.
---
docs/GL3.txt| 2 +-
docs/relnotes/10.3.html | 1 +
From: Marek Olšák
It was set to pipe_resource::last_level and _MaxLevel was embedded in max_lod,
that's why it worked for ordinary texturing. However, min_lod doesn't have
any effect on texelFetch and textureQueryLevels, so we must still set
last_level correctly.
---
src/mesa/state_tracker/st_at
On Fri, Jun 13, 2014 at 10:35:35PM +0200, Bruno Jiménez wrote:
> 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
On Fri, Jun 13, 2014 at 10:35:34PM +0200, Bruno Jiménez wrote:
> 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
On Fri, Jun 13, 2014 at 10:35:33PM +0200, Bruno Jiménez wrote:
Reviewed-by: Tom Stellard
> ---
> 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(-)
>
>
On Sun, Jun 15, 2014 at 01:08:14PM +0200, Francisco Jerez wrote:
> Tom Stellard writes:
>
> > 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
On Fri, Jun 13, 2014 at 10:35:32PM +0200, Bruno Jiménez wrote:
> 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)
Reviewed-by: Tom Stellard
> ---
> src/gallium/drivers/r600/compute_memory_pool.c | 99
> +-
On Fri, Jun 13, 2014 at 10:35:31PM +0200, Bruno Jiménez wrote:
> 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
On Fri, Jun 13, 2014 at 10:35:30PM +0200, Bruno Jiménez wrote:
> 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 buffe
The presence of EXT_texture_integer implies EXT_gpu_shader4, so I
added "ctx->Version >= 30 || ctx->Extensions.EXT_texture_integer"
everywhere to allow drivers to disable EXT_texture_integer but not
lose integer textures from GL 3.0.
Marek
On Mon, Jun 16, 2014 at 12:49 PM, Neil Roberts wrote:
>
Ilia Mirkin writes:
> Will it? What about the MS case? I thought that for generic you had to
> do a shader-based approach.
Ah yes, you're right the commit message is nonsense. I guess I should
also avoid enabling the extension at all until the next patch.
> While I'm sure we all love the
>
> wh
Does the new CAP cover resource_from_handle or resource_get_handle or both?
Marek
On Sun, Jun 15, 2014 at 1:49 PM, Giovanni Campagna
wrote:
> From: Giovanni Campagna
>
> The kms-dri swrast driver cannot share buffers using the GEM,
> so it must tell the loader to disable extensions relying on
>
Ilia Mirkin writes:
>> + if (ctx->Version >= 30 || ctx->Extensions.EXT_texture_integer) {
>
> Just ctx->Extensions.EXT_texture_integer should be enough here, no?
I'm reluctant to change this because every other place in the code that
checks for integer textures does it in the same way. Perhaps
https://bugs.freedesktop.org/show_bug.cgi?id=80034
--- Comment #4 from Emil Velikov ---
(In reply to comment #2)
...
> I don't believe the CFLAGS have changed since I last successfully built mesa
> with them.
>
> export CFLAGS="-m${LIBDIRSUFFIX} -O3 -march=native -pipe"
> export CXXFLAGS="${CFLA
https://bugs.freedesktop.org/show_bug.cgi?id=74010
Tapani Pälli changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
op 13-06-14 07:39, Michel Dänzer schreef:
On 12.06.2014 17:00, Maarten Lankhorst wrote:
I'm pretty sure that p_atomic_dec_zero should return 1 if the count
drops to zero.
Cc: "10.2 10.1 10.0"
I don't think the stable tag is justified: These bugs have been there
for more than four years. Nothi
On Sun, 2014-06-15 at 19:18 -0400, Ilia Mirkin wrote:
> On Wed, Jun 11, 2014 at 12:31 PM, Jordan Justen wrote:
> > On Wed, Jun 11, 2014 at 2:49 AM, Iago Toral wrote:
> >> Hi Chris,
> >>
> >> thanks for the quick review!
> >>
> >> On Wed, 2014-06-11 at 21:45 +1200, Chris Forbes wrote:
> >>> I sent
https://bugs.freedesktop.org/show_bug.cgi?id=80034
--- Comment #3 from Tapani Pälli ---
(In reply to comment #2)
> export CFLAGS="-m${LIBDIRSUFFIX} -O3 -march=native -pipe"
> export CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
> export CPPFLAGS="${CXXLAGS} -I${XBUILD}/include
> -L${XBUILD}/li
On 06/15/2014 08:17 PM, Matt Turner wrote:
Perhaps useful for debugging? Never used otherwise. Added by commit
8cf5bdad.
---
src/mesa/main/performance_monitor.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/src/mesa/main/performance_monitor.c
b/src/mesa/main/performance_mo
Have a look at the ir_texture stuff -- it's complex, but it has a
whole bunch of ir_value* for the various texture parameters. You'll be
able to do something simpler, but will probably have to touch most of
the same places that currently treat texturing specially.
On Mon, Jun 16, 2014 at 7:04 PM,
Hi Chris,
On Sat, 2014-06-14 at 08:34 +1200, Chris Forbes wrote:
> 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
74 matches
Mail list logo
