Reviewed-by: Edward O'Callaghan
On 08/30/2016 08:09 PM, Michael Schellenberger Costa wrote:
> These are the final asserts in the tree that do not follow the pattern
> assert(!"foo"). To simplify spotting of (mostly) incorrect asserts via git
> grep "assert(\"" rewrite them into the standard for
On Tue, Aug 30, 2016 at 07:34:57AM -0700, Jason Ekstrand wrote:
>On Mon, Aug 29, 2016 at 11:39 PM, Pohjolainen, Topi
><[1]topi.pohjolai...@gmail.com> wrote:
>
> On Mon, Aug 29, 2016 at 09:00:33AM -0700, Jason Ekstrand wrote:
> > Topi asked to have the prefix removed because there
On Tue, Aug 30, 2016 at 12:09:52PM +0200, Michael Schellenberger Costa wrote:
> These are the final asserts in the tree that do not follow the pattern
> assert(!"foo"). To simplify spotting of (mostly) incorrect asserts via git
> grep "assert(\"" rewrite them into the standard form.
>
> Signed-o
On Tue, Aug 30, 2016 at 04:49:53PM -0700, k...@bitplanet.net wrote:
> From: "Kristian H. Kristensen"
>
> As long as the dma_buf fds import to the same drm_intel_bo, we're fine.
>
> Reviewed-by: Stéphane Marchesin
Looks good to me.
Reviewed-by: Eric Engestrom
> ---
> src/mesa/drivers/dri/i96
From: Nayan Deshmukh
v2: avoid dividing by zero when calculating lanczos
v4 (chk): rebase on master
Signed-off-by: Nayan Deshmukh
---
src/gallium/auxiliary/Makefile.sources | 2 +
src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445 +++
src/gallium/auxiliary/vl/v
From: Nayan Deshmukh
HIGH_QUALITY_SCALING_L2 to HIGH_QUALTIY_SCALING_L7
uses lanczos filter with number representing the size
of the sinc window.
v3: avoid L8 and L9 to allow for other scaling algrithms
v4 (chk): rebased on master
Signed-off-by: Nayan Deshmukh
---
src/gallium/state_trackers/v
Hi Nayan,
picking this topic up once more. Following this mail are your patches rebased
on top of current master.
I also played around with them a bit. One bug I've found which should also be
reproducible for you is when switching mpv from windowed to fullscreen and back
the video seems to become
Hi,
On 31.08.2016 08:03, Kenneth Graunke wrote:
On Tuesday, August 30, 2016 3:52:12 PM PDT Ian Romanick wrote:
[snip]
I don't recall any native Linux games encountering this, but my memory
may have faded. There were some Windows DirectX games that would
exhaust VMA when run inside VMware. Onc
On 08/30/2016 09:27 AM, Serge Martin wrote:
> On Tuesday 30 August 2016 01:20:55 Vedran Miletić wrote:
>> Options specified via the CLOVER_COMPILER_OPTIONS shell variable are
>> appended to the compiler options specified by the OpenCL program (if
>> any).
>>
>> Signed-off-by: Vedran Miletić
>> ---
Hi Christian,
You missed a few things in the merge. I will send in the updated patch.
I looked at the code in vl_winsys.c and vl_winsys3.c and also
at the code in presentation.c where delayed rendering is used. I was trying
to compile using vl_dri3_screen_create() but its giving me some error. I
https://bugs.freedesktop.org/show_bug.cgi?id=93723
Eero Tamminen changed:
What|Removed |Added
Summary|vblank_mode=3 segfaults |vblank_mode=3 segfaults
HIGH_QUALITY_SCALING_L2 to HIGH_QUALTIY_SCALING_L7
uses lanczos filter with number representing the size
of the sinc window.
v3: avoid L8 and L9 to allow for other scaling algrithms
v4 (chk): rebased on master
Signed-off-by: Nayan Deshmukh
---
src/gallium/state_trackers/vdpau/mixer.c |
v2: avoid dividing by zero when calculating lanczos
v4 (chk): rebase on master
Signed-off-by: Nayan Deshmukh
---
src/gallium/auxiliary/Makefile.sources | 2 +
src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445 +++
src/gallium/auxiliary/vl/vl_lanczos_filter.h | 6
Options specified via the CLOVER_EXTRA_COMPILER_OPTIONS shell variable
are appended to the compiler and linker options specified by the OpenCL
program (if any).
v2:
* rename to CLOVER_EXTRA_COMPILER_OPTIONS
* use debug_get_option
* append to linker options as well
Signed-off-by: Vedran Miletić
On 08/28/2016 04:42 PM, Niels Ole Salscheider wrote:
> This is required by the OpenCL standard.
>
> Signed-off-by: Niels Ole Salscheider
Reviewed-by: Vedran Miletić
Good catch. Do we miss more defines from [1]?
Regards,
Vedran
[1]
https://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/pre
On 08/31/2016 08:03 AM, Kenneth Graunke wrote:
On Tuesday, August 30, 2016 3:52:12 PM PDT Ian Romanick wrote:
[snip]
I don't recall any native Linux games encountering this, but my memory
may have faded. There were some Windows DirectX games that would
exhaust VMA when run inside VMware. Once
NS2 causes mmap failures on radeonsi. My guess is that there is a memory
leak somewhere. I have no evidence that the compiler is responsible for
that.
Marek
On Aug 31, 2016 11:31 AM, "Eero Tamminen" wrote:
> Hi,
>
> On 31.08.2016 08:03, Kenneth Graunke wrote:
>
>> On Tuesday, August 30, 2016 3:
On 08/31/2016 12:11 PM, Vedran Miletić wrote:
> Options specified via the CLOVER_EXTRA_COMPILER_OPTIONS shell variable
> are appended to the compiler and linker options specified by the OpenCL
> program (if any).
>
> v2:
> * rename to CLOVER_EXTRA_COMPILER_OPTIONS
> * use debug_get_option
> * a
On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
>
> On 30/08/16 06:51 PM, Marek Olšák wrote:
> >
> > If we don't care about memory usage, let's use my allocator. If we do,
> > let's import jemalloc into the Mesa tree and use it for ralloc.
>
> Instead of importing jemalloc into Mesa, could we use
HI,
On 31.08.2016 15:40, Marek Olšák wrote:
On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
On 30/08/16 06:51 PM, Marek Olšák wrote:
If we don't care about memory usage, let's use my allocator. If we do,
let's import jemalloc into the Mesa tree and use it for ralloc.
Instead of importing
On 30 August 2016 at 23:38, Matt Turner wrote:
> The biweekly stable releases have stopped without any indication why.
> 11.2.2 was nearly four months ago, and there effectively hasn't been a
> stable release in the 12.0 series.
>
> Can we resume these as soon as possible?
Consider everything back
On Wednesday 31 August 2016 12:11:05 Vedran Miletić wrote:
> Options specified via the CLOVER_EXTRA_COMPILER_OPTIONS shell variable
> are appended to the compiler and linker options specified by the OpenCL
> program (if any).
>
> v2:
> * rename to CLOVER_EXTRA_COMPILER_OPTIONS
> * use debug_get_
On 31 August 2016 at 13:40, Marek Olšák wrote:
> On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
>>
>> On 30/08/16 06:51 PM, Marek Olšák wrote:
>> >
>> > If we don't care about memory usage, let's use my allocator. If we do,
>> > let's import jemalloc into the Mesa tree and use it for ralloc.
>>
On Wed, Aug 31, 2016 at 2:22 AM, Thomas Hellstrom wrote:
> The code was triggering asserts in DEBUG builds of the SVGA driver since
> the reference count of the resource was never decremented before destroy.
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Brian Paul
Reviewed-by: Alex Deucher
On Wed, Aug 31, 2016 at 3:02 PM, Emil Velikov wrote:
> On 31 August 2016 at 13:40, Marek Olšák wrote:
>> On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
>>>
>>> On 30/08/16 06:51 PM, Marek Olšák wrote:
>>> >
>>> > If we don't care about memory usage, let's use my allocator. If we do,
>>> > let's
On Tue, 2016-08-30 at 21:50 -0700, Kenneth Graunke wrote:
> calculate_attr_overrides() uses is_drawing_points(), which depends
> on tessellation and geometry program state, as well as polygon state.
>
> v2: Add missing _NEW_POLYGON as well. Caught by Iago Toral.
>
> Signed-off-by: Kenneth Graunk
https://bugs.freedesktop.org/show_bug.cgi?id=97549
Bug ID: 97549
Summary: [SNB, BXT] up to 40% perf drop from "loader/dri3:
Overhaul dri3_update_num_back" commit
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
On Wednesday 31 August 2016 12:39:23 Vedran Miletić wrote:
> On 08/28/2016 04:42 PM, Niels Ole Salscheider wrote:
> > This is required by the OpenCL standard.
> >
> > Signed-off-by: Niels Ole Salscheider
> Reviewed-by: Vedran Miletić
>
> Good catch. Do we miss more defines from [1]?
I think __
On Tue, 2016-08-30 at 21:51 -0700, Kenneth Graunke wrote:
> The original motivation was that gen6_clip_state ignored _NEW_POLYGON
> as it didn't care about early culling. The only other change was
> that
> Gen6 ignored BRW_NEW_TES_PROG_DATA as it doesn't have tessellation
> shaders, but listening
This set implements hevc decode for omx, it includes basic structures
from h264 implementation and hevc specific sps, pps, slice header and
reference picture sets, as well as what's required by uvd.
Leo Liu (7):
st/omx/dec: add initial omx hevc support
st/omx/dec/h265: add sequence parameter s
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_dec_h265.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/src/gallium/state_trackers/omx/vid_dec_h265.c
b/src/gallium/state_trackers/omx/vid_dec_h265.c
index df2dc05..7c0f75d 100644
--- a/src/gallium/
Specified by subclause 7.3.2.2
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_dec.h | 2 +
src/gallium/state_trackers/omx/vid_dec_h265.c | 295 ++
2 files changed, 297 insertions(+)
diff --git a/src/gallium/state_trackers/omx/vid_dec.h
b/src/galliu
Specified by subclause 7.3.7
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_dec_h265.c | 114 +-
1 file changed, 110 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec_h265.c
b/src/gallium/state_trackers/omx/vid_dec_h265.c
i
Specified by subclause 7.3.6.1
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_dec.h | 3 +
src/gallium/state_trackers/omx/vid_dec_h265.c | 215 +-
2 files changed, 216 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec
Specified by subclause 7.3.2.3
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_dec_h265.c | 98 +++
1 file changed, 98 insertions(+)
diff --git a/src/gallium/state_trackers/omx/vid_dec_h265.c
b/src/gallium/state_trackers/omx/vid_dec_h265.c
index 293bdd2..b
Mainly based on the h264 implementation.
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/Makefile.sources | 1 +
src/gallium/state_trackers/omx/vid_dec.h| 11 ++
src/gallium/state_trackers/omx/vid_dec_h265.c | 148
3 files changed, 160 insertions(+
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_dec.c | 23 ++-
src/gallium/state_trackers/omx/vid_dec.h | 3 +++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec.c
b/src/gallium/state_trackers/omx/vid_dec.c
On Aug 19, 2016 12:07 AM, "Michel Dänzer" wrote:
>
> From: Michel Dänzer
>
> Always use 3 buffers when flipping. With only 2 buffers, we have to wait
> for a flip to complete (which takes non-0 time even with asynchronous
> flips) before we can start working on the next frame. We were previously
On 31 August 2016 at 14:37, Marek Olšák wrote:
> On Wed, Aug 31, 2016 at 3:02 PM, Emil Velikov
> wrote:
>> On 31 August 2016 at 13:40, Marek Olšák wrote:
>>> On Aug 31, 2016 5:02 AM, "Michel Dänzer" wrote:
On 30/08/16 06:51 PM, Marek Olšák wrote:
>
> If we don't care about
Hi,
On 31.08.2016 16:37, Marek Olšák wrote:
...
OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
conflict with libc and Steam.
>
When building jemalloc from source, there is an option to add a function prefix.
There are basically two options at the moment:
- my allocator: is
On Tue, 2016-08-30 at 12:08 -0700, Matt Turner wrote:
> Without this, we would pass over the instructions in the SIMD8
> program
> (which is located earlier in the buffer) when brw_set_uip_jip() is
> called to handle the SIMD16 program.
oh, right.
> The assertion about compacted control flow was
On Mon, Jun 20, 2016 at 11:46:49AM +0100, Eric Engestrom wrote:
> On Fri, Jun 17, 2016 at 06:29:40PM +0100, Frank Binns wrote:
> > When trying to get a device name for an fd using sysfs, it would always fail
> > as it was expecting key/value pairs to be delimited by '\0', which is not
> > the
> >
Series is
Reviewed-by: Ilia Mirkin
I think this was an attempt to feed immediates via a constbuf. Not
sure what the advantage is, although at least on nv50 many
instructions can't take an immediate. Like you said, this was never
completed, I think it's fine to remove.
On Wed, Aug 31, 2016 at 11
This has never been used because info->immd.bufSize is always 0
and anyways this is an experimental code which has never been
completed.
This gets rid of some unused code in the program validation process.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_program.c |
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nv50/nv50_program.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.h
b/src/gallium/drivers/nouveau/nv50/nv50_program.h
index fc9ada4..009d41f 100644
--- a/src/gallium/drivers/nouveau/
If false, it means do the clear unconditionally.
---
src/gallium/docs/source/context.rst | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/docs/source/context.rst
b/src/gallium/docs/source/context.rst
index 1b045fa..13dd606 100644
--- a/src/gallium/docs/source/context.rst
+++ b/
Blorp consults brw_is_color_fast_clear_compatible() to see if any
restrictions apply for fast clear in addition to the capablities
advertised in isl_format.c::format_info[]. On Gen8+ integer formats
are backlisted for plain old fast clear but there is no reason why
lossless compression shouldn't be
Otherwise once mcs buffer gets allocated without delay for
lossless compression (same as we do for msaa), assert starts
to fire in piglit case: tex3d. The test uses depth of one
which is in fact supported even now.
Signed-off-by: Topi Pohjolainen
---
src/intel/isl/isl.c | 7 ++-
1 file chang
This series requests hardware to generate as many copies of drawing
primitives as there are layers to be cleared instead of submitting
separate render passes for the layers.
In case of patches 2, 3, 8 and 9 I'm open to suggestions. There
probably are other (better?) alternatives.
CC: Jason Ekstra
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp.h | 6 +++---
src/intel/blorp/blorp_clear.c | 16 +---
src/mesa/drivers/dri/i965/brw_blorp.c | 6 +++---
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/src/intel/blorp/blorp.h b/src/int
Originally re-clears where skipped but when lossless compression
was introduced the re-clears where errorneously enabled also for
non-compressed fast clears.
Signed-off-by: Topi Pohjolainen
CC: Ben Widawsky
CC: Kenneth Graunke
CC: Harri Syrja
Cc: Chad Versace
---
src/mesa/drivers/dri/i965/br
Once mcs buffer gets allocated without delay for lossless
compression (same as we do for msaa), one gets regression in:
GL45-CTS.texture_barrier_ARB.same-texel-rw
Setting the auxiliary surface for both sampling engine and data
port seems to fix this. I haven't found any hardware documentation
bac
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp_blit.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 170c381..026061b 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -1271,9 +1271,6
This will indicate target layer (Render Target Array Index) needed
for layered clears.
v2: Use 3DSTATE_VF_SGVS for gen8+
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp_genX_exec.h | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/src/inte
From: Topi Pohjolainen
Blorp consults brw_is_color_fast_clear_compatible() to see if any
restrictions apply for fast clear in addition to the capablities
advertised in isl_format.c::format_info[]. On Gen8+ integer formats
are backlisted for plain old fast clear but there is no reason why
lossless
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp.h | 6 +++---
src/intel/blorp/blorp_clear.c | 16 +---
src/mesa/drivers/dri/i965/brw_blorp.c | 6 +++---
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/src/intel/blorp/blorp.h b/src/int
This will indicate target layer (Render Target Array Index) needed
for layered clears.
v2: Use 3DSTATE_VF_SGVS for gen8+
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp_genX_exec.h | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/src/inte
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
index 4dbba01..17c1ff4 100644
--- a/src/intel/blorp/blorp.c
+++ b/src/intel/blorp/blorp.c
@@ -119,6 +119,9 @@
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp.c | 36 ---
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index ce8b848..c487c0c 100644
--- a/sr
Once mcs buffer gets allocated without delay for lossless
compression (same as we do for msaa), one gets regression in:
GL45-CTS.texture_barrier_ARB.same-texel-rw
Setting the auxiliary surface for both sampling engine and data
port seems to fix this. I haven't found any hardware documentation
bac
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 6339932..ce8b848 100644
--- a/src/mesa/drivers/dri/i965/brw_blo
Otherwise once mcs buffer gets allocated without delay for
lossless compression (same as we do for msaa), assert starts
to fire in piglit case: tex3d. The test uses depth of one
which is in fact supported even now.
Signed-off-by: Topi Pohjolainen
---
src/intel/isl/isl.c | 7 ++-
1 file chang
And fix a mangled comment while at it.
Signed-off-by: Topi Pohjolainen
CC: Ben Widawsky
CC: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_blorp.c | 7 +++-
src/mesa/drivers/dri/i965/brw_meta_util.c | 56 +--
src/mesa/drivers/dri/i965/brw_meta_util.h | 10 +++
such as we do for compressed msaa. In case of non-compressed simgle
sampled buffers the allocation of mcs is deferred until there is
actually a clear operation that needs the mcs.
In case of render buffer compression the mcs buffer always needed
and there is no real reason to defer the allocation.
And fix a mangled comment while at it.
Signed-off-by: Topi Pohjolainen
CC: Ben Widawsky
CC: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_blorp.c | 7 +++-
src/mesa/drivers/dri/i965/brw_meta_util.c | 56 +--
src/mesa/drivers/dri/i965/brw_meta_util.h | 10 +++
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp.c | 36 ---
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index ce8b848..c487c0c 100644
--- a/sr
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp_blit.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 170c381..026061b 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -1271,9 +1271,6
Originally re-clears where skipped but when lossless compression
was introduced the re-clears where errorneously enabled also for
non-compressed fast clears.
Signed-off-by: Topi Pohjolainen
CC: Ben Widawsky
CC: Kenneth Graunke
CC: Harri Syrja
Cc: Chad Versace
---
src/mesa/drivers/dri/i965/br
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 6339932..ce8b848 100644
--- a/src/mesa/drivers/dri/i965/brw_blo
From: Topi Pohjolainen
such as we do for compressed msaa. In case of non-compressed simgle
sampled buffers the allocation of mcs is deferred until there is
actually a clear operation that needs the mcs.
In case of render buffer compression the mcs buffer always needed
and there is no real reason
This series requests hardware to generate as many copies of drawing
primitives as there are layers to be cleared instead of submitting
separate render passes for the layers.
In case of patches 2, 3, 8 and 9 I'm open to suggestions. There
probably are other (better?) alternatives.
CC: Jason Ekstra
Signed-off-by: Topi Pohjolainen
---
src/intel/blorp/blorp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
index 4dbba01..17c1ff4 100644
--- a/src/intel/blorp/blorp.c
+++ b/src/intel/blorp/blorp.c
@@ -119,6 +119,9 @@
On Wed, 2016-08-31 at 15:53 +0200, Serge Martin wrote:
> On Wednesday 31 August 2016 12:39:23 Vedran Miletić wrote:
> >
> > On 08/28/2016 04:42 PM, Niels Ole Salscheider wrote:
> > >
> > > This is required by the OpenCL standard.
> > >
> > > Signed-off-by: Niels Ole Salscheider > > e.de>
> > Re
On Wed, Aug 31, 2016 at 05:39:20PM +0300, Eero Tamminen wrote:
> Hi,
Hi,
>
> On 31.08.2016 16:37, Marek Olšák wrote:
> ...
> > OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
> > conflict with libc and Steam.
> >
> > When building jemalloc from source, there is an option to ad
On Wed, Aug 31, 2016 at 4:39 PM, Eero Tamminen
wrote:
> Hi,
>
> On 31.08.2016 16:37, Marek Olšák wrote:
> ...
>>
>> OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
>> conflict with libc and Steam.
>
>>
>>
>> When building jemalloc from source, there is an option to add a functio
We handled the unsized case, implicitly sizing arrays to the value
of gl_MaxPatchVertices. But if a size was present, we failed to
raise a compile error if it wasn't the value of gl_MaxPatchVertices.
Fixes CTS tests:
*.tessellation_shader.compilation_and_linking_errors.
{tc,te}_invalid_array
https://bugs.freedesktop.org/show_bug.cgi?id=9427
karan kapoor changed:
What|Removed |Added
CC||karan.kapoor...@gmail.com
--
You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=9427
karan kapoor changed:
What|Removed |Added
Version|unspecified |9.2
Resolution|WONTFIX
https://bugs.freedesktop.org/show_bug.cgi?id=9427
karan kapoor changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |karan.kapoor...@gmail.com
Kenneth Graunke writes:
> We handled the unsized case, implicitly sizing arrays to the value
> of gl_MaxPatchVertices. But if a size was present, we failed to
> raise a compile error if it wasn't the value of gl_MaxPatchVertices.
>
> Fixes CTS tests:
>
> *.tessellation_shader.compilation_and_l
From: Jordan Justen
If scissor X or Y was set to a negative value then the previous
code might have indicated noop scissors when the scissor range
actually was masking a portion of the framebuffer.
Since fb->_Xmin, _Xmax, _Ymin and _Ymax take scissors into
account, we can use these to test for a
On Wed, Aug 31, 2016 at 1:05 PM, Matt Turner wrote:
> From: Jordan Justen
>
> If scissor X or Y was set to a negative value then the previous
> code might have indicated noop scissors when the scissor range
> actually was masking a portion of the framebuffer.
>
> Since fb->_Xmin, _Xmax, _Ymin and
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 31, 2016 at 6:04 PM, Brian Paul wrote:
> If false, it means do the clear unconditionally.
> ---
> src/gallium/docs/source/context.rst | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/docs/source/context.rst
> b/src/gallium/doc
On Wed, Aug 31, 2016 at 1:33 AM, Ilia Mirkin wrote:
> On Mon, Aug 29, 2016 at 11:49 AM, Marek Olšák wrote:
>> On Mon, Aug 29, 2016 at 5:41 PM, Ilia Mirkin wrote:
>>> On Mon, Aug 29, 2016 at 11:35 AM, Marek Olšák wrote:
On Sat, Aug 27, 2016 at 11:53 PM, Ilia Mirkin wrote:
> Signed-off-
This function will be helpful for resizing the code segment
area when we need to evict all shaders.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 47 +++--
src/gallium/drivers/nouve
To avoid the bins list to grow up indefinitely when the code segment
size will be bumped, we need to separate that bin from the SCREEN
one because it contains other resources like the uniform bo.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_context.c | 4 ++--
src/gal
When an application uses a ton of shaders, we need to evict them
when the code segment is full but this is not really a good solution
if monster shaders are used because code eviction will happen a lot.
To avoid this, it seems better to dynamically resize the code
segment area after each eviction.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index 6c6d177..0627f3d 100644
--- a/src/gallium/dr
This refactoring will help for fixing the "out of code space"
eviction issue because we will need to reupload the code for
all currently bound shaders but it's slightly different than
uploading a new fresh code.
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_context.h
This fixes a very old issue which happens when the code segment
size is full. A bunch of real applications like Tomb Raider,
F1 2015, Elemental, hit that issue because they use a ton of shaders.
In this case, all shaders are evicted (for freeing space) but all
currently bound shaders also need to
On Wed, Aug 31, 2016 at 4:46 PM, Marek Olšák wrote:
> On Wed, Aug 31, 2016 at 1:33 AM, Ilia Mirkin wrote:
>> On Mon, Aug 29, 2016 at 11:49 AM, Marek Olšák wrote:
>>> On Mon, Aug 29, 2016 at 5:41 PM, Ilia Mirkin wrote:
On Mon, Aug 29, 2016 at 11:35 AM, Marek Olšák wrote:
> On Sat, Aug
The first thing to go in this new library is brw_device_info.
Signed-off-by: Jason Ekstrand
Cc: Rob Herring
---
The android build files I just copied-and-pasted from blorp but I don't
have an android build setup so I can't test them.
src/intel/Android.common.mk| 37 +++
This is the only remaining part of genX_l3.c and there's really no good
reason for it to be in its own file.
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/Makefile.sources | 4 -
src/intel/vulkan/anv_genX.h| 2 +-
src/intel/vulkan/gen7_cmd_buffer.c | 2 +-
src/intel/vulkan/ge
When Jordan first implement L3$ configuration for Vulkan, he copied+pasted
from the GL driver because we had no good place to share it. Now that we
have src/intel/common, we should be sharing these tables.
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_private.h | 6 +-
src/intel/vulk
Right now, we have 3 places where code is shared between the Vulkan and GL
drivers: blorp, isl, and libi965_compiler. There are a few places where we
want to share misc. code that doesn't fall into any of these categories.
This little series adds a new src/intel/common folder and puts the device
i
Now that we're using gen_l3_config.c, we no longer have one set of l3
config functions per gen and we can simplify a bit. Also, we know that
only compute uses SLM so we don't need to look for it in all of the stages.
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_genX.h | 2 --
sr
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/genX_cmd_buffer.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 95ed5f2..2806231 100644
--- a/src/intel/
Signed-off-by: Jason Ekstrand
---
src/intel/common/gen_device_info.c | 4 ++--
src/intel/common/gen_device_info.h | 4 ++--
src/intel/isl/tests/isl_surf_get_image_offset_test.c | 6 +++---
src/intel/tools/disasm.c | 2 +-
src/intel/v
Signed-off-by: Jason Ekstrand
---
src/intel/Makefile.sources| 4 +-
src/intel/common/gen_l3_config.c | 297
src/intel/common/gen_l3_config.h | 108 +
src/mesa/drivers/dri/i965/brw_context.h | 4 +-
src/mesa/drivers/dri/i965/
+Mauro
On Wed, Aug 31, 2016 at 1:56 PM, Jason Ekstrand
wrote:
> The first thing to go in this new library is brw_device_info.
>
> Signed-off-by: Jason Ekstrand
> Cc: Rob Herring
> ---
>
> The android build files I just copied-and-pasted from blorp but I don't
> have an android build setup so I
1 - 100 of 175 matches
Mail list logo
