On 08/22/2014 08:31 AM, Tapani Pälli wrote:
> On 08/22/2014 02:25 AM, Micael Dias wrote:
>> ---
>> If samplers occupy zero locations we can run into a lot of issues. See
>> #82921.
>> I briefly tested this with my own code (which was previously crashing and
>> misbehaving) and also ran other apps
On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote:
> The primary goal of these patches is to introduce what I've started
> calling, "prelocations" on Broadwell. A prelocation is like a
> relocation, except not. When a GPU client specifies a prelocation, it is
> instructing the kernel whe
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82846
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82929
---
Planning to commit this to master as well as to 10.3 directly,
since BDW is just broken without it.
src/mesa/drivers/dri/i965/brw_eu_compact.c | 14 ++
1 file
Aaron Watry writes:
> Signed-off-by: Aaron Watry
Reviewed-by: Francisco Jerez
> ---
> src/gallium/state_trackers/clover/api/platform.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
> b/src/gallium/state_trackers
On 08/22/2014 02:25 AM, Micael Dias wrote:
> ---
> If samplers occupy zero locations we can run into a lot of issues. See #82921.
> I briefly tested this with my own code (which was previously crashing and
> misbehaving) and also ran other apps and everything seems to work fine.
> I'm not used to c
Another patch was sent for this bug as well:
[PATCH] glsl: uniform sampler should occupy 1 location
I don't have any idea what the appropriate fix is, I just wanted to
let you know.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.f
Signed-off-by: Tapani Pälli
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82921
---
src/glsl/glsl_types.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp
index 66e9b13..6c42284 100644
--- a/src/glsl/glsl_types.cp
This was a quick proof of concept to show the new API for prelocating
buffers.
It needs way more testing, to not ifdef the no-relocs, and to do a
libdrm ABI dep bump.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
src
The primary goal of these patches is to introduce what I've started
calling, "prelocations" on Broadwell. A prelocation is like a
relocation, except not. When a GPU client specifies a prelocation, it is
instructing the kernel where in the GPU address the buffer should be
mapped. The mechanic works
On 22 August 2014 12:46, Jason Ekstrand wrote:
> On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote:
>>
>> On 21 August 2014 19:10, Henri Verbeet wrote:
>> > On 21 August 2014 04:56, Michel Dänzer wrote:
>> >> On 21.08.2014 04:29, Henri Verbeet wrote:
>> >>> For whatever it's worth, I have been
On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie wrote:
> On 21 August 2014 19:10, Henri Verbeet wrote:
> > On 21 August 2014 04:56, Michel Dänzer wrote:
> >> On 21.08.2014 04:29, Henri Verbeet wrote:
> >>> For whatever it's worth, I have been avoiding radeonsi in part because
> >>> of the LLVM dep
On 21 August 2014 19:10, Henri Verbeet wrote:
> On 21 August 2014 04:56, Michel Dänzer wrote:
>> On 21.08.2014 04:29, Henri Verbeet wrote:
>>> For whatever it's worth, I have been avoiding radeonsi in part because
>>> of the LLVM dependency. Some of the other issues already mentioned
>>> aside, I
---
If samplers occupy zero locations we can run into a lot of issues. See #82921.
I briefly tested this with my own code (which was previously crashing and
misbehaving) and also ran other apps and everything seems to work fine.
I'm not used to contributing code in this fashion, so please forgive m
On , Alexander von Gluck IV wrote:
* Drop creating gl_config first as it's only really used
to create the state tracker visual.
---
.../targets/haiku-softpipe/GalliumContext.cpp | 196
++--
.../targets/haiku-softpipe/GalliumContext.h|2 +
2 files changed, 96
* Drop creating gl_config first as it's only really used
to create the state tracker visual.
---
.../targets/haiku-softpipe/GalliumContext.cpp | 196 ++--
.../targets/haiku-softpipe/GalliumContext.h|2 +
2 files changed, 96 insertions(+), 102 deletions(-)
diff
---
.../targets/haiku-softpipe/GalliumFramebuffer.cpp |2 +-
.../targets/haiku-softpipe/SoftwareRenderer.cpp|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/targets/haiku-softpipe/GalliumFramebuffer.cpp
b/src/gallium/targets/haiku-softpipe/GalliumFram
dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aar
Tested on CEDAR
v2: fix indentation
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 51
Walk the array of cbufs backwards and free all of them.
v2: Change to C-style comments and fix indentation
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src
v2: Change to C-style comments and fix indentation
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/compute_memory_pool.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 9324b84
On Fri, Aug 15, 2014 at 5:12 PM, Connor Abbott wrote:
> This flag was set to true for the atomic counter intrinsics, but it
> never got plumbed through the linker, so by the time it got to the
> backends it would always be set to the false. The current i965 backend
> code doesn't use is_intrinsic,
Am 21.08.2014 19:39, schrieb Ilia Mirkin:
> On Thu, Aug 21, 2014 at 1:35 PM, Roland Scheidegger
> wrote:
>> Am 21.08.2014 04:42, schrieb Ilia Mirkin:
>>> This allows a sampler view to have a different texture target than the
>>> underlying resource. This will be used to implement the type casting
Am 21.08.2014 04:42, schrieb Ilia Mirkin:
> Signed-off-by: Ilia Mirkin
> ---
>
> v1 -> v2:
> - make use of new PIPE_CAP to determine whether ARB_texture_view is available
> - set the gl_texture_object's Target in the sampler view object
>
> src/mesa/state_tracker/st_atom_texture.c | 30 ++
On Thu, Aug 21, 2014 at 1:35 PM, Roland Scheidegger wrote:
> Am 21.08.2014 04:42, schrieb Ilia Mirkin:
>> This allows a sampler view to have a different texture target than the
>> underlying resource. This will be used to implement the type casting
>> between 2d arrays and cube maps as specified i
Am 21.08.2014 04:42, schrieb Ilia Mirkin:
> This allows a sampler view to have a different texture target than the
> underlying resource. This will be used to implement the type casting
> between 2d arrays and cube maps as specified in ARB_texture_view.
>
> Signed-off-by: Ilia Mirkin
> ---
> src
On Thu, Aug 21, 2014 at 7:14 PM, Jose Fonseca wrote:
> On 21/08/14 17:59, Roland Scheidegger wrote:
>>
>> Am 21.08.2014 18:44, schrieb Marek Olšák:
>>>
>>> From: Marek Olšák
>>>
>>> This is already supported by r600g and radeonsi.
>>> Alex suggested this could be useful for video acceleration sta
On 21/08/14 17:59, Roland Scheidegger wrote:
Am 21.08.2014 18:44, schrieb Marek Olšák:
From: Marek Olšák
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src
Am 21.08.2014 18:44, schrieb Marek Olšák:
> From: Marek Olšák
>
> This is already supported by r600g and radeonsi.
> Alex suggested this could be useful for video acceleration state trackers.
> ---
> src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
> src/gallium/auxiliary/util/u_prim.h
Am 21.08.2014 um 18:44 schrieb Marek Olšák:
From: Marek Olšák
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
I'm a bit skeptical about their usefulness for video applications, but
when you draw a lot of quads it mig
From: Marek Olšák
This is already supported by r600g and radeonsi.
Alex suggested this could be useful for video acceleration state trackers.
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst
Yeah, I see that now. I changed my editor settings halfway through
this series. I thought I had cleaned up the indentation outside of my
IDE, but I guess I missed some spots.
With regards to comment-style... I'll change it, but for the record,
I really dislike using C-style comments for single-
dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aar
On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry wrote:
> Signed-off-by: Aaron Watry
> ---
> src/gallium/drivers/r600/compute_memory_pool.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
> b/src/gallium/drivers/r600/compute_memory_pool.c
On Thu, Aug 21, 2014 at 11:09 AM, Ilia Mirkin wrote:
> On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry wrote:
>> dlopen allocates a string on dlopen failure which is retrieved via dlerror.
>> In
>> order to free that string, you need to retrieve and then free it.
>>
>> In order to keep things legi
On Thu, Aug 21, 2014 at 12:06 PM, Aaron Watry wrote:
> dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
> order to free that string, you need to retrieve and then free it.
>
> In order to keep things legit the windows/other util_dl_error paths allocate
> and then copy
Walk the array of cbufs backwards and free all of them.
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 38b7
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/compute_memory_pool.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_pool.c
index 9324b84..55ff7d5 100644
--- a/src/gallium/drivers/r600/compu
dlopen allocates a string on dlopen failure which is retrieved via dlerror. In
order to free that string, you need to retrieve and then free it.
In order to keep things legit the windows/other util_dl_error paths allocate
and then copy their error message into a buffer as well.
Signed-off-by: Aar
Tested on CEDAR
Signed-off-by: Aaron Watry
---
src/gallium/drivers/r600/evergreen_compute.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index dcb7183..71a9218 100644
Compute on evergreen has slowly developed a few more memory leaks (or maybe
I had never finished fixing them all before).
One of the leaks got in when the memory pool work went in recently, the
others seem to have been around for a while.
The last patch (aux/pipe_loader) seems to affect more than
https://bugs.freedesktop.org/show_bug.cgi?id=66931
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66175
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Mesa 10.3 release candidate 1 is now available for testing. The current
plan is to have an additional release candidate each Friday until the
eventual 10.3 release, (Ian can follow up to state what the planned date
is for that).
The tag in the git repository for Mesa 10.3-rc1 is 'mesa-10.3-rc1'.
https://bugs.freedesktop.org/show_bug.cgi?id=61416
Tom Stellard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Marek Olšák
It's almost the same.
This enables tiling for HTILE. It also enables Hyper-Z for other texture
targets (1D, 1D_ARRAY, 2D_ARRAY, CUBE, CUBE_ARRAY, 3D, RECT).
2D array depth textures are tested by Unigine Sanctuary and my new piglit
test.
---
src/gallium/drivers/r600/evergreen_
From: Marek Olšák
already implemented
---
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 e02c053..c5329e6 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
From: Marek Olšák
---
src/gallium/drivers/r600/r600_state.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index eb5d8f6..454c458 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b/src/gallium/driver
From: Marek Olšák
This is a golden setting on RV740, but there is a hw bug which recommends
setting it on all R7xx chipsets.
---
src/gallium/drivers/r600/r600_state.c | 1 +
src/gallium/drivers/r600/r600d.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_
From: Marek Olšák
I have a piglit test that hits this.
---
src/gallium/drivers/r600/r600_blit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index a3cfdae..0f43839 100644
--- a/src/gallium/drive
From: Marek Olšák
This should make a machine which is running piglit more responsive at times.
e.g. streaming-texture-leak can easily eat 600 MB because of how fast it
creates new textures.
---
src/gallium/auxiliary/pipebuffer/pb_bufmgr.h | 3 ++-
src/gallium/auxiliary/pipebuffer/pb_bufmg
From: Marek Olšák
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_blit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index 0f43839..f766e37 100644
--- a/src/gallium/driv
From: Marek Olšák
This fixes rendering to non-zero layer/face/slice with HTILE.
---
src/gallium/drivers/r600/evergreen_state.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_s
From: Marek Olšák
This fixes rendering to a non-zero layer/face/slice with HTILE.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72685
---
src/gallium/drivers/radeonsi/si_state.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/rade
Pushed, thanks.
Marek
On Wed, Aug 20, 2014 at 9:55 PM, Glenn Kennard wrote:
> If only the flat/smooth shade state changed between
> two render calls the prior code would miss updating the
> hardware state.
>
> Also add check for sprite coord, potentially same type
> of issue otherwise for it.
>
In that case, feel free to upgrade to a
Reviewed-by: Aaron Watry
On Thu, Aug 21, 2014 at 8:25 AM, Tom Stellard wrote:
> On Thu, Aug 21, 2014 at 08:20:57AM -0500, Aaron Watry wrote:
>> On Thu, Aug 21, 2014 at 6:46 AM, Tom Stellard
>> wrote:
>> > From: Michel Dänzer
>> >
>> > v2: Tom Stellard
>
On Thu, Aug 21, 2014 at 08:20:57AM -0500, Aaron Watry wrote:
> On Thu, Aug 21, 2014 at 6:46 AM, Tom Stellard wrote:
> > From: Michel Dänzer
> >
> > v2: Tom Stellard
> > - Properly destroy the Module
> > ---
> > src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
> > 1
Signed-off-by: Aaron Watry
---
src/gallium/state_trackers/clover/api/platform.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/api/platform.cpp
b/src/gallium/state_trackers/clover/api/platform.cpp
index 81b0854..cf71593 100644
--- a/src/ga
On Thu, Aug 21, 2014 at 6:46 AM, Tom Stellard wrote:
> From: Michel Dänzer
>
> v2: Tom Stellard
> - Properly destroy the Module
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/s
Tom Stellard writes:
> From: Michel Dänzer
>
> v2: Tom Stellard
> - Properly destroy the Module
Thanks,
Reviewed-by: Francisco Jerez
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src
Signed-off-by: Olivier Galibert
---
src/mesa/main/getstring.c | 6 ++
src/mesa/main/version.c | 140 +-
2 files changed, 143 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/getstring.c b/src/mesa/main/getstring.c
index 431d60b..f9d13a7 100
From: Michel Dänzer
v2: Tom Stellard
- Properly destroy the Module
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers
Le 2014-08-20 16:03, Francisco Jerez a écrit :
EdB writes:
Each time you call c_str() it will grow up, may be you could check if
the string is already \0 terminated before adding it.
Nope, that's not how it works. Every time c_str() is called the size
of
the underlying array is forced to
Hi
Thank you for the review! I will send an updated version asap.
On Wed, Aug 20, 2014 at 4:50 PM, Emil Velikov
wrote:
> Do you have any rough numbers about the benefit this brings us ?
I doubt that there is a big timing impact between sharing named drm handles
and prime fds, but yeah right now
Matthew Waters (2):
egl: rework handling EGL_CONTEXT_FLAGS for ES debug contexts
glapi: add function pointers for KHR_debug for gles
src/egl/main/eglcontext.c | 50 +++---
src/mapi/glapi/gen/KHR_debug.xml| 73 +
src/mesa/dr
As of version 15 of the EGL_KHR_create_context spec, debug contexts
are allowed for ES contexts. We should allow creation instead of
erroring.
Signed-off-by: Matthew Waters
---
src/egl/main/eglcontext.c | 50 ++
src/mesa/drivers/dri/common/dri_util.c
Signed-off-by: Matthew Waters
---
src/mapi/glapi/gen/KHR_debug.xml| 73 +
src/mesa/main/extensions.c | 2 +-
src/mesa/main/tests/dispatch_sanity.cpp | 25 +++
3 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/src/mapi/glap
On 21.08.2014 18:10, Andy Furniss wrote:
> Haven't had time to find what caused this, it does seem to be mesa -
>
> Updated mesa last night from a day or two old, llvm 5-10 days old
> previous mesa built OK against that.
>
> Got the build fail, updated llvm retried - same fail.
>
> Going back in
Haven't had time to find what caused this, it does seem to be mesa -
Updated mesa last night from a day or two old, llvm 5-10 days old
previous mesa built OK against that.
Got the build fail, updated llvm retried - same fail.
Going back in mesa and applying the build fix for current llvm doesn'
On 21 August 2014 04:56, Michel Dänzer wrote:
> On 21.08.2014 04:29, Henri Verbeet wrote:
>> For whatever it's worth, I have been avoiding radeonsi in part because
>> of the LLVM dependency. Some of the other issues already mentioned
>> aside, I also think it makes it just painful to do bisects ov
This series is
Reviewed-by: Michel Dänzer
Good riddance! :)
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@list
70 matches
Mail list logo
