https://bugs.freedesktop.org/show_bug.cgi?id=25994
Eric Anholt changed:
What|Removed |Added
Summary|[GM45][GLSL] 'return' |[GM45][GLSL] 'return'
|s
https://bugs.freedesktop.org/show_bug.cgi?id=29654
Kenneth Graunke changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|mesa-...@l
Xorg, at least, should be able to get by with only rects; just gotta write
the code.
Sending from a mobile, pardon the brevity. ~ C.
On Aug 18, 2010 4:55 PM, "Luca Barbieri" wrote:
> Pushed a new version that had no piglit regressions on nv30, softpipe
> and "softpipe without NPOT".
>
> Vega, Xo
Pushed a new version that had no piglit regressions on nv30, softpipe
and "softpipe without NPOT".
Vega, Xorg, EGL and WGL still require PIPE_CAP_NPOT_TEXTURES to work
properly, but this can be fixed later if desired.
It should hopefully have a decent chance of being correct or nearly so
at least
On Wed, Aug 18, 2010 at 7:03 PM, Luca Barbieri wrote:
>> Couple of minor comments:
>> - You've documented FLEXIBLE_SAMPLING in the main part of the docs, I
>> think I'd prefer to keep forward-looking/todo items separate from the
>> documentation of the interface as it currently stands. Can these
1. Fix the single-threaded p_atomic_cmpxchg to return the
original value, not the current/new value.
2. Fix the single-threaded and Solaris implementations of
p_atomic_dec_zero to return true when the value reaches zero,
not the other way around. (Also edit the assembly-based ones
to be more clear
On Tuesday 17 August 2010 04:27:38 Aras Pranckevicius wrote:
> Hi,
>
> Since commits 2f9ecc818d67 and a433cd286c60 (Add builtins profile for GLSL
> 1.30), GLSL2 does not compile on MSVC 2008:
> builtin_function.cpp(15821) : fatal error C1091: compiler limit: string
> exceeds 65535 bytes in lengt
https://bugs.freedesktop.org/show_bug.cgi?id=29654
Summary: [regression] DynamicBranching3: preprocessor error:
Invalid tokens after #
Product: Mesa
Version: git
Platform: Other
URL: http://www.humus.name/index.php?page=
> Couple of minor comments:
> - You've documented FLEXIBLE_SAMPLING in the main part of the docs, I
> think I'd prefer to keep forward-looking/todo items separate from the
> documentation of the interface as it currently stands. Can these
> paragraphs go in a new section?
The reason is that curre
On Wed, 2010-08-18 at 10:27 -0700, Luca Barbieri wrote:
> I pushed a first version on the gallium-rect-textures branch (not
> tested beyond compilation).
>
> As a consequence of the decisions made in this thread, the interface
> is exactly identical to OpenGL, and internal drawing code works
> exa
Mesa git started failing to configure early this week.
I ran
./autogen.sh \
--with-driver=xlib \
--disable-gallium
and configure complained about missing talloc.
I looked and saw that my fedora 12 machine has libtalloc installed but
libtalloc-devel was not installed, so I installed it.
Tha
I pushed a first version on the gallium-rect-textures branch (not
tested beyond compilation).
As a consequence of the decisions made in this thread, the interface
is exactly identical to OpenGL, and internal drawing code works
exactly as an OpenGL application not requiring
ARB_texture_non_power_of
On 18 aug 2010, at 17.08, Luca Barbieri wrote:
I have a feeling that CL performance will not matter that much for
nvfx and r300, compared to nv50 and r600.
Sure.
The point is that if you can't use normalized coordinates at all on
PIPE_TEXTURE_RECT, you can't implement OpenCL well on nv50 and r6
On Wed, 2010-08-18 at 09:08 -0700, Luca Barbieri wrote:
> > I have a feeling that CL performance will not matter that much for
> > nvfx and r300, compared to nv50 and r600.
>
> Sure.
> The point is that if you can't use normalized coordinates at all on
> PIPE_TEXTURE_RECT, you can't implement Open
> I have a feeling that CL performance will not matter that much for
> nvfx and r300, compared to nv50 and r600.
Sure.
The point is that if you can't use normalized coordinates at all on
PIPE_TEXTURE_RECT, you can't implement OpenCL well on nv50 and r600.
Hence, that should be allowed on OpenCL ca
On Wed, Aug 18, 2010 at 8:50 AM, Luca Barbieri wrote:
>> For instance use 2D/normalized for internal rendering iff the driver
>> advertises CAP_2D_NPOT, otherwise use RECT/non-normalized.
>
> Yes, indeed that makes more sense than adding a new cap for that.
>
>> Hmm - my intention was that TEXTURE
> For instance use 2D/normalized for internal rendering iff the driver
> advertises CAP_2D_NPOT, otherwise use RECT/non-normalized.
Yes, indeed that makes more sense than adding a new cap for that.
> Hmm - my intention was that TEXTURE_RECT implies non-normalized
> coordinates -- so this doesn't
On Wed, 2010-08-18 at 08:01 -0700, Luca Barbieri wrote:
> > I appreciate all the work you've put into looking at alternatives, but
> > at this stage I'm going to be firm - if PIPE_TEXTURE_RECT can be made to
> > work, that's the direction we should be taking. I haven't seen anything
> > so far tha
> I appreciate all the work you've put into looking at alternatives, but
> at this stage I'm going to be firm - if PIPE_TEXTURE_RECT can be made to
> work, that's the direction we should be taking. I haven't seen anything
> so far that suggests it isn't a feasible approach.
Yes, it seems feasible,
https://bugs.freedesktop.org/show_bug.cgi?id=29646
--- Comment #2 from Alban Browaeys 2010-08-18 07:54:17 PDT
---
(In reply to comment #1)
> Created an attachment (id=37952)
--> (https://bugs.freedesktop.org/attachment.cgi?id=37952)
> backtrace of mutter
>
> Also reported in gnome bugzilla :
>
On Tue, 2010-08-17 at 13:16 -0700, Luca Barbieri wrote:
> > Using a flag instead of a new texture target allows to avoid hundreds of
> > changes to existing code, and allows drivers for modern hardware to
> > just ignore this flag.
> I grepped a bit through the code, and a new texture target seems
https://bugs.freedesktop.org/show_bug.cgi?id=29646
--- Comment #1 from Alban Browaeys 2010-08-18 07:35:22 PDT
---
Created an attachment (id=37952)
--> (https://bugs.freedesktop.org/attachment.cgi?id=37952)
backtrace of mutter
Also reported in gnome bugzilla :
https://bugzilla.gnome.org/show_bu
https://bugs.freedesktop.org/show_bug.cgi?id=29646
Summary: baddrawable when resizing a window in
gnome-shell/mutter
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
> Hmm this is indeed rather complicated, though I guess it could work.
A possibly less complicated simplified restatement, from the state
tracker point of view:
- If PIPE_CAP_FLEXIBLE_SAMPLER is supported, you can do anything and
PIPE_RESOURCE_FLAG_TEXTURE_RECT_SEMANTICS is ignored
- If you use PI
On 17.08.2010 21:54, Luca Barbieri wrote:
> Changes in v4:
> - Use a single flag for state tracker -> driver like in v1, but with
> a better name and separated from the other flags
> - Fully clarify semantics of that flag
>
> Changes in v3:
> - Rework to use multiple flags
>
> Changes in v2:
>
https://bugs.freedesktop.org/show_bug.cgi?id=29644
--- Comment #2 from Nicolas Kaiser 2010-08-18 04:40:04 PDT ---
Great, thanks! I just blindly tried to avoid the segfaults.
I tested your patch set, and it fixes the problems at my place.
--
Configure bugmail: https://bugs.freedesktop.org/userp
https://bugs.freedesktop.org/show_bug.cgi?id=29644
--- Comment #1 from Luca Barbieri 2010-08-18 04:18:18
PDT ---
I just sent a patch to Ian Romanick that should fix exactly this.
I think your patch is incorrect, though.
IMHO that line should be:
if (field && (!statevars[i].field || strcmp(stat
https://bugs.freedesktop.org/show_bug.cgi?id=29644
Summary: glsl2 regression: oolite and vegastrike segfault on
initialization
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Again, this is a one-element struct that was incorrectly missing the
field.
---
src/mesa/program/ir_to_mesa.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 825c6f4..d9f431d 100644
--- a/src/mesa/p
This was triggered by the previous bug, but is a separate problem
in the general sense.
---
src/mesa/program/ir_to_mesa.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index 1f3072f..825c6f4 100644
---
According to both GLSL 1.20 and 4.0, these are a struct with one field
called "sceneColor".
Fixes a crash on loading in FlightGear.
---
src/mesa/program/ir_to_mesa.cpp |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir
31 matches
Mail list logo
