| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
- fill in more src/dst formats
- disable depth copies for now
- set proper data formats in render target regs
- fill in additional default state
The swizzles on some of the less used mesa formats
are probably wrong.
|
| |
|
|
|
|
| |
Unfinished.
|
|\
| |
| |
| |
| |
| | |
Conflicts due to DRI1 removal:
src/mesa/drivers/dri/intel/intel_context.c
src/mesa/drivers/dri/intel/intel_screen.c
|
| |
| |
| |
| |
| |
| | |
Needed to support the SwapBuffers code properly.
Signed-off-by: Kristian Høgsberg <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Support the new DRI2 protocol request, DRI2SwapBuffers, in both direct
and indirect rendering context. This request allows the display server
to optimize back->front swaps (e.g. through page flipping) and allows us
to more easily support other GLX features like swap interval and the OML
sync extension in DRI2.
Signed-off-by: Jesse Barnes <[email protected]>
|
| |
| |
| |
| |
| | |
On r100 we emit the indices inline so we need to account
for that in the emission size.
|
| |
| |
| |
| | |
This bug was fixed in libdrm ages ago, port to non-kms
|
| | |
|
| |
| |
| |
| | |
Depth buffer accelerated blits aren't implemented yet.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_emit.c
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
R600_OUT_BATCH_RELOC doesn't really use offset so set it
in TEX_RESOURCE2
+ typo fix
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ordering of texture components was
backwards for the floating point textures.
Signed-off-by: Pierre Ossman <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Check whether the index is within bounds before accessing the array.
Signed-off-by: Roel Kluin <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Seems to be the only way to stay fully portable.
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
configs/default
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
src/mesa/main/version.h
|
| | |
| | |
| | |
| | | |
Invalid assertion found by Roel Kluin <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | | |
This can never be true.
Signed-off-by: Roel Kluin <[email protected]>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* remove-intel-dri1:
intel: intelScreenContext() is no longer used
intel: Remove remaining dri2.enabled tests
intel: Drop more cliprect bookkeeping
intel: Remove struct intel_framebuffer
intel: Remove client-side vblank code
intel: Drop intelWindowMoved()
intel: Drop batchbuffer cliprect_mode tracking
intel: Drop DRI1 static regions
intel: Use depth buffer from ctx.DrawBuffer in copypix_src_region()
intel: Drop LOCK/UNLOCK_HARDWARE()
intel: Drop DRI1 SwapBuffer implementation
intel: Drop DRI1 CopySubBuffer implementation
intel: Drop DRI1 support
Push __driDriverExtensions out of dri_util.c and into the drivers
Remove leftover __DRI{screen,drawable,context}Private references
Check for libdrm_$chipset.pc when needed
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With the vsync fields no longer relevant and by refactoring the code
to no longer use color_rb[0-1] we can just use struct gl_framebuffer
directly.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Everything this functions does under DRI2 is also taken care of
by intel_draw_buffer(), which is always called where intelWindowMoved()
is called.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This function was using intel->depth_region, which is the static region
for the DRI1 depth buffer. This code has always been broken with DRI2
but I suspect it doesn't get excersized much.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The DDX driver stopped supporting DRI1 so we're dropping support for
that from the DRI driver too.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This lets the individual drivers select which extensions to advertise.
Specifically, most drivers (tdfx, sis, savage etc) don't support DRI2
but the shared extension list in dri_util.c does list the DRI2 extension.
Pushing the list into the drivers, lets us avoid listing the DRI2
extension for drivers that don't support it.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As part of the DRI driver interface rewrite I merged __DRIscreenPrivate
and __DRIscreen, and likewise for __DRIdrawablePrivate and
__DRIcontextPrivate. I left typedefs in place though, to avoid renaming
all the *Private use internal to the driver. That was probably a
mistake, and it turns out a one-line find+sed combo can do the mass
rename. Better late than never.
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
This adds missing pkg-config lookup for intel and moves the radeon
lookup into a case...esac so it's only looked up when one or more of
the radeon drivers are enabled.
|
| | |
| | |
| | |
| | |
| | |
| | | |
R600_OUT_BATCH_RELOC doesn't really use offset so set it
in TEX_RESOURCE2
+ typo fix
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When we have integer-valued texture formats, the texture border color
must also store integer and uint values.
With GL 3.0, the new glTexParameterIiv() and glTexParameterIuiv() functions
can set the border color to int or uint values.
|
|\ \ \
| |/ /
|/| /
| |/
| |
| |
| |
| |
| | |
Conflicts:
docs/relnotes.html
src/gallium/drivers/llvmpipe/lp_tex_sample_c.c
src/gallium/drivers/r300/r300_cs.h
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
src/mesa/main/enums.c
|
| |
| |
| |
| |
| |
| | |
It was OK before because we proceed to clamp the value to hardware
limits, but given that other use of MaxLevel has been a trap, let's
avoid it.
|
| |
| |
| |
| | |
Fixes piglit fbo-copyteximage.
|
| |
| |
| |
| |
| |
| | |
If we ever had a non-tile-aligned tiled renderbuffer, the math was all
off. Use the existing x,y coordinates instead of trying to
reconstruct them from an incorrectly-calculated offset value.
|
| |
| |
| |
| |
| | |
Use vertex program key mechanism and swizzle during vertex fetch - is there
a better way?
|