| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This isn't quite right yet. The delete behavior and the context
clean-up needs some work.
|
|
Several changes are made to program parameter limits. Several of the
non-NATIVE limits are set higher. All of the NATIVE limits are set to
zero in the core Mesa code. Each driver must set the actual value in
its context creation routine. If the NATIVE value remains zero, this
indicates that hardware shaders may not be supported.
Each of the preceeding changes matches the bahavior of Apple's shader
assembler, so it seems safe.
Finally, we limit the value of MaxEnvParams to be no greater than
MaxNativeAttribs. At least one case has been found where an
application does the wrong thing if MaxNativeAttribs < MaxEnvParams.
See also bugzilla #23490.
|
|
|
|
This info is essential to using/debugging a shader outside of its normal
application.
|
|
Tests if the current shader/program is valid and that the framebuffer is
complete. To be called by glBegin, glDrawArrays, etc.
|
|
|
|
The ARB version requires VAOs to be per-context while the Apple extension
was ambiguous.
|
|
Conflicts:
docs/relnotes-7.6.html
progs/tests/Makefile
src/gallium/drivers/softpipe/sp_prim_vbuf.c
src/glx/x11/indirect.c
src/mesa/glapi/Makefile
src/mesa/glapi/dispatch.h
src/mesa/glapi/glapioffsets.h
src/mesa/glapi/glapitable.h
src/mesa/glapi/glapitemp.h
src/mesa/glapi/glprocs.h
src/mesa/main/dlist.c
src/mesa/main/enums.c
src/mesa/sparc/glapi_sparc.S
src/mesa/x86-64/glapi_x86-64.S
src/mesa/x86/glapi_x86.S
|
|
Conflicts:
src/mesa/drivers/dri/i915/i915_tex_layout.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
src/mesa/drivers/dri/intel/intel_buffer_objects.c
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
src/mesa/drivers/dri/intel/intel_pixel_draw.c
src/mesa/main/enums.c
src/mesa/main/texstate.c
src/mesa/vbo/vbo_exec_array.c
|
|
The first time a context is bound to a drawable, the viewport and scissor
bounds are initialized to the buffer's size. This is actually a bit tricky.
A new _mesa_check_init_viewport() function is called in several places
to check if the viewport has been initialized. We also use a new
ctx->ViewportInitialized flag instead of the overloaded
ctx->FirstTimeCurrent flag.
|
|
Conflicts:
src/mesa/main/context.c
|
|
|
|
|
|
|
|
|
|
|
|
The former may point to the later.
|
|
|
|
|
|
Add a new flag mvp_with_dp4 in the context, and use that to switch
both ffvertex.c and programopt.c vertex transformation code to
either DP4 or MUL/MAD implementations.
|
|
|
|
Since shared array objects may point to the null/default buffer object,
the null/default buffer object should be part of the shared state.
|
|
Add a new flag mvp_with_dp4 in the context, and use that to switch
both ffvertex.c and programopt.c vertex transformation code to
either DP4 or MUL/MAD implementations.
|
|
Already doing this for driver.flush()
|
|
As of commit 23ad86cfb91c294ce85a3116d4b825aaa3988a6e all messages go
through output_if_debug().
Add new parameter to output_if_debug() to indicate whether to emit a newline.
_mesa_warning() and _mesa_error() calls should not end their strings with \n.
_mesa_debug() calls should end their text with \n.
|
|
Need to do this to ensure vbo code unmaps its buffers before calling
the driver, which may be sitting on top of a memory manager which
objects to firing commands from a mapped buffer.
|
|
|
|
|
|
add new entrypoints, new texture format, etc
translate in texenvprogram.c for drivers using the mesa-generated tex env
fragment program
also handled in swrast, but not tested (cannot work due to negative texel
results not handled correctly)
|
|
|
|
A bit of refactoring with an eye toward ES2 and GL 3.1
|
|
Otherwise two threads might think each made the refcount go zero.
|
|
|
|
This makes debugging with gdb a bit easier.
Ex:
(gdb) p ctx->DrawBuffer.Attachment[BUFFER_STENCIL]
Note however that gdb only seems to recognize enum types that are actually
used to declare a variable somewhere. For example, gl_buffer_index isn't
used to declare any vars so it's invisible to gdb. Work around this by
adding a dummy function in context.c that declares some vars with these
new types.
|
|
This rewrites the sparc GLAPI code so that it's PIC friendly and works
with all of the TLS/PTHREADS/64-bit/32-bit combinations properly.
As a result we can turn SPARC asm back on. Currently it's only
enabled on Linux, as that's the only place where I can test this
stuff out.
For the moment the cliptest SPARC asm routines are disabled as they
are non-working. The problem is that they use register %g7 as a
temporary which is where the threading libraries store the thread
pointer on SPARC. I will fix that code up in a future change as it's
a pretty important routine to optimize.
Like x86 we do the runtime patch as a pthread once-invoked initializer
in init_glapi_relocs().
Unlike x86, however, our GLAPI stubs on SPARC are just two instruction
sequences that branch to a trampoline and put the GLAPI offset into a
register. The trampoline is what we run-time patch. The stubs thus
all look like:
glFoo:
ba __glapi_sparc_foo_stub
sethi GLAPI_OFFSET(glFOO) * PTR_SIZE, %g3
This actually makes generate_entrypoint() a lot simpler on SPARC. For
this case in generate_entrypoint() we generate stubs using a 'call'
instead of the 'ba' above to make sure it can reach.
In order to get a proper tail call going here, in the unpatched case,
we do several tricks. To get the current PC, for example, we save the
return address register into a temporary, do a call, save the return
address register written by the call to another temporary, then
restore the original return address register value. This is to
avoid having to allocate a stack frame.
This is necessary for PIC address formation.
This new GLAPI scheme lets us get rid of the ugly SPARC GLAPI hacks in
__glXInitialize() and one_time_init().
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This trims down and cleans up imports.h and glheader.h quite a bit.
|
|
Plus, put them in the order of highest to lowest priority to simplify
the texture_override() loop.
|
|
Replace Default1D/2D/3D/Cube/etc with DefaultTex[TEXTURE_x_INDEX].
The same should be done with the Current1D/2D/3D/etc pointers...
|
|
|
|
|
|
Only VBO uses the evaluator code so call _math_init_eval() there.
Only TNL uses the transform/translate code so call _math_init_transformation()
and _math_init_translate9) there.
This is a step toward resolving some symbol collisions between Mesa's and
gallium's x86 codegen.
Have VBO and TNL modules call _math_init_transformation()
|
|
This is the big merge of the gallium-0.2 branch into master.
gallium-master-merge was just the staging area for it.
Both gallium-0.2 and gallium-master-merge are considered closed now.
Conflicts:
progs/demos/Makefile
src/mesa/main/state.c
src/mesa/main/texenvprogram.c
|
|
|
|
Merge commit 'origin/gallium-0.2' into gallium-master-merge
Conflicts:
Makefile
docs/relnotes-7.4.html
docs/relnotes.html
src/mesa/drivers/dri/i965/brw_wm.h
src/mesa/main/imports.c
src/mesa/main/mtypes.h
src/mesa/main/texcompress.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
src/mesa/vbo/vbo_exec_api.c
src/mesa/vbo/vbo_save_draw.c
|
|
Rename some structs and fields to be more consistant with the rest of mesa.
|
|
|
|
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>
|
|
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>
|
|
Conflicts:
src/mesa/main/ffvertex_prog.c
src/mesa/main/texenvprogram.c
|
