On Tue 27 Sep 2016, Chad Versace wrote:
> Test results of dEQP-EGL.functional.gles2.multithread.* on Skylake,
> using deqp-egl directly (no Piglit):
>
> * Before:
> Bajillions of failures and randomly occuring crashes. The
> testrun died on me on 10/10 tries.
>
> * After:
>
From: Nicolai Hähnle
This is basically a re-write of the slab allocator into a design where
multiple child pools are linked to a parent pool. The intention is that
every (GL, pipe) context has its own child pool, while the corresponding
parent pool is held by the winsys or screen, or possibly the
From: Nicolai Hähnle
v2: slab_alloc_st -> slab_alloc
---
src/gallium/drivers/r300/r300_context.c | 5 ++---
src/gallium/drivers/r300/r300_context.h | 2 +-
src/gallium/drivers/r300/r300_screen.c| 3 +++
src/gallium/drivers/r300/r300_screen.h| 2 ++
src/gallium/drivers
On Tue, Sep 27, 2016 at 11:51:18PM -0700, Chad Versace wrote:
> Test results of dEQP-EGL.functional.gles2.multithread.* on Skylake,
> using deqp-egl directly (no Piglit):
>
> * Before:
> Bajillions of failures and randomly occuring crashes. The
> testrun died on me on 10/10 tries
From: Nicolai Hähnle
The difference to the virtually identical ARB_robustness (which is already
enabled unconditionally) is miniscule and handled elsewhere, but this set
of caps seems like the right thing to require for this extension.
---
docs/features.txt | 2 +-
docs/reln
Andy Furniss wrote:
I started to get some numbers but found a possible bug = I made a 1000
frame 15mbit 1080p50 mkv with ffmpeg/libx264.
Using it as source for transcode (s/w or h/w dec) it came out far too
low bitrate.
After re-applying debugging patch to mesa it turns out that framerate is
b
Andy Furniss wrote:
Andy Furniss wrote:
I started to get some numbers but found a possible bug = I made a 1000
frame 15mbit 1080p50 mkv with ffmpeg/libx264.
Using it as source for transcode (s/w or h/w dec) it came out far too
low bitrate.
After re-applying debugging patch to mesa it turns ou
>> #define SOMEPREFIX "sensors_temp_cu-"
>> then
>> hud_sensors_temp_graph_install(pane, &name[sizeof(SOMEPREFIX - 1)]
>>
>> Or, have I misunderstood your comment?
>
>
> Thanks for explaining. But why not do this?
>
> else if (sscanf(name, "sensors_temp_cu-%s", arg_name) == 1) {
> h
On Tue, Sep 27, 2016 at 8:03 PM, Brian Paul wrote:
> On 09/27/2016 05:17 PM, Steven Toth wrote:
>>
>> On Fri, Sep 23, 2016 at 12:19 PM, Brian Paul wrote:
>>>
>>> Hi Steven,
>>>
>>> I did a more thorough review per your request...
>>
>>
>> Thank you Brian.
>>
>> All of your suggestions have been i
V7: Increase precision when measuring lmsensors volts
Flatten patch series.
V6: Feedback based on peer review
Simplify sensor initialization (arg passing).
Constify some func args
V5: Feedback based on peer review
Convert sprintf to snprintf
Convert char * to const char *
For the series:
Reviewed-by: Marek Olšák
Regarding patch 8, I only skimmed through it.
Marek
On Thu, Sep 22, 2016 at 2:28 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> v2: enable only when compute is available
> ---
> docs/features.txt | 2 +-
> docs/relnotes/12
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 26, 2016 at 7:23 PM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> docs/features.txt | 2 +-
> docs/relnotes/12.1.0.html | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/docs/features.txt b/docs/feat
From: Marek Olšák
The other flag seems to have a slightly different meaning.
---
src/mesa/main/fbobject.c| 4
src/mesa/main/framebuffer.c | 1 +
src/mesa/main/mtypes.h | 6 ++
3 files changed, 11 insertions(+)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
in
From: Marek Olšák
st/mesa does this for us.
---
src/gallium/drivers/radeonsi/si_pipe.h | 1 -
src/gallium/drivers/radeonsi/si_state.c | 9 +
src/gallium/drivers/radeonsi/si_state_shaders.c | 6 ++
3 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/src/ga
From: Marek Olšák
---
src/mesa/state_tracker/st_atom_blend.c | 3 ++-
src/mesa/state_tracker/st_atom_depth.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_blend.c
b/src/mesa/state_tracker/st_atom_blend.c
index 76d6a644..adba645 100644
---
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 26, 2016 at 7:23 PM, Samuel Pitoiset
wrote:
> v3: - use a new case statement in r600_pipe_common.c
> - fix compilation of softpipe...
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/docs/source/screen.rst | 4
> src/galliu
Reviewed-by: Marek Olšák
Marek
On Mon, Sep 26, 2016 at 7:23 PM, Samuel Pitoiset
wrote:
> This extension is only exposed if the underlying driver supports
> ARB_compute_shader and if PIPE_COMPUTE_MAX_VARIABLE_THREADS_PER_BLOCK
> is set.
>
> v3: - initialize max_variable_threads_per_block to 0
>
Oh interesting, I happen to be running into this recently!!! I'll have
to read though this, thanks for looking into it!
On 09/28/2016 04:21 AM, Nicolai Hähnle wrote:
> Hi all,
>
> it can happen that a buffer that is mapped from one context ends up being
> unmapped in another one. I found nothing
Reviewed-by: Marek Olšák
Marek
On Wed, Sep 28, 2016 at 12:25 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The difference to the virtually identical ARB_robustness (which is already
> enabled unconditionally) is miniscule and handled elsewhere, but this set
> of caps seems like the righ
For the series:
Reviewed-by: Marek Olšák
Marek
On Tue, Sep 27, 2016 at 4:56 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Most of the time, even the 512 bytes that we now get is more than sufficient
> (pipeline stats queries are the largest at 184 bytes per shot).
> ---
> src/gallium/
Hmm, does this actually pass all the piglits and so on because I don't
see how you are dealing with the lost context situation from the
KHR_robustness spec?
Cheers,
Edward.
On 09/28/2016 11:52 PM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Wed, Sep 28, 2016 at 12:25 PM, Nic
On Wed, Sep 28, 2016 at 4:00 PM, Edward O'Callaghan
wrote:
> Hmm, does this actually pass all the piglits and so on because I don't
> see how you are dealing with the lost context situation from the
> KHR_robustness spec?
We don't have lost contexts, we have lost machines.
Until the GPU reset is
On 09/29/2016 12:13 AM, Marek Olšák wrote:
> On Wed, Sep 28, 2016 at 4:00 PM, Edward O'Callaghan
> wrote:
>> Hmm, does this actually pass all the piglits and so on because I don't
>> see how you are dealing with the lost context situation from the
>> KHR_robustness spec?
>
> We don't have lost
On Wed, Sep 28, 2016 at 6:25 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The difference to the virtually identical ARB_robustness (which is already
> enabled unconditionally) is miniscule and handled elsewhere, but this set
> of caps seems like the right thing to require for this extensi
On 09/29/2016 12:18 AM, Vedran Miletić wrote:
> The options specified in the CLOVER_EXTRA_BUILD_OPTIONS shell
> variable are appended to the options specified by the OpenCL program
> in the clBuildProgram function call, if any.
> Analogously, the options specified in the CLOVER_EXTRA_COMPILE_OPTI
The options specified in the CLOVER_EXTRA_BUILD_OPTIONS shell
variable are appended to the options specified by the OpenCL program
in the clBuildProgram function call, if any.
Analogously, the options specified in the CLOVER_EXTRA_COMPILE_OPTIONS
and CLOVER_EXTRA_LINK_OPTIONS variables are appended
On 09/28/2016 04:22 PM, Edward O'Callaghan wrote:
> Just drop the Rb as soon as you revise any patch please. Obviously there
> was a bunch of stuff that happened and discussion..
>
Indeed, v1 and v6 are quite different. Will do in the future.
Regards,
Vedran
--
Vedran Miletić
vedran.miletic.ne
On 28/09/16 11:47, Andy Furniss wrote:
> Andy Furniss wrote:
>> Andy Furniss wrote:
>>
>>> I started to get some numbers but found a possible bug = I made a 1000
>>> frame 15mbit 1080p50 mkv with ffmpeg/libx264.
>>>
>>> Using it as source for transcode (s/w or h/w dec) it came out far too
>>> low b
OpenCL apps can quote arguments they pass to the OpenCL compiler, most
commonly include paths containing spaces.
If the Clang OpenCL compiler was called via a shell, the shell would
split the arguments with respect to to quotes and then remove quotes
before passing the arguments to the compiler. S
On 09/16/2016 06:21 PM, Tapani Pälli wrote:
> Changes make copy_propagation_elements pass faster, reducing link
> time spent in test case of bug 94477. Does not fix the actual issue
> but brings down the total time. No regressions seen in CI.
How does this affect the time of a full shader-db run?
On 09/28/2016 07:44 AM, Marek Olšák wrote:
From: Marek Olšák
The other flag seems to have a slightly different meaning.
I don't recall what the GL spec says w.r.t. mixing floating point and
integer color buffers. I suspect it may be implementation dependent.
I wonder if we should replace
I found just a few more nit-picks below. With those fixed (if appropriate),
Reviewed-by: Brian Paul
I'll push the patch for you then.
-Brian
On 09/28/2016 07:21 AM, Steven Toth wrote:
V7: Increase precision when measuring lmsensors volts
Flatten patch series.
V6: Feedback based on peer
Timothy Arceri writes:
> On Sun, 2016-09-25 at 19:51 -0700, Kenneth Graunke wrote:
>> On Saturday, September 24, 2016 3:26:09 PM PDT Timothy Arceri wrote:
>> >
>> > Pointers will have different lengths so we simple create a
>> > different
>> > sha1 for each platform.
>>
>> I don't understand...
> I found just a few more nit-picks below. With those fixed (if appropriate),
> Reviewed-by: Brian Paul
>
> I'll push the patch for you then.
All reasonable requests, thank you.
I'll take care of these later this afternoon.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
__
On 28.09.2016 16:20, Ilia Mirkin wrote:
On Wed, Sep 28, 2016 at 6:25 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
The difference to the virtually identical ARB_robustness (which is already
enabled unconditionally) is miniscule and handled elsewhere, but this set
of caps seems like the right
On Wed, Sep 28, 2016 at 5:14 PM, Brian Paul wrote:
> On 09/28/2016 07:44 AM, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> The other flag seems to have a slightly different meaning.
>
>
> I don't recall what the GL spec says w.r.t. mixing floating point and
> integer color buffers. I suspect
From: Marek Olšák
More info about jemalloc:
https://github.com/jemalloc/jemalloc/wiki/History
Average from 3 takes compiling Alien Isolation shaders from GLSL to GCN
bytecode:
glibc:17.183s
jemalloc: 15.558s
diff: -9.5%
The diff is -10.5% for a full shader-db run.
---
TODO:
On Wed, Sep 28, 2016 at 12:27 PM, Nicolai Hähnle wrote:
> On 28.09.2016 16:20, Ilia Mirkin wrote:
>>
>> On Wed, Sep 28, 2016 at 6:25 AM, Nicolai Hähnle
>> wrote:
>>>
>>> From: Nicolai Hähnle
>>>
>>> The difference to the virtually identical ARB_robustness (which is
>>> already
>>> enabled uncond
On Wed, Sep 28, 2016 at 4:17 PM, Edward O'Callaghan
wrote:
>
>
> On 09/29/2016 12:13 AM, Marek Olšák wrote:
>> On Wed, Sep 28, 2016 at 4:00 PM, Edward O'Callaghan
>> wrote:
>>> Hmm, does this actually pass all the piglits and so on because I don't
>>> see how you are dealing with the lost context
On 09/28/2016 10:29 AM, Marek Olšák wrote:
On Wed, Sep 28, 2016 at 5:14 PM, Brian Paul wrote:
On 09/28/2016 07:44 AM, Marek Olšák wrote:
From: Marek Olšák
The other flag seems to have a slightly different meaning.
I don't recall what the GL spec says w.r.t. mixing floating point and
inte
On Wednesday, September 28, 2016 9:00:50 AM PDT Eric Anholt wrote:
> Timothy Arceri writes:
>
> > On Sun, 2016-09-25 at 19:51 -0700, Kenneth Graunke wrote:
> >> On Saturday, September 24, 2016 3:26:09 PM PDT Timothy Arceri wrote:
> >> >
> >> > Pointers will have different lengths so we simple cr
Hi,
It's been almost 4 months since the 12.0 branch was created, and soon
it will have been 3 months since Mesa 12.0 was released.
Is there any reason we haven't created the stable branch yet?
Ideally, we would time the release so that it's 1-2 months before fall
distribution releases.
Marek
__
On Wed, Sep 28, 2016 at 8:01 PM, Brian Paul wrote:
> On 09/28/2016 10:29 AM, Marek Olšák wrote:
>>
>> On Wed, Sep 28, 2016 at 5:14 PM, Brian Paul wrote:
>>>
>>> On 09/28/2016 07:44 AM, Marek Olšák wrote:
From: Marek Olšák
The other flag seems to have a slightly different
V8: Feedback based on peer review
convert if block into a switch
Constify some func args
V7: Increase precision when measuring lmsensors volts
Flatten patch series.
V6: Feedback based on peer review
Simplify sensor initialization (arg passing).
Constify some func args
V5: Fee
On Wed, Sep 21, 2016 at 12:49 PM, Anuj Phogat wrote:
> On Wed, Sep 21, 2016 at 11:49 AM, Jason Ekstrand wrote:
>> This seems odd... When can it even happen that we have persample_dispatch
>> set in wm_surface_state and have only one sample? Does this fix a test
>> case?
>>
> No, It just fixes a
On Wed, Sep 28, 2016 at 6:27 PM, Nicolai Hähnle wrote:
> On 28.09.2016 16:20, Ilia Mirkin wrote:
>>
>> On Wed, Sep 28, 2016 at 6:25 AM, Nicolai Hähnle
>> wrote:
>>>
>>> From: Nicolai Hähnle
>>>
>>> The difference to the virtually identical ARB_robustness (which is
>>> already
>>> enabled uncondi
On Wed, Sep 28, 2016 at 6:00 PM, Bas Nieuwenhuizen
wrote:
> On Wed, Sep 28, 2016 at 6:27 PM, Nicolai Hähnle wrote:
>> On 28.09.2016 16:20, Ilia Mirkin wrote:
>>>
>>> On Wed, Sep 28, 2016 at 6:25 AM, Nicolai Hähnle
>>> wrote:
From: Nicolai Hähnle
The difference to the virtual
On Wed 28 Sep 2016, Chris Wilson wrote:
> On Tue, Sep 27, 2016 at 11:51:18PM -0700, Chad Versace wrote:
> > Test results of dEQP-EGL.functional.gles2.multithread.* on Skylake,
> > using deqp-egl directly (no Piglit):
> >
> > * Before:
> > Bajillions of failures and randomly occuring cras
Mark Thompson wrote:
On 28/09/16 11:47, Andy Furniss wrote:
Andy Furniss wrote:
Andy Furniss wrote:
I started to get some numbers but found a possible bug = I
made a 1000 frame 15mbit 1080p50 mkv with ffmpeg/libx264.
Using it as source for transcode (s/w or h/w dec) it came out
far too low b
https://bugs.freedesktop.org/show_bug.cgi?id=97967
Bug ID: 97967
Summary: glsl/tests/cache-test regression
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Keywords: bisected
On 28.09.2016 21:53, Marek Olšák wrote:
> Hi,
>
> It's been almost 4 months since the 12.0 branch was created, and soon
> it will have been 3 months since Mesa 12.0 was released.
>
> Is there any reason we haven't created the stable branch yet?
>
> Ideally, we would time the release so that it's
51 matches
Mail list logo
