https://bugs.freedesktop.org/show_bug.cgi?id=100960
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #3 from Timothy A
https://bugs.freedesktop.org/show_bug.cgi?id=106445
zacharybin...@hotmail.com changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOL
https://bugs.freedesktop.org/show_bug.cgi?id=106445
--- Comment #3 from zacharybin...@hotmail.com ---
Could you optimize it for better performance with Cemu please? Just compare amd
on linux vs nvidia.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Conta
Signed-off-by: Tapani Pälli
---
src/mesa/drivers/dri/i965/intel_extensions.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index b5860f13cb..192971f32c 100644
--- a/src/mesa/driver
Functionality already covered by ARB_texture_view, patch also
adds missing 'gles guard' for enums (added in f1563e6392).
Tested via arb_texture_view.*_gles3 tests and individual app
utilizing texture view with ETC2.
Signed-off-by: Tapani Pälli
---
src/mapi/glapi/gen/es_EXT.xml | 15 ++
https://bugs.freedesktop.org/show_bug.cgi?id=91039
--- Comment #2 from Axel Davy ---
To my knowledge we've been handling function stack realignment in nine for a
few years now, and thus I assume this issue is solved. Do you confirm ?
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=103264
Vinson Lee changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=36295
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=91039
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Gallium/StateTracker/galliu
https://bugs.freedesktop.org/show_bug.cgi?id=91106
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #5 from Timothy Ar
On Tue, May 8, 2018 at 10:34 PM, Timothy Arceri wrote:
> The shader cache code wont be used on this platform so just disable
> it to avoid make check errors.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103264
> ---
> configure.ac | 4 +++-
> 1 file changed, 3 insertions(+), 1 delet
https://bugs.freedesktop.org/show_bug.cgi?id=87136
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/DRI/swrast
--
You are receivin
Reviewed-by: Tapani Pälli
On 09.05.2018 08:34, Timothy Arceri wrote:
The shader cache code wont be used on this platform so just disable
it to avoid make check errors.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103264
---
configure.ac | 4 +++-
1 file changed, 3 insertions(+), 1
https://bugs.freedesktop.org/show_bug.cgi?id=35178
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi,
On Wednesday, 9 May 2018 04:22:43 CEST Brian Paul wrote:
> One comment needs updating below.
[...]
> > -extern const struct gl_vertex_array*
> > +
> > +/**
> > + * Vertex array information which is derived from gl_array_attributes
> > + * and gl_vertex_buffer_binding information. Used by the
Hi Paul,
On Wednesday, 9 May 2018 04:22:39 CEST Brian Paul wrote:
> Minor nit-picks below and on patches 4 and 11. I skimmed the i965
> changes, but otherwise everything looks OK AFAICT.
>
> Nice work!
>
> Reviewed-by: Brian Paul
I will update the patches.
Thanks for the review!
best
Mathia
https://bugs.freedesktop.org/show_bug.cgi?id=103264
--- Comment #1 from Timothy Arceri ---
Fix:
https://patchwork.freedesktop.org/patch/221629/
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._
The shader cache code wont be used on this platform so just disable
it to avoid make check errors.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103264
---
configure.ac | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index c0fbfe94135..d
ping ..
On 03.05.2018 19:00, Tapani Pälli wrote:
This is done to avoid having same code for multiple
entrypoints, next patch wants to utilize glFinish.
Signed-off-by: Tapani Pälli
---
src/egl/drivers/dri2/egl_dri2.c | 44 +
1 file changed, 23 insertio
https://bugs.freedesktop.org/show_bug.cgi?id=106445
--- Comment #2 from zacharybin...@hotmail.com ---
Could you add it for Cemu with Wine?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
On 13/04/18 17:19, Axel Davy wrote:
Hi,
It would be great to have something for the gallium state trackers as
well. galliumnine, vaapi, etc
Hi Axel,
I've added Gallium/StateTracker/galliumnine for you.
Yours,
Axel
On 13/04/2018 09:00, Timothy Arceri wrote:
Wasn't sure who to bug about
https://bugs.freedesktop.org/show_bug.cgi?id=62612
--- Comment #2 from Timothy Arceri ---
Hi Matt, do you think we should just close this? Or do you still think the test
should be re-factored?
--
You are receiving this mail because:
You are the assignee for the bug._
I'd like a separate state for this, because set_framebuffer_state is a
memory and execution barrier, so it decreases performance, thus there is a
high incentive not to couple other states with it. Since cso_context won't
be used for setting the state (as I suggested on patch 2), st/mesa will
have t
---
src/mesa/state_tracker/st_program.c | 65 +
1 file changed, 58 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_program.c
b/src/mesa/state_tracker/st_program.c
index fe72ddaf2c0..4e2476a26ef 100644
--- a/src/mesa/state_tracker/st_program.c
+++
The following patch will make use of this for asm style programs.
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
src/mesa/state_tracker/st_nir.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracke
https://bugs.freedesktop.org/show_bug.cgi?id=106445
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=106445
Bug ID: 106445
Summary: No Threading
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority:
One comment needs updating below.
On 05/07/2018 12:15 AM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
The only remaining users of gl_vertex_array are tnl based
drivers. So move everything related to that into tnl and
rename it accordingly.
Signed-off-by: Mathias Fröhlich
---
sr
Two minor nits below.
-Brian
On 05/07/2018 12:14 AM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
Finally make use of the binding information in the VAO when
setting up arrays for draw.
v2: Emit less relocations also for interleaved userspace arrays.
Signed-off-by: Mathias Fröhli
Minor nit-picks below and on patches 4 and 11. I skimmed the i965
changes, but otherwise everything looks OK AFAICT.
Nice work!
Reviewed-by: Brian Paul
On 05/07/2018 12:14 AM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
Compute VAO buffer binding information past the position
On Fri, May 4, 2018 at 8:09 AM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/mapi/glapi/gen/gl_API.xml | 52 +++
> src/mesa/main/config.h | 7 +
> src/mesa/main/dd.h | 7 +
> src/mesa/main/extensions_table.h| 1 +
>
BTW, is there any reason for get_sample_pixel_grid to be in pipe_context?
It seems that pipe_screen is a better place, because the returned values
are immutable. pipe_context also doesn't like functions that return
something, because it limits multithreading.
Marek
On Tue, May 8, 2018 at 9:32 PM,
The cso_context changes are unnecessary. It looks like that meta ops don't
enable MSAA, so they are unaffected by sample locations, and thus no need
to have any code for them in cso_context.
The names don't have to use the _state suffix, i.e. set_sample_locations.
I wouldn't add struct pipe_sampl
On 05/07/2018 08:25 PM, Marek Olšák wrote:
Mesa 18.0.1 can hang on Raven. It's fixed in Mesa 18.0.2.
Marek
OK, thank you very much for information!
Regards,
Jerry
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.o
A fence can outlive the ctx it was created from (see glmark2).. etnaviv
doesn't actually need fence->ctx so lets remove it before someone makes
the mistake of assuming it is a valid pointer.
Signed-off-by: Rob Clark
---
I assume this was just copy-pasta from freedreno.. where since eed9685d
(for
From: Dave Airlie
This fixes the fmask descriptor generation to handle 2d ms arrays.
---
src/amd/vulkan/radv_image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index bfe497caa30..ad480901eed 100644
--- a/src/amd/v
This would be nicer as a new helper function in u_hash_table.c that returns
the count or is_empty.
Marek
On Tue, May 8, 2018 at 5:07 PM, Jan Vesely wrote:
> Fixes memory leak on module unload.
> CC:
> Signed-off-by: Jan Vesely
> ---
> Not the prettiest way to do this, but it works and imo sho
Reviewed-by: Marek Olšák
Marek
On Tue, May 8, 2018 at 1:46 AM, Jan Vesely wrote:
> CC:
> Signed-off-by: Jan Vesely
> ---
> src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c
> b/src
For the series:
Reviewed-by: Marek Olšák
Marek
On Mon, May 7, 2018 at 8:49 PM, Timothy Arceri
wrote:
> Just let validate_context_version() do it instead. This fixes
> MESA_GL_VERSION_OVERRIDE for compat, it will also allow us to
> enable new compat versions on a per driver bases in future.
>
On Tue, May 8, 2018 at 3:54 PM, Nanley Chery wrote:
> On Tue, May 08, 2018 at 03:33:22PM -0700, Jason Ekstrand wrote:
> > On Thu, May 3, 2018 at 12:03 PM, Nanley Chery
> wrote:
> >
> > > Before this patch, if we failed to initialize an MCS buffer, we'd
> > > end up in a state in which the miptre
I made a small smattering of comments. With those resolved, the series is
Reviewed-by: Jason Ekstrand
I really like the way it all came together in the end. Patch 13 was one I
didn't expect to like but when I saw it, it completely changed my mind.
That seems like exactly the right way to do th
On Thu, May 3, 2018 at 12:03 PM, Nanley Chery wrote:
> There isn't much that changes between the aux allocation functions.
> Remove the duplicated code.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 227
> +++---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 9
On 2018-05-07 17:30:50, Scott D Phillips wrote:
> ---
> src/intel/vulkan/anv_allocator.c | 16 +++-
> src/intel/vulkan/anv_batch_chain.c | 27 +--
> src/intel/vulkan/anv_device.c | 32
> src/intel/vulkan/anv_private.h
Alyssa Rosenzweig writes:
> Hi all,
>
> Certain embedded GPUs do not implement coordinate transformation in
> hardware. Instead, section 12.5 "Coordinate Transformation" of the ES
> 3.2 specification is implemented in the vertex shader itself. Relevant
> examples include Midgard and vc4.
>
> To h
Invalidating the indirect state pointers might affect a previously
scheduled & still running 3DPRIMITIVE (causing page fault). So stall
on pixel scoreboard before that.
v2: Fix compile issue :(
v3: Stall on pixel scoreboard
v4: Drop the post sync operation (Lionel)
Signed-off-by: Lionel Landwer
Hi,
A quick update on the i965 patch, dropping the Post-Sync operation.
Thanks a lot,
Lionel Landwerlin (2):
i965: require post sync operation prior to ISP disable
anv: emit stall at pixel scoreboard before ISP disable
src/intel/vulkan/genX_cmd_buffer.c | 9 -
src/mesa/dr
We want to make sure that all indirect state data has been loaded into
the EUs before disable the pointers.
Signed-off-by: Lionel Landwerlin
Fixes: 78c125af3904c ("anv/gen10: Ignore push constant packets during context
restore.")
---
src/intel/vulkan/genX_cmd_buffer.c | 9 -
1 file chan
For the commit message, I have a suggestion:
---
anv: for pinned BOs, skip relocations, but track bo usage
References to pinned BOs won't need to be relocated, so just write the
final value of the reference into the bo.
Add a `set` to the relocation lists for tracking dependencies that
were pre
On Tue, May 08, 2018 at 03:33:22PM -0700, Jason Ekstrand wrote:
> On Thu, May 3, 2018 at 12:03 PM, Nanley Chery wrote:
>
> > Before this patch, if we failed to initialize an MCS buffer, we'd
> > end up in a state in which the miptree thinks it has an MCS buffer,
> > but doesn't. We also leaked th
On Tue, May 8, 2018 at 3:41 PM, Jason Ekstrand wrote:
> On Thu, May 3, 2018 at 12:03 PM, Nanley Chery
> wrote:
>
>> The indirect clear color isn't correctly tracked in
>> intel_miptree::fast_clear_color. The initial value of ::fast_clear_color
>> is zero, while that of the indirect clear color i
On Mon, May 7, 2018 at 11:04 AM, Nanley Chery wrote:
> On Mon, May 07, 2018 at 03:06:29PM +0300, Pohjolainen, Topi wrote:
> > On Thu, May 03, 2018 at 12:03:53PM -0700, Nanley Chery wrote:
> > > We have enough information to determine the optimal flags internally.
> > > ---
> > > src/mesa/drivers
On Thu, May 3, 2018 at 12:03 PM, Nanley Chery wrote:
> The indirect clear color isn't correctly tracked in
> intel_miptree::fast_clear_color. The initial value of ::fast_clear_color
> is zero, while that of the indirect clear color is undefined or
> non-zero.
>
> Topi Pohjolainen discovered this
On Thu, May 3, 2018 at 12:03 PM, Nanley Chery wrote:
> Before this patch, if we failed to initialize an MCS buffer, we'd
> end up in a state in which the miptree thinks it has an MCS buffer,
> but doesn't. We also leaked the clear_color_bo if it existed.
>
> With this patch, we now free the miptr
On Mon, May 7, 2018 at 5:30 PM, Scott D Phillips wrote:
> ---
> src/intel/vulkan/anv_allocator.c | 16 +++-
> src/intel/vulkan/anv_batch_chain.c | 27 +--
> src/intel/vulkan/anv_device.c | 32
> src/intel/vulkan/anv_priv
Reviewed-by: Jordan Justen
On 2018-05-07 17:30:48, Scott D Phillips wrote:
> Soft pinning lets us satisfy the binding table address
> requirements without using both sides of a growing state_pool.
>
> If you do use both sides of a state pool, then you need to read
> the state pool's center_bo_of
On Tue, May 08, 2018 at 09:24:19AM +0300, Pohjolainen, Topi wrote:
> On Thu, May 03, 2018 at 12:04:00PM -0700, Nanley Chery wrote:
> > Although BLORP currently does the update when performing a fast clear,
> > it's simpler to do it ourselves. Remove the dependency on BLORP.
>
> Should we note in t
On 2018-05-07 17:30:47, Scott D Phillips wrote:
> The state_pools reserve virtual address space of the full
> BLOCK_POOL_MEMFD_SIZE, but maintain the current behavior of
> growing from the middle.
>
> v2: - rename block_pool::offset to block_pool::start_address (Jason)
> - assign state pool st
On Mon, May 7, 2018 at 5:30 PM, Scott D Phillips wrote:
> References to pinned bos won't need relocated, so just write the
> final value of the reference into the bo. Add a `set` to the
> relocation lists for tracking dependencies that were previously
> tracked by relocations.
>
> v2: - visit bos
On Mon, May 7, 2018 at 5:30 PM, Scott D Phillips wrote:
> Soft pinning lets us satisfy the binding table address
> requirements without using both sides of a growing state_pool.
>
> If you do use both sides of a state pool, then you need to read
> the state pool's center_bo_offset (with the devic
On Mon, May 7, 2018 at 5:30 PM, Scott D Phillips wrote:
> The state_pools reserve virtual address space of the full
> BLOCK_POOL_MEMFD_SIZE, but maintain the current behavior of
> growing from the middle.
>
> v2: - rename block_pool::offset to block_pool::start_address (Jason)
> - assign stat
On Mon, May 7, 2018 at 5:30 PM, Scott D Phillips wrote:
> These will be used to assign virtual addresses to soft pinned
> buffers in a later patch.
>
> Two allocators are added for separate 'low' and 'high' virtual
> memory areas. Another alternative would have been to add a
> double-sided alloca
On Tue, May 08, 2018 at 08:43:20AM +0300, Pohjolainen, Topi wrote:
> On Mon, May 07, 2018 at 11:04:20AM -0700, Nanley Chery wrote:
> > On Mon, May 07, 2018 at 03:06:29PM +0300, Pohjolainen, Topi wrote:
> > > On Thu, May 03, 2018 at 12:03:53PM -0700, Nanley Chery wrote:
> > > > We have enough inform
On Tue, May 08, 2018 at 08:22:39AM +0300, Pohjolainen, Topi wrote:
> On Mon, May 07, 2018 at 11:35:39AM -0700, Nanley Chery wrote:
> > On Mon, May 07, 2018 at 10:10:16AM -0700, Nanley Chery wrote:
> > > On Mon, May 07, 2018 at 11:51:50AM +0300, Pohjolainen, Topi wrote:
> > > > On Fri, May 04, 2018
On Thu, May 03, 2018 at 12:03:52PM -0700, Nanley Chery wrote:
> A name of "aux-miptree" should be sufficient.
I should mention that I went over this some teamates on #intel-3d and
received no objections.
Another comment below.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 -
Fixes memory leak on module unload.
CC:
Signed-off-by: Jan Vesely
---
Not the prettiest way to do this, but it works and imo shouldn't need
anything more fancy.
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/
On Tue, May 08, 2018 at 08:31:39AM +0300, Pohjolainen, Topi wrote:
> On Mon, May 07, 2018 at 10:11:39AM -0700, Nanley Chery wrote:
> > On Mon, May 07, 2018 at 11:30:15AM +0300, Pohjolainen, Topi wrote:
> > > On Thu, May 03, 2018 at 12:03:51PM -0700, Nanley Chery wrote:
> > > > The indirect clear co
I've got a bunch of comments below. However, I think this test is
sufficient to demonstrate that the allocator works for the use-cases in
this series so it doesn't need to block the rest of the patches. Over-all,
it looks really good. Thanks!
On Mon, May 7, 2018 at 5:30 PM, Scott D Phillips wr
Reviewed-by: Jordan Justen
On 2018-05-07 17:30:46, Scott D Phillips wrote:
> These will be used to assign virtual addresses to soft pinned
> buffers in a later patch.
>
> Two allocators are added for separate 'low' and 'high' virtual
> memory areas. Another alternative would have been to add a
>
On Tuesday, May 8, 2018 10:09:30 AM PDT Lionel Landwerlin wrote:
> We want to make sure that all indirect state data has been loaded into
> the EUs before disable the pointers.
>
> Signed-off-by: Lionel Landwerlin
> Fixes: 78c125af3904c ("anv/gen10: Ignore push constant packets during context
>
On Tuesday, May 8, 2018 10:09:29 AM PDT Lionel Landwerlin wrote:
> Invalidating the indirect state pointers might affect a previously
> scheduled & still running 3DPRIMITIVE (causing page fault). So stall
> on pixel scoreboard before that.
>
> v2: Fix compile issue :(
>
> v3: Stall on pixel score
On 2018-05-08 01:54:13, Chris Wilson wrote:
> Quoting Scott D Phillips (2018-05-08 01:30:45)
> > A later patch will make use of this in other places. Also, remove
> > dependency on undefined behavior of left-shifting a signed value.
>
> Can it find a home in src/intel/common/gen_gtt.h (or gen_vma
On Tuesday, May 8, 2018 11:03:38 AM PDT Scott D Phillips wrote:
> Kenneth Graunke writes:
>
> > On Thursday, May 3, 2018 11:51:52 PM PDT Chris Wilson wrote:
> >> Quoting Kenneth Graunke (2018-05-04 02:12:39)
> >> > ---
> >> > src/mesa/drivers/dri/i965/brw_bufmgr.c | 2 +-
> >> > 1 file changed,
There is a fairly simple relation to turn this into ufind_msb.
---
src/compiler/nir/nir.h| 2 ++
src/compiler/nir/nir_opt_algebraic.py | 4
2 files changed, 6 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index ee45b0709636..53ac1598dfc9 100644
--
These toegether get the GLSL 3.00 unpack functions and MESA_shader_integer
operations working.
---
src/broadcom/compiler/nir_to_vir.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/broadcom/compiler/nir_to_vir.c
b/src/broadcom/compiler/nir_to_vir.c
ufind_msb is easily expressed in terms of clz, and we can reduce ifind_msb
to that.
---
src/compiler/nir/nir.h| 2 ++
src/compiler/nir/nir_opt_algebraic.py | 4
2 files changed, 6 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index ee1d59ffe7cd..e
V3D doesn't have opcodes for ibfe/ubfe, so we need to lower similarly to
glsl/lower_instructions.cpp.
---
src/compiler/nir/nir.h| 3 +++
src/compiler/nir/nir_opt_algebraic.py | 16
2 files changed, 19 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compil
This is based on the glsl/lower_instructions.cpp implementation, but
should be much more readable.
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/meson.build | 1 +
src/compiler/nir/nir.h| 3 +
src/compiler/nir/nir_lower_alu.c
If you don't have HW to do bfi, then lowering bitfieldInsert to bfi makes
things harder than keeping the "bits" argument around.
This still uses bfm, but I've added the obvious lowering of bfm if you
need it.
---
src/compiler/nir/nir.h| 5 +
src/compiler/nir/nir_opt_algebraic
This is basically the same as the GLSL lowering path.
---
src/compiler/nir/nir.h | 2 ++
src/compiler/nir/nir_lower_alu.c | 47 +++-
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 5586a38c8
This is basically the same as the GLSL lowering path.
---
src/compiler/nir/nir.h | 2 ++
src/compiler/nir/nir_lower_alu.c | 36
2 files changed, 38 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 5b29645a6c48..e424a01c82
dri*_bind_context, when switching current drawables, will drop the
reference on the old one; since that refcount has probably now gone to
zero that means we lose all the state we applied to that drawable
before, like when swaps are expected to complete.
Dropping this reference might make some sens
On 05/04/2018 05:09 AM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/mesa/state_tracker/st_atom_framebuffer.c | 64
>
> src/mesa/state_tracker/st_cb_msaa.c | 22 ++
> src/mesa/state_tracker/st_extensions.c | 1 +
> 3 files changed
On 05/08/2018 12:13 PM, Ian Romanick wrote:
> On 05/08/2018 07:43 AM, Brian Paul wrote:
>> Change the size of the bitset from 128 bits to 96. This works around an
>> apparent GCC 5.4 bug in which bad SSE code is generated, leading to a
>> crash in ast_type_qualifier::validate_in_qualifier() (ast_t
Reviewed-by: Jordan Justen
On 2018-05-03 18:12:35, Kenneth Graunke wrote:
> We're planning to start managing the PPGTT in userspace in the near
> future, rather than relying on the kernel to assign addresses. While
> most buffers can go anywhere, some need to be restricted to within 4GB
> of a b
On 05/08/2018 07:43 AM, Brian Paul wrote:
> Change the size of the bitset from 128 bits to 96. This works around an
> apparent GCC 5.4 bug in which bad SSE code is generated, leading to a
> crash in ast_type_qualifier::validate_in_qualifier() (ast_type.cpp:654).
Is there a difference in the code
On Tue, May 8, 2018 at 2:20 PM, Dylan Baker wrote:
> Quoting Mark Janes (2018-05-08 11:10:19)
> > Dylan Baker writes:
> >
> > > I have both pulled into the 18.1-proposed tree now. I think we need to
> have a
> > > wider discussion about better ways to propose patches to stable after
> the fact
>
From: Boyuan Zhang
All vce firmwares with major version greater than or equal to 53 are supported
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_vce.c
b/src/galli
On Tuesday, May 8, 2018 10:02:22 AM PDT Scott D Phillips wrote:
> Kenneth Graunke writes:
[snip]
> > + /* If this node is now completely full, remove it from the free list. */
> > + if (node->bitmap == 0ull) {
> > + (void) util_dynarray_pop(vma_list, struct vma_bucket_node);
> > + }
> >
On Tue, May 8, 2018 at 3:06 AM, Nicolai Hähnle wrote:
> On 02.05.2018 06:00, Marek Olšák wrote:
>
>> From: Marek Olšák
>>
>> ---
>> src/amd/common/ac_surface.c | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_
Quoting Mark Janes (2018-05-08 11:10:19)
> Dylan Baker writes:
>
> > I have both pulled into the 18.1-proposed tree now. I think we need to have
> > a
> > wider discussion about better ways to propose patches to stable after the
> > fact
> > like ea1fff4416036066cff51826f95b4703d7211008. Thanks
Dylan Baker writes:
> I have both pulled into the 18.1-proposed tree now. I think we need to have a
> wider discussion about better ways to propose patches to stable after the fact
> like ea1fff4416036066cff51826f95b4703d7211008. Thanks for helping get this
> resolved so quickly.
We have to expe
On Tue, May 8, 2018 at 10:58 AM, Jordan Justen
wrote:
> On 2018-05-07 17:30:43, Scott D Phillips wrote:
> > From: Jason Ekstrand
> >
> > This is simple linear-walk first-fit allocator roughly based on the
> > allocator in the radeon winsys code. This allocator has two primary
> > functional dif
Kenneth Graunke writes:
> This isn't strictly necessary, but anyone running Cannonlake will
> already have Kernel 4.5 or later, so there's no reason to support
> the relocation model on Gen10+.
>
> This will let us avoid dealing with them for new features.
I think the discussion about aliasing p
Kenneth Graunke writes:
> On Thursday, May 3, 2018 11:51:52 PM PDT Chris Wilson wrote:
>> Quoting Kenneth Graunke (2018-05-04 02:12:39)
>> > ---
>> > src/mesa/drivers/dri/i965/brw_bufmgr.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > This enables it for Broadwell (with a
Could potentially just fold into "util: Add a virtual memory
allocator".
Reviewed-by: Jordan Justen
On 2018-05-03 18:12:33, Kenneth Graunke wrote:
> I want to use this in a bucketing allocator for i965.
> ---
> src/util/vma.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff -
I have both pulled into the 18.1-proposed tree now. I think we need to have a
wider discussion about better ways to propose patches to stable after the fact
like ea1fff4416036066cff51826f95b4703d7211008. Thanks for helping get this
resolved so quickly.
Dylan
Quoting Jan Vesely (2018-05-08 10:24:5
On 2018-05-07 17:30:43, Scott D Phillips wrote:
> From: Jason Ekstrand
>
> This is simple linear-walk first-fit allocator roughly based on the
> allocator in the radeon winsys code. This allocator has two primary
> functional differences:
>
> 1) It cleanly returns 0 on allocation failure
>
>
Kenneth Graunke writes:
> On Tuesday, May 8, 2018 1:23:32 AM PDT Eero Tamminen wrote:
>> Hi,
>>
>> On 08.05.2018 06:45, Matt Turner wrote:
>> > On Mon, May 7, 2018 at 8:02 PM, Brian Paul wrote:
>> >>
>> >> I don't know when this started happening (I'll try bisecting tomorrow) but
>> >> we're se
Kenneth Graunke writes:
> We'd like to start using soft-pin to assign BO addresses up front, and
> never move them again. Our previous plan for dealing with 48-bit VF
> cache bugs was to relocate vertex buffers to the low 4GB, so we'd never
> have addresses that alias in the low 32 bits. But th
Hi,
the code_bo line was added in ea1fff4416036066cff51826f95b4703d7211008
Which was also requested for stable [0].
sorry for the confusion. Is there a way to indicate dependencies that I
missed?
regards,
Jan
[0] https://lists.freedesktop.org/archives/mesa-stable/2018-May/008249.
html
On Tue, 2
1 - 100 of 143 matches
Mail list logo
