| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=33386
NOTE: This is a candidate for the 7.9 and 7.10 branches
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=33388
NOTE: This is a candidate for the 7.9 and 7.10 branches.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
This was from way back when glsl2 lived in its own repository.
|
|
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 * ).
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
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>
|
|
Reported by Vinson Lee.
|
|
|
|
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.
|
|
|
|
fixes stellarium text and menu display
|
|
|
|
This reverts commit 88550083b3857184445075e70fed8b2eed4952a1.
|
|
|
|
|
|
|
|
r400 fragment shaders now support up to 64 temporary registers,
512 ALU instructions, and 512 TEX instructions.
|
|
|
|
|
|
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.
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
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.
|
|
The hw can't do it and the code was useless anyway (it's lowered
in the GLSL compiler).
|
|
|
|
|
|
|
|
Fixes negative relative branch offsets.
|
|
|
|
|
|
|
|
|
|
|
|
The rvalue of the returned value can be NULL if the shader says
'return foo();' and foo() is a function that returns void.
Existing GLSL specs do *NOT* say that this is an error. The type of
the return value is void. If the return type of the function is also
void, then this should compile without error. I expect that future
versions of the GLSL spec will fix this (wink, wink, nudge, nudge).
Fixes piglit test glsl-1.10/compiler/expressions/return-01.vert and
bugzilla #33308.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
Before, we were converting between linear/sRGB in glReadPixels,
glDrawPixels, glAccum, etc if the renderbuffer was an sRGB texture.
Those all need to operate on pixel values as-is without conversion.
Also, when setting up render-to-texture, if the texture is sRGB the
pipe_surface view must be linear RGB. This will change when we
support GL_ARB_framebuffer_sRGB.
This fixes http://bugs.freedesktop.org/show_bug.cgi?id=33353
|
|
When we read/write image tiles we need to use the format specified
in the pipe_surface, not the pipe_transfer format (which comes from
the underlying texture/resource format).
This comes up when rendering to sRGB surfaces (via OpenGL render to
texture). Ignoring the new GL_ARB/EXT_framebuffer_sRGB extension
for now, when we render to a sRGB surface we need to treat it like
a regular, linear colorspace RGB surface. Before, when we read/wrote
tiles to sRGB surfaces we were inadvertantly doing the color space
conversion.
|
|
|
|
Implement it in terms of pipe_get_tile_rgba_format()
|
|
The new function, pipe_get_tile_rgba_format(), no longer takes a
swizzle (we weren't actually using it anywhere). Rename it to
indicate that the format is passed explicitly.
|
|
|
|
|
|
|
|
|
