On Wednesday, June 14, 2017 5:22:08 PM PDT Lionel Landwerlin wrote:
> Hi,
>
> While working with changes that span from kernel to user space, I've
> been wondering whether we need to depend on libdrm's header files at
> all for the anv & i965 drivers. Indeed with Ken's recent changes, we
> depend
On Wednesday, June 14, 2017 5:38:30 PM PDT Lionel Landwerlin wrote:
> From: Robert Bragg
>
> Enables access to OA unit metrics on Gen8+ via INTEL_performance_query.
>
> Signed-off-by: Robert Bragg
> ---
> src/mesa/drivers/dri/i965/Makefile.am | 8 +-
> src/mesa/drivers/dri/i965/b
On Wednesday, June 14, 2017 5:38:31 PM PDT Lionel Landwerlin wrote:
> Due to an underlying hardware race condition, we have no guarantee
> that all the reports coming from the OA buffer related to the workload
> we're trying to measure have landed to memory by the time all the work
> submitted has
On Wednesday, June 14, 2017 5:38:32 PM PDT Lionel Landwerlin wrote:
> From: Robert Bragg
>
> From experimentation in IGT, we found that the OA unit might label
> some report as "idle" (using an invalid context ID), right after a
> report for a given context. Deltas generated by those reports actu
On Wednesday, June 14, 2017 5:38:33 PM PDT Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> src/mesa/drivers/dri/i965/brw_performance_query.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
Reviewed-by: Kenneth Graunke
signature.asc
Description: This
On Wednesday, June 14, 2017 5:38:25 PM PDT Lionel Landwerlin wrote:
> Hi,
>
> This series has been used by a few people for some time already. Now
> that the kernel patches are making their way to upstream, here are the
> userspace side ones.
>
> This series depends on [1] which includes kernel h
On 06/15/2017 03:56 AM, Timothy Arceri wrote:
The storage was once used by get_sampler_uniform_value() but that
was fixed long ago to use the uniform storage assigned by the
linker.
By not assigning storage for images/samplers the constant buffer
for gallium drivers will be reduced which could
On 25/05/2017 15:14, Chris Wilson wrote:
On Wed, May 24, 2017 at 12:28:07PM +0100, Tvrtko Ursulin wrote:
On 18/05/2017 18:00, Chris Wilson wrote:
On Thu, May 18, 2017 at 05:20:38PM +0100, Tvrtko Ursulin wrote:
On 18/05/2017 14:37, Chris Wilson wrote:
On Thu, May 18, 2017 at 02:06:35PM +010
Quoting Kenneth Graunke (2017-06-14 22:49:01)
> On Friday, June 9, 2017 6:01:33 AM PDT Chris Wilson wrote:
> > If we know the bo is idle (that is we have no submitted a command buffer
> > referencing this bo since the last query) we can skip asking the kernel.
> > Note this may report a false negat
Hi Lionel,
Final reminder - doing this will throw a wrench into non-Linux
platforms which want to use Mesa.
On those the kernel vs libdrm copy of the headers have diverged and
while I'm nudging with the guys to get that sorted, the extra copy is
a recipe for disaster.
On 15 June 2017 at 01:22, L
On Wednesday, 2017-06-14 21:46:57 -0600, Brian Paul wrote:
> The SCons build has been using 10 digits of the git hash id for the
> MESA_GIT_SHA1 string in git_sha1.h for about a year now. I bumped it
> up after running into a case where a 7-digit hash ID was ambiguous.
>
> This patch makes the sa
Quoting Kenneth Graunke (2017-06-14 23:10:38)
> On Friday, June 9, 2017 6:01:36 AM PDT Chris Wilson wrote:
> > diff --git a/src/mesa/drivers/dri/i965/hsw_queryobj.c
> > b/src/mesa/drivers/dri/i965/hsw_queryobj.c
> > index b81ab3b6f8..cb1a2df52d 100644
> > --- a/src/mesa/drivers/dri/i965/hsw_queryo
Quoting Kenneth Graunke (2017-06-14 23:50:12)
> On Friday, June 9, 2017 6:01:37 AM PDT Chris Wilson wrote:
> > If we map the bo upon creation, we can avoid the latency of mmapping it
> > when querying, and later use the asynchronous, persistent map of the
> > predicate to do a quick query.
> >
> >
Hi Brian,
On 15 June 2017 at 04:46, Brian Paul wrote:
> The SCons build has been using 10 digits of the git hash id for the
> MESA_GIT_SHA1 string in git_sha1.h for about a year now. I bumped it
> up after running into a case where a 7-digit hash ID was ambiguous.
>
> This patch makes the same c
Hi Jason,
On 14 June 2017 at 17:59, Jason Ekstrand wrote:
> On Wed, Jun 14, 2017 at 1:06 AM, Daniel Stone wrote:
>> Ah, missed this reply. I'll leave that in your hands then and wait for
>> your patches, as well as Chad's ones to update the new protocol in a
>> few days. Happy to review those wh
Quoting Kenneth Graunke (2017-06-15 00:13:14)
> On Friday, June 9, 2017 6:01:38 AM PDT Chris Wilson wrote:
> > Ony non-llc architectures where we are primarily reading back the
> > results of the GPU queries, then we can improve performance by using a
> > cacheable mapping of the results. Unfortuna
On Thursday, 2017-06-15 09:56:55 +0100, Emil Velikov wrote:
> Hi Brian,
>
> On 15 June 2017 at 04:46, Brian Paul wrote:
> > The SCons build has been using 10 digits of the git hash id for the
> > MESA_GIT_SHA1 string in git_sha1.h for about a year now. I bumped it
> > up after running into a cas
https://bugs.freedesktop.org/show_bug.cgi?id=77240
Eric Engestrom changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Wed, 2017-06-14 at 10:15 +0200, Iago Toral wrote:
> I dropped a minor suggestion in patch 7 (feel free to ignore) and a
> style issue in patch 8, otherwise:
>
> Patches 1-8 are:
> Reviewed-by: Iago Toral Quiroga
Patches 9-13 are also:
Reviewed-by: Iago Toral Quiroga
Granted, my blorp / fast
On 15 June 2017 at 10:12, Eric Engestrom wrote:
> On Thursday, 2017-06-15 09:56:55 +0100, Emil Velikov wrote:
>> Hi Brian,
>>
>> On 15 June 2017 at 04:46, Brian Paul wrote:
>> > The SCons build has been using 10 digits of the git hash id for the
>> > MESA_GIT_SHA1 string in git_sha1.h for about a
st/mesa already takes care of this.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/radeonsi/si_state.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 1cd1f9190e0..ac9358c6b3b 100644
--- a/src/
Quoting Kenneth Graunke (2017-06-15 00:19:35)
> On Friday, June 9, 2017 6:01:40 AM PDT Chris Wilson wrote:
> > Reuse the same query object buffer for multiple queries within the same
> > batch.
> >
> > A task for the future is propagating the GL_NO_MEMORY errors.
> >
> > Signed-off-by: Chris Wils
On 15.06.2017 00:36, Connor Abbott wrote:
I was looking into WQM stuff today, and I realized that LLVM will no
longer mark this instruction as needing WQM, which seems like a
problem. Seems like we need a patch to LLVM. Other uses of DPP (e.g.
for the subgroup reduction stuff) won't want WQM, so
---
I haven't tried to benchmark/profile this with anything but it makes
sense to try skip this if we can.
src/mesa/main/uniform_query.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index fed33df..3
Quoting Kenneth Graunke (2017-06-14 21:41:56)
> On Tuesday, June 13, 2017 2:53:24 PM PDT Jason Ekstrand wrote:
> > From: Topi Pohjolainen
> >
> > v2 (Jason Ekstrand):
> > - Take a flags parameter to control the flushes
> > - Refactoring
> >
> > Signed-off-by: Topi Pohjolainen
> > ---
> > src
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_eu.h | 18 ++--
src/intel/compiler/brw_eu_emit.c| 38 +
src/intel/compiler/brw_fs_generator.cpp | 5 +++--
3 files changed, 43 insertions(+), 18 deletions(-)
diff
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_eu_defines.h | 2 +
src/intel/compiler/brw_shader.cpp| 5 +
src/intel/compiler/brw_vec4.cpp | 7 ++
src/intel/compiler/brw_vec4.h| 8 ++
src/intel/compiler/brw_vec4_genera
Both spill/unspill process assume that both lower simd width
and DF scalarization were previously done.
* Spilling process does the following:
1) Reads the existing content from the scratch memory that
corresponds to the vertex (use inst->group to know if we
are going to write data to
Hello,
As mentioned in the patch series that implemented Ivybridge support
ARB_gpu_shader_fp64 [0], the only missing feature in that series was
register spilling of 64-bit data and, because of that, about ~39 fp64
piglit tests failed to spill registers.
This new patch series implement register sp
Quoting Kenneth Graunke (2017-06-14 21:44:45)
> On Tuesday, June 13, 2017 2:53:20 PM PDT Jason Ekstrand wrote:
> > As I've been working on converting more things in the GL driver over to
> > blorp, I've been highly annoyed by all of the hangs on Haswell. About one
> > in 3-5 Jenkins runs would han
Use MRF for 1-Oword read messages again to avoid problems when
sending scratch read messages. We cannot reuse the destination as the DF
scratch reads on IVB are splitted in several instructions and that could
end up having invalid data.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/comp
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_vec4_reg_allocate.cpp | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_vec4_reg_allocate.cpp
b/src/intel/compiler/brw_vec4_reg_allocate.cpp
index 58cd862841
We emit scratch read/write to resolve reladdr and when moving
varyings to scratch memory, however these instructions are emitted
before lower simd splitting and before scalarizing DF instructions.
As the code added for doing DF scratch read/writes assumes both
were previously done, added a flag to
On Thu, Jun 1, 2017 at 2:15 PM, Eric Engestrom
wrote:
> If the detections methods ever become able to return different results
> for different threads, the if chain might make threads go back and forth
> between invalid and valid platforms.
> Solve this by doing the detection in a local var and on
On 15/06/17 09:45, Emil Velikov wrote:
Hi Lionel,
Final reminder - doing this will throw a wrench into non-Linux
platforms which want to use Mesa.
On those the kernel vs libdrm copy of the headers have diverged and
while I'm nudging with the guys to get that sorted, the extra copy is
a recipe f
From: Marek Olšák
---
src/mesa/state_tracker/st_atom_sampler.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_sampler.c
b/src/mesa/state_tracker/st_atom_sampler.c
index 8a2205d..f2f4bae 100644
--- a/src/mesa/state_track
Metrics such as IPC are better represented as floats instead of ints.
This will help query with AMD_performance monitor to return more
useful values instead of 0 and 1s.
Signed-off-by: Boyan Ding
---
.../drivers/nouveau/nvc0/nvc0_query_hw_metric.c| 28 +++---
1 file changed,
Performance counters may return floating point values, but the hud is
currently interpreting them as int regarding of type. As hud doesn't
support floating point values, cast them to ints instead.
Reviewed-by: Samuel Pitoiset
Signed-off-by: Boyan Ding
---
src/gallium/auxiliary/hud/hud_driver_qu
Now that gallium hud properly handle floating point values. And it also
helps AMD_performance_monitor to return return correct values for non
integer types.
Reviewed-by: Samuel Pitoiset
Signed-off-by: Boyan Ding
---
.../drivers/nouveau/nvc0/nvc0_query_hw_metric.c| 70 +-
On Thursday, 2017-06-15 14:24:55 +0300, Grazvydas Ignotas wrote:
> On Thu, Jun 1, 2017 at 2:15 PM, Eric Engestrom
> wrote:
> > If the detections methods ever become able to return different results
> > for different threads, the if chain might make threads go back and forth
> > between invalid and
Hi Jason
On 15.06.2017 03:54, Jason Ekstrand wrote:
> Sky Lake and above can fast-clear exactly the same set of formats as
> older hardware. The only restriction is that you can't *texture* from
> it unless the format supports CCS_E but you can fast-clear and render to
> it just fine. All of th
As mentioned offline, patch 1 is missing previous Marek's Rb, please
re-add it before pushing.
Looks good to me.
Reviewed-by: Samuel Pitoiset
On 06/15/2017 02:11 PM, Boyan Ding wrote:
Metrics such as IPC are better represented as floats instead of ints.
This will help query with AMD_performa
Hi Emil and Christian,
Modified patch as per the comments and added CC: mesa-stable
From: Chandu Babu N
As encode support is added along with decode,
increase max_entrypoints to two.
vaMaxNumEntrypoints will return correct value.
v2: assert when max_entrypoints needs to be bigger
---
src/gal
Hi,
This a pretty minor update that splits the build system changes into 2
parts (i915 & i965/anv) following Emil's comments. I left people's
Ack-by/Reviewed-by given there isn't any functionnal change. Unless I
get any complaint within the next day, it'll pushed.
Thanks!
Lionel Landwerlin (3):
This enables us to compile aubinator without the libdrm dependency.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Kenneth Graunke
---
src/intel/tools/intel_aub.h | 153
1 file changed, 153 insertions(+)
create mode 100644 src/intel/tools/intel_aub.h
Signed-off-by: Lionel Landwerlin
Reviewed-by: Kenneth Graunke
---
configure.ac| 4 ++--
src/gallium/drivers/i915/Automake.inc | 2 +-
src/gallium/targets/pipe-loader/Makefile.am | 2 +-
src/gallium/winsys/i915/drm/Makefile.am | 2 +-
src/mesa/drivers/dri
On 06/15/2017 03:38 AM, Emil Velikov wrote:
On 15 June 2017 at 10:12, Eric Engestrom wrote:
On Thursday, 2017-06-15 09:56:55 +0100, Emil Velikov wrote:
Hi Brian,
On 15 June 2017 at 04:46, Brian Paul wrote:
The SCons build has been using 10 digits of the git hash id for the
MESA_GIT_SHA1 str
On Mon, 2017-05-15 at 11:56 +0100, Emil Velikov wrote:
> On 13 May 2017 at 01:11, Andres Gomez wrote:
> > We were not considering as multiple fixes lines with:
> > Fixes: $sha_1, Fixes: $sha_2
> >
> > Now, we split the lines so we will consider them individually, as in:
> > Fixes: $sha_1,
> > Fix
On 15/06/17 08:42, Kenneth Graunke wrote:
On Wednesday, June 14, 2017 5:38:30 PM PDT Lionel Landwerlin wrote:
From: Robert Bragg
Enables access to OA unit metrics on Gen8+ via INTEL_performance_query.
Signed-off-by: Robert Bragg
---
src/mesa/drivers/dri/i965/Makefile.am | 8 +
Hi Emil and Christian,
Modified patch as per the comments and added CC: mesa-stable
From: Chandu Babu N
As encode support is added along with decode, increase max_entrypoints to two.
vaMaxNumEntrypoints will return correct value.
v2: assert when max_entrypoints needs to be bigger
---
src/gal
Hello list,
The candidate for the Mesa 17.1.3 is now available. Currently we have:
- 25 queued
- 11 nominated (outstanding)
- and 0 rejected patch(es)
In the current queue we have:
On the loaders side - GLX/DRI3 has correct drawable invalidation while EGL
has improved error handling in eglQu
Hey all,
We haven't landed the fixes to break the r600g dependency on AMDGPU yet.
I'm headed out of town for a long weekend and don't feel like risking the
push before being gone for five days.
I've got a v3 of Emil's patch 4/5 that removes the AMDGPU header dependency
from r600 and I'm good with
On Thursday, 2017-06-15 06:54:18 -0600, Brian Paul wrote:
> On 06/15/2017 03:38 AM, Emil Velikov wrote:
> > On 15 June 2017 at 10:12, Eric Engestrom wrote:
> > > On Thursday, 2017-06-15 09:56:55 +0100, Emil Velikov wrote:
> > > > Hi Brian,
> > > >
> > > > On 15 June 2017 at 04:46, Brian Paul wro
On 14 June 2017 at 15:57, Chuck Atkins wrote:
> Thanks Emil. I assume this is fine for 17.1 stable as well then?
>
Indeed it is. Relaxing restrictions is always welcome ;-)
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.fr
On Tue, Jun 13, 2017 at 1:55 PM, Chad Versace wrote:
> On Fri 09 Jun 2017, Tapani Pälli wrote:
>>
>>
>> On 06/08/2017 09:27 PM, Chad Versace wrote:
>> > On Thu 08 Jun 2017, Tomasz Figa wrote:
>> > > On Thu, Jun 8, 2017 at 4:08 PM, Tapani Pälli
>> > > wrote:
>> > > >
>> > > > On 06/08/2017 09:36
On 15 June 2017 at 13:54, Brian Paul wrote:
> On 06/15/2017 03:38 AM, Emil Velikov wrote:
>>
>> On 15 June 2017 at 10:12, Eric Engestrom
>> wrote:
>>>
>>> On Thursday, 2017-06-15 09:56:55 +0100, Emil Velikov wrote:
Hi Brian,
On 15 June 2017 at 04:46, Brian Paul wrote:
>
>
On 15 June 2017 at 13:55, Andres Gomez wrote:
> On Mon, 2017-05-15 at 11:56 +0100, Emil Velikov wrote:
>> On 13 May 2017 at 01:11, Andres Gomez wrote:
>> > We were not considering as multiple fixes lines with:
>> > Fixes: $sha_1, Fixes: $sha_2
>> >
>> > Now, we split the lines so we will consider
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because
of a fence issue.
while debuging further it is observed that droid_window_enqueue_buffer() is
forcing
fence_fd =-1. Whats the expectation here if app wants to use fence sync?
If we want to have this native a
On 15 June 2017 at 13:46, Lionel Landwerlin
wrote:
> --- a/src/intel/Makefile.vulkan.am
> +++ b/src/intel/Makefile.vulkan.am
> @@ -84,13 +84,13 @@ VULKAN_CFLAGS = \
> VULKAN_CPPFLAGS = \
> -I$(top_srcdir)/src/compiler \
> -I$(top_srcdir)/src/intel/compiler \
> + -I$(top_src
On 15 June 2017 at 13:46, Lionel Landwerlin
wrote:
> Signed-off-by: Lionel Landwerlin
> Reviewed-by: Kenneth Graunke
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On 15 June 2017 at 14:27, Marathe, Yogesh wrote:
> Hello,
>
> I'm tyring to run flatland native app on android. It apparantly fails because
> of a fence issue.
> while debuging further it is observed that droid_window_enqueue_buffer() is
> forcing
> fence_fd =-1. Whats the expectation here if ap
On 12 January 2017 at 15:31, Emil Velikov wrote:
> On 12 January 2017 at 07:38, Liu Zhiquan wrote:
>> when dri2_add_config, driver_configs may add to exist dri2_conf,
>> the config id should not increase in this case.
>> In the code, when ConfigID equal to count+1, it's mean a new config,
>> conf
On Thursday, 2017-06-15 13:27:06 +, Marathe, Yogesh wrote:
> Hello,
>
> I'm tyring to run flatland native app on android. It apparantly fails because
> of a fence issue.
> while debuging further it is observed that droid_window_enqueue_buffer() is
> forcing
> fence_fd =-1.
I assume you've
On 06/15/2017 07:10 AM, Emil Velikov wrote:
On 15 June 2017 at 13:54, Brian Paul wrote:
On 06/15/2017 03:38 AM, Emil Velikov wrote:
On 15 June 2017 at 10:12, Eric Engestrom
wrote:
On Thursday, 2017-06-15 09:56:55 +0100, Emil Velikov wrote:
Hi Brian,
On 15 June 2017 at 04:46, Brian Paul
The SCons build has been using 10 digits of the git hash id for the
MESA_GIT_SHA1 string in git_sha1.h for about a year now. I bumped it
up after running into a case where a 7-digit hash ID was ambiguous.
This patch makes the same change for the autotools build.
The command "git log | grep "^com
> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, June 15, 2017 7:24 PM
> To: Marathe, Yogesh
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] egl/android: fence_fd being forced to -1
>
> On 15 June 2017 at 14:27, Marathe, Yogesh
On Thursday, 2017-06-15 08:06:54 -0600, Brian Paul wrote:
> The SCons build has been using 10 digits of the git hash id for the
> MESA_GIT_SHA1 string in git_sha1.h for about a year now. I bumped it
> up after running into a case where a 7-digit hash ID was ambiguous.
>
> This patch makes the sam
> -Original Message-
> From: Eric Engestrom [mailto:eric.engest...@imgtec.com]
> Sent: Thursday, June 15, 2017 7:30 PM
> To: Marathe, Yogesh
> Cc: mesa-dev@lists.freedesktop.org; Chad Versace
> ; Palli, Tapani
> Subject: Re: [Mesa-dev] egl/android: fence_fd being forced to -1
>
> On Thu
On 06/15/2017 08:14 AM, Eric Engestrom wrote:
On Thursday, 2017-06-15 08:06:54 -0600, Brian Paul wrote:
The SCons build has been using 10 digits of the git hash id for the
MESA_GIT_SHA1 string in git_sha1.h for about a year now. I bumped it
up after running into a case where a 7-digit hash ID w
On 15/06/17 08:51, Kenneth Graunke wrote:
On Wednesday, June 14, 2017 5:38:31 PM PDT Lionel Landwerlin wrote:
Due to an underlying hardware race condition, we have no guarantee
that all the reports coming from the OA buffer related to the workload
we're trying to measure have landed to memory by
On 6 June 2017 at 22:28, Mauro Rossi wrote:
> And here is last (v3) version tested by building nougat-x86
>
Perfect. Pushed alongside the r600 generation fix. Will sort out the
libdrm_amdgpu ones in a second.
-Emil
___
mesa-dev mailing list
mesa-dev@lis
On 7 June 2017 at 16:22, Jonathan Gray wrote:
> On Wed, Jun 07, 2017 at 11:18:53PM +0800, Chih-Wei Huang wrote:
>> 2017-06-07 22:47 GMT+08:00 Jonathan Gray :
>> > On Wed, Jun 07, 2017 at 10:30:49PM +0800, Chih-Wei Huang wrote:
>> >> 2017-06-07 21:54 GMT+08:00 Jonathan Gray :
>> >> > On Wed, Jun 07
I think it's safer to keep this, considering that the call is quite expensive.
Marek
On Thu, Jun 15, 2017 at 11:47 AM, Samuel Pitoiset
wrote:
> st/mesa already takes care of this.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/drivers/radeonsi/si_state.c | 3 ---
> 1 file changed, 3 de
While I agree, I also think that it's safer to keep it.
Marek
On Thu, Jun 15, 2017 at 12:13 AM, Samuel Pitoiset
wrote:
> CSO already takes care of this.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/drivers/radeonsi/si_state.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a
This conflicts with:
https://patchwork.freedesktop.org/patch/161252/
Marek
On Thu, Jun 15, 2017 at 12:59 PM, Timothy Arceri wrote:
> ---
>
> I haven't tried to benchmark/profile this with anything but it makes
> sense to try skip this if we can.
>
> src/mesa/main/uniform_query.cpp | 6 +-
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
wrote:
> On Thursday, 2017-06-15 13:27:06 +, Marathe, Yogesh wrote:
>> Hello,
>>
>> I'm tyring to run flatland native app on android. It apparantly fails
>> because of a fence issue.
>> while debuging further it is observed that droid_window_enq
On Thu, Jun 15, 2017 at 4:15 AM, Chris Wilson
wrote:
> Quoting Kenneth Graunke (2017-06-14 21:44:45)
> > On Tuesday, June 13, 2017 2:53:20 PM PDT Jason Ekstrand wrote:
> > > As I've been working on converting more things in the GL driver over to
> > > blorp, I've been highly annoyed by all of the
On Thu, Jun 15, 2017 at 4:11 AM, Chris Wilson
wrote:
> Quoting Kenneth Graunke (2017-06-14 21:41:56)
> > On Tuesday, June 13, 2017 2:53:24 PM PDT Jason Ekstrand wrote:
> > > From: Topi Pohjolainen
> > >
> > > v2 (Jason Ekstrand):
> > > - Take a flags parameter to control the flushes
> > > - Re
On 06/15/2017 06:52 PM, Rob Clark wrote:
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
wrote:
On Thursday, 2017-06-15 13:27:06 +, Marathe, Yogesh wrote:
Hello,
I'm tyring to run flatland native app on android. It apparantly fails because
of a fence issue.
while debuging further it is o
On Mon, May 22, 2017 at 12:12 PM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:
> Current version fails to set depthstencil.depth_offset when there
> is only stencil attachment (it does set the intra tile offsets
> though). Fixes piglits:
>
> g45,g965,ilk: depthstencil-render-miplevels 1
Yes, please!
Reviewed-by: Jason Ekstrand
On Mon, May 22, 2017 at 12:12 PM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:
> Separate stencil and hiz are only enabled for gen6+.
>
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/brw_context.h| 6 +-
> src/mesa/d
Quoting Jason Ekstrand (2017-06-15 16:59:19)
> On Thu, Jun 15, 2017 at 4:11 AM, Chris Wilson
> wrote:
> The kernel does have a LRI after a flush before signaling the batch is
> complete. I don't see a need to add another...
>
> The question is whether this posting is required for GPU
Emil, would you be fine with leaving the image extension in dri2.c but
still adding it as a drisw extension? That solution would look like:
https://patchwork.freedesktop.org/patch/154807/
On Fri, Jun 9, 2017 at 8:40 AM, Gurchetan Singh wrote:
> Actually, these are the only patches that are req
The swr driver uses vertex_buffer->stride to determine the number
of elements in a VBO. A recent change to the state-tracker made it
possible for VBO's with stride=0. This resulted in a divide by zero
crash in the driver. The solution is to use the pre-calculated vertex
element stream_pitch in this
Quoting Jason Ekstrand (2017-06-15 16:58:13)
> On Thu, Jun 15, 2017 at 4:15 AM, Chris Wilson
> wrote:
>
> Quoting Kenneth Graunke (2017-06-14 21:44:45)
> > If Chris is right, and what we're really seeing is that MI_SET_CONTEXT
> > needs additional flushing, it probably makes sense to
This patch makes the assumption that, if stencil_irb != NULL then depth_irb
!= NULL. I did a bunch of digging and I am now convinced that this is a
fine assumption. Specifically, in intel_renderbuffer_format() in
intel_fbo.c, we map all STENCIL_INDEX internal formats to Z24_UNORM_S8_UINT
on gen4-
On Thu, Jun 15, 2017 at 9:36 AM, Jason Ekstrand
wrote:
> This patch makes the assumption that, if stencil_irb != NULL then
> depth_irb != NULL. I did a bunch of digging and I am now convinced that
> this is a fine assumption. Specifically, in intel_renderbuffer_format() in
> intel_fbo.c, we map
On Thu, Jun 15, 2017 at 9:32 AM, Chris Wilson
wrote:
> Quoting Jason Ekstrand (2017-06-15 16:58:13)
> > On Thu, Jun 15, 2017 at 4:15 AM, Chris Wilson
> wrote:
> >
> > Quoting Kenneth Graunke (2017-06-14 21:44:45)
> > > If Chris is right, and what we're really seeing is that
> MI_SET_CONT
On Thu, Jun 15, 2017 at 9:14 AM, Chris Wilson
wrote:
> Quoting Jason Ekstrand (2017-06-15 16:59:19)
> > On Thu, Jun 15, 2017 at 4:11 AM, Chris Wilson
> wrote:
> > The kernel does have a LRI after a flush before signaling the batch
> is
> > complete. I don't see a need to add another...
>
On Thu, Jun 15, 2017 at 2:28 AM, Iago Toral wrote:
> On Wed, 2017-06-14 at 10:15 +0200, Iago Toral wrote:
> > I dropped a minor suggestion in patch 7 (feel free to ignore) and a
> > style issue in patch 8, otherwise:
> >
> > Patches 1-8 are:
> > Reviewed-by: Iago Toral Quiroga
>
> Patches 9-13 a
On Thu, Jun 15, 2017 at 12:04 PM, Tapani Pälli wrote:
> On 06/15/2017 06:52 PM, Rob Clark wrote:
>>
>> On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
>> wrote:
>>>
>>> On Thursday, 2017-06-15 13:27:06 +, Marathe, Yogesh wrote:
Hello,
I'm tyring to run flatland native app
On Mon, Jun 12, 2017 at 4:25 PM, Anuj Phogat wrote:
> On Mon, Jun 12, 2017 at 3:28 PM, Francisco Jerez
> wrote:
>> Anuj Phogat writes:
>>
>>> On Mon, Jun 12, 2017 at 12:22 PM, Francisco Jerez
>>> wrote:
Anuj Phogat writes:
> On Mon, Jun 12, 2017 at 11:10 AM, Francisco Jerez
>
On Thu, Jun 15, 2017 at 09:41:42AM -0700, Jason Ekstrand wrote:
> On Thu, Jun 15, 2017 at 9:36 AM, Jason Ekstrand
> wrote:
>
> > This patch makes the assumption that, if stencil_irb != NULL then
> > depth_irb != NULL. I did a bunch of digging and I am now convinced that
> > this is a fine assump
On 06/15/2017 07:57 PM, Rob Clark wrote:
On Thu, Jun 15, 2017 at 12:04 PM, Tapani Pälli wrote:
On 06/15/2017 06:52 PM, Rob Clark wrote:
On Thu, Jun 15, 2017 at 9:59 AM, Eric Engestrom
wrote:
On Thursday, 2017-06-15 13:27:06 +, Marathe, Yogesh wrote:
Hello,
I'm tyring to run flatland na
On Wed, Jun 14, 2017 at 10:13:41AM +0200, Iago Toral wrote:
> On Tue, 2017-06-13 at 11:41 -0700, Nanley Chery wrote:
> > Splitting out these fields will make the color buffer transitioning
> > function simpler when it gains more features.
> >
> > Signed-off-by: Nanley Chery
> > ---
> > src/intel
On Thu, Jun 15, 2017 at 10:14 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:
> On Thu, Jun 15, 2017 at 09:41:42AM -0700, Jason Ekstrand wrote:
> > On Thu, Jun 15, 2017 at 9:36 AM, Jason Ekstrand
> > wrote:
> >
> > > This patch makes the assumption that, if stencil_irb != NULL then
> >
The line stipple fallback code for virtual HW version 8 didn't work.
With HW version 8, we were getting zero when querying the max line
widths (AA and non-AA). This means we were setting the draw module's
wide line threshold to zero. This caused the wide line stage to always
get enabled. That c
We shouldn't use the wide line stage if the line width is 1.
This check isn't strictly needed because all drivers are (now)
specifying a line wide threshold of at least 1.0 pixels, but
let's play it safe.
---
src/gallium/auxiliary/draw/draw_pipe_validate.c | 7 ---
1 file changed, 4 insertions
Series is
Reviewed-by: Jason Ekstrand
On Mon, May 22, 2017 at 12:12 PM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:
> CC: Kenneth Graunke
> Signed-off-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/brw_misc_state.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --g
Indeed the other two commits are related to the no_error path, but I
think at least this one should be applied. So it is:
Reviewed-by: Rafael Antognolli
On Wed, Jun 14, 2017 at 07:33:12PM +0300, Plamena Manolova wrote:
> In blit_framebuffer we're already doing a NULL
> pointer check for readFb a
1 - 100 of 191 matches
Mail list logo
