| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
- don't limit vertex count if we are using indices
- max indices count is 65535 not 65536
- remove some comments that don't apply anymore
- remove unreachable code
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/mesa/main/dlist.c
src/mesa/vbo/vbo_save_api.c
|
| |
| |
| |
| |
| | |
Fixes assertion failure when binding depth/stencil texture to FBO stencil
attachment.
|
| |
| |
| |
| |
| |
| | |
Failure to set the obj->Pointer back to null tripped up the assertion.
Bug #22428.
(cherry picked from commit 57a06d3a48c9af1067ec05e3ad96c58f4b9b99be)
|
| |
| |
| |
| | |
Fixes fighting between GPU and software rendering with TTM.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
We would have to build the program with the appropriate fog mode, and
also supply the fog coordinate if appropriate.
Bug #19413.
|
| |
| |
| |
| |
| | |
While GEM covers this for execution it knows about, it doesn't know about
the batchbuffer we're preparing. Fixes piglit vbo-map-remap.c testcase.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Valgrind doesn't know that a successful getparam sets the target of the
pointer, so just set the value beforehand.
|
| |
| |
| |
| | |
half stealing the code without taking the intel regions
|
| |
| |
| |
| | |
I suspect this might break TFP in some way but it makes firecube run here
|
| |
| |
| |
| |
| |
| |
| | |
1. the data type of <src1> (JMPI offset) must be D
2. execution size must be 1
3. NoMask
4. instruction compression isn't allowed.
|
| |
| |
| |
| | |
Bug #22000.
|
| |
| |
| |
| |
| | |
This improves the performance of my GLSL demo by 30%. It also fixes the
VS deadlock that ut2004 had, for reasons I can't explain. Bug #21330.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we can't fit all the VS outputs into the MRF, we need to overflow into
temporary GRF registers, then use some MOVs and a second brw_urb_WRITE()
instruction to place the overflow vertex results into the URB.
This is hit when a vertex/fragment shader pair has a large number of varying
variables (12 or more).
There's still something broken here, but it seems close...
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Failure to set the obj->Pointer back to null tripped up the assertion.
Bug #22428.
|
| |
| |
| |
| |
| | |
There doesn't appear to be any driver impact for enabling this, and
tests/prog_parameter passes.
|
|\| |
|
| |
| |
| |
| | |
This fixes a segfault seen with piglit's fdo20701 test.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit de447afff26706e3bf8bdcd5cfb8b1daf49b4b21 but
puts the lock under DRI1-only.
From keithw:
> It's there because the DRI1 code doesn't actually achieve the mutexing
> which it looks as if it should. For multi-threaded applications it was
> always possible to get two threads inside locked regions -- I have no
> idea how, but it certainly was and presumably still is possible.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This would cause LOCK_HARDWARE to mutex all contexts in this process on
both DRI1 and DRI2. On DRI1, LOCK_HARDWARE already does it for all
processes on the system. On DRI2, LOCK_HARDWARE doesn't, but there shouldn't
be any state outside the context that needs any additional protection.
Notably, the bufmgr is protected by its own mutex and not
LOCK_HARDWARE.
This code was originally introduced with the i915tex code dump, so it's not
clear what it was there for.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This reverts commit 0952645fe04a27968565ea4d913500c23b1b11e3.
Need to revisit where this is going wrong
|
| |
| |
| |
| |
| |
| | |
This fixes an assertion in glReadPixels from the front buffer.
Signed-off-by: Nicolai Hähnle <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
Add all source files that are symlink'ed from common radeon code to the
ignore list.
Signed-off-by: Nicolai Hähnle <[email protected]>
|
|\ \ |
|
| | | |
|
| | | |
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
Conflicts:
Makefile
src/gallium/drivers/softpipe/sp_screen.c
src/mesa/main/version.h
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To maintain correctness, the server will copy the real front-buffer to
a newly allocated fake front-buffer in DRI2GetBuffersWithFormat.
However, if the DRI2GetBuffersWithFormat is triggered by glViewport,
this will copy stale data into the new buffer. Fix this by flushing
the current fake front-buffer to the real front-buffer in
intel_viewport.
Fixes bug #22288.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
the driver used to overwrite grf0 then use implicit move by send instruction
to move contents of grf0 to mrf1. However, we must not overwrite grf0 since
it's still used later for fb write.
Instead, do the move directly do mrf1 (we could use implicit move from another
grf reg to mrf1 but since we need a mov to encode the data anyway it doesn't
seem to make sense).
I think the dp_READ/WRITE_16 functions may suffer from the same issue.
While here also remove unnecessary msg_reg_nr parameter from the dataport
functions since always message register 1 is used.
|
| | |
| | |
| | |
| | |
| | | |
This allows us to return the unused portion of the dma buffer
to the allocator instead of wasting nearly 16k a pop.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
still always enable max, but the right values this time.
More work should probably be done for saner limits without mm, and/or
dri conf option allow_large_textures (which is ignored) removed.
3D limit on r100 is pretty arbitrary as still handled by swrast anyway.
Also fix r300 limits (except 3d I've no idea what the max is anyway so
keep using mesa default).
|
| | | |
|
| | |
| | |
| | |
| | | |
This was already correct in the GEM code
|
| | | |
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
glsl compiler will not generate OPCODE_SWZ, and as a first step it would
be translated away to a MOV anyway (why?), but later internally this opcode is
generated (for EXT_texture_swizzling).
(cherry picked from commit 4ef1f8e3b52a06fcf58f78c9c36738531b91dbac)
|
| | |
| | |
| | |
| | |
| | | |
Fixes glean depthStencil test.
(cherry picked from commit 3885b708fdbb7bbd5dd3a247c41fb9a75ee7c057)
|
| | |
| | |
| | |
| | |
| | | |
Fixes the render-to-texture test in progs/tests/getteximage.c
(cherry picked from commit a03b349153660e449daf4f56d750f1caef23b1a5)
|
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes oglconform zbfunc.c and pxtrans-cidraw.c, at least.
(cherry picked from commit 405300bb190f516e16b704050abe3389b366ed27)
|