| Age | Commit message (Collapse) | Author |
|---|
|
Fixes bug #22370
|
|
|
|
i915 textured video commands are quite long, but must be contained in the
same batch buffer as the 3D setup commands. When the number of clip rects
for the video becomes too large for the associated commands to fit in the
same batch buffer, this change breaks the sequence into pieces, ensuring
that each batch contains the necessary setup sequence.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
|
|
It's been broken for years now, and KMS offers a much better chance of getting
this working sensibly without making a mess of the 2D driver.
|
|
Forgot to update i915_video.c in 872aadc7102bd5131e1582ede081e22672911ba2.
|
|
|
|
|
|
Conflicts:
configure.ac
src/reg_dumper/Makefile.am
|
|
As xvmc rendering result has already been in fb, we shouldn't
do extra copy on it. Although special care is required for i915
xvmc surface pitch alignment, which must be at least 1KB aligned.
So video display function should take it into acount instead of
always setting Y pitch to be double of U/V pitch.
|
|
This is based on airlied's RING->BATCH commit. The 965 code still needs to
be fixed up for relocations.
|
|
|
|
Several uses are actually left, which are determined by the X Server
interfaces we're implementing.
|
|
|
|
Use consistent interface for counting pixmap offset.
|
|
Front buffer tiling is now disabled with G965 and XAA. Some of the acceleration
that i830_xaa.c does can't be supported on tiled buffers.
Adds a tiling field to struct i830_memory, and uses it instead of separate
variables for each potential tiled buffer.
|
|
- change framebuffer option name to "FramebufferCompression"
- add new "Tiling" option (controls all tiling, not just front buffer)
- add debug message to fb compression enable/disable routines
- update man page with new options
|
|
|
|
Now, all 3D pipeline consumers in the driver just call
IntelEmitInvariantState(), which handles basic state setup, the caching of that
state setup, and notifying DRI clients. This also removes a mistaken idle
wait in the Render code which was papering over the brokenness in the context
switching.
|
|
- The screen dimensions were used for the clipping despite drawing being done
to any pixmap, not necessarily the screen.
- One piece of state setup was not documented anywhere, and isn't used in other
3d hardware paths that also work.
- A 3DSTATE_MODES_1 command (830-class only) was issued even though it no
longer exists.
|
|
|
|
We should just call i830MarkSync/i830WaitSync in places we need,
which care for both XAA and EXA.
|
|
Currently, when the backing pixmap is not in framebuffer, we just BadAlloc
rather than drawing garbage to the front buffer. This can be fixed with EXA.
|
|
|
|
|
|
Conflicts:
man/i810.man
src/Makefile.am
src/i830.h
src/i830_driver.c
src/i830_rotate.c
src/i830_video.c
|
|
|
|
Now, the generic invariant state is always set while the X Server is active,
and happens automatically when the X Server grabs the DRI lock. More 3D state
is moved to the generic code.
Then, the 3D consumers (video, rotation, render) set last_3d to their enum
entry, and can update their own invariant state when another consumer was
active.
|
|
|
|
Although in the history of this branch it had happened before, this time it's
for real.
|
|
This moves the i915 textured video implementation into i915_video.c to avoid
conflicts in register definitions with i830_reg.h when we use i915_reg.h.
This also means that i810_reg.h's i915 3D regs definitions are removed and
replaced with i915_reg.h usage.
Conflicts:
src/i830_rotate.c
|
