summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* i965g: rename brw_constant_buffer to brw_curbe_bufferKeith Whitwell2009-11-023-13/+7
| | | | Now that there are real constant buffers, try to reduce naming confusion.
* i965g: driver and winsys compileKeith Whitwell2009-11-0119-551/+308
| | | | | A milestone of sorts. Still a long way from something working -- the old one compiled too, at least some of the time...
* i965g: the whole drivers/i965 directory is compilingKeith Whitwell2009-11-013-143/+108
| | | | | | That was a lot more work than I expected. Still the winsys to go, then the small matter of making it work and re-enabling the missing functionality.
* i965g: more files compilingKeith Whitwell2009-11-014-166/+205
|
* i965g: more files compilingKeith Whitwell2009-11-018-147/+269
|
* i965g: more files compilingKeith Whitwell2009-11-017-322/+576
|
* i965g: more files compilingKeith Whitwell2009-11-017-161/+176
|
* i965g: more work on compilation -- surface managementKeith Whitwell2009-11-019-617/+474
|
* i965g: more work on compilationKeith Whitwell2009-10-316-171/+169
|
* i965g: non-glsl fragment shader path is compilingKeith Whitwell2009-10-318-192/+230
| | | | Disabled glsl code for now, probably want to clean this up somehow.
* i965g: wip on fragment shadersKeith Whitwell2009-10-312-236/+698
|
* i965g: work in progress on fragment shadersKeith Whitwell2009-10-2918-1000/+682
|
* i965g: still working on compilationKeith Whitwell2009-10-286-90/+208
|
* i965g: still working on compilationKeith Whitwell2009-10-277-88/+83
|
* i965g: still working on compilationKeith Whitwell2009-10-269-470/+485
|
* i965g: still working on compilationKeith Whitwell2009-10-2638-680/+789
|
* i965g: start hooking up some to the gallium context interfacesKeith Whitwell2009-10-2512-294/+519
| | | | | | - create/bind/destroy blend and depth state - framebuffer and viewport - etc.
* i965g: more compiling wipKeith Whitwell2009-10-2516-200/+243
|
* i965g: more work on compiling, particularly the brw_draw filesKeith Whitwell2009-10-2533-404/+722
|
* i965g: more work on compilingKeith Whitwell2009-10-2443-603/+920
|
* i965g: more files compilingKeith Whitwell2009-10-2447-492/+1027
|
* ws/i965: renames from i915, hook up makefilesKeith Whitwell2009-10-2412-237/+236
|
* i965g: first compiling fileKeith Whitwell2009-10-245-35/+114
|
* ws/i965: pull in the rest of the i915 winsys tree.Keith Whitwell2009-10-237-0/+299
| | | | | | 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.
* ws/i965: clone the i915 winsysKeith Whitwell2009-10-237-0/+799
| | | | | | 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.
* i965g: wip on removing GL stuff, trying to get a few files compilingKeith Whitwell2009-10-2350-1021/+421
|
* i965: ignore cliprect_modeKeith Whitwell2009-10-231-17/+4
|
* i965g: wipKeith Whitwell2009-10-2340-2599/+907
|
* i965g: re-starting from the dri driverKeith Whitwell2009-10-2368-0/+29208
|
* gallium: remove extended negate also, and also the ExtSwz tokenKeith Whitwell2009-10-2315-346/+11
| | | | | | 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.
* cell: typo from ExtSwizzle commitKeith Whitwell2009-10-231-1/+1
|
* gallium: remove the swizzling parts of ExtSwizzleKeith Whitwell2009-10-2326-489/+96
| | | | | | | | | 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.
* gallium: remove noise opcodesKeith Whitwell2009-10-2310-77/+20
| | | | | | | | | | | 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.
* r300g: last changes's typo, miss a include fileCooper Yuan2009-10-231-0/+1
|
* r300g: add flush_frontbuffer function to display video surfaceCooper Yuan2009-10-231-1/+51
|
* g3dvl: pass display and screen to g3dvl when creating video private contextCooper Yuan2009-10-233-5/+7
|
* r600: remove remains of old tnl pipelineAlex Deucher2009-10-237-268/+41
|
* r600: fix render size predictionAlex Deucher2009-10-233-20/+20
|
* r600: remove old tnl pipelineAlex Deucher2009-10-232-192/+34
|
* r600: clean up context creationAlex Deucher2009-10-231-102/+100
| | | | Make it more consistent with other radeon drivers.
* Revert "Store clipping distance for user clip planes as part of vertex ↵Ian Romanick2009-10-224-132/+18
| | | | | | | | | | processing" This reverts commit f058b25881e08c9d89a33345e5c84e1357396932. This change is completely wrong in so many ways. When clip distances are generated as part of vertex processing, they must be interpolated to perform clipping. Geometric clipping goes right out the window.
* Merge branch 'mesa_7_6_branch'Brian Paul2009-10-228-19/+84
|\
| * intel: flush old context before binding new contextBrian Paul2009-10-221-2/+15
| | | | | | | | | | Per the GLX spec, when changing rendering contexts, the old context should first be flushed.
| * glx: don't destroy context immediately if it's currently boundBrian Paul2009-10-221-0/+10
| | | | | | | | | | | | | | 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.
| * mesa: code refactoring- new _mesa_finish(), _mesa_flush()Brian Paul2009-10-222-8/+37
| |
| * i965: fix hacked Fallback usage in brw_prepare_vertices()Brian Paul2009-10-222-2/+6
| | | | | | | | | | | | | | | | 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).
| * intel: define INTEL_FALLBACK_DRIVER for driversBrian Paul2009-10-221-0/+1
| |
| * intel: Fallback field is a bitmask, use GLbitfieldBrian Paul2009-10-223-5/+14
| |
| * i965: remove unused brw_context::tmp_fallback fieldBrian Paul2009-10-221-1/+0
| |
| * i965: remove unused BRW_FALLBACK_TEXTURE bitBrian Paul2009-10-221-1/+1
| | | | | | | | | | The value was probably wrong too. It was the same as INTEL_FALLBACK_DRAW_BUFFER.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 08:53:22 +0000