| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting this flag prevents declarations of uniforms from being removed
from the IR. Since the IR is directly used by several API functions
that query uniforms in shaders, uniform declarations cannot be removed
after the locations have been set. However, it should still be safe
to reorder the declarations (this is not tested).
Signed-off-by: Ian Romanick <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41980
Tested-by: Brian Paul <[email protected]>
Reviewed-by: Bryan Cain <[email protected]>
Cc: Vinson Lee <[email protected]>
Cc: José Fonseca <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Yuanhan Liu <[email protected]>
|
|
|
|
|
|
|
| |
These should be useful for doing transform feedback on Sandybridge.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
These are correct to the best of my knowledge, gleaned from a variety of
internal sources. Sadly, the Sandybridge PRM has incorrect limits.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The inconsistency between vs_max_threads and max_vs_entries was rather
annoying. I could never seem to remember which one was reversed, which
made it harder to find quickly. "Max __ Threads" seems more natural.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the docs for 3DSTATE_PS (Gen7+) and 3DSTATE_WM (Gen6),
there is a platform dependent value for the minimum number of pixel
shader threads. It may also vary based on whether WIZ Hashing is on.
For example, Ivybridge requires at least 4 threads if WIZ hashing is
disabled, and 8 if it's enabled. Programming it to use less threads is
illegal. Sandybridge appears to have similar restrictions.
So on newer platforms, INTEL_DEBUG=sing will probably just hang the GPU.
Rather than try to patch it up for newer platforms and extend it to
support geometry shaders, just remove it as it isn't that useful anyway.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For GL_RGB_SCALE and GL_ALPHA_SCALE targets, the API wrapper code
attempts to ensure the parameter is 1.0, 2.0, or 4.0.
This is unnecessary: set_combiner_scale in texenv.c (called by
_mesa_TexEnvfv) already checks this and raises an appropriate error.
It's also incorrect: For glTexEnvx, the API validation code directly
compares the GLfixed input parameter with a floating point constant,
prior to converting fixed-point to floating point.
Fixes an issue in the OpenGL ES 1.1 conformance suite.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Makes texture_from_pixmap work with non-DRI llvmpipe.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kill the code paths taken when src_mt is null. It is never null, otherwise
there would be a segfault on line 4 of this function:
GLuint width = src_mt->level[level].width;
(Some interleaved lines in the diff make the real diff non-obvious. All
I did was delete some code and then left-shifted what remained to correct
the indentation.)
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
Fixes Coverity resource leak defect.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Fixes Coverity resource leak defect.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Fixes MSVC build.
|
| |
|
| |
|
|
|
|
| |
Also call r600_conv_pipe_prim earlier.
|
| |
|
|
|
|
|
|
| |
Fixes Coverity resource leak defect.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
The kernel currently overwrites the flags, but if we stopped doing that,
this would break badly.
|
|
|
|
|
|
|
|
|
| |
glXMakeCurrent(dpy, None, NULL) would not correctly unbind the context
causing subsequent GLX requests to fail in peculiar ways
http://xquartz.macosforge.org/trac/ticket/514
Signed-off-by: Jeremy Huddleston <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
| |
Fixes Coverity resource leak defect.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A driver trying to set up builtin uniforms is faced with a problem:
How do I walk the ir_variable structure (representing an array of
structs, or array of matrices, or struct, or whatever), and set up
driver structures so that dereference of that uniform gets the
corresponding ParameterValues[] entry. The rule in general is that
each corresponding vector-sized field of an array of structs is one
builtin uniform state slot. i965 relied on another invariant: each
state slot has a number of unique channel swizzles corresponding to
the number of elements in the field's vector, to avoid needing to walk
the glsl_type in parallel to get at vector_elements.
All of the builtin uniforms followed this behavior, except for
gl_NormalMatrix. That's a mat3 (so 3 vec3s), but it was swizzled as 3
vec4s.
Fixes piglit glsl-fs-normalmatrix.
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is the new name for gl_MaxVaryingFloats now that non-float
varyings exist. Fixes piglit
glsl-1.30/execution/maximums/gl_MaxVaryingFloats
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit 3e5d3626, Eric added a homebrew workaround to fix GPU hangs in
the Mesa "engine" demo and oglc's api-texcoord test.
Unfortunately, his PIPE_CONTROL contains a Depth Stall, which
necessitates the post-sync non-zero workaround,
Fixes GPU hangs in Civilization 4, PlaneShift, and 3DMMES.
Hopefully Heroes of Newerth as well, though I haven't tested that.
NOTE: This is candidate for the 7.11 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41096
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-and-tested-by: Eric Anholt <[email protected]>
|
| |
|
| |
|
|
|
|
|
| |
MAX_TEXTURE_2D_LEVELS and MAX_TEXTURE_CUBE_LEVELS are supposed to be
14 not 13, while MAX_TEXTURE_3D_LEVELS should be 12 not 10.
|
| |
|
|
|
|
|
|
|
|
|
| |
I had a colleague hitting issues compiling with an old gcc3.2
system. These patches got them through.
NOTE: This is a candidate for the 7.11 branch.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Use VRAM for static and immutable buffers. This restores the
recently removed r600g winsys behaviour for memory locations.
This also improoves rendering times on the gpu for some
OpenSceneGraph based test cases by about 15%.
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
We can trivially remove the gotos in two places in this code and make
it a bit more readable.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure we do not run into the classic ABA problem on buffer object bind,
reusing this name and may be never rebind since we get an new name
that was just deleted and never rebound in between.
The explicit rebinding to the debault object in the current context
prevents the above in the current context, but another context
sharing the same objects might suffer from this problem.
Minor var renaming and comments edited by Brian.
Signed-off-by: Mathias Fröhlich <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Buffer objects may be shared across contexts.
Rework the array attrib push/pop implementation
to be thread safe. Make use of more library functions
for this purpose.
Signed-off-by: Mathias Fröhlich <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
This was dead code anyway.
|
|
|
|
| |
We'll use this soon.
|
|
|
|
|
| |
The views (sampler views and surfaces) are great tools for changing resource
properties without having to change pipe_resource.
|
| |
|
| |
|
| |
|
|
|
|
| |
Failed when exercising i965 swrast fallback rendering.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past, swrast_texture_image::Data has been overloaded. It could
either point to malloc'd memory storing texture data, or it could point
to a current mapping of GPU memory.
Now, Buffer always points to malloc'd memory (if we're not using GPU
memory) and Data always points to mapped memory. The next step would
be to rename Data -> Map.
This change also involves adding swrast functions for mapping textures
and renderbuffers prior to rendering to setup the Data pointer. Plus,
corresponding functions to unmap texures and renderbuffers. This is
very much like similar code in the dri drivers.
|
|
|
|
| |
Core Mesa no longer does any texture memory allocation.
|
|
|
|
|
|
| |
Only swrast and the drivers that fall back to swrast need these fields now.
This removes the last of the fields related to software rendering from
gl_texture_image.
|
|
|
|
|
|
|
| |
In lp_build_stencil_op() the incoming 'stencil' var is a 2-element array.
There's a front-face writemask and a back-face writemask but we're ignoring
the later. This patch doesn't fix anything but at least points out the
problem.
|
|
|
|
|
| |
Compare 'front_facing' to NULL to make it more obvious that front_facing
is a pointer and not a simple boolean value.
|
| |
|