I did not get as impressive results with these 3 patches (how did you
measure?) but on my machine (HSW GT2) complete shader_runner time goes
from ~83 secs to ~70secs so it is definitely improving.
I simply do 'time bin/shader_runner' for the measurement.
Tested-by: Tapani Pälli
On 09/05/2015
2015-09-07 16:58 GMT+08:00 Emil Velikov :
> Move the fcntl(dupfd_cloexec) to the else branch where it belongs.
> Otherwise it's not immediately obvious that the code is hit, only when
> an existing device is used.
A potential problem here. The fd acquired from gbm device provided as
platform displ
On Tue, 2015-09-08 at 08:09 +1000, Timothy Arceri wrote:
> On Mon, 2015-09-07 at 11:24 -0700, Jason Ekstrand wrote:
> > On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri <
> > t_arc...@yahoo.com.au>
> > wrote:
> > > This allows the correct offset to be easily calculated for
> > > indirect
> > > indexi
2015-09-07 16:58 GMT+08:00 Emil Velikov :
> From: Matt Turner
>
> v2: [Emil Velikov]
> Rework the error path to a common goto, close only if we own the fd.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Boyan Ding
> ---
> src/egl/drivers/dri2/platform_drm.c | 27 ++-
> 1
When parsing an variable declaration qualified with the typename
keyword, clang attempted to declare a variable with the type of non
type member "enum type type" of module::argument (within the header
file clover/core/module.hpp) instead of the typed member of
module::argument "enum type".
Replace
On 8 September 2015 at 01:16, Albert Freeman wrote:
> On 7 September 2015 at 08:22, Emil Velikov wrote:
>> On 7 September 2015 at 05:59, Albert Freeman
>> wrote:
>>> Correction, we just need someone to mark all the comitted patches in
>>> patchwork...
>> This is already done automatically.
>>
>
https://bugs.freedesktop.org/show_bug.cgi?id=91888
--- Comment #3 from nerdopol...@verizon.net ---
So, should I report this against qtwayland instead?
--
You are receiving this mail because:
You are the QA Contact for the bug.
___
mesa-dev mailing list
Kill it!
--
Edward O'Callaghan
edward.ocallag...@koparo.com
On Mon, Sep 7, 2015, at 08:14 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> This allows using the new tex instrinsics unconditionally.
> ---
> configure.ac| 2 +-
> src/gallium/drivers/rad
Kill it !
--
Edward O'Callaghan
edward.ocallag...@koparo.com
On Mon, Sep 7, 2015, at 08:14 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> LLVM 3.3 has been unsupported for quite a while.
> ---
> src/gallium/drivers/r600/r600_llvm.c | 106
> ---
> 1 file ch
LGTM, thanks for catching this!
--
Edward O'Callaghan
edward.ocallag...@koparo.com
On Tue, Sep 8, 2015, at 09:32 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Since 7a32652231f96eac14c4bfce02afe77b4132fb77
> r600: Turn 'r600_shader_key' struct into union
>
> we were accessing key fields
On 7 September 2015 at 08:22, Emil Velikov wrote:
> On 7 September 2015 at 05:59, Albert Freeman
> wrote:
>> Correction, we just need someone to mark all the comitted patches in
>> patchwork...
> This is already done automatically.
>
> Sigh top posting :'(.
> -Emil
Sorry, I didn't realise I was
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h | 3 +++
src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c | 8
2 files changed, 11 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nouveau_v
- split nvc0_decoder_bsp in begin/next/end
- preserve content buffer when calling nvc0_decoder_bsp_next
- implement pipe_video_codec::begin_frame/end_frame
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h|
v3:
Indent to 3 spaces.
Move "unsigned bsp_size" and unsigned int nb_slices" in
commits that use it.
v2:
Squash some commits as requested.
Currently nouveau does not support chunk decoding
which is required to support st/va.
The low level code is already there since it supports
vpau. But it is m
It allows to call nouveau_vp3_bsp_next multiple times
between one begin/end.
It is required to support st/va.
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h| 16 +++-
.../drivers/nouveau/nouveau_vp3_video_
Currently nouveau does not support chunk decoding
which is required to support st/va.
The low level code is already there since it supports
vpau. But it is missing the possibility to feed
the nouveau_bo buffers gradually.
Resizing is already there too. But it also requires
to preserve the content
vainfo fails in vaDriverInit because "dd_create_screen"
does not reach strcmp(driver_name, "nouveau") code.
Indeed when compiling the va target.c, the macro GALLIUM_NOUVEAU
is not defined.
This patch define the macro the same it is done for dri and
vdpau targets.
Tested with:
./autogen.sh --enable
From: Dave Airlie
Since 7a32652231f96eac14c4bfce02afe77b4132fb77
r600: Turn 'r600_shader_key' struct into union
we were accessing key fields that might be aliased in the union
with other fields, so we should check what shader type we are
compiling for before using key values from it.
v1.1: make
On 8 September 2015 at 08:46, Dave Airlie wrote:
> On 8 September 2015 at 08:38, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> Since 7a32652231f96eac14c4bfce02afe77b4132fb77
>> r600: Turn 'r600_shader_key' struct into union
>>
>> we were accessing key fields that might be aliased in the union
>>
On 8 September 2015 at 08:38, Dave Airlie wrote:
> From: Dave Airlie
>
> Since 7a32652231f96eac14c4bfce02afe77b4132fb77
> r600: Turn 'r600_shader_key' struct into union
>
> we were accessing key fields that might be aliased in the union
> with other fields, so we should check what shader type we
From: Dave Airlie
Since 7a32652231f96eac14c4bfce02afe77b4132fb77
r600: Turn 'r600_shader_key' struct into union
we were accessing key fields that might be aliased in the union
with other fields, so we should check what shader type we are
compiling for before using key values from it.
Signed-off
On Mon, 2015-09-07 at 11:24 -0700, Jason Ekstrand wrote:
> On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri
> wrote:
> > This allows the correct offset to be easily calculated for indirect
> > indexing when a struct array contains multiple samplers, or any crazy
> > nesting.
> >
> > The indices for
On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede wrote:
> msaa use on nv30 may trigger a (mesa?) bug where dmesg says:
> [ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
> [ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
> [ 1197.850654] nouveau E[soffice.bin[3785]] vali
May I ask why you're doing 512x512 instead of 1024x1024? These are
already scaled up coordinates, so 1024x1024 should work no? Or is it
because of the seams on the edges? Do those not also appear with
512x512 or does it sample outside of the box?
Separately, why not use this approach on nv40 as we
Yeah, I noticed this was odd too when looking over the code earlier.
Glad you picked up on that as well.
Reviewed-by: Ilia Mirkin
Cc: "10.6 11.0"
On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede wrote:
> The sifm object has a limit of 1024x1024 for its input size and 2048x2048
> for its output. T
We do not have a generic blitter on nv3x cards, so we must use the
sifm object for color resolving.
This commit divides the sources and dest surfaces in to tiles which
match the constraints of the sifm object, so that color resolving
will work properly on nv3x cards.
Signed-off-by: Hans de Goede
msaa use on nv30 may trigger a (mesa?) bug where dmesg says:
[ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
[ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.766955] nouveau E[soffice.bin[3785]] fail tt
The sifm object has a limit of 1024x1024 for its input size and 2048x2048
for its output. The code checking this was trying to be clever resulting
in it seeing a surface of e.g 1024x256 being outside of the input size
limit.
This commit fixes this.
Signed-off-by: Hans de Goede
---
src/gallium/d
Le 05/09/2015 10:19, Samuel Pitoiset a écrit :
>
> On 09/04/2015 08:57 PM, Benjamin Bellec wrote:
>> Currently, the temperature is displayed with a "%" symbol in
>> gallium/hud, which is quite odd.
>> Marek suggested to only change the value "100" to another value so
>> that this symbol is no more
Reviewed-by: Jason Ekstrand
On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri wrote:
> ---
> src/glsl/link_uniforms.cpp | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
> index f68ea9d..c28ac52
On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri wrote:
> This will allow us to access the uniform later on without resorting to
> building a name string and looking it up in UniformHash.
>
> V2: store slot number for all non-UBO uniforms to make code more
> consitent, renamed explicit_binding to ex
On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri wrote:
> This is required so that the next patch can safely assign the slot id
> to the var.
>
> The ids are now assigned in the order we want before allocating storage
> so there is no need to sort the storage array and move things around.
> ---
> s
On Tue, Sep 1, 2015 at 7:44 PM, Timothy Arceri wrote:
> This allows the correct offset to be easily calculated for indirect
> indexing when a struct array contains multiple samplers, or any crazy
> nesting.
>
> The indices for the folling struct will now look like this:
> Sampler index: 0 Name: s[
On Mon, Sep 7, 2015 at 11:06 AM, Jason Ekstrand wrote:
> On Thu, Sep 3, 2015 at 1:48 AM, Kenneth Graunke wrote:
>> By performing the vertex counting in NIR, we're able to elide a ton of
>> useless safety checks around every EmitVertex() call:
>>
>> total instructions in shared programs: 3952 -> 3
On Thu, Sep 3, 2015 at 1:48 AM, Kenneth Graunke wrote:
> By performing the vertex counting in NIR, we're able to elide a ton of
> useless safety checks around every EmitVertex() call:
>
> total instructions in shared programs: 3952 -> 3720 (-5.87%)
> instructions in affected programs: 3491 ->
On Sep 3, 2015 1:49 AM, "Kenneth Graunke" wrote:
>
> This patch also introduces a lowering pass to convert the simple GS
> intrinsics to the new ones. See the comments above that for the
> rationale behind the new intrinsics.
>
> This should be useful for i965; it's a generic enough mechanism tha
On Mon, Sep 07, 2015 at 10:15:56AM -0700, Kenneth Graunke wrote:
> On Saturday, September 05, 2015 08:58:07 PM Chris Wilson wrote:
> > On Sat, Sep 05, 2015 at 11:30:44AM -0700, Jordan Justen wrote:
> > > From: Francisco Jerez
> > >
> > > Fixes
> > > arb_shader_image_load_store/execution/load-fro
LGTM:
Reviewed-by: Jason Ekstrand
On Mon, Sep 7, 2015 at 4:52 AM, Iago Toral wrote:
> Jason, since that commit is yours, could you review this change? it is a
> one liner.
>
> Thanks,
> Iago
>
> On Tue, 2015-09-01 at 11:32 +0200, Iago Toral Quiroga wrote:
>> Commit 2126c68e5cba killed the array
On Saturday, September 05, 2015 08:58:07 PM Chris Wilson wrote:
> On Sat, Sep 05, 2015 at 11:30:44AM -0700, Jordan Justen wrote:
> > From: Francisco Jerez
> >
> > Fixes
> > arb_shader_image_load_store/execution/load-from-cleared-image.shader_test
> >
> > Cc: Chris Wilson
> > Cc: Jason Ekstrand
On Sunday, September 06, 2015 05:37:18 PM Chris Wilson wrote:
> glCopyTexImage behaves similarly to glReadPixels with respect to the
> pixel transfer operations. Therefore if any are set we cannot use the
> simply blit fast paths.
>
> Signed-off-by: Chris Wilson
> Cc: Jason Ekstrand
> Cc: Kennet
Chris Wilson writes:
> On Mon, Sep 07, 2015 at 05:21:53PM +0300, Francisco Jerez wrote:
>> I'm sure you had some specific practical advantage in mind? Bashing the
>> rather sensitive L3 configuration registers to see if something sticks
>> is a hack with potential implications. I'd prefer to av
On Mon, Sep 07, 2015 at 05:21:53PM +0300, Francisco Jerez wrote:
> I'm sure you had some specific practical advantage in mind? Bashing the
> rather sensitive L3 configuration registers to see if something sticks
> is a hack with potential implications. I'd prefer to avoid that unless
> there is a
Chris Wilson writes:
> On Sun, Sep 06, 2015 at 07:48:40PM +0300, Francisco Jerez wrote:
>> Chris Wilson writes:
>>
>> > On Sun, Sep 06, 2015 at 07:28:12PM +0300, Francisco Jerez wrote:
>> >> Chris Wilson writes:
>> >>
>> >> > On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
>>
Reviewed-by: Iago Toral Quiroga
On Mon, 2015-09-07 at 00:30 -0700, Kenneth Graunke wrote:
> This code is all pretty much identical. We just needed the translation
> from one enum value to the other.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 47
>
Reviewed-by: Iago Toral Quiroga
On Mon, 2015-09-07 at 00:30 -0700, Kenneth Graunke wrote:
> This converts NIR intrinsics that load system values into Mesa's
> SYSTEM_VALUE_* enumerations.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/nir/nir.c | 34 ++
> s
On 07/09/15 10:17, Jean-Sébastien Pédron wrote:
On 04.09.2015 01:37, Matt Turner wrote:
You need to test for this support in configure.ac. It's as simple as
adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
list and then a little bit of preprocessor in src/util/macros.h.
Shou
Looks correct, based on the previous discussion about the same fix for
ReadPixels and TexImage. CopyTexImage has the same requirements.
Reviewed-by: Iago Toral Quiroga
On Sun, 2015-09-06 at 17:37 +0100, Chris Wilson wrote:
> glCopyTexImage behaves similarly to glReadPixels with respect to the
>
Jason, since that commit is yours, could you review this change? it is a
one liner.
Thanks,
Iago
On Tue, 2015-09-01 at 11:32 +0200, Iago Toral Quiroga wrote:
> Commit 2126c68e5cba killed the array elements parameter on load/store
> intrinsics that was stored in const_index[1]. It looks like that
Hi Jon,
On 4 September 2015 at 12:43, Jon TURNEY wrote:
> X11_CFLAGS isn't defined by configure.ac since commmit 35189d76 removed
> PKG_CHECK_MODULES([X11],[x11])
>
> Fix the remaining uses of X11_CFLAGS. There are no uses of X11_LIBS
>
> Jon TURNEY (2):
> Use X11_INCLUDES instead of X11_CFLA
On 04.09.2015 01:37, Matt Turner wrote:
>> +__attribute__((destructor))
>
> You need to test for this support in configure.ac. It's as simple as
> adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
> list and then a little bit of preprocessor in src/util/macros.h. (I
> think you s
On 07/09/15 11:32, Samuel Iglesias Gonsálvez wrote:
>
>
> On 29/08/15 00:59, Jordan Justen wrote:
>> On 2015-08-05 01:30:16, Iago Toral Quiroga wrote:
>>> From: Samuel Iglesias Gonsalvez
>>>
>>> The returned drm buffer object has a size multiple of 4096 but that should
>>> not
>>> be exposed
On 29/08/15 00:59, Jordan Justen wrote:
> On 2015-08-05 01:30:16, Iago Toral Quiroga wrote:
>> From: Samuel Iglesias Gonsalvez
>>
>> The returned drm buffer object has a size multiple of 4096 but that should
>> not
>> be exposed to the API user, which is working with a different size.
>
> Woul
On 04.09.2015 01:37, Matt Turner wrote:
> You need to test for this support in configure.ac. It's as simple as
> adding a call to AX_GCC_FUNC_ATTRIBUTE in the existing alphabetized
> list and then a little bit of preprocessor in src/util/macros.h.
Should the code fallbacks on atexit(3) if the attr
On 06.09.2015 23:40, Emil Velikov wrote:
> Hi Jean-Sébastien,
Hi!
> On 3 September 2015 at 19:07, Jean-Sébastien Pédron
> We have 4(5) users of atexit() - EGL, gallium trace driver, core mesa
> and util/ralloc. The latter of which is used almost everywhere in
> mesa. So a bit I'm confused how you
Hi Jon,
On 4 September 2015 at 14:00, Jon TURNEY wrote:
> When checking for LLVM shared libraries, use IMP_LIB_EXT for the extension for
> shared libraries appropriate to the target, rather than hardcoding '.so'
>
> Also add some comments to explain why we have this circus of pain.
>
> Signed-off
https://bugs.freedesktop.org/show_bug.cgi?id=91869
Jean-Sébastien Pédron changed:
What|Removed |Added
Attachment #118072|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=91888
--- Comment #2 from Daniel Stone ---
I think that commit is a a red herring. 0x3098 is EGL_CONTEXT_CLIENT_VERSION,
and Mesa has recently gained more strictness:
if ((api != EGL_OPENGL_ES_API &&
(!dpy->Extensions.KHR_create_c
Move the fcntl(dupfd_cloexec) to the else branch where it belongs.
Otherwise it's not immediately obvious that the code is hit, only when
an existing device is used.
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_drm.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(
From: Matt Turner
v2: [Emil Velikov]
Rework the error path to a common goto, close only if we own the fd.
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/platform_drm.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/src/egl/drivers/dri2/p
https://bugs.freedesktop.org/show_bug.cgi?id=91793
--- Comment #3 from Emil Velikov ---
Nope, I mean that the requirements are not being met :)
It should be a matter of making sure the relevant .pc are around at configure
time and the headers + libs (.dll, .dll.a and/or .lib) are there at build/
On 07/09/15 11:22, Emil Velikov wrote:
On 7 September 2015 at 05:59, Albert Freeman wrote:
Correction, we just need someone to mark all the comitted patches in
patchwork...
This is already done automatically.
Sigh top posting :'(.
-Emil
I often have to help patchwork a lot when I push my pa
On 7 September 2015 at 05:59, Albert Freeman wrote:
> Correction, we just need someone to mark all the comitted patches in
> patchwork...
This is already done automatically.
Sigh top posting :'(.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedeskto
These two are:
Reviewed-by: Chris Forbes
On Mon, Sep 7, 2015 at 7:03 PM, Kenneth Graunke wrote:
> TRIFAN_NOSTIPPLE has always been 0x16 - 0x15 is marked "Reserved" on all
> platforms. See the 965 PRM, Volume 2, Table 3-1, "3D Primitive Topology
> Type Encoding" for a list.
>
> We don't current
This code is all pretty much identical. We just needed the translation
from one enum value to the other.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 47 +++---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 30 +--
2 file
This converts NIR intrinsics that load system values into Mesa's
SYSTEM_VALUE_* enumerations.
Signed-off-by: Kenneth Graunke
---
src/glsl/nir/nir.c | 34 ++
src/glsl/nir/nir.h | 2 ++
2 files changed, 36 insertions(+)
diff --git a/src/glsl/nir/nir.c b/src/glsl/n
From: Chris Forbes
v2 (Ken):
- Squash together commits for HS, DS, and TE, as well as fixes.
- Add INTEL_MASK variants so we can use SET_FIELD if we want.
- Rename GEN7_HS_INSTANCE_CONTROL to GEN7_HS_INSTANCE_COUNT to match
the documentation.
- Add some more fields from the PRMs.
- Add Broadwel
These didn't exist on the original 965.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_defines.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 411a97d..a8594af
TRIFAN_NOSTIPPLE has always been 0x16 - 0x15 is marked "Reserved" on all
platforms. See the 965 PRM, Volume 2, Table 3-1, "3D Primitive Topology
Type Encoding" for a list.
We don't currently use this, and I don't expect we will, but we may as
well not leave the bogus value around.
Signed-off-by:
68 matches
Mail list logo
