Re: [Mesa-dev] Mesa releases in early January?
On Tue, 2010-11-30 at 18:07 -0800, Roland Scheidegger wrote: > Am 30.11.2010 21:23, schrieb Ian Romanick: > > It seems that new development in master has slowed a bit, so how does > > a 7.10 release on January 7th sound? If we're going to do that, > > we'll want to make the 7.10 branch on, say, December 8th. That's > > roughly a week from now. > Don't say development has slowed if I'm just about to merge > gallium-array-textures which likely will cause havoc :-). > Though maybe a week is enough to clean up the mess mostly ;-). > Is there any harm in creating the 7.10 branch a little earlier, prior to Roland's merge? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 --- Comment #7 from Jared Clark 2010-12-01 04:56:13 PST --- Created an attachment (id=40698) --> (https://bugs.freedesktop.org/attachment.cgi?id=40698) dmesg output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 --- Comment #8 from Jared Clark 2010-12-01 04:56:51 PST --- Created an attachment (id=40699) --> (https://bugs.freedesktop.org/attachment.cgi?id=40699) Xorg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 --- Comment #9 from Jared Clark 2010-12-01 04:59:27 PST --- Unfortunately I was having several issues initially, differing output depending on what drivers and kernel combo I was using. This is currently a decently performing combo, but this crash is certainly repeatable. If any more info is needed I'll do my best to provide. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: fix lowering conditional returns in subroutines
Hello!
My last mail was misleading. The described behaviour (continue out of loop
etc.) occurs with mesa's current glsl compiler. The attached patch tries to
fix that.
I appologize for the faulty description and hope it was the cause for the lack
of feedback to my last mail.
I also attached two piglit tests to demonstrate the bug.
Fabian
On Friday 26 November 2010 02:09:31 Fabian Bieler wrote:
> Hello!
>
> This patch fixes a bug in the lower_jumps pass if lower_sub_return is set
> to true.
>
> Subroutines such as
>
> void sub() {
> for (int i = 0; i < 2; ++i) {
> if (i)
> return;
> }
> }
>
> a continue instruction is inserted outside of the loop.
>
> Subroutines such as
>
> void sub() {
> for (int j = 0; j < 2; ++j) {
> for (int i = 0; i < 2; ++i) {
> if (i)
> return;
> }
> }
> alter_some_global_variable();
> return;
> }
>
> get transformed to
>
> void sub() {
> bool return_flag = false;
> for (int j = 0; j < 2; ++j) {
> for (int i = 0; i < 2; ++i) {
> if (i) {
> return_flag = true;
> break;
> }
> }
> if (return_flag)
> break;
> }
> alter_some_global_variable();
> return;
> }
>
> Please review
>
> Fabian
From 001a40b4033f072c2683426d13bd67cbc793da8c Mon Sep 17 00:00:00 2001
From: Fabian Bieler
Date: Wed, 1 Dec 2010 14:44:58 +0100
Subject: [PATCH] glsl: fix lowering conditional returns in subroutines
this fix applies to the lower_sub_return 'branch' of the lower_jumps pass
---
src/glsl/lower_jumps.cpp |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/glsl/lower_jumps.cpp b/src/glsl/lower_jumps.cpp
index e1e7a5b..9009495 100644
--- a/src/glsl/lower_jumps.cpp
+++ b/src/glsl/lower_jumps.cpp
@@ -490,7 +490,11 @@ lower_continue:
if(this->loop.may_set_return_flag) {
assert(this->function.return_flag);
ir_if* return_if = new(ir) ir_if(new(ir) ir_dereference_variable(this->function.return_flag));
- return_if->then_instructions.push_tail(new(ir) ir_loop_jump(saved_loop.loop ? ir_loop_jump::jump_break : ir_loop_jump::jump_continue));
+ saved_loop.may_set_return_flag = true;
+ if(saved_loop.loop)
+return_if->then_instructions.push_tail(new(ir) ir_loop_jump(ir_loop_jump::jump_break));
+ else
+move_outer_block_inside(ir, &return_if->else_instructions);
ir->insert_after(return_if);
}
--
1.7.1
[require]
GL >= 2.0
GLSL >= 1.10
[vertex shader]
void main()
{
gl_Position = gl_Vertex;
}
[fragment shader]
float val = 0.0;
void sub() {
for (int i = 0; i < 3; ++i) {
if (i == 1)
return;
val = 0.5;
}
val = 1.0;
}
void main() {
sub();
gl_FragColor = vec4(val);
}
[test]
draw rect -1 -1 2 2
probe all rgb 0.5 0.5 0.5 0.5
[require]
GL >= 2.0
GLSL >= 1.10
[vertex shader]
void main()
{
gl_Position = gl_Vertex;
}
[fragment shader]
float val = 0.0;
void sub() {
for (int i = 0; i < 3; ++i) {
for (int j = 0; j < 3; ++j) {
if (i == 1 && j == 1)
return;
val = 0.5;
}
}
val = 1.0;
}
void main() {
sub();
gl_FragColor = vec4(val);
}
[test]
draw rect -1 -1 2 2
probe all rgb 0.5 0.5 0.5 0.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 Alex Deucher changed: What|Removed |Added Attachment #40698|application/octet-stream|text/plain mime type|| Attachment #40698|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 --- Comment #10 from Jared Clark 2010-12-01 07:55:28 PST --- Sorry I just realized that dmesg I attached didn't have the pertinent failure in it for some reason. I will reproduce and attach a new one that has a different name. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 --- Comment #11 from Jared Clark 2010-12-01 08:02:52 PST --- Created an attachment (id=40705) --> (https://bugs.freedesktop.org/attachment.cgi?id=40705) dmesg - new with the error -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa releases in early January?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/30/2010 06:07 PM, Roland Scheidegger wrote: > Am 30.11.2010 21:23, schrieb Ian Romanick: >> It seems that new development in master has slowed a bit, so how does >> a 7.10 release on January 7th sound? If we're going to do that, >> we'll want to make the 7.10 branch on, say, December 8th. That's >> roughly a week from now. > Don't say development has slowed if I'm just about to merge > gallium-array-textures which likely will cause havoc :-). > Though maybe a week is enough to clean up the mess mostly ;-). That should be fine, though we should get opinions from other stakeholders. Making the branch really just closes the window for major changes like this. Once the branch is created, there will be about month to stabilize before the release. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz2m0UACgkQX1gOwKyEAw8yBgCgmdMj/0m8lMXpqgXOk6NSVRx5 RDoAnitad++BRGv9/crlLCMbr/Lp9thy =tZe7 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 Jared Clark changed: What|Removed |Added Attachment #40705|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 Jared Clark changed: What|Removed |Added Attachment #40699|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Improve ONE_DIV_LN2 and M_PI constants
1/ln(2) is equivalent to log2(e), so define it as such. log2(e) = ln(e)/ln(2) = 1/ln(2) M_PI is updated to add some precision (value found in my math.h header). Signed-off-by: Matt Turner --- src/mesa/main/compiler.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h index 5557a3b..4c52be2 100644 --- a/src/mesa/main/compiler.h +++ b/src/mesa/main/compiler.h @@ -351,7 +351,7 @@ static INLINE GLuint CPU_TO_LE32(GLuint x) #ifndef M_PI -#define M_PI (3.1415926536) +#define M_PI (3.14159265358979323846) #endif #ifndef M_E @@ -363,7 +363,7 @@ static INLINE GLuint CPU_TO_LE32(GLuint x) #endif #ifndef ONE_DIV_LN2 -#define ONE_DIV_LN2 (1.442695040888963456) +#define ONE_DIV_LN2 M_LOG2E #endif #ifndef ONE_DIV_SQRT_LN2 -- 1.7.2.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Improve ONE_DIV_LN2 and M_PI constants
On Wed, Dec 1, 2010 at 10:40 PM, Matt Turner wrote: > 1/ln(2) is equivalent to log2(e), so define it as such. > > log2(e) = ln(e)/ln(2) = 1/ln(2) > > M_PI is updated to add some precision (value found in my math.h header). > > Signed-off-by: Matt Turner > --- > src/mesa/main/compiler.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h > index 5557a3b..4c52be2 100644 > --- a/src/mesa/main/compiler.h > +++ b/src/mesa/main/compiler.h > @@ -351,7 +351,7 @@ static INLINE GLuint CPU_TO_LE32(GLuint x) > > > #ifndef M_PI > -#define M_PI (3.1415926536) > +#define M_PI (3.14159265358979323846) > #endif Erm... just nitpicking... it may be better to define such constants using the C99 hexfloat format (e.g. the format which is generated for printf "%a"). It would avoid two issues: 1. Defining the constants in a base10 floating-point format is never 100% precise if IEEE754-style datatypes are used (which use base2) 2. (Please someone correct me if I am wrong) There is no definition what happens if the constant has more digits than fit into the datatype and the base10--->base2 conversion happens (e.g. what is used first: truncate+convert or convert+truncate). At least 128bit floating-point on SPARC with gcc4.5 and Sun Studio 12.1 deliver different results in the last two bits of the fraction part in some cases for base10 values while delivering identical results when the C99 hexfloat format is used[1]) Above in C99 hexfloat format would be (with more than enougth digits for 128bit IEEE754 floating-point :-) ): #define M_PI (0x3.243F6A8885A308D313198A2E03707344A4093822299F31D0082EFA98EC4Ep+00) [1]=As said, I'm just nitpicking - technically 39 decimal places are enougth to estimate the circumference of any circle that fits in the (observable) universe with precision down to the the radius of an hydrogen atom. Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Improve ONE_DIV_LN2 and M_PI constants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/2010 01:40 PM, Matt Turner wrote: > 1/ln(2) is equivalent to log2(e), so define it as such. > > log2(e) = ln(e)/ln(2) = 1/ln(2) > > M_PI is updated to add some precision (value found in my math.h header). I wish I had noticed this when I added M_LOG2E. It seems better to replace the single use of ONE_DIV_LN2 (in prog_statevars.c) with M_LOG2E. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz22UgACgkQX1gOwKyEAw/N1ACgmWxnoeoUkXBpoMYPZEPgXhTP WpkAoJeTxPT5VGR3mr3mlBGsveS2Dsfc =gjBF -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Improve ONE_DIV_LN2 and M_PI constants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/2010 02:45 PM, Roland Mainz wrote: > On Wed, Dec 1, 2010 at 10:40 PM, Matt Turner wrote: >> 1/ln(2) is equivalent to log2(e), so define it as such. >> >> log2(e) = ln(e)/ln(2) = 1/ln(2) >> >> M_PI is updated to add some precision (value found in my math.h header). >> >> Signed-off-by: Matt Turner >> --- >> src/mesa/main/compiler.h |4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h >> index 5557a3b..4c52be2 100644 >> --- a/src/mesa/main/compiler.h >> +++ b/src/mesa/main/compiler.h >> @@ -351,7 +351,7 @@ static INLINE GLuint CPU_TO_LE32(GLuint x) >> >> >> #ifndef M_PI >> -#define M_PI (3.1415926536) >> +#define M_PI (3.14159265358979323846) >> #endif > > Erm... just nitpicking... it may be better to define such constants > using the C99 hexfloat format (e.g. the format which is generated for > printf "%a"). That is probably true. However, I think the only cases where we need our own definitions of these constants are the same cases where the hexfloat format is not supported. Add it to the long list of useful C99 features that we can't use. :( As far as I'm aware, Visual Studio does not support hexfloat. Nor do the AIX C compiler or the VMS C compiler. I'm sure there are a few other weird C89 compilers that core Mesa intends to support that don't do this feature. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz22bUACgkQX1gOwKyEAw+ZZACdFY4Lxb173BHqYwEEUBaySkdw 8T8AnRy/tnXGRG1CwtI3uYZ75jWDGgHx =qZRk -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Improve ONE_DIV_LN2 and M_PI constants
On Wed, Dec 1, 2010 at 11:24 PM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/01/2010 01:40 PM, Matt Turner wrote: >> 1/ln(2) is equivalent to log2(e), so define it as such. >> >> log2(e) = ln(e)/ln(2) = 1/ln(2) >> >> M_PI is updated to add some precision (value found in my math.h header). > > I wish I had noticed this when I added M_LOG2E. It seems better to > replace the single use of ONE_DIV_LN2 (in prog_statevars.c) with M_LOG2E. Yeah, I wondered if that would be better, but wasn't sure if 1/ln(2) in that particular case contained some semantic meaning. Should I send a new patch to s/ONE_DIV_LN2/M_LOG2E/ and a separate one for the M_PI definition? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31986] matrix operation broken
https://bugs.freedesktop.org/show_bug.cgi?id=31986 Ian Romanick changed: What|Removed |Added Status|NEW |ASSIGNED Component|Mesa core |Drivers/DRI/i965 AssignedTo|mesa-...@lists.freedesktop. |e...@anholt.net |org | --- Comment #3 from Ian Romanick 2010-12-01 15:46:52 PST --- I was only able to reproduce this using the i965 driver. swrast and i915 do not exhibit this failure. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa releases in early January?
On 12/01/2010 12:00 PM, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/30/2010 06:07 PM, Roland Scheidegger wrote: Am 30.11.2010 21:23, schrieb Ian Romanick: It seems that new development in master has slowed a bit, so how does a 7.10 release on January 7th sound? If we're going to do that, we'll want to make the 7.10 branch on, say, December 8th. That's roughly a week from now. Don't say development has slowed if I'm just about to merge gallium-array-textures which likely will cause havoc :-). Though maybe a week is enough to clean up the mess mostly ;-). That should be fine, though we should get opinions from other stakeholders. Making the branch really just closes the window for major changes like this. Once the branch is created, there will be about month to stabilize before the release. I'm OK with this schedule. I've got a few things going on private branches but there's no dependencies. With the holidays coming up there might not be too much going on after the next 2-3 weeks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32030] [i965 oglc gles2c bisected] 4 OpenGL (ES) conformance cases regressed
https://bugs.freedesktop.org/show_bug.cgi?id=32030 Kenneth Graunke changed: What|Removed |Added Component|Drivers/DRI/i965|Mesa core AssignedTo|e...@anholt.net |mesa-...@lists.freedesktop. ||org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] shader inputs vs. system values
I was working on finishing up instanced drawing in Mesa/gallium last week. The one stumbling block was how to handle the instance ID. The instance ID is an integer accessible by the vertex shader that only changes per drawing instance, not per vertex. For that reason it seems a little funny to declare it as a Mesa PROGRAM_INPUT or Gallium TGSI_FILE_INPUT variable. Similarly, there's other shader inputs that don't change per-vertex or per-fragment that perhaps should be "system values" instead. gl_FrontFacing, for example. Here's a list of shader inputs (current and upcoming) that don't fit in with regular attributes like position, texcoords or colors: bool gl_FrontFacing - fragment shader, per triangle int gl_InstanceID - vertex shaders, per instance int gl_PrimitiveIDIn - geom/frag shader input, per primitive int gl_PrimitiveID - geom shader output, per vertex int gl_Layer - geom shader output per vertex, frag shader input per primitive int gl_VertexID - vertex shader input, per vertex int gl_SampleID - fragment shader, per sample vec2 gl_SamplePosition - fragment shader, per sample int gl_ViewportIndex - geom shader output, per vertex (There's more for tessellation, hull and compute shaders) When I prototyped instanceID as a per-vertex input it caused the draw module and softpipe to blow up because it doesn't correspond to a vertex attribute. There seem to be some assumptions in a few places about vertex shader inputs directly corresponding to vertex arrays/ attributes. I think we need to decide which of the above are system values vs. per-vertex/fragment inputs. DX10's system values encompasses the above variables plus others such as clip distance and fragment position, BTW. Zack, I think had started looking at system values about a year ago. What are/were your thoughts on this? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31940] [r300g] Crash in dri2_invalidate_drawable
https://bugs.freedesktop.org/show_bug.cgi?id=31940 --- Comment #8 from Stephen E. Baker 2010-12-01 17:04:45 PST --- Yes, Jakob's patch fixes the issue! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32031] New: loop in function causes assertion
https://bugs.freedesktop.org/show_bug.cgi?id=32031
Summary: loop in function causes assertion
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: major
Priority: medium
Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: jiajia.zh...@intel.com
Below shader causes assertion on Calpella (i965) with mesa master:
shader_runner: loop_analysis.cpp:141: virtual ir_visitor_status
loop_analysis::visit(ir_loop_jump*): Assertion `!this->state.is_empty()'
failed.
Aborted (core dumped)
[require]
GL >= 2.0
GLSL >= 1.10
[vertex shader]
bool myFunc(void)
{
int i;
for(i = 0; i < 2; i++)
{
if(i < 1)
return true;
else
return false;
}
}
void main(void)
{
if (myFunc())
gl_FrontColor = vec4(0.0, 1.0, 0.0, 1.0); // green
else
gl_FrontColor = vec4(1.0, 0.0, 0.0, 1.0); // red
gl_Position = gl_Vertex;
}
[test]
draw rect -1 -1 2 2
probe all rgba 0.0 1.0 0.0 1.0
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32031] loop in function causes assertion
https://bugs.freedesktop.org/show_bug.cgi?id=32031 --- Comment #1 from jiajia 2010-12-01 17:13:33 PST --- Created an attachment (id=40721) --> (https://bugs.freedesktop.org/attachment.cgi?id=40721) attach this shader test case -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31940] [r300g] Crash in dri2_invalidate_drawable
https://bugs.freedesktop.org/show_bug.cgi?id=31940 --- Comment #9 from Jakob Bornecrantz 2010-12-01 17:36:15 PST --- Does it fix it completely? Enabling you to change resolution? Or does the crash just go away? Cheers Jakob. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: raise maximum viewport and texture size to 8192
Looks good to me too. Once you've applied it, I'll bump the driver
limits appropriately for r6xx/7xx/evergreen.
Alex
On Mon, Nov 29, 2010 at 12:00 PM, Marek Olšák wrote:
> FWIW, it looks good to me.
>
> Marek
>
> On Wed, Nov 24, 2010 at 8:18 PM, Brian Paul wrote:
>>
>> On 11/24/2010 12:10 PM, Brian Paul wrote:
>>>
>>> On 11/24/2010 10:20 AM, Brian Paul wrote:
On 11/24/2010 05:23 AM, Marek Olšák wrote:
>
> In order to be able to create and render to textures of size 8192x8192
> on r600 and nv50, including 3D textures like 8192x4x4.
>
> Two new piglit tests have been added to test this: fbo-maxsize and
> tex3d-maxsize.
>
> Driver status:
> swrast passes fbo-maxsize and segfaults in tex3d-maxsize.
> softpipe and r300g pass both.
> (r300g returns GL_OUT_OF_MEMORY in tex3d-maxsize).
>
> Cc: Brian Paul
> Signed-off-by: Marek Olšák
> ---
> src/mesa/main/config.h | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
> index 0f2d1a8..5388069 100644
> --- a/src/mesa/main/config.h
> +++ b/src/mesa/main/config.h
> @@ -98,16 +98,16 @@
> #define MAX_COLOR_TABLE_SIZE 256
>
> /** Number of 1D/2D texture mipmap levels */
> -#define MAX_TEXTURE_LEVELS 13
> +#define MAX_TEXTURE_LEVELS 14
>
> /** Number of 3D texture mipmap levels */
> -#define MAX_3D_TEXTURE_LEVELS 9
> +#define MAX_3D_TEXTURE_LEVELS 14
>
> /** Number of cube texture mipmap levels - GL_ARB_texture_cube_map */
> -#define MAX_CUBE_TEXTURE_LEVELS 13
> +#define MAX_CUBE_TEXTURE_LEVELS 14
>
> /** Maximum rectangular texture size - GL_NV_texture_rectangle */
> -#define MAX_TEXTURE_RECT_SIZE 4096
> +#define MAX_TEXTURE_RECT_SIZE 8192
>
> /** Maximum number of layers in a 1D or 2D array texture -
> GL_MESA_texture_array */
> #define MAX_ARRAY_TEXTURE_LAYERS 64
> @@ -140,11 +140,11 @@
> */
>
> #ifndef MAX_WIDTH
> -# define MAX_WIDTH 4096
> +# define MAX_WIDTH 8192
> #endif
> /** Maximum viewport/image height */
> #ifndef MAX_HEIGHT
> -# define MAX_HEIGHT 4096
> +# define MAX_HEIGHT 8192
> #endif
>
> /** Maxmimum size for CVA. May be overridden by the drivers. */
> @@ -168,7 +168,7 @@
> #define MAX_TEXTURE_MAX_ANISOTROPY 16.0
>
> /** For GL_EXT_texture_lod_bias (typically MAX_TEXTURE_LEVELS - 1) */
> -#define MAX_TEXTURE_LOD_BIAS 12.0
> +#define MAX_TEXTURE_LOD_BIAS 13.0
>
> /** For any program target/extension */
> /*...@{*/
I'm OK w/ increasing the limits but there's a few other issues that need
to be fixed before this patch can be applied. I'm working on it now...
>>>
>>> Here's a more elaborate patch.
>>>
>>> It checks if the memory used by the texture is less than some limit. If
>>> the limit is exceeded, GL_OUT_OF_MEMORY is generated (unless it's a
>>> proxy texture). This lets us advertise GL_MAX_3D_TEXTURE_SIZE to be 8K
>>> (or larger) while preventing actual 8Kx8Kx8K textures but allowing
>>> 8Kx32x16, for example. This could have been implemented in each of the
>>> drivers using the ctx->Driver.TestProxyImage() hook but this patch
>>> avoids all that redundant code.
>>>
>>> I'll leave it up to driver maintainers to set the new
>>> ctx->Const.MaxTextureMBytes field to a reasonable driver. The default is
>>> currently 1GB.
>>>
>>> The max texture size is also bumped up to 16K, Alex.
>>>
>>> Ideally, we should also have a piglit test that exercises rasterization
>>> with the max possible texture/surface size to see if the fixed point
>>> rasterization really falls apart as I fear.
>>>
>>> If there's no comments/concerns I'll commit in a day or two.
>>>
>>> I've also posted a patch to the tex3d-maxsize.c test to the piglit test.
>>
>> Attachment.
>>
>> -Brian
>>
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31940] [r300g] Crash in dri2_invalidate_drawable
https://bugs.freedesktop.org/show_bug.cgi?id=31940 --- Comment #10 from Stephen E. Baker 2010-12-01 18:48:01 PST --- Fixes it completely -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32036] New: OpenVG demos show inadequate CPU usage and memory leak
https://bugs.freedesktop.org/show_bug.cgi?id=32036 Summary: OpenVG demos show inadequate CPU usage and memory leak Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: virtuous...@gmail.com when any of "non-trivial" OpenVG demos from mesa-demos is run, it uses >60% CPU time and also causes 'X' process to use inadequate CPU time. on laptop with RV515 `top` shows: lion -> X~10% demo~80% + constant memory leak ~20MB VIRT/RES per second sp -> X~1% demo~100% text -> X~50% demo~67% it behaves similarly on R770 hardware. all that doesn't make its rendering of vector graphic look GPU-accelerated in any way. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32036] OpenVG demos show inadequate CPU usage and memory leak
https://bugs.freedesktop.org/show_bug.cgi?id=32036 --- Comment #1 from Sergey Kondakov 2010-12-01 19:40:23 PST --- and yeah - mesa, libdrm, xf86-video-ati, mesa-progs are recent git (post-openvg-1.1-merge, anyway); X is 1.9.2.901 (1.9.3 RC 1). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32030] [i965 oglc gles2c bisected] 4 OpenGL (ES) conformance cases regressed
https://bugs.freedesktop.org/show_bug.cgi?id=32030 --- Comment #1 from Gordon Jin 2010-12-01 20:47:32 PST --- *** Bug 32037 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] shader inputs vs. system values
On Wednesday 01 December 2010 19:46:42 Brian Paul wrote: > I was working on finishing up instanced drawing in Mesa/gallium last > week. The one stumbling block was how to handle the instance ID. > > The instance ID is an integer accessible by the vertex shader that > only changes per drawing instance, not per vertex. For that reason it > seems a little funny to declare it as a Mesa PROGRAM_INPUT or Gallium > TGSI_FILE_INPUT variable. > > Similarly, there's other shader inputs that don't change per-vertex or > per-fragment that perhaps should be "system values" instead. > gl_FrontFacing, for example. > > Here's a list of shader inputs (current and upcoming) that don't fit > in with regular attributes like position, texcoords or colors: > > bool gl_FrontFacing - fragment shader, per triangle > int gl_InstanceID - vertex shaders, per instance > int gl_PrimitiveIDIn - geom/frag shader input, per primitive > int gl_PrimitiveID - geom shader output, per vertex > int gl_Layer - geom shader output per vertex, frag shader input per > primitive > int gl_VertexID - vertex shader input, per vertex > int gl_SampleID - fragment shader, per sample > vec2 gl_SamplePosition - fragment shader, per sample > int gl_ViewportIndex - geom shader output, per vertex > > (There's more for tessellation, hull and compute shaders) > > > When I prototyped instanceID as a per-vertex input it caused the draw > module and softpipe to blow up because it doesn't correspond to a > vertex attribute. There seem to be some assumptions in a few places > about vertex shader inputs directly corresponding to vertex arrays/ > attributes. > > I think we need to decide which of the above are system values vs. > per-vertex/fragment inputs. > > DX10's system values encompasses the above variables plus others such > as clip distance and fragment position, BTW. > > Zack, I think had started looking at system values about a year ago. > What are/were your thoughts on this? The conclusion was pretty much exactly as you describe above I ended up adding the TGSI_FILE_SYSTEM_VALUE register for it. The system generated values are fundamentally different to shader inputs and one either needs to special case all of them on a case by case basis (bonkers) or group them all together as a special input type. The latter just makes more sense. In terms of a list of them going with something similar to d3d probably makes sense: http://msdn.microsoft.com/en-us/library/bb509647(VS.85).aspx#System_Value z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
