| Age | Commit message (Collapse) | Author |
|---|
|
Add all source files that are symlink'ed from common radeon code to the
ignore list.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
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).
|
|
|
|
|
|
drm cmd checker rightfully fell over any cube emit
|
|
Fixes #22181. R200 requires this since DP4 is used in hw tnl mode.
R300 prefers it (should be faster due to no instruction dependencies), but
both methods should be correct (when sw tcl is used though, MUL/MAD might
be faster). Probably doesn't make much difference for R100 since vertex progs
are executed in software anyway, but let's just keep it the same there too.
|
|
In DRI1 kernel emit scissor but in dri2 cs path we have to
explicitly program them.
|
|
|
|
|
|
The duplication of state data caused a crash due to double-free on destruction
of context, because a variable wasn't correctly null'ed out.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
|
|
|
|
This still need some work to actually report somethings reasonable
if no memory manager is available.
|
|
|
|
In r*00SetTexBuffer2(), if the passed in text glx_texture_format
is GLX_TEXTURE_FORMAT_RGB_EXT, then we should use an RGB-only
texture format, even if the DRI buffer has four channels.
https://bugs.freedesktop.org/show_bug.cgi?id=21609
|
|
This was broken with last merge see 62043b27575c378c027251316421e4699f461108
for explanations
|
|
Conflicts:
src/mesa/drivers/dri/r200/r200_state.c
src/mesa/drivers/dri/r300/r300_context.h
src/mesa/drivers/dri/r300/r300_fragprog.c
src/mesa/drivers/dri/r300/r300_state.c
src/mesa/drivers/dri/r300/r300_texmem.c
src/mesa/drivers/dri/r300/r300_texstate.c
src/mesa/drivers/dri/r300/r500_fragprog.c
src/mesa/drivers/dri/radeon/radeon_screen.c
src/mesa/drivers/dri/radeon/radeon_state.c
|
|
Still doesn't fix cubemaps, I really missed the whole drmsupports
thing when testing this all originally
|
|
remove the r100-ism of swapping cube faces which doesn't apply to r200,
and also use precalculated offsets.
Note that cube textures will still not work on r100 and r200 since mipmap
layout is level-first order (for r300) whereas r100/r200 require
face-first (and possibly also 2k alignment for face at least with tiling).
|
|
|
|
|
|
Since GL_READ_BUFFER is historically part of the gl_pixel_attrib group
it made sense to signal changes with _NEW_PIXEL. But now with FBOs it's
also part of the framebuffer state.
Now _NEW_PIXEL strictly indicates pixels transfer state changes.
This change avoids framebuffer state validation when any random bit of
pixel-transfer state is set.
DRI drivers updated too: don't check _NEW_COLOR when updating framebuffer
state. I think that was just copied from the Xlib driver because we care
about dither enable/disable state there.
|
|
|
|
Make sure we detect constant buffer changes indicated by the new flag.
Should be able to remove _NEW_PROGRAM (and _NEW_MODELVIEW, _NEW_LIGHT, etc)
from several places (someday.
|
|
|
|
There's really no need for two negation fields. This came from the
GL_NV_fragment_program extension. The new, unified Negate bitfield applies
after the absolute value step.
|
|
|
|
|
|
Conflicts:
src/mesa/drivers/dri/r200/r200_tex.c
src/mesa/drivers/dri/r300/r300_cmdbuf.c
src/mesa/drivers/dri/r300/r300_context.h
src/mesa/drivers/dri/r300/r300_swtcl.c
src/mesa/drivers/dri/r300/r300_tex.c
src/mesa/drivers/dri/r300/r300_texmem.c
src/mesa/drivers/dri/r300/r300_texstate.c
src/mesa/drivers/dri/radeon/radeon_tex.c
|
|
this make gnome shell run
|
|
EyeDirection -> SpotDirection
_NormDirection -> _NormSpotDirection
|
|
This fixes up the buffer validation scheme, so that we keep a list
of buffers to validate so cmdbuf flushes during a pipeline get
all the buffers revalidated on the next emit.
This also fixes radeonFlush to not flush unless we have something
useful to send to the GPU, like a DMA buffer or something not state
|
|
Context destruction was nearly the same over all the drivers,
so collapse it down.
|
|
|
|
This might trip up some serious FBO users, will have to see, but
it avoids the slow paths for all the demos I have.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re work depth issues.
Do a lot more FBO abstactions
fixup depth/stencil buffer interactions
|
|
also fixup old interface, gets rid of white boxes in compiz
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/mesa/drivers/dri/r300/r300_cmdbuf.c
src/mesa/drivers/dri/r300/r300_state.c
src/mesa/drivers/dri/r300/r300_swtcl.c
src/mesa/drivers/dri/r300/radeon_ioctl.c
src/mesa/drivers/dri/radeon/radeon_screen.c
|
