In the long long ago, fbOffset was used for DGA. The server now has
only one reference to fbOffset, a leftover setting of it in fbdevhw.
We can safely ignore it now, which is good since we weren't updating
it in other places where the front buffer offset could change.
We know that it's clobbered at each batchbuffer, anyway. And even if
this server isn't running DRI2, it can still be clobbered at batch
start in the KMS world.
The code was using uint32_t where an XID (currently an unsigned long)
was specified in the prototype. Use XID to avoid both the warning and
any potential problem.
The previous code made no sense, (multiplying an offset by 4 is
meaningless). It could have onlt worked with the offset being
fortuitously 0.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Like with the per context stuff, also drop the now artificial limit
on surfaces. Again, with that gone, a lot of code can be deleted.
Reviewed-by: Carl Worth <cworth@cworth.org>
There's now not a reason anymore to limit the number of active contexts.
So kill this accounting, too.
With that all gone, per-context state in the ddx is nil, so rip out
all associated code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Proper bo management ensures that the cpu doesn't step on buffers
used by the gpu. Drop the now unnecessary synchronization.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Cache coherency is now fully under the control of gem.
For lack of hw documentation, I had to find out the correct cache
placements by trial and error:
Backward and forward surfaces: I915_GEM_DOMAIN_RENDER
Correlation data: I915_GEM_DOMAIN_SAMPLER
Changing any of them leads to visual corruptions, so I think these
are the correct ones.
Reviewed-by: Carl Worth <cworth@cworth.org>
Now the last user of the fixed buffers provided by the ddx is gone!
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
It works!
v2: Correlation data needs to be in the render cache!
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
I've decided to allocate a new buffer for every render command, to
prevent stalling for the gpu. libdrm bo reuse should take care of
not wasting memory in case the buffer is not busy.
Also always emit the full state, it's not worth it to complicate
the code over a few stores to wc memory.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Like with one_time_state_emit, this preps for relocatable bo's.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
This also starts to kill the last remnants of the support for
physical addresses for the indirect state buffers. With gem this
would need kernel support (in the form of a new reloc type in
execbuf2).
This does not change the ABI between ddx and client libIntelXvMC.
I've decided to do this in one swoop when all the buffer rework is
done.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Seems to be a remnant from i810 XvMC support. last_flip is always 0,
so serves no real purpose anymore. Kill it and the associated code.
With last_flip gone, last_render also lost its purpose. Kill it, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
This is in preparation for real relocatable drm_bo's instead
of memory at a fixed address. By switching to the batchbuffer
macros (like i965 xvmc) we can use the nice OUT_RELOC macro.
Also align the code more with coding-style elsewhere, i.e. bitops
instead of bitfield structures. The bitfield structures are
quite a mess to work with the batchbuffer macros, so they were
getting in the way, anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
WIP code that hasn't changed for over two years is unlikely to
suddenly start progressing. Drop it. After all, git can easily
resurect it in cases it's needed.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Yes, this breaks binary compat of the struct passed around between
X ddx and the client libXvMC. But we always ship both, so they should
not get out of sync.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Kill the corresponding !bo path in i830_free_memory.
Also kill another remnant of the pre-kms era in the same file, while I
was looking at the code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
It doesn't bind anything anymore, but does a few random things.
Give it a hopefully vague enough name to cover all cases ;)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Besides the debug stuff the went away in the previous patch,
this stuff was totally unused ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
Totally useless debug function from the pre-gem era. No point
to occasionally spam Xorg.log with a bogus "No memory allocations"
message.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
It's a left-over from the non-gem era and no longer used at all.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
On i965 class hw, kernel_exec_fencing was 1 always, anyway. And on
i945, this patch kills a memory leak (dunno how, but it does).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've accidentally broken i915 xvmc due to alignment constrains that
break my assumption that Y-pitch == UV-pitch*2. Fix this up by consistenly
using dstPitch2 for the Y-pitch. This also unifies the dst pitch
computation slightly, now that the i915 xvmc special case is gone.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25949
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(Minor edit to support compilation without INTEL_XVMC defined by
Carl Worth <cworth@cworth.org>)
In my previous cleanup I've inadvertedly dropped the offset adjustment
code for the xvmc passthrough case. Fix this up.
Also reimplement that ugly hack I've accidently killed to keep i915 class
xvmc a tad bit longer on life support.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: xunx.fang@intel.com
Rather than mangle the EDID block and hope the server does the right
thing, just build a sensible mode list up front. Do this for LVDS where
there is no EDID or where it does not claim to be continuous-frequency
(since in the latter case, the server will add reasonable modes for us).
Signed-off-by: Adam Jackson <ajax@redhat.com>
Eric Anholt
Carl Worth
Daniel Vetter
Adam Jackson