On Tue, May 31, 2011 at 4:06 PM, Chad Versace wrote:
> On 05/31/2011 11:41 AM, Marek Olšák wrote:
>
> Immediately after the last hunk,
>
>> @@ -2237,6 +2257,10 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
>> target, GLenum attachment,
>> _mesa_error(ctx, GL_INVALID_ENUM,
>>
On 05/31/2011 11:41 AM, Marek Olšák wrote:
Immediately after the last hunk,
> @@ -2237,6 +2257,10 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
> target, GLenum attachment,
> _mesa_error(ctx, GL_INVALID_ENUM,
> "glGetFramebufferAttachmentParameterivEXT(pn
https://bugs.freedesktop.org/show_bug.cgi?id=36238
--- Comment #6 from José Fonseca 2011-05-31 12:31:36 PDT
---
Probably it's missing the include/c99/* files.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
https://bugs.freedesktop.org/show_bug.cgi?id=36238
--- Comment #5 from Anthony Berent 2011-05-31 12:25:30
PDT ---
Created an attachment (id=47407)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47407)
Build log showing the stdbool.h problem.
--
Configure bugmail: https://bugs.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=36238
--- Comment #4 from Anthony Berent 2011-05-31 12:24:08
PDT ---
Unfortunately it doesn't compile on my Windows machine using VC++ 2010. The
problem seems to be that it can't find stdbool.h.
I will attach a log file
- Anthony
--
Configure bug
OpenGL 4.0 Compatibility, page 449:
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, no
framebuffer is bound to target. In this case querying pname FRAMEBUFFER_-
ATTACHMENT_OBJECT_NAME will return zero, and all other queries will generate
an INVALID_OPERATION error.
---
src/mesa/main/f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For 2/18, 3/18, 6/18, 7/18, 9/18, 10/18, 11/18, 12/18, 13/18, 14/18, and
15/18:
Reviewed-by: Ian Romanick
However, it might be better to split the brw_defines.h and
brw_wm_surface_state.c changes in 9/18. We could end up cherry picking
some other p
From: Nathan Kidd
glx code hasn't lived under xserver/GL for a long time now.
Signed-off-by: Nathan Kidd
---
src/mapi/glapi/gen/Makefile |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/mapi/glapi/gen/Makefile b/src/mapi/glapi/gen/Makefile
index 87b928c..c3829d
I couldn't find this being required by the spec.
---
src/mesa/main/shaderapi.c |2 ++
src/mesa/main/uniforms.c |4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 1e237a9..cbfbac8 100644
--- a/src/mesa/main/sh
2011/5/31 Marek Olšák :
> I think there are some IP conflicts among gpu vendors regarding
> anisotropic filtering. That's why there is no core support for it in
> OpenGL and that's why anisotropic filtering is undocumented in all the
> AMD docs. Try to search the code, some ANISO registers have bee
I think there are some IP conflicts among gpu vendors regarding
anisotropic filtering. That's why there is no core support for it in
OpenGL and that's why anisotropic filtering is undocumented in all the
AMD docs. Try to search the code, some ANISO registers have been
figured out, like S_03C000_ANI
Hello, I was studying the anisotropic filtering patch that was posted
on this list the 6th of May in order to understand better how the
r600g drivers work, but while reading the patch I noticed that the
documentation about r600 I have seems to miss some key information.
First of all the documentat
12 matches
Mail list logo
