This patch adds R10G10B10{A,X}2 MESA <-> DRI translation entries
in the appropriate places for dri2 functions to accept them.
BUG=https://crbug.com/776093
TEST=Compile and deploy mesa+this patch, then playback
a VP9 Profile 2 video with sw decoder using crrev.com/c/897894.
---
src/mesa/drivers/dr
This patch adds {X,A}BGR2101010 entries to the list of supported
|intel_image_formats|.
BUG=https://crbug.com/776093
TEST=Compile and deploy mesa this patch, then playback
a VP9 Profile 2 video with sw decoder using crrev.com/c/897894.
---
src/mesa/drivers/dri/i965/intel_screen.c | 6 ++
1 fi
Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed
formats that can render. When GetCompressed* functions are called, the
pixels are returned in the non-compressed format that is used for the
rendering.
With this patch we store both the compressed and non-compressed versions
o
On 2018-05-02 09:11 PM, Marek Olšák wrote:
> If you are shader-bound, you won't see any difference. In order to become
> RB-bound, you need more work in RBs than shaders. Blending or MSAA might
> help add that.
Indeed,
vblank_mode=0 glxgears -samples 8
shows a significant difference in performa
Nice addition :)
Reviewed-by: Lionel Landwerlin
On 02/05/18 22:48, Caio Marcelo de Oliveira Filho wrote:
Remove the need of converting values that are documented in
hexadecimal. This patch would allow writing
instead of
---
src/intel/genxml/gen_pack_header.py | 3 ++-
1 file
On Thu, 2018-05-03 at 08:39 +0200, Iago Toral wrote:
> On Wed, 2018-05-02 at 17:57 -0700, Jason Ekstrand wrote:
> > Reviewed-by: Jason Ekstrand
> >
> > Have I reviewed everything? Can we land shaderInt16 now?
>
> Yes, all patches are reviewed now, thanks Jason.
> I'll send the final set of patc
https://bugs.freedesktop.org/show_bug.cgi?id=106187
--- Comment #10 from Christian König ---
Just some technical feedback.
(In reply to Bas Nieuwenhuizen from comment #9)
> 1) Running on a GPU that is not connected to the display is slower. Arguably
> we should be able to optimize this a bit, es
On 3 May 2018 at 00:10, Timothy Arceri wrote:
>
>
> On 03/05/18 02:51, Emil Velikov wrote:
>>
>> On 2 May 2018 at 11:27, Timothy Arceri wrote:
>>>
>>> ---
>>> src/mesa/main/version.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/src/mesa/main/version.c b/src/mesa/main/versio
Hi,
On 02.05.2018 20:19, Matt Turner wrote:
On Wed, May 2, 2018 at 9:13 AM, Eleni Maria Stea wrote:
Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed
formats that can render. When GetCompressed* functions are called, the
pixels are returned in the non-compressed format th
Hi Dylan,
A few small nitpicks:
On 27 April 2018 at 22:07, Dylan Baker wrote:
> Hi List,
>
s/List/list/
> Mesa 18.1.0-rc2 is now available. There are 20 nominated patches, and no
> queued
> or rejected patches. All patches applied cleanly, so no conflicts at all. Yay.
>
Please follow the exist
Hi,
On 02.05.2018 21:19, James Xiong wrote:
On Wed, 2 May 2018 14:18:21 +0300
Eero Tamminen wrote:
[...]
You're missing information on:
* On which plaform you did the testing (affects variance)
* how many test rounds you ran, and
* what is your variance
>
I ran these tests on a gen9 platfor
https://bugs.freedesktop.org/show_bug.cgi?id=104836
--- Comment #4 from Jason Duerstock ---
Any updates on this? Is there a reason my proposed patch can't be accepted?
--
You are receiving this mail because:
You are the QA Contact for the bug.___
mes
Thanks for the feedback.
I’ve implemented your suggestion as the top two patches on a branch
here:
https://github.com/Igalia/mesa/tree/nroberts/count-uniform-storage
It also fixes a slight bug that it wasn’t passing down the
uniform_storage_locs argument into the recursion.
However I think my p
https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #9 from Mike Gorchak ---
Just checked generic path - all works fine, here is very minor fix to the
provided fix:
+ _eglLog(_EGL_WARNING, "DRI2: failed to find glFlush entry point");
should be changed glFlush to glFinish :)
Am
https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #10 from Tapani Pälli ---
(In reply to Mike Gorchak from comment #9)
> Just checked generic path - all works fine, here is very minor fix to the
> provided fix:
>
> + _eglLog(_EGL_WARNING, "DRI2: failed to find glFlush entry po
https://bugs.freedesktop.org/show_bug.cgi?id=106377
Bug ID: 106377
Summary: eglWaitClient() doesn't work for surfaceless contexts
Product: Mesa
Version: 18.0
Hardware: All
OS: All
Status: NEW
Severity: maj
https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #11 from Mike Gorchak ---
> Yes that is a separate issue, please file another bug about that one.
Done! Bug 106377.
Thank you!
--
You are receiving this mail because:
You are the QA Contact for the bug.___
From: Nicolai Hähnle
To comply with an upcoming change in LLVM, see
https://reviews.llvm.org/D46051
---
src/amd/common/ac_llvm_build.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index f21a5d2623c..c9b2e36b632 100644
A number of CTS tests from the dEQP-GLES3.functional.rasterizer_discard.*
subset
fail when the tests are run in a batch, because the GL_RASTERIZER_DISCARD state
is enabled after running glClear and the disabled state issed after a number of
draw
commands is not properly send to the host.
This h
You're supposed to keep track of the bound state (usually in the
context). After your clear() implementation is done, you have to undo
all the state you've messed up on your "hardware" (or mark it dirty
for revalidation).
See for example
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/driv
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 insertions(+), 21 deletions(-)
diff --git a/src/egl/drivers/d
As defined by the spec:
"All rendering calls for the currently bound context, for
the current rendering API, made prior to eglWaitClient, are
guaranteed to be executed before native rendering calls made
after eglWaitClient which affect the read or draw surfaces
associated with that c
Am Donnerstag, den 03.05.2018, 11:43 -0400 schrieb Ilia Mirkin:
> You're supposed to keep track of the bound state (usually in the
> context). After your clear() implementation is done, you have to undo
> all the state you've messed up on your "hardware" (or mark it dirty
> for revalidation).
Than
Hello list,
The candidate for the Mesa 18.0.3 is now available. Currently we have:
- 9 queued
- 6 nominated (outstanding)
- and 0 rejected patches
The is a fairly short queue consisting of patches to fix leaks in RADV and
Winsys,
fix deadlock in internal queue, fix issues with ANV allocator,
On Thu, May 3, 2018 at 12:29 PM, Gert Wollny wrote:
> Am Donnerstag, den 03.05.2018, 11:43 -0400 schrieb Ilia Mirkin:
>> You're supposed to keep track of the bound state (usually in the
>> context). After your clear() implementation is done, you have to undo
>> all the state you've messed up on yo
Build mesa 7614 failed
Commit 5d3caa1ca4 by Boyuan Zhang on 4/25/2018 3:49 PM:
radeon/vcn: fix mpeg4 msg buffer settings\n\nPrevious bit-fields assignments are incorrect and will result certain mpeg4\ndecode failed due to wrong flag values. This patch fixes the
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
index ab39f9fdf6..cbb21f5f72 10064
Reviewed-by: Ilia Mirkin
[Can't apply now, but will tonight if no one beats me to it.]
On Thu, May 3, 2018 at 1:02 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
Am Donnerstag, den 03.05.2018, 12:51 -0400 schrieb Ilia Mirkin:
>
> virgl_clear implements a gallium API call which is meant to clear the
> surface. It sounds like virglrenderer does not properly implement
> that
> call. Either workaround your buggy "hardware" (i.e. virglrenderer) by
> throwing in
On Thu, May 3, 2018 at 1:15 PM, Gert Wollny wrote:
> Am Donnerstag, den 03.05.2018, 12:51 -0400 schrieb Ilia Mirkin:
>>
>> virgl_clear implements a gallium API call which is meant to clear the
>> surface. It sounds like virglrenderer does not properly implement
>> that
>> call. Either workaround y
Reviewed-by: Bas Nieuwenhuizen
On Thu, May 3, 2018 at 5:18 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> To comply with an upcoming change in LLVM, see
> https://reviews.llvm.org/D46051
> ---
> src/amd/common/ac_llvm_build.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
On 2 May 2018 at 17:23, Juan A. Suarez Romero wrote:
> According to EGL 1.4 spec, section 3.5.1 ("Creating On-Screen Rendering
> Surfaces"), if config does not support the colorspace or alpha format
> attributes specified in attrib_list (as defined for
> eglCreateWindowSurface), an EGL_BAD_MATCH e
Am Donnerstag, den 03.05.2018, 13:24 -0400 schrieb Ilia Mirkin:
>
> The api call is "clear", not "glClear in the context of whatever
> random GL state there might be". When the gallium clear API is
> invoked, the bound framebuffer needs to be cleared. This is how the
> API works, this is how all d
Quoting Emil Velikov (2018-05-03 03:40:47)
> Hi Dylan,
>
> A few small nitpicks:
>
> On 27 April 2018 at 22:07, Dylan Baker wrote:
> > Hi List,
> >
> s/List/list/
>
> > Mesa 18.1.0-rc2 is now available. There are 20 nominated patches, and no
> > queued
> > or rejected patches. All patches appl
On 3 May 2018 at 18:22, Dylan Baker wrote:
> Quoting Emil Velikov (2018-05-03 03:40:47)
>> Hi Dylan,
>>
>> A few small nitpicks:
>>
>> On 27 April 2018 at 22:07, Dylan Baker wrote:
>> > Hi List,
>> >
>> s/List/list/
>>
>> > Mesa 18.1.0-rc2 is now available. There are 20 nominated patches, and no
Quoting Iago Toral Quiroga (2018-04-30 07:18:08)
> This version addresses the feedback received to v1, which includes moving the
> bit-size lowering pass from intel to core NIR (patch 8) and a separate patch
> to add Intel's specific configuration for int16 (patch 9), and then it also
> adds a few
My main motivation for this series is to avoid one type of redundant
fast-clears for color buffers (patch 15). In doing so, I take
opportunities to improve the maintainability and performance of the
affected code along the way.
* Fix bugs that this series depends on for correct behavior (1-2).
* E
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 issue with MCS buffers. This issue is
apparent when fast-clearing
Add infrastructure for initializing the clear color BO.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 68 ---
1 file changed, 31 insertions(+), 37 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
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 miptree aux buffer resources and let
intel_miptree_alloc_mcs() know t
Before this patch, the aux_state was actually AUX_INVALID because the BO
was never defined. This was fine on single slice miptrees because we
would fast-clear the resource right after creation. For multi-slice
miptrees on SKL+ however, this results in undefined behavior when
accessing a non-base sl
A name of "aux-miptree" should be sufficient.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index e70c9ff1ef4..566ead0d5c8
Drop an unused parameter.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index e065c2f62e0..1de381141ea 100644
--- a/src/me
We have enough information to determine the optimal flags internally.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 29 +--
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel
This reverts commit 1d94aa19877fb702ffacacde28ad7253cce72c97.
The next patch will make depth miptrees use the clear color setter that
was originally being used for color miptrees. Go back to using the
isl_color_value parameter because it's the same type as the
fast_clear_color field used by color
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 -
2 files changed, 95 insertions(+), 141 deletions(-)
diff --git
Reduce complexity and allow the next patch to delete some code. With
this change, clear operations will still be skipped and setting the
aux_state will cause no side-effects.
Remove the associated comment which implies an early return.
Reviewed-by: Rafael Antognolli
---
src/mesa/drivers/dri/i96
Although BLORP currently does the update when performing a fast clear,
it's simpler to do it ourselves. Remove the dependency on BLORP.
---
src/mesa/drivers/dri/i965/brw_clear.c | 37 ---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 13 ++
2 files changed
We're going to delete intel_miptree_alloc_ccs() in the next commit. With
that in mind, replace the use of this function in
do_single_blorp_clear() with intel_miptree_alloc_aux() and move the
delayed allocation logic to it's callers.
---
src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
src/me
This comment made more sense when it was above the calls to
intel_miptree_slice_set_needs_depth_resolve(). We stopped using these
functions at commit 554f7d6d02931ea45653c8872565d21c1678a6da
("i965: Move depth to the new resolve functions").
---
src/mesa/drivers/dri/i965/brw_clear.c | 4
1 fi
Reduce code duplication now and prevent it in the following commits.
---
src/mesa/drivers/dri/i965/brw_clear.c | 3 ++-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 13 -
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 5 -
3 files changed, 2 insertions(+), 19 deletion
With the previous patches, we now update the indirect clear color buffer
every time the clear color changes. Avoid redundant updates.
---
src/mesa/drivers/dri/i965/brw_blorp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mes
Allow callers to handle updating the indirect clear color buffer
themselves. This can reduce the number of clear color updates in the
case where a caller performs multiple fast clears with the same clear
color.
---
src/intel/blorp/blorp.h | 5 +
src/intel/blorp/blorp_genX_exec.h | 6
If the aux state is CLEAR and clear color value has changed, only the
surface state must be updated. The bit-pattern in the aux buffer is
exactly the same.
---
src/mesa/drivers/dri/i965/brw_blorp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965
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 handle this, a lowering pass is needed to c
On Thu, May 3, 2018 at 3:12 PM, Alyssa Rosenzweig wrote:
> 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 inc
Good catch. Rb
On May 3, 2018 12:04:59 Nanley Chery wrote:
Before this patch, the aux_state was actually AUX_INVALID because the BO
was never defined. This was fine on single slice miptrees because we
would fast-clear the resource right after creation. For multi-slice
miptrees on SKL+ however,
Reviewed-by: Jason Ekstrand
On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips wrote:
> Clear a set back to the state of having zero entries.
> ---
> src/util/set.c | 23 +++
> src/util/set.h | 3 +++
> 2 files changed, 26 insertions(+)
>
> diff --git a/src/util/set.c b/src/
Reviewed-by: Jason Ekstrand
On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips wrote:
> The last use of the field was removed in 2015's ("48a87f4ba06
> anv/queue: Get rid of the serial")
> ---
> src/intel/vulkan/anv_device.c | 1 -
> src/intel/vulkan/anv_private.h | 2 --
> 2 files changed, 3 d
On Thu, May 03, 2018 at 12:40:49PM -0700, Jason Ekstrand wrote:
> Good catch. Rb
>
Thanks!
> On May 3, 2018 12:04:59 Nanley Chery wrote:
>
> > Before this patch, the aux_state was actually AUX_INVALID because the BO
> > was never defined. This was fine on single slice miptrees because we
> > w
On Wed, May 2, 2018 at 9:01 AM, Scott D Phillips wrote:
> These will be used to assign virtual addresses to soft pinned
> buffers in a later patch.
> ---
> src/intel/vulkan/anv_device.c | 75 ++
>
> src/intel/vulkan/anv_private.h | 11 +++
> 2 files
From: Boyuan Zhang
Previous bit-fields assignments are incorrect and will result certain mpeg4
decode failed due to wrong flag values. This patch fixes these assignments.
Cc: 18.0 18.1
Signed-off-by: Boyuan Zhang
Reviewed-by: Leo Liu
---
src/gallium/drivers/radeon/radeon_vcn_dec.c | 18
Build mesa 7615 completed
Commit 589622a2fe by Vinson Lee on 5/1/2018 6:57 AM:
swr/rast: Fix WriteBitcodeToFile usage with llvm-7.0.\n\nFix build error after llvm-7.0svn r325155 ("Pass a reference to a module\nto the bitcode writer.").\n\n CXX rasterizer/
https://bugs.freedesktop.org/show_bug.cgi?id=106394
Bug ID: 106394
Summary: Black Mesa cannot compile shaders because of missing
GL_EXT_gpu_shader4
Product: Mesa
Version: git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=106394
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
I commented on this in the office, but I think this whole thing would be
cleaner if we just clearly documented address ranges in anv_private.h with
a good comment. Something like
#define LOW_HEAP_BASE_ADDRESS 4096
#define LOW_HEAP_SIZE ((3ull << 30) - 4096)
#define DYNAMIC_STATE_POOL_ADDRESS (3ul
Clayton Craft writes:
> Quoting Iago Toral Quiroga (2018-04-30 07:18:08)
>> This version addresses the feedback received to v1, which includes moving the
>> bit-size lowering pass from intel to core NIR (patch 8) and a separate patch
>> to add Intel's specific configuration for int16 (patch 9), a
https://bugs.freedesktop.org/show_bug.cgi?id=106394
--- Comment #2 from Timothy Arceri ---
It looks like they are now using a compat profile which is unfortunate.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
On 03/05/18 22:50, Neil Roberts wrote:
Thanks for the feedback.
I’ve implemented your suggestion as the top two patches on a branch
here:
https://github.com/Igalia/mesa/tree/nroberts/count-uniform-storage
It also fixes a slight bug that it wasn’t passing down the
uniform_storage_locs argument
It would be nice to avoid the extra #if LLVM_VERSION_MAJOR and include
InstCombine.h into the same #if below, as follows:
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -69,6 +69,7 @@ using PassManager = llvm::legacy::Pas
This introduces a new fast virtual memory allocator integrated with our
BO cache bucketing. For larger objects, it falls back to the simple
free-list allocator (util_vma).
This puts the allocators in place but doesn't enable softpin yet.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 291 +
I want to use this in a bucketing allocator for i965.
---
src/util/vma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/util/vma.c b/src/util/vma.c
index 3d61f6969ed..d6ee05988ef 100644
--- a/src/util/vma.c
+++ b/src/util/vma.c
@@ -88,7 +88,6 @@ util_vma_heap_alloc(struc
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This enables it for Broadwell (with a 64-bit kernel) and Skylake+ (with
any kernel). Unfortunately, it doesn't enable it for Cherryview as that
has a 32-bit GTT. We could switch that over as well, b
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.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 4
1 file changed, 4 ins
This simplifies kflag initialization, by creating a bufmgr-wide setting
for initial kflags, and just applying it whenever we create a new BO.
This also properly allows 48-bit addresses for imported BOs (via prime
or flink), which I had missed in my earlier 48-bit support series.
This will be usef
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
2) It allocates addresses top-down instead of bottom-up.
The sec
This is really useful when debugging any sort of buffer management
issues, so just printing it during INTEL_DEBUG=bat,submit seems
reasonable. With bat, we're already spamming so much output that
it doesn't really hurt. With submit, it's still easy to grep for
the older information, and the new i
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 base address.
This commit adds a "memory zone" parameter to the BO allocation
functi
If EXEC_OBJECT_PINNED is set, we don't want to emit any relocations.
We simply want to add the BO to the validation list, and possibly mark
it as writeable. The new brw_use_pinned_bo() interface does just that.
To avoid having to make every caller consider both the relocation and
softpin cases, w
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 that requires moving
buffers dynamic
Hi folks,
I search a thread earlier that identified that someone could reproduce
this problem.
I don't have skills or tools to debug this, though I would not mind
learning. I do other Open Software (gcc-gfortran)
Anyway, when I followed the thread, it was not clear if a fix had been
found
From: Marek Olšák
This can result in 2x increase in performance on non-harvested Kaveris.
v2: don't do it on radeon
Tested-by: Michel Dänzer
---
src/amd/common/ac_gpu_info.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_gpu_info.c b/src
For those wondering why the dEQP CTS tests this fixes (for example
dEQP-GLES3.functional.fragment_out.basic.float.r11f_g11f_b10f_lowp_float)
pass outside the VM, it seems it's because the test cases read pixels
with type = GL_FLOAT. virglrenderer always sets type =
GL_UNSIGNED_INT_10F_11F_11F_REV
On Wed, May 2, 2018 at 9:01 AM, 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 Thu, May 3, 2018 at 6:12 PM, Kenneth Graunke
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 failur
If I'm honest, I don't really like the way this patch worked out. It has
the virtue of being fairly simple and a nice incremental change. However,
it seems to me like we should be able to do better. That said, I don't
really know how off-hand and this looks correct and gets us going.
On Wed, Ma
Just like is done for other backends when suitable config is not
found (added in fd4eba4929).
Signed-off-by: Tapani Pälli
---
src/egl/drivers/dri2/platform_android.c | 4 +++-
src/egl/drivers/dri2/platform_surfaceless.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a
On 05/03/2018 08:49 PM, Emil Velikov wrote:
On 2 May 2018 at 17:23, Juan A. Suarez Romero wrote:
According to EGL 1.4 spec, section 3.5.1 ("Creating On-Screen Rendering
Surfaces"), if config does not support the colorspace or alpha format
attributes specified in attrib_list (as defined for
eg
Hi Nanley;
On 05/03/2018 10: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 miptree aux
Quoting Scott D Phillips (2018-05-02 17:01:00)
> This series teaches anv how to pick its own virtual graphics addresses
> instead of using the relocation facility provided by the kernel.
>
> Jason Ekstrand (1):
> util: Add a virtual memory allocator
>
> Scott D Phillips (8):
> util/set: add a
On Thu, 2018-05-03 at 11:44 -0700, Clayton Craft wrote:
> Quoting Iago Toral Quiroga (2018-04-30 07:18:08)
> > This version addresses the feedback received to v1, which includes
> > moving the
> > bit-size lowering pass from intel to core NIR (patch 8) and a
> > separate patch
> > to add Intel's sp
https://bugs.freedesktop.org/show_bug.cgi?id=106377
--- Comment #1 from Tapani Pälli ---
EGL spec says following:
"If a surface associated with the calling thread’s current context is no longer
valid, an EGL_BAD_CURRENT_SURFACE error is generated."
Having zero mention of surfaceless context her
Signed-off-by: Jan Vesely
---
src/gallium/drivers/r600/evergreen_compute.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 58626a3114..027930b586 100644
--- a/src/gallium/driv
The original bug/corruption was by util_unreference_framebuffer_state,
trying to drop reference on cbuf[0] (global AS for OCL).
Adding reference counting to set_rat uncovered problems with acessing the
pool->bo.
Also drops leaked memory from 7,4kB to 1,7Kb in single run of
conformance_bruteforce
Quoting Kenneth Graunke (2018-05-04 02:12:38)
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=106377
--- Comment #2 from Tapani Pälli ---
I've filed following bug for discussion:
https://gitlab.khronos.org/egl/API/issues/12
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.__
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 64-bit kernel) and Skylake+ (with
> any kernel). Unfortunately, it doesn't enable it for Cherryview as th
Quoting Kenneth Graunke (2018-05-04 02:12:40)
> 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+.
/o\ gvt. Need I say more?
-Chris
___
m
98 matches
Mail list logo
