https://bugs.freedesktop.org/show_bug.cgi?id=91123
--- Comment #1 from Marek Olšák ---
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 even a regression,
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 26, 2015 at 2:04 PM, Emil Velikov 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 EGL_BAD_NATIVE_WINDOW to the user.
>
> Signed-off-b
For the whole series:
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 26, 2015 at 2:04 PM, Emil Velikov 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
> feedback to the user.
>
> Signed-off-by: Emil
On 19/06/2015 00:36, Julien Isorce wrote:
On 18 June 2015 at 19:46, Emil Velikov wrote:
On 18 June 2015 at 06:53, Julien Isorce wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90908
I don't think it's necessary to create a bugzilla entry just to link to
it in your patch.
A
On Fri, Jun 26, 2015 at 9:05 PM, Brian Paul 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
>> Reviewed-by: Matt
On 19/06/2015 12:51, Emil Velikov wrote:
On 19 June 2015 at 00:05, Julien Isorce 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 was
not needed I guess
https://bugs.freedesktop.org/show_bug.cgi?id=90817
--- Comment #5 from Jon TURNEY ---
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.
--
You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=91106
--- Comment #3 from Jon TURNEY ---
(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 keeping this) Can we
https://bugs.freedesktop.org/show_bug.cgi?id=91106
--- Comment #4 from Jon TURNEY ---
(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 __APPLE__ is already upstream, wit
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 arrays).. ie. for something copying from a TEMP
array to an OUT array, we en
Grigori Goronzy writes:
> We need this to implement OpenCL's
> CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE.
Reviewed-by: Francisco Jerez
Thanks.
> ---
> src/gallium/docs/source/screen.rst | 2 ++
> src/gallium/drivers/ilo/ilo_screen.c | 8
> src/gallium/driv
From: Rob Clark
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 a
BRK, it would result i
From: Rob Clark
Signed-off-by: Rob Clark
---
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 e202ce6..1ad8c68 100644
--- a/src/gallium/auxiliary/nir/
From: Rob Clark
Signed-off-by: Rob Clark
---
src/glsl/nir/nir_lower_alu_to_scalar.c | 2 +-
src/glsl/nir/nir_lower_vec_to_movs.c | 2 +-
src/glsl/nir/nir_search.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/nir/nir_lower_alu_to_scalar.c
b/src/
From: Rob Clark
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 nir_lower_alu_to_scalar.
Signed-o
From: Rob Clark
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 143 ++--
1 file changed, 81 insertions(+), 62 deletions(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index 065bbf0..a189559
From: Rob Clark
Signed-off-by: Rob Clark
---
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 100644
--- a/src/glsl/nir/nir_lower_phis_to_scalar.c
From: Rob Clark
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
gallium/ttn: add TXB2
gal
From: Rob Clark
Signed-off-by: Rob Clark
---
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
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/sourc
Thanks!
R-B me
On Jun 27, 2015 7:57 AM, "Rob Clark" wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> src/glsl/nir/nir_lower_alu_to_scalar.c | 2 +-
> src/glsl/nir/nir_lower_vec_to_movs.c | 2 +-
> src/glsl/nir/nir_search.c | 2 +-
> 3 files changed, 3 insertions(+)
On 26 June 2015 at 17:38, Brian Paul 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 value
>
On Sat, Jun 27, 2015 at 5:08 AM, Erik Faye-Lund wrote:
> On Fri, Jun 26, 2015 at 9:05 PM, Brian Paul 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 u
On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark 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 arrays).. ie. for
On Sat, Jun 27, 2015 at 12:57 PM, Connor Abbott wrote:
> On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark 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 (rathe
On Sat, Jun 27, 2015 at 11:39 AM, Rob Clark wrote:
> On Sat, Jun 27, 2015 at 12:57 PM, Connor Abbott wrote:
>> On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark 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
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
OS
https://bugs.freedesktop.org/show_bug.cgi?id=91130
Dennis Schridde changed:
What|Removed |Added
See Also||https://github.com/magnumri
https://bugs.freedesktop.org/show_bug.cgi?id=91130
--- Comment #1 from Dennis Schridde ---
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 for the bug.
You are
Connor, btw, how does glsl_to_nir handle this?
I guess at some point we want to try to align ttn w/ gtn (ie. cleanup
the whole nir with a tgsi accent thing)..
not that this would be the worst of the ttn vs gtn diff's in the
current state, so it is fine if there isn't a better way to do it
right n
On Sat, Jun 27, 2015 at 2:54 PM, Rob Clark 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 point we want to t
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
> ---
> src/mesa/drivers/dri/i965/
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 wrote:
> On Sat, Jun 27, 2015 at 2:54 PM, Rob Clark 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) star
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 n
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"
Signed-off-by: Mario Kleiner
Cc: Ilia Mirkin
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
On Fri, Jun 5, 2015 at 9:36 AM, Mario Kleiner
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 configurations work on nouveau.
>
On 06/28/2015 03:48 AM, Ilia Mirkin wrote:
On Fri, Jun 5, 2015 at 9:36 AM, Mario Kleiner
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 ZaphodH
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).
Except instead of sticking the dup'd fd into the has
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).
Radeo
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
Date: Fri Jun 5 15:36:52 2015 +0200
nouveau: Use dup fd as key in drm-winsys hash table to fix ZaphodHeads.
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 un
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.
On Sun, Jun 28, 2015 at 12:23 AM, Mario Kleiner
wrote:
> Ok, maybe one thing for the commit message, as i just
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?
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
wrote:
> On 06/28/2015 06:25 AM, Ilia Mirkin wrote:
>>
>> But that's the thing...
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
wrote:
On 06/28/
Pushed. Thanks for the fix and for bearing with me!
On Sun, Jun 28, 2015 at 1:01 AM, Mario Kleiner
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 owner. The h
Without being intimately familiar with the radeon winsys code, this
seems sane (esp after re-reviewing the situation for nouveau).
Reviewed-by: Ilia Mirkin . But one of the radeon
people definitely needs to look at this before pushing.
On Sat, Jun 27, 2015 at 9:02 PM, Mario Kleiner
wrote:
> Same
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 t
49 matches
Mail list logo
