| Age | Commit message (Collapse) | Author |
|---|
|
Previously, we set _NEW_PIXEL and _NEW_COLOR in these functions, respectively.
That correponds to the GL attribute groups, but doesn't make much sense
otherwise. This could improve validation efficiency in a few places too.
It looks like all the drivers are already checking for _NEW_BUFFERS in the
right places (since that's the bit for FBO state) so we can trim out
_NEW_PIXEL and _NEW_COLOR at any time.
|
|
|
|
|
|
Will be replaced by _mesa_get_fixed_func_fragment_program().
|
|
It looks like Windows does not like filenames ending with a dot,
in effect renaming it to 'mms-config'.
|
|
ctx->FragmentProgram._Current
The _Current field should either point to the fragment program which is to be
run (GLSL, ARB_f_p, fixed-func-generated, etc) or be NULL if conventional
fixed-function code is to be used. Matches TNL program code.
|
|
GLSL sampler variables indicate which texture unit to use for TEX instructions.
Previously, this was baked into the fragment/vertex program and couldn't be
readily changed once set.
Now, SamplerUnits[] array indicates which texture unit is to be used for
each sampler variable. These values are set with glUniform1i().
This is extra state that must be passed to the fragment/vertex program
executor at runtime.
|
|
|
|
instructions
|
|
|
|
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...
|
|
|
|
GLSL fragment shader.
This allows Glean glsl1 test to get pretty far.
|
|
|
|
the drivers.
This should probably be pulled into main-line Mesa...
|
|
|
|
|
|
|
|
This replaces the temporary occlusion counter functions we had before.
Added new ctx->Driver.WaitQuery() function which should block until the result is ready.
Sketch out some code for vertex transformation feedback counters.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove surface ptr from gl_renderbuffer.
Use st_renderbuffer in most places.
More clean-up.
|
|
|
|
Still require the intelClear() call to flush batchbuffers. That will be
removed later...
|
|
|
|
|
|
|
|
struct pipe_buffer goes away.
Added basic region functions to softpipe to allocate/release malloc'd regions.
Surface-related code is fairly coherent now.
|
|
|
|
Z testing now works with i915 driver.
Add gl_renderbuffer::surface pointer (and reverse pointer).
Remove intel_surface and xmesa_surface types - no longer used.
|
|
into softpipe_0_1_branch
|
|
|
|
|
|
The clamping for these values depends on whether we're drawing AA or non-AA
points, lines. Defer clamping until drawing time. Drivers could compute and
keep clamped AA and clamped non-AA values if desired.
|
|
|
|
Make sure the relevant fields in window fbs get updated at appropriate time
(those are NOT the same as fbos!!!), and fix up related code accordingly.
This is a bit ugly, but there's a reason the issues section in EXT_fbo is
a couple hundred pages long...
Hopefully correct now.
|
|
|
|
Conflicts:
src/mesa/main/framebuffer.c
|
|
Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
|
|
|
|
the framebuffer objects attached to drawables can have invalidate state
associated with them, since for the window framebuffer this is per-context
state and not per-fbo state. Since drivers rely on that information
(otherwise would need to check if currently the window-framebuffer is
bound in a lot of places) fix it up in _mesa_make_current (ugly).
(Brought over from i915tex_privbuffers, where it fixes xdemos/wincopy
when switching to front buffer rendering.)
|
|
|
|
|
|
|
|
width/height/depth == 0 is a legal texture size (no error generated).
Later, the texture will be considered incomplete, however, and texturing
will effectively be disabled.
See bug 11309.
|
|
|
