| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
libraries will be created. They are libGLESv1_CM, libGLESv2, and
libglapi. Last, libGL or opengl32 will link to libglapi. This change
is required as _glapi_* will be declared as __declspec(dllimport) in
libmesa.a on windows. libmesa.a expects those symbols to be defined in
another DLL. Due to this change to GL, GLES support is marked
experimental.
Note that GLES requires libxml2-python to generate some of its sources.
|
|
|
|
| |
So that it can be renamed to _glapi_get_dispatch.
|
| |
|
|
|
|
|
| |
We almost always want to simply steal; we only need to copy when copying
a token list (in which case we're already cloning stuff anyway).
|
|
|
|
| |
These are already picked up by ir.h or glsl_types.h.
|
|
|
|
|
|
| |
The original allocations use regs->regs as the context, so talloc will
happily ignore the context given here. Change it to match to clarify
that it isn't changing.
|
|
|
|
|
|
| |
Improves the cases when:
* an explicit assignment references the read-only variable
* an 'out' or 'inout' function parameter references the read-only variable
|
|
|
|
|
|
|
| |
Fixes Piglit tests:
spec/glsl-1.30/compiler/storage-qualifiers/static-write-centroid-in-01.frag
spec/glsl-1.30/compiler/storage-qualifiers/static-write-in-01.frag
spec/glsl-1.30/compiler/storage-qualifiers/static-write-in-02.frag
|
| |
|
| |
|
|
|
|
|
| |
Even tho st/mesa use user buffers for constants align buffers
other state trackers doesn't use user buffers.
|
| |
|
|
|
|
| |
Also remove unused i915_transfer struct
|
| |
|
| |
|
|
|
|
| |
Add missing evergreen FLT_TO_INT_FLOOR instruction.
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the get/enable enums and internal gl_config storage
for this extension.
In theory this is all that is needed to enable this extension
from what I can see, since its not mandatory to implement the
features if you don't advertise the visuals or the fb configs.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
- since evergreen addition which increased this to 8 depth backends
other bytes may contain garbage values
|
| |
|
|
|
|
| |
...and remove egg from face.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
See http://bugs.freedesktop.org/show_bug.cgi?id=32309
Apparently, malloc() is failing during context creation. Not
checking for nulls here led to crashes elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The loop to choose a pixel format for the window was incrementing
'i' after we succeeded in creating the window so if we chose format[0]
for graw_create_window_and_screen() we were putting format[1] in
the pipe_resource template for creating the render target.
This only worked because of the order of the elements in the formats[]
array.
The graw_xlib.c code now properly compares the requested gallium pixel
format against the visual's color layout.
Update all the graw demos to fix the off-by-one-i error.
|
|
|
|
|
| |
Thanks to all the include frobbing, GLuint is not known in some places
that included enums.h.
|
|
|
|
| |
Remove the redundant public _mesa_prim_name[] array.
|
| |
|
| |
|
| |
|