| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
compile and behave like it did before the gallium-texture-transfer merge
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Obviously, the color of fragments produced by DrawPixels is not constant,
even if the current vertex array / vertex program state indicates that the
color for normal rendering will be constant. Therefore, we need to override
certain optimisations that have been added to texenvprogram.c
Signed-off-by: Nicolai Haehnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This new issue was exposed by commit 6eabfc27f19a10dfc2663e99f9560966ba1ff697
|
|
|
|
|
|
|
| |
Each of these programs previously called itself "First Tri" which was a
little confusing. Could have left one as "First Tri", but the trouble
then is that people would still clone that file & we'd end up with
another thousand first tri apps...
|
|
|
|
| |
Please read previous commit for more info.
|
|
|
|
|
|
|
|
|
| |
It is only the i965simple pipe driver that was broken
in the gallium-texture-transfere merge that is being
disabled, mothing more nothing less.
FYI, there never where working i965 hardware support
in gallium anyways.
|
| |
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
src/gallium/drivers/softpipe/sp_tile_cache.c
|
| | |
|
| |
| |
| |
| |
| | |
It looks like I resolved the merge conflicts but did not save my emacs
buffers before committing...
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/mesa/state_tracker/st_cb_accum.c
src/mesa/state_tracker/st_cb_drawpixels.c
|
| | |
| | |
| | |
| | | |
Fixes glReadPixels, gl(Copy)TexSubImage, glCopyPixels.
|
| | |
| | |
| | |
| | | |
A lot more test programs work.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
glxgears works.
|
| | | |
|
| | |
| | |
| | |
| | | |
Missed these for the initial gallium-texture-transfer commit.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead, a new pipe_transfer object has to be created and mapped for
transferring data between the CPU and a texture. This gives the driver more
flexibility for textures in address spaces that aren't CPU accessible.
This is a first pass; softpipe/xlib builds and runs glxgears, but it only shows
a black window. Looks like something's off related to the Z buffer, so the
depth test always fails.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gallium/auxiliary/draw/draw_vs_aos.c
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
(cherry picked from master, commit ca03e881a8d8fa3e36a601238559c20311373633)
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | | |
|
|\ \ \ \ |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
The more I look at this, the more bugs I see.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Hold on to your hats.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Movin' out of the Stone Ages.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Mostly needed a few defines for index buffers, but there's other goodies too.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously draw module asked for a pointer into (mapped) vertex data,
which it would incrementally fill and emit draw commands against. This
was hard for the drivers to deal with, especially in the case where a
draw command would force a flush and thus an unmap of the vertex data.
With this change, the draw module explicitly maps & then unmaps vertex
data prior to emitting draw commands.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The debug functions depend on several util function for os abstractions, and
these depend on debug functions, so a seperate module is not possible.
|
| | | | |
|