Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Fri, Jun 26, 2015 at 2:04 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
0 is not used as a valid drawable id, as such there is no point in
attempting to query it's geometry. Just bail out early and provide the
more meaningful
Freedreno requires {a4xx,ir3}_SOURCES and NIR to build.
Signed-off-by: Varad Gautam varadgau...@gmail.com
---
src/gallium/drivers/freedreno/Android.mk | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/freedreno/Android.mk
https://bugs.freedesktop.org/show_bug.cgi?id=91123
--- Comment #1 from Marek Olšák mar...@gmail.com ---
The bisected commit can't have caused any regression. The problem is that you
didn't enable GLES1 and GLES2 in Mesa, so the test skipped (or passed) before
that. It's possible that this isn't
For the whole series:
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Fri, Jun 26, 2015 at 2:04 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
Free the memory for dri2_surf in the unlikely case that one provides
NULL for native_window. Also set the relevant EGL_ERROR to provide
On 19/06/2015 12:51, Emil Velikov wrote:
On 19 June 2015 at 00:05, Julien Isorce julien.iso...@gmail.com wrote:
Sorry for removing the XXX line. Original message is here:
https://bugs.freedesktop.org/attachment.cgi?id=115539
At the time src/glx/apple/apple_glapi.c has been developed this patch
https://bugs.freedesktop.org/show_bug.cgi?id=90817
--- Comment #5 from Jon TURNEY jon.tur...@dronecode.org.uk ---
Something like this is also needed when the server is XWin on Cygwin/MinGW
using WGL, where the set of fbConfigs comes from the native driver and don't
match swrast's expectations.
https://bugs.freedesktop.org/show_bug.cgi?id=91106
--- Comment #4 from Jon TURNEY jon.tur...@dronecode.org.uk ---
(In reply to Emil Velikov from comment #2)
Iirc Jon had some
branches which rework/clean things up which seems like the way forward imho.
Sorry, all the clean-up I did for
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/docs/source/tgsi.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 89ca172..4e869e7 100644
---
From: Rob Clark robcl...@freedesktop.org
Mostly ttn fixes, plus a couple small nir fixes/cleanups, and a doc
patch to clairify ArrayID usage
Rob Clark (7):
tgsi: update docs for ArrayID usage
gallium/ttn: IN/OUT are only array if ArrayID != 0
gallium/ttn: partial fix for output arrays
On 19/06/2015 00:36, Julien Isorce wrote:
On 18 June 2015 at 19:46, Emil Velikov emil.l.veli...@gmail.com wrote:
On 18 June 2015 at 06:53, Julien Isorce julien.iso...@gmail.com wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90908
I don't think it's necessary to create a
On Fri, Jun 26, 2015 at 9:05 PM, Brian Paul bri...@vmware.com wrote:
On 06/26/2015 12:06 PM, Erik Faye-Lund wrote:
In order to save a small leak if mesa is continously loaded and
unloaded, let's free the locale when the shared object is unloaded.
Signed-off-by: Erik Faye-Lund
https://bugs.freedesktop.org/show_bug.cgi?id=91106
--- Comment #3 from Jon TURNEY jon.tur...@dronecode.org.uk ---
(In reply to Emil Velikov from comment #1)
+#if defined(GLX_USE_APPLEGL)
+#define _ATTRIBUTE_WEAK __attribute__((weak))
+#else
+#define _ATTRIBUTE_WEAK
+#endif
+
(If we end up
From: Rob Clark robcl...@freedesktop.org
Previously we were unconditionally doing ttn_get_src() even for
instructions with no src's. Which created a lot of unnecessary
load_const instructions. These were mostly harmless since NIR opt
passes would strip them back out. But for an ENDIF following
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index
From: Rob Clark robcl...@freedesktop.org
It isn't quite yet practical to enable TGSI_ANY_INOUT_DECL_RANGE shader
cap yet, at least not in drivers that need lower_to_scalar pass (which
right now is all of the ttn users), since the register arrays do not get
converted to SSA, which angers
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/glsl/nir/nir_lower_phis_to_scalar.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/nir/nir_lower_phis_to_scalar.c
b/src/glsl/nir/nir_lower_phis_to_scalar.c
index a57d253..739170d
Thanks!
R-B me
On Jun 27, 2015 7:57 AM, Rob Clark robdcl...@gmail.com wrote:
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/glsl/nir/nir_lower_alu_to_scalar.c | 2 +-
src/glsl/nir/nir_lower_vec_to_movs.c | 2 +-
On 26 June 2015 at 17:38, Brian Paul bri...@vmware.com wrote:
Digging up the patch from March for reference:
This fixes a GL error warning on r200 in Wine.
The GL_ARB_sampler_objects extension does not specify a dependency on
GL_ARB_shadow or GL_ARB_depth_texture for this value. Just set the
On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark robdcl...@gmail.com wrote:
I had a quick look at enabling this for freedreno.. although looks
like it is going to take some work in tgsi_to_nir and/or nir.. the
problem is we end up w/ a register array (rather than variable array
like we do for TEMP
On Sat, Jun 27, 2015 at 5:08 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Fri, Jun 26, 2015 at 9:05 PM, Brian Paul bri...@vmware.com wrote:
On 06/26/2015 12:06 PM, Erik Faye-Lund wrote:
In order to save a small leak if mesa is continously loaded and
unloaded, let's free the locale
On Sat, Jun 27, 2015 at 12:57 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark robdcl...@gmail.com wrote:
I had a quick look at enabling this for freedreno.. although looks
like it is going to take some work in tgsi_to_nir and/or nir.. the
problem is we
On Sat, Jun 27, 2015 at 11:39 AM, Rob Clark robdcl...@gmail.com wrote:
On Sat, Jun 27, 2015 at 12:57 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark robdcl...@gmail.com wrote:
I had a quick look at enabling this for freedreno.. although looks
like it is
On Sat, Jun 27, 2015 at 2:54 PM, Rob Clark robdcl...@gmail.com wrote:
Connor, btw, how does glsl_to_nir handle this?
The variable for gl_FragColor a special location (FRAG_RESULT_COLOR),
whereas normal outputs (i.e. gl_FragData[] or out variables) start at
FRAG_RESULT_DATA0.
I guess at some
On 2015-06-26 16:03:21, Kenneth Graunke wrote:
Adding new shader stages to a switch statement is less confusing than an
if-else-if ladder where all but the first case are fragment shader
specific (but don't claim to be).
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
Same problem and fix as for nouveau's ZaphodHeads trouble.
See patch ...
nouveau: Use dup fd as key in drm-winsys hash table to fix ZaphodHeads.
... for reference.
Cc: 10.3 10.4 10.5 10.6 mesa-sta...@lists.freedesktop.org
Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
Cc: Ilia Mirkin
On Saturday, June 27, 2015 05:00:22 PM Jordan Justen wrote:
On 2015-06-26 16:03:21, Kenneth Graunke wrote:
Adding new shader stages to a switch statement is less confusing than an
if-else-if ladder where all but the first case are fragment shader
specific (but don't claim to be).
On Sat, Jun 27, 2015 at 7:47 PM, Connor Abbott cwabbo...@gmail.com wrote:
On Sat, Jun 27, 2015 at 2:54 PM, Rob Clark robdcl...@gmail.com wrote:
Connor, btw, how does glsl_to_nir handle this?
The variable for gl_FragColor a special location (FRAG_RESULT_COLOR),
whereas normal outputs (i.e.
We need to distinguish a shader that has separate writes to each MRT
from one which is supposed to write the data from MRT 0 to all the MRTs.
In TGSI this is done with a property. NIR doesn't have that, so encode
it as a funny location and decode on the other end.
Signed-off-by: Ilia Mirkin
https://bugs.freedesktop.org/show_bug.cgi?id=91130
Bug ID: 91130
Summary: Mesa's cl.h defines CL_VERSION_1_2 even though it is
missing some OpenCL 1.2 functions
Product: Mesa
Version: 10.5
Hardware: Other
On Fri, Jun 5, 2015 at 9:36 AM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
The dup'ed fd owned by the nouveau_screen for a device node
must also be used as key for the winsys hash table, instead
of using the original fd passed in for a screen, to make
multi-x-screen ZaphodHeads
https://bugs.freedesktop.org/show_bug.cgi?id=91130
--- Comment #1 from Dennis Schridde devuran...@gmx.net ---
This issue turned up when trying to fix a linker error in JTR:
https://github.com/magnumripper/JohnTheRipper/issues/1470
--
You are receiving this mail because:
You are the QA Contact
https://bugs.freedesktop.org/show_bug.cgi?id=91130
Dennis Schridde devuran...@gmx.net changed:
What|Removed |Added
See Also|
On 06/05/2015 03:57 PM, Mario Kleiner wrote:
On 06/05/2015 03:50 PM, Ilia Mirkin wrote:
This scheme is copied from radeon, does it need a similar fix? I'm away
from computers for another week or so, will be able to look then.
For some reason, no. Testing on Radeon multi-x-screen ZaphodHeads
On 06/28/2015 06:25 AM, Ilia Mirkin wrote:
But that's the thing... in this case, the fd lifetime is owned by the
X server. In fact, nouveau doesn't touch that fd in mesa beyond
dup'ing it, and then exclusively using the dup'd fd.
True, it's not owned by nouveau, but instead by mesa core code?
Without being intimately familiar with the radeon winsys code, this
seems sane (esp after re-reviewing the situation for nouveau).
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu. But one of the radeon
people definitely needs to look at this before pushing.
On Sat, Jun 27, 2015 at 9:02 PM, Mario
Pushed. Thanks for the fix and for bearing with me!
On Sun, Jun 28, 2015 at 1:01 AM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
Yes, that's good.
On 06/28/2015 07:00 AM, Ilia Mirkin wrote:
How about:
/* Use dupfd in hash table, to avoid errors if the original fd gets
* closed by its
Thanks for the review Ilia. Just saw that the new amdgpu winsys driver
will need the same fix, once this one is confirmed to be ok.
thanks,
-mario
On 06/28/2015 07:23 AM, Ilia Mirkin wrote:
Without being intimately familiar with the radeon winsys code, this
seems sane (esp after re-reviewing
On 06/28/2015 05:41 AM, Ilia Mirkin wrote:
Oh duh. Thanks for the super-detailed explanation. To rephrase what
you said in a slightly shorter manner:
See bug https://bugs.freedesktop.org/show_bug.cgi?id=79823 for why we
need to dupfd (which we are already, although radeon might not be).
How's this? I updated both the commit message and the comment in the
code. If this is OK with you, I'll push.
commit 627cd0d8c0f0052033c213dcef3ea7c6e414e942
Author: Mario Kleiner mario.kleiner...@gmail.com
Date: Fri Jun 5 15:36:52 2015 +0200
nouveau: Use dup fd as key in drm-winsys hash
Ok, maybe one thing for the commit message, as i just made the same
mixup in my reply: The fd's are not owned by the x-server, but by the
mesa screens (pipe screens? dri screens?) they represent, so if such a
screen goes away, the fd goes away. Using X server would be confusing,
especially
Yes, that's good.
On 06/28/2015 07:00 AM, Ilia Mirkin wrote:
How about:
/* Use dupfd in hash table, to avoid errors if the original fd gets
* closed by its owner. The hash key needs to live at least as long as
* the screen.
*/
On Sun, Jun 28, 2015 at 12:57 AM, Mario Kleiner
On 06/28/2015 03:48 AM, Ilia Mirkin wrote:
On Fri, Jun 5, 2015 at 9:36 AM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
The dup'ed fd owned by the nouveau_screen for a device node
must also be used as key for the winsys hash table, instead
of using the original fd passed in for a screen, to
42 matches
Mail list logo
