p.org
It will be automatically picked for 11.0 after you push it.
Marek
On Sun, Oct 4, 2015 at 12:09 PM, Nicolai Hähnle wrote:
Vertex attributes of different categories (constant/per-instance/
per-vertex) go into different buffers for translation, and this is now
properly reflected in the v
The same clamping already happens for glTexParameteri. This change
also fixes a bug in mipmap generation, see
https://bugs.freedesktop.org/show_bug.cgi?id=91993
piglit test cases have been submitted for review (as additions to
arb_texture_storage-texture-storage and arb_texture_view-max-level).
--
On 18.10.2015 00:57, Emil Velikov wrote:
Add a list of driver descriptors and select one from the list, during
probe time.
As we'll need to have all the driver pipe_foo_screen_create() functions
provided externally (i.e. from another static lib) we need a separate
(non-inline) drm_helper, which
On 22.10.2015 15:57, Fredrik Höglund wrote:
On Thursday 22 October 2015, Nicolai Hähnle wrote:
The same clamping already happens for glTexParameteri. This change
also fixes a bug in mipmap generation, see
https://bugs.freedesktop.org/show_bug.cgi?id=91993
I don't think this patch is co
On 22.10.2015 17:32, Emil Velikov wrote:
On 22 October 2015 at 15:07, Nicolai Hähnle wrote:
On 18.10.2015 00:57, Emil Velikov wrote:
Add a list of driver descriptors and select one from the list, during
probe time.
As we'll need to have all the driver pipe_foo_screen_create() func
(This is an alternative to my previous patch, "mesa: clamp MaxLevel for
immutable textures at initialization"; this patch has no opinion about
how the spec should be interpreted.)
Without the clamping by NumLevels, the state tracker would reallocate the
texture storage (incorrect) and even fail to
Reviewed-by: Nicolai Hähnle
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 017d075..e6eede8 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_in
On 24.10.2015 17:49, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_texture.c | 2 +-
src/gallium/drivers/radeonsi/cik_sdma.c | 2 +-
src/gallium/drivers/radeonsi/si_blit.c| 6 +++---
src/gallium/drivers/radeonsi/si_dma.c | 2 +-
src/gallium/drivers/rad
With the remark on patch 2 (radeonsi: properly check if DCC is enabled
and allocated), the series is
Reviewed-by: Nicolai Hähnle
On 24.10.2015 17:49, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state.c | 10 +++---
1 file changed, 3 insertions(+), 7
u/drm/amdgpu_surface.c | 13 ++---
3 files changed, 7 insertions(+), 10 deletions(-)
Agreed, this is an even better solution.
Reviewed-by: Nicolai Hähnle
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index 789c66f..edfdfe3 100644
--- a/src/ga
Hi Ivan,
On 25.10.2015 02:00, Ivan Kalvachev wrote:
Some constants (like 1.0 and 0.5) could be inlined as immediate inputs
without using their literal value. The r600_bytecode_special_constants()
function emulates the negative of these constants by using NEG modifier.
However some shaders defin
On 25.10.2015 18:25, Marek Olšák wrote:
+/**
+ * Handle complex format conversions using 2 blits with a temporary texture
+ * in between, e.g. blitting from B10G10R10A2 to G16R16.
+ *
+ * This example is implemented this way:
+ * 1) First, blit from B10G10R10A2 to R10G10B10A2, which is canonical,
Without the clamping by NumLevels, the state tracker would reallocate the
texture storage (incorrect) and even fail to copy the base level image
after reallocation, leading to the graphical glitch of
https://bugs.freedesktop.org/show_bug.cgi?id=91993 .
A piglit test has been submitted for review a
On 29.10.2015 01:52, Ivan Kalvachev wrote:
-- Forwarded message --
From: Ivan Kalvachev
Date: Wed, 28 Oct 2015 23:46:44 +0200
Subject: [PATCH v3] r600g: Fix special negative immediate constants
when using ABS modifier.
To: Nicolai Hähnle
On 10/26/15, Nicolai Hähnle wrote:
Hi
On 29.10.2015 14:13, Marek Olšák wrote:
On Wed, Oct 28, 2015 at 1:00 PM, Nicolai Hähnle wrote:
Without the clamping by NumLevels, the state tracker would reallocate the
texture storage (incorrect) and even fail to copy the base level image
after reallocation, leading to the graphical glitch of
On 29.10.2015 10:24, Ivan Kalvachev wrote:
[snip]
On 10/29/15, Nicolai Hähnle wrote:
On 29.10.2015 01:52, Ivan Kalvachev wrote:
On 10/26/15, Nicolai Hähnle wrote:
On 25.10.2015 02:00, Ivan Kalvachev wrote:
Some constants (like 1.0 and 0.5) could be inlined as immediate inputs
without using
On 04.11.2015 00:47, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_blit.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index fce014a..e934146
.
With this, the whole series is
Reviewed-by: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_blit.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index d320ac4..31f22c4
The series is
Reviewed-by: Nicolai Hähnle
On 08.11.2015 22:45, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/r600/evergreen_compute.c| 14 ++---
src/gallium/drivers/r600/evergreen_hw_context.c | 10 ++--
src/gallium/drivers/r600/evergreen_state.c | 66
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 22 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 4
2 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_p
On 09.11.2015 10:43, Nicolai Hähnle wrote:
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 22
+-
src/gallium/drivers/radeon/r600_pipe_common.h | 4
2 files changed, 5 insertions(+), 21 deletions
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/r600/r600_hw_context.c| 2 +-
src/gallium/drivers/r600/r600_state_common.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.h | 1 -
src/gallium/drivers/radeon/r600_query.c | 1 -
src/gallium/d
The series is
Reviewed-by: Nicolai Hähnle
On 08.11.2015 22:48, Marek Olšák wrote:
From: Marek Olšák
and ..._cond -> ..._invert
---
src/gallium/drivers/r600/r600_hw_context.c| 2 +-
src/gallium/drivers/r600/r600_state_common.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_commo
d PS)
+*/
+ bool update_esgs = esgs_ring_size &&
+ (!sctx->esgs_ring ||
+ sctx->esgs_ring->width0 < esgs_ring_size);
+ bool update_gsvs = gsvs_ring_size &&
+ (!sctx->gsvs_ring ||
Previously, when a performance monitor was initialized, an inner loop through
all driver queries with string comparisons for each enabled performance
monitor counter was used. This hurts when a driver exposes lots of queries.
---
src/mesa/state_tracker/st_cb_perfmon.c | 74 +++-
---
src/mesa/state_tracker/st_cb_perfmon.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/mesa/state_tracker/st_cb_perfmon.c
index 80ff170..ec12eb2 100644
--- a/src/mesa/state_tracker/st_cb_perfmon.c
+++ b/src/mesa/state_tra
Hi,
the main point of this patch series is to introduce batch query objects.
For AMD_performance_monitor, hardware may not be able to start and stop
performance counters independently of each other. The current query interface
does not fit such hardware well.
With this series, drivers can mark d
---
src/gallium/auxiliary/hud/hud_context.c | 24 ++-
src/gallium/auxiliary/hud/hud_driver_query.c | 248 +++
src/gallium/auxiliary/hud/hud_private.h | 13 +-
3 files changed, 240 insertions(+), 45 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_context
It is easy enough to pre-determine the required size, and arrays are
generally better behaved especially when they get large.
---
src/mesa/state_tracker/st_cb_perfmon.c | 78 --
src/mesa/state_tracker/st_cb_perfmon.h | 18
2 files changed, 55 insertions(+),
---
src/gallium/include/pipe/p_defines.h | 2 ++
src/mesa/state_tracker/st_cb_perfmon.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 7f241c8..7ed9f6d 100644
--- a/src/gallium/include/pipe/p_defines.h
++
Some drivers (in particular radeon[si], but also freedreno judging from
a quick grep) may want to expose performance counters that cannot be
individually enabled or disabled.
Allow such drivers to mark driver-specific queries as requiring a new
type of batch query object that is used to start and
---
src/mesa/state_tracker/st_cb_perfmon.c | 75 ++
src/mesa/state_tracker/st_cb_perfmon.h | 6 +++
2 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/mesa/state_tracker/st_cb_perfmon.c
index 6c71a13..078d2
---
src/gallium/auxiliary/hud/hud_driver_query.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c
b/src/gallium/auxiliary/hud/hud_driver_query.c
index f14305e..3198ab3 100644
--- a/src/gallium/auxiliary/hud/hud_driver_query.c
+++ b/src/gallium/auxili
This was only used to implement an unnecessarily restrictive interpretation
of the spec of AMD_performance_monitor. The spec says
A performance monitor consists of a number of hardware and software
counters that can be sampled by the GPU and reported back to the
application.
I guess one cou
The idea here is that driver queries implemented outside of common code
will use the same query buffer handling with different logic for starting
and stopping the corresponding counters.
---
src/gallium/drivers/radeon/r600_query.c | 198 +++-
src/gallium/drivers/radeon/
---
src/gallium/drivers/radeon/r600_query.c | 30 +-
src/gallium/drivers/radeon/r600_query.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 59e2a5
---
src/gallium/drivers/radeon/r600_query.c | 84 +
1 file changed, 55 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 8aa8774..60381b2 100644
--- a/src/gallium/drivers/radeon/r600
HETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ * Nicolai Hähnle
+ *
+ */
+
+#ifndef R600_QUERY_H
+#define R600_QUERY_H
+
+#include "pipe/p_defines.h"
The goal here is to be able to move the implementation details of hardware-
specific queries (in particular, performance counters) out of the common code.
---
src/gallium/drivers/radeon/r600_query.c | 73 +
src/gallium/drivers/radeon/r600_query.h | 16
2 fi
---
src/gallium/drivers/radeon/r600_pipe_common.c | 46 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeon/r600_query.c | 49 +++
3 files changed, 51 insertions(+), 45 deletions(-)
diff --git a/src/gallium/drive
Move r600_query and r600_query_hw into the header because we will want to
reuse the buffer handling and suspend/resume logic outside of the common
radeon code.
---
src/gallium/drivers/radeon/r600_query.c | 281 +++-
src/gallium/drivers/radeon/r600_query.h | 39 +
2
This will be important for perfcounter queries.
---
src/gallium/drivers/radeon/r600_query.c | 33 +++--
src/gallium/drivers/radeon/r600_query.h | 3 ++-
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gall
We will need the clear_result override for the batch query implementation.
---
src/gallium/drivers/radeon/r600_query.c | 189 +++-
src/gallium/drivers/radeon/r600_query.h | 4 +
2 files changed, 94 insertions(+), 99 deletions(-)
diff --git a/src/gallium/drivers/radeo
Hi,
in preparation for performance counters, this series makes the implementation
of queries pluggable, and separates query buffer handling from CS emit and
result collection for hardware queries.
Aside from two PIPE_QUERY_GPU_FINISHED-related fixes (using context flush,
picked up from Marek, and
Software queries are all queries that do not require suspend/resume
and explicit handling of result buffers.
Note that this fixes a fence leak with PIPE_QUERY_GPU_FINISHED, and it
contains Marek's fix to GPU_FINISHED's end_query() handling.
---
src/gallium/drivers/radeon/r600_query.c | 366 ++
On 13.11.2015 00:14, Glenn Kennard wrote:
Signed-off-by: Glenn Kennard
---
Maybe there is a better way to check if a thread is a helper invocation?
Is ctx->face_gpr guaranteed to be initialized when
load_helper_invocation is called?
Aside, I'm not sure I understand correctly what this is su
On 13.11.2015 18:34, Samuel Pitoiset wrote:
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
---
src/gallium/include/pipe/p_defines.h | 2 ++
src/mesa/state_tracker/st_cb_perfmon.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium
On 13.11.2015 18:35, Samuel Pitoiset wrote:
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
This was only used to implement an unnecessarily restrictive
interpretation
of the spec of AMD_performance_monitor. The spec says
A performance monitor consists of a number of hardware and software
It is easy enough to pre-determine the required size, and arrays are
generally better behaved especially when they get large.
v2: make sure init_perf_monitor returns true when no counters are active
(spotted by Samuel Pitoiset)
---
Thanks Samuel, good catch! I did test with piglit and the tests pa
ently
exposes GL_AMD_performance_monitor? In case you didn't, I'll test it
myself in the next few days. You might not have the hardware. :-)
Sorry, I don't have the hardware.
Thanks,
Nicolai
Thanks.
On 11/13/2015 04:57 PM, Nicolai Hähnle wrote:
Hi,
the main point of this patch se
On 13.11.2015 19:27, Ilia Mirkin wrote:
On Fri, Nov 13, 2015 at 1:23 PM, Nicolai Hähnle wrote:
So really, this is a question for everybody who cares about nouveau, because
nouveau is the only driver that (if a #define is enabled) advertises a CPU
driver_query_group.
Do you want that group to
Previously, when a performance monitor was initialized, an inner loop through
all driver queries with string comparisons for each enabled performance
monitor counter was used. This hurts when a driver exposes lots of queries.
Reviewed-by: Samuel Pitoiset
---
src/mesa/state_tracker/st_cb_perfmon.
Some drivers (in particular radeon[si], but also freedreno judging from
a quick grep) may want to expose performance counters that cannot be
individually enabled or disabled.
Allow such drivers to mark driver-specific queries as requiring a new
type of batch query object that is used to start and
Hi,
I have updated patches 6 - 9. Samuel, thank you for your input and I hope
you find your points to be resolved satisfactorily ;)
Cheers,
Nicolai
---
nha@deadlights:~/amd/mesa$ git diff master | diffstat
gallium/auxiliary/hud/hud_context.c | 24 +-
gallium/auxiliary/hud/hud_driver_quer
Reviewed-by: Samuel Pitoiset
---
src/mesa/state_tracker/st_cb_perfmon.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
b/src/mesa/state_tracker/st_cb_perfmon.c
index 80ff170..ec12eb2 100644
--- a/src/mesa/state_tracker/st_cb_perf
Reviewed-by: Samuel Pitoiset
---
src/gallium/include/pipe/p_defines.h | 2 ++
src/mesa/state_tracker/st_cb_perfmon.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 7f241c8..7ed9f6d 100644
--- a/src/galli
This was only used to implement an unnecessarily restrictive interpretation
of the spec of AMD_performance_monitor. The spec says
A performance monitor consists of a number of hardware and software
counters that can be sampled by the GPU and reported back to the
application.
I guess one cou
v2: forgot a null-pointer check (spotted by Samuel Pitoiset)
---
src/mesa/state_tracker/st_cb_perfmon.c | 78 +++---
src/mesa/state_tracker/st_cb_perfmon.h | 6 +++
2 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_perfmon.c
v2: be more defensive about allocations
---
src/gallium/auxiliary/hud/hud_context.c | 24 ++-
src/gallium/auxiliary/hud/hud_driver_query.c | 265 +++
src/gallium/auxiliary/hud/hud_private.h | 13 +-
3 files changed, 256 insertions(+), 46 deletions(-)
diff --git
Reviewed-by: Samuel Pitoiset
---
src/gallium/auxiliary/hud/hud_driver_query.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_driver_query.c
b/src/gallium/auxiliary/hud/hud_driver_query.c
index f14305e..3198ab3 100644
--- a/src/gallium/auxiliary/hud/hud_driver_qu
It is easy enough to pre-determine the required size, and arrays are
generally better behaved especially when they get large.
v2: make sure init_perf_monitor returns true when no counters are active
(spotted by Samuel Pitoiset)
---
src/mesa/state_tracker/st_cb_perfmon.c | 81 -
On 26.01.2017 06:47, Ilia Mirkin wrote:
When a texture is immutable, we can't tack on extra levels
after-the-fact like we could with glTexImage. So check against that
level limit and return an error if it's surpassed.
The spec is a little unclear in that it says to check if "level is not a
suppo
Signed-off-by: Ilia Mirkin
Reviewed-by: Nicolai Hähnle
---
v1 -> v2: no changes. also no change in Intel CI.
src/mesa/main/fbobject.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 6e86
On 26.01.2017 17:04, Marek Olšák wrote:
From: Marek Olšák
The update frequency is very low.
Difference: Only account for the size when allocating a new one.
Why not in the atom emit? With this patch, the size is only accounted
for in the first CS.
Nicolai
---
src/gallium/drivers/radeon
I have one comment/question on patch #16. Apart from that, the series is
Reviewed-by: Nicolai Hähnle
On 26.01.2017 17:04, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +
1 file changed, 13 insertions(+), 12 deletions
On 27.01.2017 14:34, Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
Reviewed-by: Nicolai Hähnle
---
src/mesa/state_tracker/st_sampler_view.c | 2 +-
src/mesa/state_tracker/st_sampler_view.h | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/mesa
On 27.01.2017 14:35, Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
---
src/gallium/auxiliary/hud/hud_nic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/hud/hud_nic.c
b/src/gallium/auxiliary/hud/hud_nic.c
index f9935dea8b..7e4feb9573 1006
>= 0x304
+ char *str = LLVMPrintModuleToString(gallivm->module);
+ fprintf(stderr, "%s", str);
+ LLVMDisposeMessage(str);
+#else
+ DumpModule(gallivm->module);
Should be: LLVMDumpModule
Apart from that:
Reviewed-by: Nicolai Hähnle
+#endif
}
}
diff --git a/sr
Nice find!
On 29.01.2017 19:10, Bartosz Tomczyk wrote:
---
src/gallium/drivers/r600/sb/sb_valtable.cpp | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_valtable.cpp
b/src/gallium/drivers/r600/sb/sb_valtable.cpp
index a8b7b49cd4..d31a1b76
For the series:
Reviewed-by: Nicolai Hähnle
On 30.01.2017 01:33, Marek Olšák wrote:
From: Marek Olšák
the value from the kernel is wrong
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm
On 30.01.2017 13:55, Samuel Pitoiset wrote:
Should be r600_common_screen instead of r600_screen.
Fixes: 80157a2c20 ("gallium/radeon: clean up r600_query_init_backend_mask")
Signed-off-by: Samuel Pitoiset
Reviewed-by: Nicolai Hähnle
---
src/gallium/drivers/r600/r600_pipe.c | 2
Reviewed-by: Nicolai Hähnle
On 30.01.2017 12:54, Marek Olšák wrote:
From: Marek Olšák
The update frequency is very low.
Difference: Only account for the size when allocating a new one and when
starting a new IB, and check for NULL. (v3)
---
src/gallium/drivers/radeonsi
On 30.01.2017 14:07, Bartosz Tomczyk wrote:
Commit 7b5878ee0491e7a93914389a8369cd6752b9757d increased number of
outputs to 64, but left output array intact. This caused stack overflow
when number of outputs is bigger then 32. Found by ASAN.
Pushed, thanks!
---
src/gallium/drivers/r600/r600_s
On 27.01.2017 12:02, Marek Olšák wrote:
From: Marek Olšák
Notes:
- make sure the default size is large enough to handle all state trackers
- pipe wrappers don't receive transfer calls from stream_uploader, because
pipe_context::stream_uploader points directly to the underlying driver's
stre
ahead with this.
I have some comments on patch #3, but apart from that, the series is
Reviewed-by: Nicolai Hähnle
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mail
On 30.01.2017 18:23, Ilia Mirkin wrote:
On Mon, Jan 30, 2017 at 4:36 AM, Ilia Mirkin wrote:
On Mon, Jan 30, 2017 at 4:33 AM, Nicolai Hähnle wrote:
On 26.01.2017 06:47, Ilia Mirkin wrote:
When a texture is immutable, we can't tack on extra levels
after-the-fact like we could with glTex
On 30.01.2017 18:20, Marek Olšák wrote:
On Mon, Jan 30, 2017 at 6:00 PM, Nicolai Hähnle wrote:
On 27.01.2017 12:02, Marek Olšák wrote:
From: Marek Olšák
Notes:
- make sure the default size is large enough to handle all state trackers
- pipe wrappers don't receive transfer calls
On 30.01.2017 18:17, Jan Ziak wrote:
On Mon, Jan 30, 2017 at 5:08 PM, Marek Olšák wrote:
On Mon, Jan 30, 2017 at 4:41 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
Hello
Just a note about the future of Mesa:
It is likely that optimizing Mesa will lead you (Marek) to consider
generative prog
On 30.01.2017 19:09, Ilia Mirkin wrote:
On Mon, Jan 30, 2017 at 1:06 PM, Ilia Mirkin wrote:
On Mon, Jan 30, 2017 at 12:26 PM, Nicolai Hähnle wrote:
On 30.01.2017 18:23, Ilia Mirkin wrote:
On Mon, Jan 30, 2017 at 4:36 AM, Ilia Mirkin wrote:
On Mon, Jan 30, 2017 at 4:33 AM, Nicolai Hähnle
On 31.01.2017 02:37, Marek Olšák wrote:
On Mon, Jan 30, 2017 at 6:29 PM, Nicolai Hähnle wrote:
On 30.01.2017 18:20, Marek Olšák wrote:
On Mon, Jan 30, 2017 at 6:00 PM, Nicolai Hähnle
wrote:
On 27.01.2017 12:02, Marek Olšák wrote:
From: Marek Olšák
Notes:
- make sure the default size
Both patches:
Reviewed-by: Nicolai Hähnle
On 31.01.2017 07:54, Michel Dänzer wrote:
From: Michel Dänzer
The kernel driver reports correct values now.
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 7 ++-
1 file changed, 6 insertions(+), 1
On 31.01.2017 12:02, Bartosz Tomczyk wrote:
The `end+1` skips the ']', whereas the `strlen+1` includes the final
'\0' in the move to terminate the string.
Thanks! R-b and pushed.
Nicolai
---
src/compiler/glsl/link_uniforms.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
the <16 x i8>
s/whicha/which/
Also, this affects constant buffers in addition to RW buffers (at least
for older versions of LLVM).
Apart from that and having to wait until the corresponding LLVM changes
land, the two patches are
Reviewed-by: Nicolai Hähnle
+ * type. W
For the series:
Reviewed-by: Nicolai Hähnle
On 01.02.2017 01:58, Timothy Arceri wrote:
From: Timothy Arceri
In the past I've gotten this function confused with the one in
ir_to_mesa.cpp of the same name. Now that the affected flag setting
has move into a helper it makes sense just to i
Reviewed-by: Nicolai Hähnle
On 01.02.2017 01:22, Tom Stellard wrote:
This was broken by: e0cc0a614c96011958bc3a1b84da9168e0e1ccbb
v2:
- Use preprocessor macro
---
src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a
On 01.02.2017 05:48, Dave Airlie wrote:
From: Dave Airlie
This code should be used in radv, so move it to a shared location
in advance of doing that.
Signed-off-by: Dave Airlie
Reviewed-by: Nicolai Hähnle
---
src/amd/common/ac_llvm_util.c| 71 ++
src
V_008F0C_BUF_DATA_FORMAT_32_32_32_32
+ };
+ assert(num_channels >= 1 && num_channels <= 4);
+
+ ac_build_tbuffer_store(ctx, rsrc, vdata, num_channels, vaddr, soffset,
+ inst_offset, dfmt[num_channels-1],
Spaces around the '
For the series:
Reviewed-by: Nicolai Hähnle
On 02.02.2017 00:41, Dave Airlie wrote:
From: Dave Airlie
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 44 ++---
1 file changed, 2 insertions(+), 42 deletions(-)
diff --git a/src/amd
For the series:
Reviewed-by: Nicolai Hähnle
On 02.02.2017 00:56, Dave Airlie wrote:
From: Dave Airlie
Signed-off-by: Dave Airlie
---
src/amd/common/ac_nir_to_llvm.c | 75 -
1 file changed, 7 insertions(+), 68 deletions(-)
diff --git a/src/amd
Ping after a week - does anybody still want to take a look at this?
On 26.01.2017 12:50, Nicolai Hähnle wrote:
Hi all,
this is mostly motivated by the need to support more screen depths than
just 24/32-bit RGB in Glamor. The extension is simple enough, just adding
three more enums that are
From: Nicolai Hähnle
Cc: 17.0
---
src/glx/dri3_glx.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index f7bcba3..2d40f0a 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -112,20 +112,24 @@ static void
glx_dri3_set_drawable_size
From: Nicolai Hähnle
The GLX specification says about glXDestroyPixmap:
"The storage for the GLX pixmap will be freed when it is not current
to any client."
So arguably, functions like glXSwapIntervalMESA can be called after
glXDestroyPixmap has been called for the curre
Hi all,
upon Emil's encouragement, I looked a bit deeper into this issue. The first
and last patch are as before, just in reverse order. I'm not completely
certain that patch #2 is needed, but it seems like a good idea. Patch #3 is
hopefully straightforward.
Please review!
Thanks,
Nicolai
--
sr
From: Nicolai Hähnle
The GLX specification says about glXDestroyPixmap:
"The storage for the GLX pixmap will be freed when it is not current
to any client."
We're not really following this language to the letter: some of the storage
is freed immediately (in
From: Nicolai Hähnle
With a subsequent patch, we might see NULL loaderPrivates, e.g. when
a DRIdrawable is flushed whose corresponding GLXDRIdrawable was destroyed.
This resulted in a crash, since the loader vs. DRI3 drawable structures
have a non-zero offset.
Fixes glx-visuals-{depth,stencil
On 02.02.2017 19:46, Marek Olšák wrote:
From: Marek Olšák
This reverts commit bdd860e3076655519d45bd66936ef7be9b7dda63.
Requested by a game developer.
Cc: 17.0
We're really being pushed towards bindless_texture :)
Reviewed-by: Nicolai Hähnle
---
src/gallium/drivers/rad
Acked-by: Nicolai Hähnle
On 03.02.2017 01:05, Dave Airlie wrote:
From: Dave Airlie
Suggested by Marek.
Signed-off-by: Dave Airlie
---
src/amd/Makefile.sources | 2 +
src/amd/common/ac_llvm_build.c| 752 ++
src/amd/common
On 03.02.2017 20:13, Eric Anholt wrote:
Now that there's MESA_LOADER_DRIVER_OVERRIDE for choosing the driver name
we load, we don't need this any more.
I like the override flag, could come in handy.
For the series (including the additional hunk for patch #3):
Reviewed-by: Nico
INT64 without supporting division and
modulo operations.
Seems reasonable. This patch is:
Reviewed-by: Nicolai Hähnle
Signed-off-by: Ilia Mirkin
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
src/gallium/drivers/free
It may be time to start thinking about whether CS emit functions can be
shared between radv and the gallium winsys. This code has seen a lot of
subtle bug fixes over time, so duplication is not very nice.
Nicolai
On 07.02.2017 07:01, Dave Airlie wrote:
From: Dave Airlie
This enables a trans
1 - 100 of 4145 matches
Mail list logo
