The set of internalFormat parameters accepted by glRenderBufferStorage
depends on the EXT vs. ARB version of framebuffer_object. The later
added support for GL_ALPHA, GL_LUMINANCE, etc. formats. Note that
these formats might be legal but might not be supported. That should
be checked with glCheckFramebufferStatus().
This reverts commit 65c41d55a0.
There really are quite a few differences in the set of internal
formats allowed by glTexImage and glRenderbufferStorage.
Per the spec, all OpenVG handles are 32-bit. We can't just cast them
to/from integers on 64-bit systems.
Start fixing that mess by introducing a set of handle/pointer conversion
functions in handle.h. The next step is to implement a handle/pointer
hash table...
We were sending too long requests for GLXChangeDrawableAttributes,
GLXGetDrawableAttributes, GLXDestroyPixmap and GLXDestroyWindow.
NOTE: This is a candidate for the 7.9 and 7.10 branches
Signed-off-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Brian Paul <brianp@vmware.com>
FLT_TO_INT is a vector instruction, despite what the (current) documentation
says. FLT_TO_INT_FLOOR and FLT_TO_INT_RPI aren't explicitly mentioned in the
documentation, but those are vector instructions too.
largely a merge of the previously discussed origin/gallium-resource-sampling
but updated.
the idea is to allow arbitrary binding of resources, the way opencl, new gl
versions and dx10+ require, i.e.
DCL RES[0], 2D, FLOAT
LOAD DST[0], SRC[0], RES[0]
SAMPLE DST[0], SRC[0], RES[0], SAMP[0]
Contrary what the name may suggest, LLVM's opaque types are used for
recursive types -- types whose definition refers itself -- so opaque
types correspond to pre-declaring a structure in C. E.g.:
struct node;
struct link {
....
struct node *next;
};
struct node {
struct link link;
}
Void pointers are also disallowed by LLVM. So the suggested way of creating
what's commonly referred as "opaque pointers" is using byte pointer (i.e.,
uint8_t * ).
Fixes the build when selecting driver=osmesa and building static libraries.
Otherwise, mklib tries to add the ‘-ltalloc’ object to the archive, which
obviously fails.
Clients which statically link to osmesa will need to link to libtalloc also,
as specified in the Libs.private of osmesa.pc.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=33360
NOTE: This is a candidate for the 7.10 branch.
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
I couldn't make it work.
GB_TILE_CONFIG.Z_EXTENDED, which enables per-pixel Z clamping, and
VAP_CLIP_CNTL.CLIP_DISABLE, which disables clipping, do help, but they
also add regressions like random graphics corruptions in some games.
But we have to cheat and peek at the GENERIC semantic indices the
state tracker uses for TEXn.
Only outputs from 0x300 to 0x37c can be replaced, and so we have to
know on shader compilation which ones to put there in order to keep
doing separate shader objects properly.
At some point I'll probably create a patch that makes gallium not
force us to discard the information about what is a TexCoord.
The _NEW_ACCUM flag was only set when changing the accumulation
buffer clear color and never used anywhere. Reclaim that dirty bit.
Clean up the definitions of the other dirty bit flags.
Only a few texture object parameters can effect texture completeness:
min level, max level, minification filter. Don't mark the texture
incomplete for other texture object state changes.
We are not required to do the linear->sRGB conversion if ARB_framebuffer_sRGB
is unsupported. However I think the conversion should work in hw except
for blending, which matches the D3D9 behavior.
