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
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 Sat, Nov 22, 2014 at 6:52 PM, Ben Widawsky
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 similarity to the
> previou
>>Even APPLE_texture_format_BGRA
>>mentions that BGRA8_EXT is not accepted as an
>>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 ?
Corr
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. EXT_texture_format_BGRA
On Fri Nov 21 2014 at 10:36:29 PM Ilia Mirkin 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 queries.
>
> Perhaps t
On Fri Nov 21 2014 at 9:57:46 PM Ilia Mirkin wrote:
> On Sat, Nov 22, 2014 at 12:44 AM, John Ettedgui
> wrote:
> > On Fri Nov 21 2014 at 7:50:03 PM Ilia Mirkin
> wrote:
> >>
> >> What's the actual problem?
> >
> > If you mean in-game, a blocking black screen, the game wants to display
> > somet
On Fri Nov 21 2014 at 10:51:59 PM Ilia Mirkin 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 will start a quer
On Fri Nov 21 2014 at 10:14:19 PM Ilia Mirkin 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 will
On Sat Nov 22 2014 at 2:05:59 AM Axel Davy 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, after talk
On Fri Nov 21 2014 at 7:50:03 PM Ilia Mirkin 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 marked as FRESH.
This
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, an
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 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
> ---
> src/mesa/drivers/dri/i965/brw_draw_upload.c | 4
> 1 file
https://bugs.freedesktop.org/show_bug.cgi?id=86594
--- Comment #2 from Chris Forbes ---
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 calling through a null
https://bugs.freedesktop.org/show_bug.cgi?id=86594
--- Comment #1 from Simon Budig ---
Created attachment 109875
--> https://bugs.freedesktop.org/attachment.cgi?id=109875&action=edit
Testcase
This is a testcase triggering the crash for me.
Compile with
gcc -Wall -g -o bugtest bugtest.c -l
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: major
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 to
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
> ---
> src/mesa/drivers/dri/i965/brw_draw_upload.c | 4
> 1 file
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 VARYI
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 VARYI
On Saturday, November 22, 2014 09:18:32 AM Matt Turner wrote:
> On Sat, Nov 22, 2014 at 12:50 AM, Kenneth Graunke
> 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 usi
On Sat, Nov 22, 2014 at 1:03 PM, Kenneth Graunke 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 is_math() check i
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
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
---
src/mesa/drivers/dri/i965/brw_vs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drive
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
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.
As documented in:
https://www.opengl.org/registry/specs/ARB/compute_shader.txt
const uvec3 gl_WorkGroupSize;
Signed-off-by: Jordan Justen
---
src/glsl/ast_to_hir.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
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 g
> On Nov 22, 2014, at 7:35 AM, Marek Olšák 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, where I
thin
On Sat, Nov 22, 2014 at 8:18 AM, Jason Ekstrand 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 old code
> some mo
On Sat, Nov 22, 2014 at 12:50 AM, Kenneth Graunke 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 have no idea
On Nov 21, 2014 1:06 PM, "Matt Turner" 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 viewed with git
AFAICS, the R600 backend doesn't implement the intrinsics for R600.
Marek
On Sat, Nov 22, 2014 at 3:53 AM, Michel Dänzer wrote:
> On 21.11.2014 06:21, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> So far it has been compiled into pretty ugly code (8 instructions or so
>> for either opcode).
On 22/11/2014 07:51, Ilia Mirkin wrote :
It requires a begin_query for some but not all queries.
Perhaps the code should read like
} else {
if (This->state != NINE_QUERY_STATE_RUNNING)
pipe->begin_query(pipe, This->pq);
pipe->end_query(pipe, This->pq);
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 cond
36 matches
Mail list logo
