562ca4eae2
i965g: more compiling wip
2009-10-25 01:20:56 +01:00
4dd2f6640b
i965g: more work on compiling, particularly the brw_draw files
2009-10-25 00:02:16 +01:00
4f7931bb35
i965g: more work on compiling
2009-10-24 17:07:28 +01:00
074606a806
i965g: more files compiling
2009-10-24 13:19:26 +01:00
7ee60648a3
i965g: hook into build system
2009-10-24 11:55:25 +01:00
357e5c9a0e
ws/i965: renames from i915, hook up makefiles
2009-10-24 11:55:05 +01:00
d71af266df
i965g: first compiling file
2009-10-24 11:53:43 +01:00
c93d2e4540
ws/i965: pull in the rest of the i915 winsys tree.
...
The intel_xorg file looks like it's got quite a bit of code that could
be lifted up into the xorg state tracker -- should really just have a
list of pci ids and a pointer to a screen create func.
2009-10-23 23:37:45 +01:00
b7efe646b6
ws/i965: clone the i915 winsys
...
I'll want to rework this, not sure trying to share this code is a very
good idea at least until the interfaces from the two drivers calm
down.
2009-10-23 23:36:02 +01:00
22906f7301
i965g: wip on removing GL stuff, trying to get a few files compiling
2009-10-23 23:27:43 +01:00
6b48fb0022
i965: ignore cliprect_mode
2009-10-23 20:19:14 +01:00
57a920cb1a
i965g: wip
2009-10-23 17:03:45 +01:00
2f5f7c0773
i965g: re-starting from the dri driver
2009-10-23 17:03:45 +01:00
da253319f9
gallium: remove extended negate also, and also the ExtSwz token
...
Likewise, the extended negate functionality hasn't been
used since mesa switched to using tgsi_ureg to build programs,
and has been translating the SWZ opcode internally to a single MAD.
2009-10-23 14:50:02 +01:00
8a571b809a
cell: typo from ExtSwizzle commit
2009-10-23 14:38:30 +01:00
b9cb74c7f8
gallium: remove the swizzling parts of ExtSwizzle
...
These haven't been used by the mesa state tracker since the
conversion to tgsi_ureg, and it seems that none of the
other state trackers are using it either.
This helps simplify one of the biggest suprises when starting off with
TGSI shaders.
2009-10-23 14:31:24 +01:00
4e1d51786e
gallium: remove noise opcodes
...
Provide a dummy implementation in the GL state tracker (move 0.5 to
the destination regs).
At some point, a motivated person could add a better
implementation of noise. Currently not even the nvidia
binary drivers do anything more than this. In any case, the
place to do this is in the GL state tracker, not the poor
driver.
2009-10-23 13:56:07 +01:00
19403935aa
progs/demos: add fps to multiarb
2009-10-23 13:56:07 +01:00
9b6c86b8be
r300g: last changes's typo, miss a include file
2009-10-23 16:40:31 +08:00
6df12aad2f
r300g: add flush_frontbuffer function to display video surface
2009-10-23 14:46:29 +08:00
0072a26662
g3dvl: pass display and screen to g3dvl when creating video private context
2009-10-23 14:44:27 +08:00
45eb9d2f6d
r600: remove remains of old tnl pipeline
2009-10-23 01:01:19 -04:00
fc38a3cfe8
r600: fix render size prediction
2009-10-23 01:01:19 -04:00
614e8f2203
r600: remove old tnl pipeline
2009-10-23 01:01:19 -04:00
95328c7cf9
r600: clean up context creation
...
Make it more consistent with other radeon drivers.
2009-10-23 01:01:18 -04:00
286611d990
Revert "Store clipping distance for user clip planes as part of vertex processing"
...
This reverts commit f058b25881
2009-10-22 19:21:21 -07:00
ab9d1011f5
Merge branch 'mesa_7_6_branch'
2009-10-22 18:38:19 -06:00
347fb3737b
docs: document 'useprog' debug option
2009-10-22 18:35:13 -06:00
fdce832437
mesa: fix up vbo comments
2009-10-22 18:35:13 -06:00
488e67bab2
mesa: added _mesa_dump_texture()
2009-10-22 18:35:12 -06:00
55058652b8
intel: flush old context before binding new context
...
Per the GLX spec, when changing rendering contexts, the old context
should first be flushed.
2009-10-22 18:33:26 -06:00
5e6a6a2719
glx: don't destroy context immediately if it's currently bound
...
According to the GLXDestroyContext() man page, the context should not
immediately be destroyed if it's bound to some thread. Wait until it's
unbound to really delete it. The code for doing the later part is
already present in MakeContextCurrent() so no change was needed there.
2009-10-22 18:20:28 -06:00
4837e01bcd
mesa: code refactoring- new _mesa_finish(), _mesa_flush()
2009-10-22 18:16:10 -06:00
fb22e80169
st/xorg: fix the makefile when used with new xextproto
2009-10-22 19:33:04 -04:00
61a96a2ac7
progs/xdemos: fix command line flag typo
2009-10-22 17:11:59 -06:00
8810b8f671
i965: fix hacked Fallback usage in brw_prepare_vertices()
...
Setting intel->Fallback = 1 clobbered any fallback state that was already
set. Not sure where this hack originated (the git history is a little
convoluted). Define and use a new BRW_FALLBACK_DRAW bit instead. This
shouldn't break anything and could potentially fix some bugs (but no
specific ones are known).
2009-10-22 16:52:59 -06:00
c24466c34e
intel: define INTEL_FALLBACK_DRIVER for drivers
2009-10-22 16:52:59 -06:00
ea659f8917
intel: Fallback field is a bitmask, use GLbitfield
2009-10-22 16:52:59 -06:00
f9bbbe5803
i965: remove unused brw_context::tmp_fallback field
2009-10-22 16:52:59 -06:00
2f7abf5c04
i965: remove unused BRW_FALLBACK_TEXTURE bit
...
The value was probably wrong too.
It was the same as INTEL_FALLBACK_DRAW_BUFFER.
2009-10-22 16:52:59 -06:00
04ec113e09
r300g: Enable more stuff in r300_screen, cleanup comments.
...
Also enable 24-bit depth buffers without stencil.
2009-10-22 14:29:48 -07:00
ff9e1c0198
r300g: Cleanup PSC setup math a bit and stop using Draw formats.
2009-10-22 14:29:48 -07:00
198925caa1
nv50: handle PIPE_TEX_FILTER_ANISO case
...
Set the same bits as for linear filtering (in addition
to max anisotropy), and 2 unknown bits I've seen set.
2009-10-22 23:05:12 +02:00
4b8de9bd7c
nouveau: nv30: rewrite so we can render only in depth buffer
2009-10-22 22:01:53 +02:00
f9a69c0f04
nouveau: nv30: use a8r8g8b8 as depth texture format for z24s8
2009-10-22 22:00:46 +02:00
fd7ee2bcb7
Kill off trident.
...
Hm. I could have said "chew trident and spit it out," or perhaps
"spear trident," instead. Dohoho.
2009-10-22 12:57:13 -07:00
8e4657a9d4
Nuke s3v.
...
As per FDO #17889 .
2009-10-22 12:29:30 -07:00
06e464c2d5
r300g: Clean up duplicate code in r300_render.
2009-10-22 11:50:51 -07:00
1f7f9bab81
r300g: Move render functions to r300_render.
...
Part of the fastpath cleanup.
2009-10-22 11:50:51 -07:00
bf48447caf
scons: Hack LLVM support on Windows.
...
Doesn't quite work yet though, as small differences in the compilation flags
used when building LLVM and Mesa cause link failures for STL symbols.
2009-10-22 19:12:14 +01:00
Keith Whitwell