Reviewed-by: Marek Olšák
Marek
On Fri, May 18, 2018 at 3:06 AM, Timothy Arceri
wrote:
> Just let the extension detection do its job as we will be adding
> compat profile support in future, also we want these to work
> with compat profile version overrides.
> ---
> src/mesa/main/get_hash_param
Are you sure about this? The fixed-func vertex and fragment shaders can
move zero-stride vertex attribs into constants (uniforms). If a shader
changes, it might no longer be necessary to submit zero-stride attribs via
the vertex API, but this would be missed if _NEW_PROGRAM was ignored.
Marek
On
!num is totally fine.
Marek
On Thu, May 17, 2018 at 4:45 AM, Benedikt Schemmer wrote:
>
>
> Am 17.05.2018 um 08:59 schrieb Tapani Pälli:
> >
> >
> > On 05/10/2018 12:05 PM, Benedikt Schemmer wrote:
> >> remove a memset too and yes, this is all functionally identical
> >>
> >> ---
> >> src/me
LGPL code can't be part of Mesa or a dependency.
Marek
On Fri, May 18, 2018 at 4:56 AM, Benedikt Schemmer wrote:
> > Agreed, using ENABLE_SHADER_CACHE to guard some OS specifics is dirty,
> it should be only guarding shader cache itself.
>
> I found this online, but I'm not sure if it can be us
For the series:
Reviewed-by: Marek Olšák
Marek
On Thu, May 10, 2018 at 5:06 AM, Benedikt Schemmer wrote:
> Sometimes it is nice (and useful) to not just see if you've messed up
> but also if you've made an improvement.
>
> ---
> si-report.py | 24
> 1 file changed,
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, May 18, 2018 at 11:14 AM, Eric Engestrom
wrote:
> Signed-off-by: Eric Engestrom
> ---
> src/mesa/drivers/dri/common/dri_util.c | 142 +
> 1 file changed, 76 insertions(+), 66 deletions(-)
>
> diff --git a/src/me
Reviewed-by: Marek Olšák
Marek
On Fri, May 18, 2018 at 7:07 PM, Bas Nieuwenhuizen
wrote:
> We're not sharing 32_32_32 formats between different GPUs, so we
> do not have to align for vega on pre-vega cards.
>
> Fixes: e361970ed73 "radv: Add support for IMG_DATA_FORMAT_32_32_32."
> ---
> src/a
Changes in v2:
- move "#ifdef DEBUG" from above dumpProgram to above createDumpFilename
Previously, findFirstUse() only considered reads "uses". This fixes that by
making it check both an instruction's sources and definitions. It also shortens
both findFistUse() and findFirstDef() along the way.
Previously, findFirstUse() only considered reads "uses". This fixes that by
making it check both an instruction's sources and definitions. It also shortens
both findFistUse() and findFirstDef() along the way.
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 103 ++---
1 fi
The NV50_PROG_DUMP environment variable specifies a (already created) directory
to dump both shader binaries and tgsi code. The NV50_PROG_REPLACE environment
variable specified a (again, already created) directory that is searched to
find replacement binaries. This is all much like MESA_SHADER_DUMP
https://bugs.freedesktop.org/show_bug.cgi?id=106580
--- Comment #6 from lukas...@gmail.com ---
ok, thanks for the hint. I will try this.
I attached the dmesg log. The last lines show errors and were highlighted red.
But I don't understand it.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=106580
--- Comment #5 from lukas...@gmail.com ---
Created attachment 139643
--> https://bugs.freedesktop.org/attachment.cgi?id=139643&action=edit
dmesg_errors
dmesg errors
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106580
--- Comment #4 from Ilia Mirkin ---
Something very odd is happening... nouveau loads, and then
[ 6.447] (II) config/udev: removing GPU device
/sys/devices/pci:00/:00:02.0/:02:00.0/drm/card1 /dev/dri/card1
[ 6.447] xf86: remo
https://bugs.freedesktop.org/show_bug.cgi?id=106580
--- Comment #3 from lukas...@gmail.com ---
Thanks for the response.
I added the Xorg log found at /var/log/Xorg.0.log
If I use my GT 630 as primary (as selected in the bios) I can't use the output
of my motherboard any more.
I am not sure where
El 18 may. 2018 16:04, Andreas Boll escribió:2018-05-17 20:48 GMT+02:00 Juan A. Suarez Romero :
> Mesa 18.0.4 is now available.
>
> In this release we have:
>
> r600 driver gets a fix for constant buffer boounds, which fixes rendering bugs
> in Trine and Witcher 1.
>
> Several fixes for RA
https://bugs.freedesktop.org/show_bug.cgi?id=106580
--- Comment #2 from lukas...@gmail.com ---
Created attachment 139642
--> https://bugs.freedesktop.org/attachment.cgi?id=139642&action=edit
xorg log after restart /var/log/Xorg.0.log
--
You are receiving this mail because:
You are the QA Conta
Benedikt Schemmer writes:
> Most of the extensions are currently either always available or not.
> A mechanism to enable extensions based on the required OpenGL version is
> already
> in place, its just rarely used.
>
> This might cause problems when an application actually tries to use an
> ex
On Fri, May 18, 2018 at 6:00 PM, Samuel Pitoiset
wrote:
> This is needed for 32-bit GPU pointers. Ported from RadeonSI.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/s
On Fri, May 18, 2018 at 6:00 PM, Samuel Pitoiset
wrote:
> We still use 64-bit GPU pointers for all ring buffers because
> llvm.amdgcn.implicit.buffer.ptr doesn't seem to support 32-bit
> GPU pointers for now. This can be improved later anyways.
>
> Vega10:
> Totals from affected shaders:
> SGPRS:
https://bugs.freedesktop.org/show_bug.cgi?id=106580
--- Comment #1 from Ilia Mirkin ---
Please provide your xorg log, preferably after that error happens.
Also, you're likely going to be getter off using the GT 630 as the primary than
a Radeon 3000.
Note that this issue has nothing to do with m
https://bugs.freedesktop.org/show_bug.cgi?id=106580
Bug ID: 106580
Summary: glitches and unable to use monitors
Product: Mesa
Version: 18.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: ma
is the prerequisit for the others I just sent
CC: "Marek Olšák"
CC: Eric Anholt
CC: Emil Velikov
CC: Timothy Arceri
CC: Ilia Mirkin
Signed-off-by: Benedikt Schemmer
---
src/mesa/main/extensions_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/exten
Most of the extensions are currently either always available or not.
A mechanism to enable extensions based on the required OpenGL version is already
in place, its just rarely used.
This might cause problems when an application actually tries to use an extension
in a context for which the extensio
These are just a few extensions for which I had the specifications handy, to
get a feel for what this might look like.
It's already been pointed out that applications might fail because of this.
(I haven't found an application that does yet but I can only test on 64-bit)
The argument for this cha
This just makes the constants more descriptive
CC: "Marek Olšák"
CC: Eric Anholt
CC: Emil Velikov
CC: Timothy Arceri
CC: Ilia Mirkin
Signed-off-by: Benedikt Schemmer
---
src/mesa/main/extensions_table.h | 833 ---
1 file changed, 417 insertions(+), 416
I had hoped this would land in 18.1.0
Any signs of a review and can we get this backported asap?
On Wed, 16 May 2018, 15:49 Michel Dänzer, wrote:
> On 2018-05-16 01:39 PM, Mike Lothian wrote:
> > Can this be added to stable too?
>
> Right, I meant add that but forgot, thanks for the reminder. C
From: Mathias Fröhlich
Hi,
Below a patch to radeonsi to get a small bit more out of the recent
VAO changes.
The change did not introduce regressions into piglit and some variant
of deqp availble through piglit on a radeonsi system.
Please review!
best Mathias
Instead of tracking which pipe_ve
27 matches
Mail list logo
