Changes in v2:
- Add a much longer and better comment
This allows the OpenGL state tracker to inform the driver that we
are using GL_TEXTURE_RECTANGLE as opposed to GL_TEXTURE_2D.
---
src/gallium/include/pipe/p_defines.h | 26 ++
1 files changed, 26 insertions(+), 0 dele
Changes in v2:
- u_blit no longer sets the unnormalized hint flag for NPOT textures:
the driver should do that if it wants to
Currently Gallium internals always use normalized coordinates to
access textures.
However, for NPOT textures on hardware without ARB_texture_non_power_of_two
support (e.
Changes in v2:
- compress_with_blit no longer sets the unnormalized hint flag for NPOT
textures: the driver should do that if it wants to
Allow to pass flags to st_texture_create and take advantage of that
to tell the pipe driver that a texture is going to be used with unnormalized
coordinates.
Changes:
- Add a much longer and better comment for the flag
- u_blit no longer sets the unnormalized hint flag for NPOT textures:
the driver should do that if it wants to
This is a revised version of this patchset.
The change is that the driver is now expected to set or clear the
flag if it pr
Dan Nicholson writes:
[snip]
> So, sorry for not reading the whole thread, but is GL being linked
> because it's needed by the app, because pkg-config said so, or
> because the linker added it?
It's needed by the app. Not really, it's not used at runtime, but
needed at link time because the app
[Apparently bri...@kemper.freedesktop.org is forwarded to
brian.p...@tungstengraphics.com, which is no longer valid.]
I'd suggest to put it in struct pipe_index_buffer.
The argument is that the index buffer needs to be prepared
specifically for the primitive restart enable setting:
1. If the
> gallium: re-implement primitive restart through pipe_draw_info struct
>
> This is better than the previous pipe_context::primitive_restart() method
> but it's still open for discussion.
I'd suggest to put it in struct pipe_index_buffer.
The argument is that the index buffer needs to be
Corrected.
I rescaned the whole code and tried to perform more aggressive checks.
I rerun all the tests, warsow and nexuiz.
Please find the updated patch attached.
Cheers,
Ben
From: Brian Paul [brian.e.p...@gmail.com]
Sent: Wednesday, August 11, 2010 7:3
On Fri, Aug 6, 2010 at 2:20 PM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>> On 08/06/2010 03:15 PM, tom fogal wrote:
>> > If you could build VTK with just a single GL library -- i.e. with
>> > just libOSMesa or just libGL, but not both -- and could reproduce
>> > the crash,= that would rule ou
On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri wrote:
> > Because all nvidia hardware seems to have the normalized bit as a
> property
> > of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
> ATI
> > hardware has the normalized bit as part of the texture instruction (it's
> a
On Wed, Aug 11, 2010 at 7:12 PM, Brian Paul wrote:
> I'm just reviewing the patch again and doing some testing. I'll
> probably commit it soon. Thanks.
I found a problem. I was going through the code and added a few new
assertions. At line 526 or so we use the loop counter 'arg' after the
loo
I'm just reviewing the patch again and doing some testing. I'll
probably commit it soon. Thanks.
-Brian
On Wed, Aug 11, 2010 at 5:19 PM, Segovia, Benjamin
wrote:
> Hello all,
> is there actually any issue with the patch for the commit?
> Cheers,
> Ben
>
___
On Wed, Aug 11, 2010 at 6:06 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ian Romanick wrote:
>> Brian Paul wrote:
>>> It looks like function prototypes aren't handled properly.
>>
>>> I've added a new piglit test for this:
>>
>>> $ bin/shader_runner tests/shaders/
On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca wrote:
> On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> José Fonseca wrote:
>> > Could then Aras Pranckevicius's talloc port to windows be merged into
>> > glsl2 branch before glsl2 is m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
> Brian Paul wrote:
>> It looks like function prototypes aren't handled properly.
>
>> I've added a new piglit test for this:
>
>> $ bin/shader_runner tests/shaders/glsl-function-prototype.shader_test -auto
>
>> GLSL2 error: 0:3(
https://bugs.freedesktop.org/show_bug.cgi?id=29519
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wed, 2010-08-11 at 13:18 -0700, Aras Pranckevicius wrote:
> > Could then Aras Pranckevicius's talloc port to windows be
> merged into
> > glsl2 branch before glsl2 is merged into master?
>
>
> I think we learned our lesson with GLEW. Trying to k
On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> José Fonseca wrote:
> > Could then Aras Pranckevicius's talloc port to windows be merged into
> > glsl2 branch before glsl2 is merged into master?
>
> I think we learned our lesson with GL
Hello all,
is there actually any issue with the patch for the commit?
Cheers,
Ben
From: Segovia, Benjamin
Sent: Tuesday, July 27, 2010 7:11 PM
To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org
Subject: RE: [PATCH] Mesa prog_optimize.c: better optimizati
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
>
> It looks like function prototypes aren't handled properly.
>
> I've added a new piglit test for this:
>
> $ bin/shader_runner tests/shaders/glsl-function-prototype.shader_test -auto
>
> GLSL2 error: 0:3(1): error: empty declar
https://bugs.freedesktop.org/show_bug.cgi?id=29520
Ian Romanick changed:
What|Removed |Added
AssignedTo|mesa-...@lists.freedesktop. |i...@freedesktop.org
|o
https://bugs.freedesktop.org/show_bug.cgi?id=29520
Summary: [glsl2] piglit test glsl-function-prototype fails
Product: Mesa
Version: git
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=29519
Summary: [glsl2] Compiler should generate better diagnostics
for use of reserved words
Product: Mesa
Version: git
Platform: All
OS/Version: All
Status: NEW
On Wed, Aug 11, 2010 at 6:34 PM, Marek Olšák wrote:
> On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri
> wrote:
>>
>> > Because all nvidia hardware seems to have the normalized bit as a
>> > property
>> > of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
>> > ATI
>> > hardwar
On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri wrote:
> > Because all nvidia hardware seems to have the normalized bit as a
> property
> > of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
> ATI
> > hardware has the normalized bit as part of the texture instruction (it's
> a
On Wed, Aug 11, 2010 at 1:07 PM, Luca Barbieri wrote:
>> Because all nvidia hardware seems to have the normalized bit as a property
>> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all ATI
>> hardware has the normalized bit as part of the texture instruction (it's a
>> shader
It looks like function prototypes aren't handled properly.
I've added a new piglit test for this:
$ bin/shader_runner tests/shaders/glsl-function-prototype.shader_test
-auto
GLSL2 error: 0:3(1): error: empty declaration list
Failed to compile FS: 0:3(1): error: empty declaration list
PIGLI
Sorry, i missed much more places where GLSL compiler check and define
functions ... patch in this mail still not correct, may be just duplicating
entries in slang/library/*.gc was not good idea at all .
currently array demo dies with
Error: problem compiling shader: Error: undeclared typ
"Kevin H. Hobbs" writes:
> When I do :
>
> ./autogen.sh --with-driver=xlib --disable-gallium --enable-debug
>
> I get for example :
>
> $ nm lib/libGL.so | grep glDepthFunc
> 0020ce30 T glDepthFunc
> $ nm lib/libOSMesa.so | grep glDepthFunc
> 001ca760 T glDepthFunc
>
> As I und
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin H. Hobbs wrote:
> How is symbol visibility set up in mesa's shared objects?
>
> When I do :
>
> ./autogen.sh --with-driver=xlib --disable-gallium --enable-debug
>
> I get for example :
>
> $ nm lib/libGL.so | grep glDepthFunc
> 0020ce
On 10-08-11 03:40 PM, Ian Romanick wrote:
I think you overlooked the first error message: "Could not implicitly
convert operands to arithmetic operator" :) We've tried to prevent
cascading error messages, but some cases still slip through. The second
message happens because the type of the expr
>
> > Could then Aras Pranckevicius's talloc port to windows be merged into
> > glsl2 branch before glsl2 is merged into master?
>
> I think we learned our lesson with GLEW. Trying to keep a copy of an
> external dependency in our tree only leads to sadness. I have no
> intention to repeat that m
> Because all nvidia hardware seems to have the normalized bit as a property
> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all ATI
> hardware has the normalized bit as part of the texture instruction (it's a
> shader state, so a driver looks for TGSI_TEXTURE_RECT), I believe
How is symbol visibility set up in mesa's shared objects?
When I do :
./autogen.sh --with-driver=xlib --disable-gallium --enable-debug
I get for example :
$ nm lib/libGL.so | grep glDepthFunc
0020ce30 T glDepthFunc
$ nm lib/libOSMesa.so | grep glDepthFunc
001ca760 T glDepthFunc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
José Fonseca wrote:
> Could then Aras Pranckevicius's talloc port to windows be merged into
> glsl2 branch before glsl2 is merged into master?
I think we learned our lesson with GLEW. Trying to keep a copy of an
external dependency in our tree only l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Jones wrote:
> On 10-08-11 02:23 PM, Kenneth Graunke wrote:
>> On Wednesday 11 August 2010 10:13:13 Thomas Jones wrote:
>>
>>> This shader does
>>>
>> not compile with glsl2 and did with the old one
>>
>>> #version 110
>>> void
>>>
On Wed, Aug 11, 2010 at 8:34 PM, Luca Barbieri wrote:
> > I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning
> that
> > all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
> > unnormalized coordinates. However if a texture is NPOT as in OpenGL,
> meaning
>
On Wed, Aug 11, 2010 at 9:29 PM, nobled wrote:
> (this patch doesn't compile without the "st/dri: include xmlconfig.h"
> patch first:)
> http://lists.freedesktop.org/archives/mesa-dev/2010-August/001833.html
> http://github.com/nobled/mesa/commits/drisw
> ---
> Factor out the TexBuffer extension i
> With nv50 and nvc0 (Fermi), coordinate normalization is still part of
> the resource and not the sampler state. Even though the hardware does
> support mix and match of samplers and images, this normalization bit
> trashes the orthogonality/elegance.
Oh right, it's strange they didn't fix that i
On 10-08-11 02:23 PM, Kenneth Graunke wrote:
On Wednesday 11 August 2010 10:13:13 Thomas Jones wrote:
This shader does
not compile with glsl2 and did with the old one
#version 110
void
main() {
gl_TexCoord[1] = gl_MultiTexCoord0*2-1;
gl_Position =
g
On 08/11/2010 08:34 PM, Luca Barbieri wrote:
>> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning that
>> all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
>> unnormalized coordinates
...
>
>> Some time ago I think Brian suggested to add PIPE_TEXTURE_RE
> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning that
> all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
> unnormalized coordinates. However if a texture is NPOT as in OpenGL, meaning
> that all shaders use the TGSI_TEXTURE_2D sampler type, we should
(this patch doesn't compile without the "st/dri: include xmlconfig.h"
patch first:)
http://lists.freedesktop.org/archives/mesa-dev/2010-August/001833.html
http://github.com/nobled/mesa/commits/drisw
---
Factor out the TexBuffer extension into a common file and share it
between dri2 and drisw.
This
Next version, with changes for src/glsl/cl/sl_cl_parse.c
diff --git a/src/glsl/cl/sl_cl_parse.c b/src/glsl/cl/sl_cl_parse.c
index 09456f5..8bd448b 100644
--- a/src/glsl/cl/sl_cl_parse.c
+++ b/src/glsl/cl/sl_cl_parse.c
@@ -154,18 +154,21 @@
#define TYPE_SPECIFIER_TYPENAME25
On Wednesday 11 August 2010 10:13:13 Thomas Jones wrote:
> This shader does
not compile with glsl2 and did with the old one
>
> #version 110
> void
main() {
> gl_TexCoord[1] = gl_MultiTexCoord0*2-1;
> gl_Position =
gl_Vertex;
> }
>
> The compiler gives the message:
>
> 0:5(38): error:
On Wed, 2010-08-11 at 10:44 -0700, Marek Olšák wrote:
> I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning
> that all shaders use the TGSI_TEXTURE_RECT sampler type, it makes
> sense to use unnormalized coordinates. However if a texture is NPOT as
> in OpenGL, meaning that all s
I agree that if a texture was created as GL_TEXTURE_RECTANGLE, meaning that
all shaders use the TGSI_TEXTURE_RECT sampler type, it makes sense to use
unnormalized coordinates. However if a texture is NPOT as in OpenGL, meaning
that all shaders use the TGSI_TEXTURE_2D sampler type, we shouldn't forc
This shader does not compile with glsl2 and did with the old one
#version 110
void main() {
gl_TexCoord[1] = gl_MultiTexCoord0*2-1;
gl_Position = gl_Vertex;
}
The compiler gives the message:
0:5(38): error: Could not implicitly convert operands to arithmetic operator
0:5(40): error: Ope
> It might even be a good idea to split it in two flags, one for state
> tracker->driver communication, and another for the driver->state
> tracker.
> This way, r300g won't have to do anything.
On second thought, maybe not, since the normal thing is for the
driver to accept the state tracker's dem
On 11.08.2010 18:20, Luca Barbieri wrote:
>> Assert failures mean something that developers didn't anticipate to
>> happen did happen. But release code should still continue past the
>> assert and do something sensible like ignoring. That is, it should be
>> resilient against the unexpected. At lea
> I am not sure if the following is legal, but I think we will just mask this
> unnormalized flag out in resource_create, because r300 doesn't like (read:
> doesn't support in hardware) unnormalized texture coordinates, and switching
> shaders just because of the flag is silly.
Hmm I thought it su
> Assert failures mean something that developers didn't anticipate to
> happen did happen. But release code should still continue past the
> assert and do something sensible like ignoring. That is, it should be
> resilient against the unexpected. At least this is my perspective.
Note however that
On Wed, Aug 11, 2010 at 5:41 PM, Luca Barbieri wrote:
> > I'm completely okay with this iteration of this patchset, since it
> > requires no Gallium API changes and seems very straightforward. I do
> > have a question, though, since I'm so unfamiliar with nvfx. In r300g
> > there is a fragment pro
On Wed, 2010-08-11 at 07:59 -0700, Luca Barbieri wrote:
> I assumed that the fact it would crash on a debug build would make the
> behavior safe to change.
> Even if it doesn't crash, it is anyway working incorrectly.
Assert failures mean something that developers didn't anticipate to
happen did h
> I'm completely okay with this iteration of this patchset, since it
> requires no Gallium API changes and seems very straightforward. I do
> have a question, though, since I'm so unfamiliar with nvfx. In r300g
> there is a fragment program rewrite to normalize texcoords
> unconditionally for r300
On 08/10/2010 12:11 PM, randrianas...@gmail.com wrote:
Hello all!
Today i dived into GLSL for first time, so sorry if i write something stupid.
One user at #radeon (nick) asked why some shade doesn't work.
Here is link to vertex shader as i saw it today:
http://mapserver.flightgear.org/git
On Wed, Aug 11, 2010 at 4:44 AM, Luca Barbieri wrote:
> Currently Gallium doesn't know about GL_TEXTURE_RECTANGLE textures, except
> for the normalized coordinates bit in the sampler state.
> Also, internal code always use normalized coordinates.
>
> This works fine on new hardware, but on older h
On Tue, 2010-08-10 at 12:43 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Keith Whitwell wrote:
> > On Mon, 2010-08-09 at 23:48 -0700, Eric Anholt wrote:
> >> The previous compiler called _mesa_remove_output_reads unconditionally,
> >> while the new compiler does
In the nv30/nv40 (and probably nv50) case, it should simply be faster
to not ask the hardware to fetch a vertex repeatedly, even though the
hardware can do it.
Knowing this in the vertex element CSO allows to do things very
nicely, and in particular
setup a single instance of translate in the vert
I assumed that the fact it would crash on a debug build would make the
behavior safe to change.
Even if it doesn't crash, it is anyway working incorrectly.
I'll revert it until further notice.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
My preference for these constant elements would be to actually turn them
into constants, ie. bind the buffer as a constant buffer (rather than a
vertex buffer) and have the shader refer to them as CONST[], rather than
INPUT[].
This is based on a few considerations, but primarily a recognition that
Note that assert(0) != crash. In a release build the previous code would
never crash, but simply ignore. Now it will crash.
Did you went through all callers of translate_create() and made sure
they cope with a NULL return value? It doesn't look so. Until then I'd
rather see this patch reverted.
J
On 08/10/2010 04:44 PM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>>
>> VTK_USE_X:BOOL=ON is set the test segfaults.
>
> What does VTK_USE_X change/end up doing?
>
Most of the action seems to happen in Rendering/CMakeLists.txt where on
linux with VTK_USE_X=ON :
vtkXGPUInfoList.cxx is added
Currently constant elements are specified only with stride = 0.
However, drivers often need to know whether an element is constant
or not when setting up the vertex element CSO instead of when setting
the buffers.
Hence, in addition to stride = 0, also set instance_divisor = ~0 in
the vertex elem
On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote:
> One of the items on the TODO list is proper support for GLSL ES. That
> work won't happen until the last couple weeks of August, so I don't
> think any sort of ES testing is suitable merge criteria. Unless, of
> course, the tests in questi
On Wed, 2010-08-11 at 04:47 -0700, Luca Barbieri wrote:
> util_framebuffer_copy was attempting to copy all elements of the
> source framebuffer state.
>
> However, this breaks if the user does not zero initialize the structure.
> Instead, only copy the elements up to nr_cbufs, and clear elements u
The u_blitter part is OK with me.
-Marek
On Wed, Aug 11, 2010 at 1:44 PM, Luca Barbieri wrote:
> Currently Gallium internals always use normalized coordinates to
> access textures.
>
> However, for NPOT textures on hardware without ARB_texture_non_power_of_two
> support (e.g. nv30) this can trig
util_framebuffer_copy was attempting to copy all elements of the
source framebuffer state.
However, this breaks if the user does not zero initialize the structure.
Instead, only copy the elements up to nr_cbufs, and clear elements up
to dst->nr_cbufs, if the destination was larger than the source.
Allow to pass flags to st_texture_create and take advantage of that
to tell the pipe driver that a texture is going to be used with unnormalized
coordinates.
This is useful for hardware with no mipmapped NPOT support that needs to
allocate texture rectangles in a special way (e.g. nv30).
---
src/
Currently Gallium internals always use normalized coordinates to
access textures.
However, for NPOT textures on hardware without ARB_texture_non_power_of_two
support (e.g. nv30) this can trigger a software fallback or even not be
supported at all.
Hence, this change adds support for both kinds of
This allows the OpenGL state tracker to inform the driver that we
are using GL_TEXTURE_RECTANGLE as opposed to GL_TEXTURE_2D.
---
src/gallium/include/pipe/p_defines.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/i
Currently Gallium doesn't know about GL_TEXTURE_RECTANGLE textures, except
for the normalized coordinates bit in the sampler state.
Also, internal code always use normalized coordinates.
This works fine on new hardware, but on older hardware like nv30, coordinate
normalization is coupled to the re
On Tue, 2010-08-10 at 22:57 -0700, Aras Pranckevicius wrote:
> > No, it's missing most of the API that talloc provides.
> Also,
> > http://github.com/aras-p/glsl-optimizer/ ported it to
> windows.
> Could then Aras Pranckevicius's talloc port to windows be
>
Only compile-tested ... But i'm on the right track?
diff --git a/src/mesa/slang/slang_typeinfo.c b/src/mesa/slang/slang_typeinfo.c
index d039a12..eccd29f 100644
--- a/src/mesa/slang/slang_typeinfo.c
+++ b/src/mesa/slang/slang_typeinfo.c
@@ -187,8 +187,11 @@ static const type_specifier_type_name typ
Hello all!
Today i dived into GLSL for first time, so sorry if i write something stupid.
One user at #radeon (nick ) asked why some shade doesn't work.
Here is link to vertex shader as i saw it today:
http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob;f=Shaders/3dcloud.vert;h=1356
75 matches
Mail list logo
