-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tom fogal wrote:
> Ian Romanick writes:
>> Brian Paul wrote:
>>> On 10/12/2010 07:49 PM, Ian Romanick wrote:
Brian Paul wrote:
>> -
>> +#include
> Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be
> consistent
Hi,
i crosscompiling Mesa-7.9. if xorg-server-1.9 already installed in
toolchain (headers, libs) and i (re)build Mesa it fails. if i remove the
devel packages from toolchain and build xorg-server again after Mesa it
compiles:
/home/stephan/projects/openelec/build.OpenELEC-ATV.i386.devel/too
Ian Romanick writes:
> Brian Paul wrote:
> > On 10/12/2010 07:49 PM, Ian Romanick wrote:
> >> Brian Paul wrote:
> -
> +#include
> >>>
> >>> Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be
> >>> consistent?
> >>
> >> If possible, I'd prefer not. [. . .]
> >
> > My
On Fri, Oct 15, 2010 at 7:28 AM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brian Paul wrote:
>> On 10/12/2010 07:49 PM, Ian Romanick wrote:
>>> Brian Paul wrote:
> -
> +#include
Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolas Kaiser wrote:
> This patch adds support for the compiler built-in Boolean type
> to GLboolean and the "boolean" type in gallium
> by bringing them in line with the "bool" type in stdbool.h.
>
> Signed-off-by: Nicolas Kaiser
> ---
> include/G
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> On 10/12/2010 07:49 PM, Ian Romanick wrote:
>> Brian Paul wrote:
-
+#include
>>>
>>> Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be
>>> consistent? It wouldn't surprise me if stdbool.h isn't presen
https://bugs.freedesktop.org/show_bug.cgi?id=24226
Nathan Kidd changed:
What|Removed |Added
CC||nat...@hummingbird.com
--
Configure bugma
https://bugs.freedesktop.org/show_bug.cgi?id=24226
--- Comment #18 from Nathan Kidd 2010-10-14 13:52:26
PDT ---
1) To further document "lots of people affected by this" (and I'm well aware I
haven't gotten off my posterior to fix this either):
SuSE brought this up last year[1] and ended up ship
Signed-off-by: Thomas Hellstrom
---
src/mesa/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index c41c38c..7a6936e 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -34,7 +34,7 @@ ES1_CPPFLAGS := -DFEATURE_ES1=1 $(D
https://bugs.freedesktop.org/show_bug.cgi?id=24226
--- Comment #17 from Jeremy Huddleston 2010-10-14
12:46:22 PDT ---
More users are complaining about this... ping...
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 20710, which changed state.
Bug 20710 Summary: YoFrankie (blender open-source project) does not work on
Intel GM965
https://bugs.freedesktop.org/show_bug.cgi?id=20710
What|Old Value |New
https://bugs.freedesktop.org/show_bug.cgi?id=29044
Bug 29044 depends on bug 27143, which changed state.
Bug 27143 Summary: [G45] Yo Frankie: problems with shaders
https://bugs.freedesktop.org/show_bug.cgi?id=27143
What|Old Value |New Value
---
https://bugs.freedesktop.org/show_bug.cgi?id=30124
Bug 30124 depends on bug 27831, which changed state.
Bug 27831 Summary: [regression] DynamicBranching3 does not render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=27831
What|Old Value |New Value
--
On Thu, Oct 14, 2010 at 12:00 PM, Keith Whitwell
wrote:
> Dave,
>
> Sorry for being confusing, but this patch doesn't actually work - this
> is what I think should be happening, but at the moment I have to
> return early to avoid segfaults on unbinding constant buffers, ie:
>
> + if (buffer
This was being classed as unsupported in one place but used in others.
Enabling it seems to work fine.
---
src/gallium/drivers/r600/r600_shader.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600
Dave,
Sorry for being confusing, but this patch doesn't actually work - this
is what I think should be happening, but at the moment I have to
return early to avoid segfaults on unbinding constant buffers, ie:
+ if (buffer == NULL) {
+return;
+}
+else {
Statetrackers can unbind a constant buffer slot by calling
pipe->set_constant_buffer(pipe, shader, slot, NULL)
The driver should unbind the buffer and potentially allow its storage
to be released.
---
src/gallium/drivers/r600/r600_state.c | 20
1 files changed, 16 inser
Tested with demos/pixeltest - line rasterization doesn't seem to be
set up for GL conventions yet, but at least width is respected now.
---
src/gallium/drivers/r600/r600_state.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/sr
Would try to destroy radeon->cman, radeon->kman both which were still
NULL.
---
src/gallium/winsys/r600/drm/r600_drm.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/gallium/winsys/r600/drm/r600_drm.c
b/src/gallium/winsys/r600/drm/r600_drm.c
index 5f175a4.
Guess so. I hadn't noticed that test before.
-Brian
On Thu, Oct 14, 2010 at 9:05 AM, Keith Whitwell
wrote:
> Isn't this a quite similar concept to tests/texfilt?
>
> Keith
>
>
> On Thu, Oct 14, 2010 at 3:55 PM, Brian Paul
> wrote:
>> Module: Demos
>> Branch: master
>> Commit: 4d981d192bcff29f
Isn't this a quite similar concept to tests/texfilt?
Keith
On Thu, Oct 14, 2010 at 3:55 PM, Brian Paul
wrote:
> Module: Demos
> Branch: master
> Commit: 4d981d192bcff29fd85c794415148988518c6eae
> URL:
> http://cgit.freedesktop.org/mesa/demos/commit/?id=4d981d192bcff29fd85c794415148988518c6e
21 matches
Mail list logo
