It is possible for ctx->DrawBuffer to be NULL, so don't fault when
that happens. This change is not being committed to master because it
doesn't appear to be necessary there.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Handle the loader returning a fake front-buffer. Since the driver
never specifically requests a fake front-buffer, the driver assumes
that it will never receive both a fake and a real front-buffer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
(cherry picked from commit 6a6e478e55)
Assume that the front-buffer exists even if the server didn't tell the
client that it exists.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
(cherry picked from commit e6386e0d9a)
Track two flags: whether or not front-buffer rendering is currently
enabled and whether or not front-buffer rendering has been enabled
since the last glFlush. If the second flag is set, the front-buffer
is flushed via a loader call back. If the first flag is cleared, the
second flag is cleared at this time.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
(cherry picked from commit 43cf0d1eeb)
Need to clamp default point size to min/max range before checking if it's one.
Fixes glean pointAtten test.
(cherry picked from master, commit 228f20e324)
If _math_matrix_analyse() got called before we allocated the inverse
matrix array we could lose the flag indicating that we needed to compute
the inverse. This could happen with certain vertex shader cases.
(cherry picked from master, commit ce461ffc5a)
premature return in TexParameterf caused mesa to never call Driver.TexParameter
breaking drivers relying on this (fix bug #20966).
While here, also fix using ctx->ErrorValue when deciding to call
Driver.TexParameter. Errors are sticky and uncleared errors thus would cause
this to no longer get called. Since we thus need return value of
set_tex_parameter[if] can also optimize this to only call when value changed.
The 'dots' register wasn't getting properly un-negated and un-swizzled
after emitting the code for back-face lighting. So, if more than one
light source was enabled, the specular exponent for the next light source
was wrong.
During execution we were evaluating pow(x, y) where y was negative instead
of positive. This led to the outcome being zero or NaN.
This fixes the occasional black triangles seen in isosurf when hacked to
enable two-sided lighting.
(cherry picked from master, commit 919f57078b)
This lets swrast produce an fbconfig suitable for the root visual now that
the server's not allowing mismatched fbconfigs.
(cherry picked from commit 529d1d720e)
This also cuts instructions by just using the existing bit in the payload
rather than computing it from the determinant in the SF unit and passing it
as a varying down to the WM. Something still goes wrong with getting the
backface color right, but a simpler shader appears to get the right result.
(cherry picked from commit 699db6d842)
Previously, we would sample (f,glFrontFacing,undef,undef) instead of the
(f,0,0,1) that fragment.fogcoord is supposed to return. Due to
glFrontFacing's presence in FOGC.y, we'll still give bad results there when
glFrontFacing is used.
Bug #19122, piglit testcase fp-fog.
(cherry picked from commit 411d913cce)
Move flags for linking standard C/C++ libraries from configure.ac to mklib
Use -norunpath flag when linking with Sun C++ compiler
Convert mklib -exports list into a linker mapfile
Set FINAL_LIBS correctly when -noprefix is used
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
This scheme breaks when the display connection doesn't receive ConfigureNotify
events. This caused reporoducible problems (cropped / misplaced output) when
starting a 3D application in a guest operating system in VMware Workstation.
This reverts commit dd1c68f151.
Conflicts:
src/glx/x11/dri2_glx.c
(cherry picked from commit 11da7e02aa)
Turns out that XXX comment was important. We weren't flagging the WM to
re-update with the statistics enable, so we got zeroes out of our query.
Bug #20740, fixes piglit occlusion_query test.
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit c0d6e07909)
Avoid a little bit of unneeded state validation and fixes a bug where the
texture complete flags was set to false, but we didn't signal _NEW_TEXTURE.
Fixes piglit tex1d-2dborder failure.
(cherry picked from commit aad3f546a0)
The polygon stipple pattern, like the viewport and the
polygon face orientation, must be inverted on the i965
when rendering to a FBO (which itself has an inverted pixel
coordinate system compared to raw Mesa).
In addition, the polygon stipple offset, which orients
the stipple to the window system, disappears when rendering
to an FBO (because the window system offset doesn't apply,
and there's no associated FBO offset).
With these fixes, the conform triangle and polygon stipple
tests pass when rendering to texture.
(cherry picked from commit 29309b45b0)
In the i965, the FBO coordinate system is inverted from the standard
OpenGL/Mesa coordinate system; that means that the viewport and the
polygon face orientation have to be inverted if rendering to a FBO.
The viewport was already being handled correctly; but polygon face
was not. This caused a conform failure when rendering to texture with
two-sided lighting enabled.
This fixes the problem in the i965 driver, and adds to the comment about
the gl_framebuffer "Name" field so that this isn't a surprise to other
driver writers.
(cherry picked from commit 6dceeb2eb8)
The MAX-based function can produce values that are non-monotonic for a span
which causes glitches in texture filtering. The sqrt-based one avoids that.
This is perhaps slightly slower than before, but the difference
probably isn't noticable given we're doing software mipmap filtering.
Issue reported by Nir Radian <nirr@horizonsemi.com>
(cherry picked from master, commit c334ce273e)
Before this change we would up emitting instructions with invalid register
numbers. This typically (but not always) hung the GPU. For now, just
prevent emitting bad instructions to avoid hangs. Still need to do some
kind of proper error recovery.
(cherry picked from commit e60b3067d8)
Instructions such as RCP, RSQ, LOG must smear the result of the function
across the dest register's X, Y, Z and W channels (subject to write masking).
Before this change, only the X component was getting written.
Among other things, this fixes cube map texture sampling in GLSL shaders
(since cube lookups involve normalizing the texcoord).
(cherry picked from commit 3485801978)
Previously, the prog_instruction::Data field was used to map original Mesa
instructions to brw instructions in order to resolve subroutine calls. This
was a rather tangled mess. Plus it's an obstacle to implementing dynamic
allocation/growing of the instruction buffer (it's still a fixed size).
Mesa's GLSL compiler emits a label for each subroutine and CAL instruction.
Now we use those labels to patch the subroutine calls after code generation
has been done. We just keep a list of all CAL instructions that needs patching
and a list of all subroutine labels. It's a simple matter to resolve them.
This also consolidates some redundant post-emit code between brw_vs_emit.c and
brw_wm_glsl.c and removes some loops that cleared the prog_instruction::Data
fields at the end.
Plus, a bunch of new comments.
(cherry picked from commit c51c822ee0)
This was causing hangs in cairogears, as we would blit to the 8bpp target
(A8 texture) as 16bpp, and stomp over state objects.
(cherry picked from commit 19e134051c)
The i965 hardware cannot do GL_CLAMP behavior on textures; an earlier
commit forced a software fallback if strict conformance was required
(i.e. the INTEL_STRICT_CONFORMANCE environment variable was set) and
2D textures were used, but it was somewhat flawed - it could trigger
the software fallback even if 2D textures weren't enabled, as long
as one texture unit was enabled.
This fixes that, and adds software fallback for GL_CLAMP behavior with
1D and 3D textures.
It also adds support for a particular setting of the INTEL_STRICT_CONFORMANCE
environment variable, which forces software fallbacks to be taken *all*
the time. This is helpful with debugging. The value is:
export INTEL_STRICT_CONFORMANCE=2
(cherry picked from commit 3468315087)
For regular GL, we must have vertex positions in order to draw. But ES2
doesn't have that requirement (positions can be computed from any array
of data).
See bug 19911.
(cherry picked from commit 97dd2ddbd9)
i965 doesn't natively support GL_CLAMP; it treats it like
GL_CLAMP_TO_EDGE, which fails conformance tests.
This fix adds a clause to the check_fallbacks() test to check
whether GL_CLAMP is in use on any enabled 2D texture. If so,
and if strict conformance is required (via INTEL_STRICT_CONFORMANCE),
a software fallback is mandated.
In addition, validate textures *before* checking for fallbacks,
rather than after; otherwise, the texture state is never validated
and can't be trusted. (In particular, if texturing is enabled and
the sampler would access any level beyond level 0 of a texture, the
sampler will segfault, because texture validation sets the firstLevel
and lastLevel fields of a texture object so that the valid levels
will be mapped and accessed correctly. If texture validation doesn't
occur, only level 0 is accessed correctly, and that only because
firstLevel and lastLevel happen to be set to 0.)
(cherry picked from commit 17c7852bf9)
Replace Default1D/2D/3D/Cube/etc with DefaultTex[TEXTURE_x_INDEX].
The same should be done with the Current1D/2D/3D/etc pointers...
(cherry picked from commit 4d24b639d1)
While running conform with render-to-texture:
conform -d 33 -v 2 -t -direct
the i965 driver failed this assertion:
intel_clear.c:77: intel_clear_tris: Assertion `(mask & ~((1 << BUFFER_BACK_LEFT) | (1 << BUFFER_FRONT_LEFT) | (1 << BUFFER_DEPTH) | (1 << BUFFER_STENCIL))) == 0' failed.
The problem is that intel_clear_tris() is called by intelClear() to
clear any and all of the available color buffers, but intel_clear_tris()
actually only handles the back left and front left color buffers; so
the assertion fails as soon as you try to clear a non-standard color
buffer.
The fix is to have intelClear() only call intel_clear_tris() with
buffers that intel_clear_tris() can support. intelClear() already backs
down to _swrast_Clear() for all buffers that aren't handled explicitly.
(cherry picked from commit 0ccbc3c905)
This lets us avoid allocing new buffers for renderbuffers, finalized miptrees,
and PBO-uploaded textures when there's an unreferenced but still active one
cached, while also avoiding CPU waits for batchbuffers and CPU-uploaded
textures. The size of BOs allocated for a desktop running current GL
cairogears on i915 is cut in half with this.
Note that this means we require libdrm 2.4.5.
(cherry picked from commit 40dd024be6)
We were asking for something illegal (write_domain != 0 && read_domains !=
write_domain) because at the time of writing the region surfaces were used
for texturing occasionally as well, and we weren't really clear on the model
GEM was going to use.
This reliably triggered a kernel bug with domain handling, resulting in
oglconform mustpass.c failure. Of course, it only became visible after
01bc4d441f cleaned up some gratuitous flushing.
(cherry picked from commit 078e8a61b2)
It is possible that an object whose vertices all are outside of a
view plane is passed to clip thread due to the RHW workaround. This
object should be rejected by clip thread. Fix bug #19879
(cherry picked from commit 68915fd6fa)
The default for EmitCondCodes got flipped when gallium-0.2 was merged.
This fixes GLSL if/else/endif regressions.
Drivers that use GLSL should always explicitly set the flag to be safe.
(cherry picked from commit a9e753c84c)
Tries to use either GLX_MESA_swap_control or GLX_SGI_video_sync to
detect whether the display is synchronized to the vertical blank. If
it detects this, a message will be printed. HOPEFULLY this will
prevent some of the bug reports such as "glxgears only gets 59.7fps.
What's wrong with my driver?"
(cherry picked from commit 58b9cd411f)
The wrap_texture() function doesn't set the renderbuffer PutRowRGB() method,
which is used to implement DrawPixels(). This fix adds an implementation
of this method.
(cherry picked from commit 523febe12e)
On Mobile chipsets, we often enable PipeB instead of PipeA, but the test
in here was insufficient, falling back to pipe A if the area
intersection returned zero. Therefore, in the case where a window went
off to the top of the left of the screen, it would freeze, waiting on
the wrong vblank.
Fix this mess by checking the sarea for a crtc being zero sized, and in
that case always default to the other one.
(cherry picked from commit 0b5266ff64)
intelMakeCurrent is called before intelWindowMoved (in fact, it calls
it), so calculation of the correct vblank crtc has not happened yet.
Fix this by making a function that fixes up a set of vblank flags and
call if from both functions.
(cherry picked from commit 39b4061bb9)
When doing line stipple, the stipple count resets on each line segment,
unless the primitive is a GL_LINE_LOOP or a GL_LINE_STRIP.
The existing code correctly identifies the need for a software fallback
to handle conformant line stipple on GL_LINE_LOOP primitives, but
neglects to make the same assessment on GL_LINE_STRIP primitives.
This fixes it so they match.
(cherry picked from commit 73658ff04f)
Back-face stencil operations didn't work correctly because this value was
zero. It needs to be 1 or 2. The only place it's set otherwise is in
glEnable/Disable(GL_STENCIL_TEST_TWO_SIDE_EXT).
(cherry picked from commit 2a968113a9)
Track separate back-face stencil state for OpenGL 2.0 /
GL_ATI_separate_stencil and GL_EXT_stencil_two_side. This allows all
three to be enabled in a driver. One set of state is set via the 2.0
or ATI functions and is used when STENCIL_TEST_TWO_SIDE_EXT is
disabled. The other is set by StencilFunc and StencilOp when the
active stencil face is set to BACK. The GL_EXT_stencil_two_side spec has
more details.
http://opengl.org/registry/specs/EXT/stencil_two_side.txt
(cherry picked from commit dde7cb9628)
If we're using anything but GL_NEAREST sampling of a cube map, we need to
use the BRW_TEXCOORDMODE_CUBE texcoord wrap mode. Before this, the GPU
would either lock up or subsequent texture filtering would be corrupted.
(cherry picked from master, commit 6f915b10d5)
This catches the linux-uclibc case and any others that were being set
prior to 98fcdf3f. Fixes bug 20345.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
(cherry picked from commit ac55db1d7d)
When a hw driver fell back to swrast, swrast wasn't always getting informed
of program changes. When fixed function is translated into shaders, flags
like _NEW_LIGHT, _NEW_TEXTURE, etc. should really signal _NEW_PROGRAM.
In this case, swrast wasn't seeing _NEW_PROGRAM when new fragment shaders
were generated.
(cherry picked from master, commit de1caa5507)
If glBufferDataARB() is called while a buffer object is currently mapped
we're supposed to unmap the current buffer, then replace it. Don't generate
an error.
(cherry picked from master, commit 75e3ccf6a5)
This fixes the case of "infinitely" nested swizzles such as EXPR.wzyx.yxwz.xxyz
This doesn't appear in typical shaders but with function inlining and the
compiler's internal use of swizzles it can happen.
New glean glsl1 test case added for this.
(cherry picked from master, commit d9881356a6)
Only 15 actually worked before since we always reserved generic[0] as an
alias for vertex position.
The case of vertex attribute 0 is tricky. The spec says that there is no
aliasing between generic vertex attributes 0..MAX_VERTEX_ATTRIBS-1 and the
conventional attributes. But it also says that calls to glVertexAttrib(0, v)
are equivalent to glVertex(v). The distinction seems to be in glVertex-mode
versus vertex array mode.
So update the VBO code so that if the shader uses generic[0] but not gl_Vertex,
route the attribute data set with glVertex() to go to shader input generic[0].
No change needed for the glDrawArrays/Elements() path.
This is a potentially risky change so regressions are possible. All the usual
tests seem OK though.
(cherry picked from mesa, commit dea0d4d563)
Follow-up: This patch doesn't seem to be as risky as noted above.
There have been no known regressions on Mesa/master because of it.
Move the is_boolean/integer_type() calls out of the loops.
Move the is_sampler_type() function near the bool/int functions.
Add a bunch of comments.
(cherry picked from master, commit c4ffbf009e)
If the vertex shader writes to a varying array with a variable index,
mark all the elements of that array as being written.
For example, if the vertex shader does:
for (i = 0; i < 4; i++)
gl_TexCoord[i] = expr;
Mark all texcoord outputs as being written, not just the first.
Linking will fail if a fragment shader tries to read an input that's not
written by the vertex shader. Before this fix, this linker test could fail.
(cherry picked from master, commit dac19f17f3)
Old limit was 256. Note that no arrays are declared to this size.
The only place we have to be careful about raising this limit is the
prog_src/dst_register Index bitfields. These have been bumped up too.
Added assertions to check we don't exceed the bitfield in the future too.
(cherry picked from master, commit 5b2f8dc013)
The new array features, precision/invariant/centroid qualifiers, etc. were
done a while back. The glGetString(GL_SHADING_LANGUAGE_VERSION) query returns
"1.20" now (for drivers that support it anyway).
(cherry picked from master, commit f59719c6c7)
This fixes a bug found with swizzled array indexes such as in "array[index.z]"
where "index" is an ivec4.
(cherry picked from master, commit 6eabfc27f1)
Arrays of sampler vars haven't been tested much and might actually be broken.
Will need to be revisited someday.
Another fix for bug 20056.
(cherry picked from master, commit 2b4f0216bf)
location = -1 is silently ignored, but other negative values should raise
an error.
Another fix for bug 20056.
(cherry picked from master, commit 234f03e90a)
If too many array elements are specified, they're to be silently ignored (don't
raise a GL error).
Fixes another issue in bug 20056.
(cherry picked from master, commit 2c1ea0720d)
This fixes a regression introduced in 46ae1abbac
Break program validation into two steps, do part before texture state
validation and do the rest after:
1. Determine Vertex/Fragment _Enabled state.
2. Update texture state.
3. Determine pointers to current Vertex/Fragment programs (which may involve
generating new "fixed-function" programs).
See comments in the code for more details of the dependencies.
(cherry picked from master, commit 537d3ed6f3)
Program state needs to be updated before texture state since the later depends
on the former.
Fixes piglit texgen failure. The second time through the modes (press 't'
three times) we disable the fragment program and return to conventional texture
mode. State validation failed here because update_texture() saw stale fragment
program state.
(cherry picked from master, commit 46ae1abbac)
On newer GCC releases, the compiler's headers have been split between
the include and include-fixed directories. Add both if the directories
exist.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
(cherry picked from master, commit a3d223f0d2)
If we had a vertex shader but no fragment shader (i.e. fixed function) we
didn't get the right enabled texture targets.
Fixes blank/white texture problem.
(cherry picked from master, commit b46611633c)
Handle the case where there's no per-vertex texcoords but the fragment shader
needs texcoords.
Fixes piglit shaders/fp-generic/dph test.
(cherry picked from master, commit f6d23943cd)
Fixes piglit shaders/fp-incomplete-tex test.
(cherry picked from master, commit 1df62651b2)
Conflicts:
src/mesa/swrast/s_fragprog.c
Also updated the fetch_texel_lod(), fetch_texel_deriv() functions to match
those in git/master.
We were hitting the assertion when we ran out of registers, which can happen.
Also, add some additional assertions and freshen up some comments.
(cherry picked from master, commit 0744805d58)
Some apps won't run w/ indirect rendering contexts.
Also, consolidate some context-init code in new init_glx_context() function.
(cherry-picked from master, commit 49e80bf6b1)
We only wanted to request when asked for the same set of buffers when a resize
has happened. We can just watch the protocol stream for a ConfigureNotify
and flag to do it then.
This is about a 5% win from doing two glViewport()s per frame in openarena.
Fixes bug 19835. However, a more elaborate fix should be implemented someday
which uses proper reference counting for gl_array_object.
(cherry picked from master, commit 88e0b92a74)
Previously, "in-place" swizzles such as:
MOV t, t.xxyx;
were handled incorrectly. Fixed by splitting the one loop into two loops so we
get all the refs before assigning them (to avoid potential clobbering).
(cherry picked from master/commit faa48915d2)
There were several bugs in the infrastructure for these two routines.
1. GLX_ALIAS was incorrectly used. The function and its alias must be
identical! glXMakeContextCurrent / glXMakeCurrentReadSGI and
MakeContextCurrent had different parameters. This caused the last
parameter of MakeContextCurrent to get random values.
2. We based the implementation of glXMakeContextCurrent on the manual
page instead of the GLX spec. The GLX spec says that
glXMakeContextCurrent can be passed a Window as a drawable. When this
happens, it will behave just like glXMakeCurrentReadSGI or
glXMakeCurrent.
3. If there was a problem finding or creating the DRI drawable,
MakeContextCurrent would crash instead of returning an error.
This commit fixes all three issues, and fixes bug #18367 and bug #19625.
The upstream linux kernel headers and libdrm kernel headers disagree on the
tag name for the sarea struct: _drm_i915_sarea vs drm_i915_sarea. They
both typedef it to drm_i915_sarea_t though, so just use that.
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
This utility is useful for hardware that doesn't support HW index buffers.
It's a bit inefficient but appears to give a substantial performance gain,
as we can emit tri strips that would otherwise be split into triangles.
Dri drivers often may validate first a write drawable and then a read
drawable ("readable"). However, the hardware lock may be unlocked when
validating the readable, causing the write drawable status to be stale.
Drivers should use this macro instead when validating two drawables.
Since we use an inverted viewport transformation for render to texture, that
inverts front/back polygon orientation.
Now glCullFace(GL_FRONT / GL_BACK) works correctly.
OpenGL allows mixing and matching depth and stencil renderbuffers in
framebuffer objects while the hardware really only supports interleaved
depth/stencil buffers. This makes for some tricky buffer management.
An extra wrinkle is the situation where the user allocates a 16bpp depth
texture or renderbuffer then tries to render to it along with a stencil
buffer. We'd have to promote the 16bpp Z values to 24-bit Z values and
mix in the stencil values to setup the depth/stencil renderbuffer.
There's no support for that now, so always allocate 32bpp depth textures/
renderbuffers for now.
Previously MaxTextureUnits was used to validate both texture image
units and texture coordinate units in fragment programs. Instead, use
MaxTextureCoordUnits for texture coordinate units and
MaxTextureImageUnits for texture image units.
Fixes bugzilla #19468.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Copied language from the glXSwapBuffers manual page about the implicit
glFlush and expected command completion. This just codifies what
people already expect from glXCopySubBufferMESA. The intention of
this command is to work like glXSwapBuffers but on a sub-rectangle of
the drawable.
Acked-by: Brian Paul <brianp@vmware.com>
When we use the do_blit_bitmap() function, it seems the fragment Z is always
1.0. If depth testing is on, that means that bitmap fragments are often
occluded by other rendering. So, the bitmap doesn't appear even if
rasterpos.Z==0.
The fix is to use the intel_texture_bitmap() path when depth testing is on.
Also, fix the incorrect Z coordinate. It needs to be an NDC value in [-1,1].
Just call _mesa_append_fog_code() if the fragment program's FogOption is
not GL_NONE.
This allows us to remove some unnecessary i965 fog code.
Note, the arbfplight.c demo can be used to test this (see DO_FRAGMENT_FOG).
Fixes regression in progs/demos/convolution.c due to loop unrolling.
This also allows the following to be compiled correctly:
for (int i = 0; i < n; i++) {
int i;
...
}
This fix is a bit of a hack, however. The better fix would be to change
the slang_shader.syn grammar. Will revisit that...
1-component structs such as "struct foo { float x; }" could get placed at
any position within a register. This caused some trouble computing the
field offset which assumed all struct objects were placed at R.x.
It would be unusual to hit this case in normal shaders.
These functions need to return the final computed value.
Now expressions such as a = (b += c) work properly.
Also, no need to use __asm intrinsics in these functions. The resulting
code is the same when using ordinary arithmetic operators and is more legible.
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
Reviewed-by: Brian Paul <brianp@vmware.com>
Add a "max complexity" heuristic to allow unrolling long loops with small
bodies and short loops with large bodies.
The loop unroll limits may need further tweaking...
Loops such as this will be unrolled:
for (i = 0; i < 4; ++i) {
body;
}
where 'body' isn't too large.
This also helps to fix the issue reported in bug #19190. The problem there
is indexing vector types with a variable index. For example:
vec4 v;
v[2] = 1.0; // equivalent to v.z = 1.0
v[i] = 2.0; // variable index into vector!!
Since the for-i loop can be unrolled, we can avoid the problems associated
with variable indexing into a vector (at least in this case).
This fixes cases such as:
vec4 v4;
vec2 v2;
v4.xz.yx = v2;
The last line now correctly compiles into MOV TEMP[1].xz, TEMP[0].yyxw;
Helps to fix the Humus Domino demo. See bug 19189.
This adds all of the `mglu' symbols to the list of symbol exports
for GLU. Without this patch, mangled GLU symbols are considered
`internal' symbols, and calling any results in undefined references.
Now only the samplers that are actually used by texture() functions are
saved in the uniform variable list. Before, we could run out of samplers
if too many were declared while only some of them were actually used.
The max texture coord units is still 8. All the fixed-function paths are
still limited to 8 too. But GLSL shaders can use more samplers now.
Note that some texcoord-related data structures are declared to be 16
elements in size rather than 8. This just simplifies the code in a few
places; the extra elements aren't accessible to the user.
These changes haven't been extensively tested yet, but sanity checking has
been done.
It should be possible to increase the max image units/samplers to 32 without
doing anything special. Beyond that we'll need longer bitfields in a few
places.
This lets us avoid software fallbacks when clients forget to turn some state
off (engine demo) or just do crazy things to test conformance (OGLC).
This should probably be brought into mesa generic code so other drivers can
make use of it.
Bug #19016.
This allows code such as "vec4 a = gl_LightSource[i].ambient;" to work.
When a built-in uniform array is indexed with a variable index we need to
"unroll" the whole array into the parameter list (aka constant buffer) because
we don't know which elements may be accessed at compile-time. In the case of
the gl_LightSource array of size [8], we emit 64 state references into the
parameter array (8 elements times 8 vec4s per gl_LightSourceParameters
struct).
Previously, we only allowed constant-indexed references to uniform arrays
(such as gl_LightSource[2].position) which resulted in a single state reference
being added to the parameter array, not 64. We still optimize this case.
Users should be aware that using "gl_LightSource[i].ambient" in their shaders
is a bit expensive since state validation will involve updating all 64
light source entries in the parameter list.
We'd come up with a negative remainder, while we were looking for the positive
version of it in the loop conditional. And, since the "did we hit our target"
break was disabled for the target_msc == 0 ("Just make the divisor/remainder
work") path, we'd never exit.
Simplify the code by just using int64_t all over instead of trying to do it
in a u32 space.
Previously fog parameter and specular color are packed into the
same dword. Note specular color should be packed in BGRA for device,
so if fog parameter and specular color all are present, fog parameter
will dirty the alpha term of specular color. This fixes rendering
issue when playing 'Yo Frankie' on 915/945.
Previously 3D textures were mipmapped using multiple passed through
the 2D mipmap generation code. This had 3 disadvantages. First, the
extra passes were slow. Second, this required the allocation of a
temporary buffer to hold intermediate data. Third, and most
important, the extra passes caused loss of additional bits due to
integer division / bit-shifting.
With this change, our mipmapgen conformance test passes for
non-compressed texture formats.
glCopyTexSubImage already gets the (correct) clipping for us, so it doesn't
need the path. While moving the clipping out, replace the code with the mesa
path to do the same job.
Note how if:
x + width == xmax + 0: width -= 0
x + width == xmax + 1: width -= 0
x + width == xmax + 2: width -= 1
So, the function was clipping to [xmin, xmax+1), not [xmin, xmax) like it was
supposed to. Same for ymax.
It is possible for applications to specify any texture base level,
including trivially invalid values (i.e., 47000000). When an app
specifies an invalide base level, we should gracefully disable the
texture instead of accessing memory outside the gl_texture_object.
This fixes an occasional segfault in one of our conformance tests.
Commit db61cbfa2aa241da49589331d8b6875d9a77d826 made modifications to
the protocol generator data and scripts. This commit represents the
changes to the generated files resulting from the previous changes.
This is the client-side part of the fix for bugzilla #11003.
img_null_flag was being ignored when calculating the size of a request
so a BadLength error gets thrown for glTexImage3D when the pixels
parameter is NULL.
See bug #11003
The TexSubImage commands do not have the "NULL image" flag that was
introduced with glTexImage3D. However, there is a CARD32 pad element
where that flag would be. Removing the img_null_flag causes the flag
to be removed from the protocol. This changes the protocol and breaks
everything.
In order to prevent needing to hand-code all of the TexSubImage
functions, a new attribute was added to the param element. This new
attribute, called "padding," is a boolean flag that selects whether or
not the parameter is a real parameter (default / false) or is protocol
padding (true) that does not appear in the function's parameter list.
This change resulted in a number of changes to other Python scripts.
In almost all cases parameters with the is_padding flag set should not
be emitted.
This patch only changes the the XML, the DTD, and the generator
scripts. It does NOT include the resulting changes to the generated
code. Generated code in the X server is also changed by the script /
XML changes in this patch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
The pkg-config files have been filled in more thoroughly to allow users
to use mesa more effectively. By adding metadata to Requires.private,
Libs.private and Cflags, we can ensure that all the libraries and
headers will be found in all situations. However, the full substitutions
are only done when using the configure script.
This also fixes the glu pkg-config file to account for using GL or
OSMesa.
Fixes bug 18161.
Added missing OPCODE_NOISE4, and use BRW_REGISTER_TYPE_D (instead of _UD)
in the initial RNDD instructions (which avoids saturating negative inputs
to 0).
For example, a declaration like
const float[3] xxx = float[3](1.1, 2.2, 3.3);
will place the array in the constant buffer whereas a regular, non-const array
would be placed in the temporary register file.
Next up: do the same thing for uniform arrays.
The i915 (and related graphics cores) only support TEXCOORDMODE_CLAMP and
TEXCOORDMODE_CUBE when using cube map texture coordinates, so fall back to
software rendering for other modes to avoid potential gpu hang issue. This
fixes scorched3d issue on 945GM(see bug 14539).
SSE movss from memory zeroes out everything above the destination dword, so
we get the (a, 0) or (a, 0, 0) result that these functions needed.
Bug #16520.
The ctx->Driver.GenerateMipmap() hook only expects cubemap face enums, not
CUBE_MAP_ARB, so walk all faces when we encounter that. Fixes oglconform
fbo.c segfault with both swrast and i965 drivers.
The images aren't mapped at this point, so we want the generic Mesa path for
GenerateMipmapEXT that does the mapping/unmapping for us. Ideally Mesa would
just call it for us.
This is fallout from the ffvertex_prog.c work. It doesn't call
ProgramStringNotify, so we don't set param_state, so we wouldn't track when
VP parameters changed, and constants wouldn't get uploaded. Instead, remove
param_state entirely and just use the real value that we want to be tracking.
Fixes rendering in openarena since BRW_NEW_BATCH got disentangled from
BRW_NEW_INDICES.
Bug #18822.
Intel docs state that only 830/845 have VBOs, 855/865 don't. So
lets just not use them on i8xx at all.
This restores the old pre-vbo code and uses it on all 8xx hw.
The CACHE_NEW_SURFACE bit always gets spammed since we get many different
surface BOs per state emit, but the only consumer of it wanted to just know
how many surfaces were enabled.
Later primitives, even if they caused a full state validate, wouldn't check
that there was enough space in the batchbuffer, occasionally triggering the
sanity check. We also skipped the aperture space check, even if it would
mean bringing in new programs and associated state.
This uses a GLX VendorPrivate request. VendorPrivates are real GLX API
calls but use the same protocol request. XCB does not currently
support specific VendorPrivetes directly. See eg.:
http://lists.freedesktop.org/archives/xcb/2008-November/004036.html
for more information.
There were hacks in EmitCopyBlit before to adjust offsets so that y=0 after
the offsets had been adjusted for a negative pitch. It appears that those
hacks were due to an unclear and surprising aspect of the hardware: inverting
the pitch results in the blit into the specified rectangle being inverted,
without the user needing to adjust y and base offset.
Tested with piglit copytexsubimage test on 915GM and GM965. Should fix
serious performance issues with ETQW and other applications.
We now express arrays in terms of indirect addressing. For example:
dst = a[i];
becomes:
MOV dst, TEMP[1 + TEMP[2].y];
At instruction-emit time indirect addressing is converted into ARL/
ADDR-relative form:
ARL ADDR.x, TEMP[2].y;
MOV dst, TEMP[1 + ADDR.x];
This fixes a number of array-related issues. Arrays of arrays and complex
array/struct nesting works now.
There may be some regressions, but more work is coming.
This is a step toward better array handling code. In particular, when more
than one operand of an instruction uses indirect addressing, we'll need some
temporary instructions and registers. By converting IR storage to instruction
operands all in one place (emit_instruction()) we can be smarter about this.
Also, somewhat better handling of dst register swizzle/writemask handling.
This results in tighter writemasks on some instructions which is good for
SOA execution.
And, cleaner instruction commenting with inst_comment().
Next: remove some more dead code and additional clean-ups...
As far as I can read in the docs, VS threads can be 1:1 with the pairs of
VUE handles allocated for them. Also, G4X can run twice as many threads as
before (though we won't unless the we bump the preferred URB entries for VS).
We were dividing the number of URB entries by two to get number of threads,
which looks suspiciously like a copy'n'paste-o from brw_vs_state.c. Also, the
maximum number of threads is 24, not 12.
The clip thread could potentially deadlock when processing tristrips since
being moved back to dual-thread mode, as the two threads could each have 4 VUEs
referenced and not be able to allocate another one since SF processing
wasn't able to continue (needing 5 entries before it freed 2).
In constrained URB mode, similar deadlock could even have occurred with
polygons (so we cut back max_threads if we can't handle it any primitive type).
This ensures all batchbuffers have a same cliprect mode after calling
_intel_batchbuffer_flush even if there aren't invalid commands in the
current batch buffer. (fix bug#18362).
See bug 18445.
When getting array results, __glXReadReply() always reads a multiple of
four bytes. This can cause writing to invalid memory when 'n' is not a
multiple of four.
Special-case the glAreTexturesResident() functions now.
To fix the bug, we use a temporary buffer that's a multiple of four bytes
in length.
NOTE: this commit also reverts part of commit 919ec22ecf
(glx/x11: Added some #ifdef GLX_DIRECT_RENDERING protection) which
directly edited the indirect.c file rather than the python generator!
I'm not repairing that issue at this time.
If an application never calls glUniform() to set sampler variable values
they'll remain 0 (the default value/unit).
Now call _mesa_update_shader_textures_used() at link time in case glUniform()
is never called. program->TextureUsed[] will then be correct for state
validation.
Now i965 also uses the vertex program created by Mesa Core, but this vertex program
is not only depend on mesa state _NEW_PROGRAM, so always check the current vertex
program is updated or not. This fixes broken demo cubemap.
Quoting section 11.3.10, paragraph 10.2 of the 965PRM:
10.2. If ExecSize is 1, dst.HorzStride must not be 0. Note that this is
relaxed from rule 10.1.2. Also note that this rule for destination
horizontal stride is different from that for source as stated in
rule #7.
GM45 gets very angry when rule 10.2 is violated.
Patch 58dc8b7 (i965: support destination horiz strides in align1 access mode)
added support for additional horizontal strides in the ExecSize 1 case, but
failed to notice that mesa occasionally re-purposes a register as a
temporary destination, even though it was constructed as a repeating source
with HorzStride = 0.
While, ideally, we should probably fix the code using these register
specifications, this patch simply rewrites them to use HorzStride 1 as the
pre-58dc8b7 code did.
Signed-off-by: Keith Packard <keithp@keithp.com>
Previously, since my check_aperture API change, we would check each piece of
state against the batchbuffer individually, but not all the state against the
batchbuffer at once. In addition to not being terribly useful in assuring
success, it probably also increased CPU load by calling check_aperture many
times per primitive.
This avoids issues with dereferencing stale cliprects around intel_draw_buffer
time. Additionally, take advantage of cliprects staying constant for FBOs and
DRI2, and emit cliprects in the batchbuffer instead of having to flush batch
each time they change.
Previously, we were trying to pass a name to the GEM GET_TILING_IOCTL,
which needs a handle, and failing. None of our buffers were tiled yet, but
they will be at some point with DRI2 and UXA.
This is nasty because there's no way in GL to output data to the stencil
buffer directly, so we have to do a dance to wrap the depth/stencil buffer
in an ARGB renderbuffer.
Improves performance of several oglconform testcases by better than a factor
of 2.
If we shift bytes into the texel word (or use the PACK_COLOR_8888 macro),
we don't have to worry about big vs. little endian. See comments about
texel formats in texformat.h.
Remove an unneeded/incorrect else-if clause that produced wrong results
on big-endian systems.
If the tnl output attributes matches the swsetup input attributes we still
need to check if the desired vertex color type (float vs. chan) has changed
so that we use the right emit functions.
Fixes a conformance failure found with logicop test at pathlevel 3.
This lets us short-circuit when we're leaving the same cliprects in place,
which becomes quite common with metaops clears, and may be useful for some of
our FBO paths.
Without this, we would reject programs which sampled multiple times from
registers defined in the same phase (block of instructions with the same
texture indirection count), as each sample would count as a new phase
beginning. Instead, keep track of which phases registers were written in,
and only bump phase when we're reading from one generated in this phase.
On the other hand, we failed to count oC or oD texture samples as being new
phases.
Bug #17865.
Move GL_ARB_texture_non_power_of_two and GL_ATI_separate_stencil
from the generic extension list to the 965-specific list. Neither
extension is supported on i830-class hardware, and
GL_ATI_separate_stencil is not supported on i915-class hardare.
GL_ARB_texture_non_power_of_two is supported on i915-class hardare and
is already in the i915-specific list.
The ARB extension is a superset of the older SGIX extension. Any
hardware that can support the SGIX version can also support the ARB
version. In Mesa, any driver that supports one also supports the
other. This unification just simplifies some bits of code.
- Sort extensions by ARB, then EXT, then vendor by name
- Remove redundant (only one of GL_{ARB,EXT,NV}_texture_rectangle) or
duplicate extension strings
The GL_OBJECT_TYPE_ARB query is handled directly in
_mesa_GetObjectParamterivARB because it is only supported in the
extension version of the shanding language API. glGetProgramiv and
glGetShaderiv should not accept this enum.
The GL_ARB_shader_objects spec says that glAttachShaderARB is supposed
to return GL_INVALID_OPERATION if a shader is attached to a program
where it is already attached. _mesa_attach_shader perviously returned
without error in this case.
Added an x86-64 CPUID function and use it to detect 3Dnow! If 3Dnow!
is available, use _mesa_3dnow_transform_points4_3d_no_rot,
_mesa_3dnow_transform_points4_perspective,
_mesa_3dnow_transform_points4_2d_no_rot, and _mesa_3dnow_transform_points4_2d.
This fixes long standing bug #8724.
The i965 driver previously had it's own set of code to convert
fixed-function TNL state to a vertex program. Core Mesa has code to
do this, so there is no reason to duplicate that effort in the driver.
In fact, this duplication leads to bugs when other aspects of the Mesa
infrastructure change.
The VBO module may use a real VBO or a malloc'd buffer for vertex storage.
Be careful not to accidentally replace the later with the former when drawing.
Check if using a real VBO at destroy time to prevent a double-free.
Also use BufferData(NULL) to get fresh storage and avoid synchronous
operation where we would have to flush and wait for the fence after each
draw because of the map.
This will chew through a whole load of buffer space on small draws, so
it isn't a proper solution. Need to support a no-fence or append mapping
mode to do this right, or use user buffers.
Additional error checking.
Allow setting elements of uniform arrays. This involves encoding both
a uniform location and a parameter offset in the value returned by
glGetUniformLocation().
Limit glUniform[if]v()'s count to the size of the uniform array.
When setting bool-valued uniforms, convert all float/int values to 0 or 1.
This isn't required for GEM (at least, yet), but the check_aperture code
for non-GEM results in batch getting flushed during emit. brw_state_upload
restarts state emits, but a bunch of the state emit functions were assuming
that they would be called exactly once, after prepare and before new_batch.
Bug #17179.
Move _glapi_proc typedef from glapitable.h to glapi.h
Also, don't include glapitable.h from glapi.h
Before we were including the huge glapitable.h file in every .c file.
Also, check the FEATURE flags in many places.
(cherry picked from commit 40d1a40f29)
Conflicts:
src/mesa/main/config.h
src/mesa/main/context.c
src/mesa/main/texobj.c
src/mesa/main/texstate.c
src/mesa/main/texstore.c
Without these we can find ourselves in _mesa_load_state_parameters()
computing derived lighting/material values whhen the current material
properties haven't been updated from the VBO.
This may be a somewhat wide-spread problem that needs more attention...
(cherry picked from commit 49adf51eee)
matypes.h doesn't really depend on assyntax.h; assyntax.h is only present
on x86; and this way we remove the need of grep being available (which is
relevant for scons and non-unix platforms).
(cherry picked from commit fc286ff3ba)
Under the terms of version 1.1, "once Covered Code has been published
under a particular version of the License, Recipient may, for the
duration of the License, continue to use it under the terms of that
version, or choose to use such Covered Code under the terms of any
subsequent version published by SGI."
FreeB 2.0 license refers to "dates of first publication". They are here
taken to be 1991-2000, as noted in the original license text:
** Original Code. The Original Code is: OpenGL Sample Implementation,
** Version 1.2.1, released January 26, 2000, developed by Silicon Graphics,
** Inc. The Original Code is Copyright (c) 1991-2000 Silicon Graphics, Inc.
** Copyright in any portions created by third parties is as indicated
** elsewhere herein. All Rights Reserved.
Official FreeB 2.0 text:
http://oss.sgi.com/projects/FreeB/SGIFreeSWLicB.2.0.pdf
As always, this code has not been tested for conformance with the OpenGL
specification. OpenGL conformance testing is available from
http://khronos.org/ and is required for use of the OpenGL logo in
product advertising and promotion.
Calls to glBindAttribLocation() should not take effect until the next time
that glLinkProgram() is called.
gl_shader_program::Attributes now just contains user-defined bindings.
gl_shader_program::VertexProgram->Attributes contains the actual/final bindings.
Mesa requires that we be able to share objects between contexts, which means
that the objects need to be created by the same bufmgr, and the bufmgr
internally requires pthread protection for thread safety.
Rely on the bufmgr having appropriate locking.
A thread switch is implicitly invoked after the issuance of an IF/ELSE/ENDIF
instruction if necessary. Unfortunately it seems sometimes a forced thread
switch is needed.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
