On Friday, November 21, 2014 12:41:25 PM Matt Turner wrote:
---
Strangely, the suggested implementations of double-precision sqrt/rcp
in the BSpec show using a math instruction with an eo conditional
modifier. I have no idea what that could possibly mean, or how it could
work since
AFAICS, the R600 backend doesn't implement the intrinsics for R600.
Marek
On Sat, Nov 22, 2014 at 3:53 AM, Michel Dänzer mic...@daenzer.net wrote:
On 21.11.2014 06:21, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
So far it has been compiled into pretty ugly code (8 instructions
On Nov 21, 2014 1:06 PM, Matt Turner matts...@gmail.com wrote:
With bblock_t::end_ip, we can skip entire blocks rather than checking
every instruction in them. Also by making the loops nested (explicitly,
it already was a nested loop), the continue seen at the end of the first
hunk (when
On Sat, Nov 22, 2014 at 12:50 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On Friday, November 21, 2014 12:41:25 PM Matt Turner wrote:
---
Strangely, the suggested implementations of double-precision sqrt/rcp
in the BSpec show using a math instruction with an eo conditional
modifier. I
On Sat, Nov 22, 2014 at 8:18 AM, Jason Ekstrand ja...@jlekstrand.net wrote:
Is it just me, or did you loose this bit? Maybe it wasn't needed. Also,
continuing until we get to a late enough block is not the same as continuing
until we get to a certain instruction IP. I'll have to look at the
On Nov 22, 2014, at 7:35 AM, Marek Olšák mar...@gmail.com wrote:
AFAICS, the R600 backend doesn't implement the intrinsics for R600.
Marek
Should it? It’s trivial to switch to these for it, but I wasn’t sure what the
actual semantics of its instructions were. There’s MAX and MAX_DX10,
The R600 LLVM support for graphics is disabled by default and is
missing some features. Unless somebody implements the missing
features, discussing how each TGSI instruction is compiled is fairly
low priority. We should rather be asking whether that project is
really dead. It's sad but true.
For
As documented in:
https://www.opengl.org/registry/specs/ARB/compute_shader.txt
const uvec3 gl_WorkGroupSize;
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/glsl/ast_to_hir.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp
For drawing the OpenGL API should validate this before we try to upload the
state.
For compute, these might not be set.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 4
1 file changed, 4 insertions(+)
diff --git
For drawing the OpenGL API should validate this before we try to upload the
state.
For compute, these might not be set.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_vs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Friday, November 21, 2014 12:43:43 PM Matt Turner wrote:
Ben was asking about the undocumented restriction that the math
instruction cannot use the dependency control hints. I went to reconfirm
and disabled the is_math() check in opt_set_dependency_control() and saw
that the disassembled
On Sat, Nov 22, 2014 at 1:03 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On Friday, November 21, 2014 12:43:43 PM Matt Turner wrote:
Ben was asking about the undocumented restriction that the math
instruction cannot use the dependency control hints. I went to reconfirm
and disabled the
On Saturday, November 22, 2014 09:18:32 AM Matt Turner wrote:
On Sat, Nov 22, 2014 at 12:50 AM, Kenneth Graunke kenn...@whitecape.org
wrote:
On Friday, November 21, 2014 12:41:25 PM Matt Turner wrote:
---
Strangely, the suggested implementations of double-precision sqrt/rcp
in the BSpec
The state upload code was incorrectly shifting the attribute swizzles. The
effect of this is we're likely to get the default swizzle values, which disables
the component.
This doesn't technically fix any bugs since Skylake support is still disabled by
default (no PCI IDs).
While here, since
The state upload code was incorrectly shifting the attribute swizzles. The
effect of this is we're likely to get the default swizzle values, which disables
the component.
This doesn't technically fix any bugs since Skylake support is still disabled by
default (no PCI IDs).
While here, since
On Sat, Nov 22, 2014 at 12:02:31PM -0800, Jordan Justen wrote:
For drawing the OpenGL API should validate this before we try to upload the
state.
For compute, these might not be set.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_draw_upload.c |
This patch implements ARB_pipeline_statistics_query. This addition to GL does
not add a new API. Instead, it adds new tokens to the existing query APIs. The
work to hook up the new tokens is trivial due to it's similarity to the previous
work done for the query APIs. I've implemented all the new
https://bugs.freedesktop.org/show_bug.cgi?id=86594
Bug ID: 86594
Summary: Segfault in glGetActiveUniformName
Product: Mesa
Version: 10.3
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=86594
--- Comment #1 from Simon Budig si...@gimp.org ---
Created attachment 109875
-- https://bugs.freedesktop.org/attachment.cgi?id=109875action=edit
Testcase
This is a testcase triggering the crash for me.
Compile with
gcc -Wall -g -o bugtest
https://bugs.freedesktop.org/show_bug.cgi?id=86594
--- Comment #2 from Chris Forbes chr...@ijw.co.nz ---
Looks like there's more than one thing wrong here.
glGetActiveUniformName is introduced with 3.1/ARB_uniform_buffer_object, which
is not supported on Ironlake. Your test program ends up
On Saturday, November 22, 2014 12:02:31 PM Jordan Justen wrote:
For drawing the OpenGL API should validate this before we try to upload the
state.
For compute, these might not be set.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/brw_draw_upload.c
Ilia noticed that my lowering pass was converting the constant array
used by textureGatherOffsets' offsets parameter to a uniform. This
broke textureGather for Nouveau, and is generally a horrible plan,
since it violates the GLSL constraint that offsets must be an
immediate constant.
When I
On Fri Nov 21 2014 at 7:50:03 PM Ilia Mirkin imir...@alum.mit.edu wrote:
What's the actual problem?
If you mean in-game, a blocking black screen, the game wants to display
something but is unable to and keeps trying pretty much forever.
If there's no begin, then a new query would
remain
On Sat Nov 22 2014 at 2:05:59 AM Axel Davy axel.d...@ens.fr wrote:
After reading the documentation and the code myself, I think Ilia's
comment are right.
The current patch won't issue a query when the applications issues
D3DISSUE_END directly, whereas
Ilia's proposed code does.
Alright,
So I tried both code you thought of.
1) Always having end_query did not seem to get a different behavior from my
patch. (I'm sure it does somewhere but I didn't see that in my quick test).
2) Your 2nd code is more problematic (adding the begin_query as needed)
The game completely dies/freezes,
On Fri Nov 21 2014 at 10:51:59 PM Ilia Mirkin imir...@alum.mit.edu wrote:
No, but it seems like my proposed code above handles all the
situations... if it's in the Building state (aka 'RUNNING'), then it
just executes end_query. If it's in any other state (i.e. FRESH,
ENDED, or FLUSHED) it
On Fri Nov 21 2014 at 10:14:19 PM Ilia Mirkin imir...@alum.mit.edu wrote:
Oh, I think i see the problem.
In GetData:
user_assert(This-state != NINE_QUERY_STATE_RUNNING,
D3DERR_INVALIDCALL);
should be
user_assert(This-state != ... || This-state |= FRESH,
D3DERR_INVALIDCALL)
This
On Fri Nov 21 2014 at 10:36:29 PM Ilia Mirkin imir...@alum.mit.edu wrote:
Right, I figured as much. My point is that doing what I'm proposing
there would allow such usage even though it is illegal based on the
API description.
Alright.
It requires a begin_query for some but not all
On Fri Nov 21 2014 at 9:57:46 PM Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Nov 22, 2014 at 12:44 AM, John Ettedgui john.etted...@gmail.com
wrote:
On Fri Nov 21 2014 at 7:50:03 PM Ilia Mirkin imir...@alum.mit.edu
wrote:
What's the actual problem?
If you mean in-game, a blocking
Hi,
I am looking at Immutable textures usage with image data of BGRA
format. According to Texture storage extension spec [1] if either
EXT_texture_format_BGRA or APPLE_texture_format_BGRA are
supported, glTexStorage2DEXT
must accept BGRA8_EXT as internal format.
Even APPLE_texture_format_BGRA
mentions that BGRA8_EXT is not accepted as an internalformat
parameter to TexImage* when the GL is OpenGL ES 3.0. With GLES3.0, I
am wondering if their is any way to use image data in BGRA format and
Immutable textures without swizzling the data to RGBA format ?
On Sat, Nov 22, 2014 at 6:52 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
This patch implements ARB_pipeline_statistics_query. This addition to GL does
not add a new API. Instead, it adds new tokens to the existing query APIs. The
work to hook up the new tokens is trivial due to it's
On 2014-11-22 17:33:54, Kenneth Graunke wrote:
On Saturday, November 22, 2014 12:02:31 PM Jordan Justen wrote:
For drawing the OpenGL API should validate this before we try to upload the
state.
For compute, these might not be set.
Signed-off-by: Jordan Justen
On Saturday, November 22, 2014 11:26:39 PM Jordan Justen wrote:
On 2014-11-22 17:33:54, Kenneth Graunke wrote:
On Saturday, November 22, 2014 12:02:31 PM Jordan Justen wrote:
For drawing the OpenGL API should validate this before we try to upload
the
state.
For compute, these
35 matches
Mail list logo
