In my review of
commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9
Author: Rob Clark robdcl...@gmail.com
Date: Fri May 30 11:37:03 2014 -0400
drm: add object property typ
I asked for a check to make sure that we never leak an fb from the
generic mode object lookup since those have completely
On Wed, Jul 23, 2014 at 08:38:19PM -0300, Paulo Zanoni wrote:
2014-07-23 19:41 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Thu, Jul 24, 2014 at 12:35:25AM +0200, Daniel Vetter wrote:
On Wed, Jul 23, 2014 at 06:30:59PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
In my review of
commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9
Author: Rob Clark robdcl...@gmail.com
Date: Fri May 30 11:37:03 2014 -0400
drm: add object property typ
I asked for a check to make sure that we never leak an fb from the
generic mode object lookup since those have completely
Hi Dave,
This time in time! Just 32bit-pae fix from Hugh, semaphores fun from Chris
and a fix for runtime pm cherry-picked from next.
Paulo is still working on a fix for runtime pm when X does cursor fun when
the display is off, but that one isn't ready yet.
Cheers, Daniel
The following
On Thu, Jul 24, 2014 at 09:54:27AM +0200, Daniel Vetter wrote:
In my review of
commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9
Author: Rob Clark robdcl...@gmail.com
Date: Fri May 30 11:37:03 2014 -0400
drm: add object property typ
I asked for a check to make sure that we never
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Tuesday, July 22, 2014 11:15 AM
To: Intel-gfx@lists.freedesktop.org
Cc: Tvrtko Ursulin; Ursulin, Tvrtko; Gore, Tim
Subject: [PATCH] igt/gem_userptr_blits: Fix multi-threaded mm stress tester
Two
On Thu, Jul 24, 2014 at 08:19:19AM +, Gore, Tim wrote:
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Tuesday, July 22, 2014 11:15 AM
To: Intel-gfx@lists.freedesktop.org
Cc: Tvrtko Ursulin; Ursulin, Tvrtko; Gore, Tim
Subject: [PATCH]
Looks fine to me
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Wednesday, July 23, 2014 11:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim; daniel.vet...@ffwll.ch
Subject: [PATCH i-g-t 1/8] lib: warn when attempting to run an unknown
subtest
Looks fine to me.
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Wednesday, July 23, 2014 11:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim; daniel.vet...@ffwll.ch
Subject: [PATCH i-g-t 2/8] tests: remove unused getopt header includes
Looks fine.
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Wednesday, July 23, 2014 11:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim; daniel.vet...@ffwll.ch
Subject: [PATCH i-g-t 3/8] lib: move option parsing into common_init
Move option
Looks fine.
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Wednesday, July 23, 2014 11:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim; daniel.vet...@ffwll.ch
Subject: [PATCH i-g-t 4/8] lib: add igt_simple_init_parse_opts
This function allows
Looks sensible.
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Wednesday, July 23, 2014 11:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim; daniel.vet...@ffwll.ch
Subject: [PATCH i-g-t 5/8] lib: don't ignore unknown options in multi-tests
None
In my review of
commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9
Author: Rob Clark robdcl...@gmail.com
Date: Fri May 30 11:37:03 2014 -0400
drm: add object property typ
I asked for a check to make sure that we never leak an fb from the
generic mode object lookup since those have completely
There is a problem here with the -r option in gem_seqno_wrap, as this conflicts
with the --run-subtest option in common_init. This is a general issue with this
method of splitting the responsibility for parsing the command line. As the
common command line options defined in common_init
Yes, this looks sensible.
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Wednesday, July 23, 2014 11:58 AM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim; daniel.vet...@ffwll.ch
Subject: [PATCH i-g-t 7/8] lib: always warn about unknown options
All
See my comment on patch 6. --debug returns 'd' from getopt, which can conflict
with the short options for some tests, such as gem_render_copy and
gem_seqn0_wrap.
This problem also exists for the --run-subtest.
Tim
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
On 07/07/2014 22:24, Daniel Vetter wrote:
On Mon, Jul 7, 2014 at 11:16 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
I don't think it's unreasonable to use a macro that checks a global
list for whether to apply a given WA. They'll be scattered all over,
but at least it'll be easy to see:
One of the side-effects we test for are kernel oops and knowing the
guilty subtest can help speed up debugging. We can write to /dev/kmsg to
inject messages into dmesg, so let's do so before the start of every
test.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
lib/igt_core.c | 29
Move the code around in order to acquire and release the spinlock in the
same function and in the same block. This keeps static analysers happy
and the reader sane.
Suggested-by: Julia Lawall julia.law...@lip6.fr
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Julia Lawall
On Thu, Jul 24, 2014 at 11:43:11AM +0100, Siluvery, Arun wrote:
On 07/07/2014 22:24, Daniel Vetter wrote:
On Mon, Jul 7, 2014 at 11:16 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I don't think it's unreasonable to use a macro that checks a global
list for whether to apply a given WA.
On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote:
One of the side-effects we test for are kernel oops and knowing the
guilty subtest can help speed up debugging. We can write to /dev/kmsg to
inject messages into dmesg, so let's do so before the start of every
test.
On 24/07/2014 13:33, Daniel Vetter wrote:
On Thu, Jul 24, 2014 at 11:43:11AM +0100, Siluvery, Arun wrote:
On 07/07/2014 22:24, Daniel Vetter wrote:
On Mon, Jul 7, 2014 at 11:16 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
I don't think it's unreasonable to use a macro that checks a global
On 24 July 2014 13:36, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote:
One of the side-effects we test for are kernel oops and knowing the
guilty subtest can help speed up debugging. We can write to /dev/kmsg to
inject messages into dmesg, so
All of the NULL tests are a bit complicated but since they are there
anyway, I guess it is reasonable to take advantage of them.
julia
On Thu, 24 Jul 2014, Chris Wilson wrote:
Move the code around in order to acquire and release the spinlock in the
same function and in the same block. This
In order to prevent external observers walking the list of open DRM
files from seeing an invalid drm_file_private in the process of being
torndown, the first operation we need to take is to unlink the
drm_file_private from that list.
general protection fault: [#1] PREEMPT SMP
Hi
On Thu, Jul 24, 2014 at 3:23 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
In order to prevent external observers walking the list of open DRM
files from seeing an invalid drm_file_private in the process of being
torndown, the first operation we need to take is to unlink the
From: Tim Gore tim.g...@intel.com
commit 745945546f7366a413a3a51a37f90caa3a227b1d
breaks the build under Android because some of the
macros used in pm_rps.c are defined in sys/wait.h
which is not included.
Signed-off-by: Tim Gore tim.g...@intel.com
---
tests/pm_rps.c | 1 +
1 file changed, 1
On Thu, Jul 24, 2014 at 02:03:01PM +0100, Thomas Wood wrote:
On 24 July 2014 13:36, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote:
One of the side-effects we test for are kernel oops and knowing the
guilty subtest can help speed up
On Thu, Jul 24, 2014 at 02:58:08PM +0100, Chris Wilson wrote:
On Thu, Jul 24, 2014 at 02:03:01PM +0100, Thomas Wood wrote:
On 24 July 2014 13:36, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Jul 24, 2014 at 12:48:33PM +0100, Chris Wilson wrote:
One of the side-effects we test for are
From: Rafael Barbalho rafael.barba...@intel.com
This particular nasty presented itself while trying to register the
intelfb device (intel_fbdev.c). During the process of registering the device
the driver will disable the crtc via i9xx_crtc_disable. These will
also disable the panel using the
From: Tim Gore tim.g...@intel.com
commit 743dc7997aa9f5210055896940d87c88983dcda6
breaks the build under Android because version.h
is not created. This happens because the android
make executes from the ANDROID_BUILD_TOP directory
rather than from the directory containing the source
files, so we
On 24 July 2014 15:40, tim.g...@intel.com wrote:
From: Tim Gore tim.g...@intel.com
commit 743dc7997aa9f5210055896940d87c88983dcda6
breaks the build under Android because version.h
is not created. This happens because the android
make executes from the ANDROID_BUILD_TOP directory
rather
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Thursday, July 24, 2014 4:27 PM
To: Gore, Tim
Cc: Intel Graphics Development
Subject: Re: [Intel-gfx] [PATCH] intel-gpu-tools: fix version.h creation in
android
On 24 July 2014 15:40, tim.g...@intel.com
On 23/07/2014 19:50, Daniel Vetter wrote:
On Wed, Jul 23, 2014 at 5:37 PM, John Harrison
john.c.harri...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 0977653..fbafa68 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++
From: Oscar Mateo oscar.ma...@intel.com
For the most part, logical ring context objects are similar to hardware
contexts in that the backing object is meant to be opaque. There are
some exceptions where we need to poke certain offsets of the object for
initialization, updating the tail pointer or
From: Oscar Mateo oscar.ma...@intel.com
Any given ringbuffer is unequivocally tied to one context and one engine.
By setting the appropriate pointers to them, the ringbuffer struct holds
all the infromation you might need to submit a workload for processing,
Execlists style.
Signed-off-by: Oscar
From: Thomas Daniel thomas.dan...@intel.com
For a description of this patchset, please check the previous cover letters:
[1], [2], [3] and [4].
I have taken ownership of this patchset from Oscar, and this version represents
his last work on the execlists patchset. The narrative below is from
From: Oscar Mateo oscar.ma...@intel.com
For the moment this is just a placeholder, but it shows one of the
main differences between the good ol' HW contexts and the shiny
new Logical Ring Contexts: LR contexts allocate and free their
own backing objects. Another difference is that the allocation
From: Oscar Mateo oscar.ma...@intel.com
GEN8 brings an expansion of the HW contexts: Logical Ring Contexts.
These expanded contexts enable a number of new abilities, especially
Execlists.
The macro is defined to off until we have things in place to hope to
work.
v2: Rename advanced contexts to
From: Oscar Mateo oscar.ma...@intel.com
In this patch:
commit 78382593e921c88371abd019aca8978db3248a8f
Author: Oscar Mateo oscar.ma...@intel.com
Date: Thu Jul 3 16:28:05 2014 +0100
drm/i915: Extract the actual workload submission mechanism from execbuffer
So that we isolate the
From: Oscar Mateo oscar.ma...@intel.com
The backing objects and ringbuffers for contexts created via open
fd are actually empty until the user starts sending execbuffers to
them. At that point, we allocate populate them. We do this because,
at create time, we really don't know which engine is
From: Oscar Mateo oscar.ma...@intel.com
A context backing object only makes sense for a given engine (because
it holds state data specific to that engine).
In legacy ringbuffer sumission mode, the only MI_SET_CONTEXT we really
perform is for the render engine, so one backing object is all we
From: Oscar Mateo oscar.ma...@intel.com
These two functions make no sense in an Logical Ring Context Execlists
world.
v2: We got rid of lrc_enabled and centralized everything in the sanitized
i915.enbale_execlists instead.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
From: Oscar Mateo oscar.ma...@intel.com
Allocate and populate the default LRC for every ring, call
gen-specific init/cleanup, init/fini the command parser and
set the status page (now inside the LRC object). These are
things all engines/rings have in common.
Stopping the ring before cleanup and
From: Oscar Mateo oscar.ma...@intel.com
On a previous iteration of this patch, I created an Execlists
version of __i915_add_request and asbtracted it away as a
vfunc. Daniel Vetter wondered then why that was needed:
with the clean split in command submission I expect every
function to know
From: Oscar Mateo oscar.ma...@intel.com
Execlists are indeed a brave new world with respect to workload
submission to the GPU.
In previous version of these series, I have tried to impact the
legacy ringbuffer submission path as little as possible (mostly,
passing the context around and using the
From: Oscar Mateo oscar.ma...@intel.com
Each logical ring context has the tail pointer in the context object,
so update it before submission.
v2: New namespace.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19
From: Oscar Mateo oscar.ma...@intel.com
This is what i915_gem_do_execbuffer calls when it wants to execute some
worload in an Execlists world.
v2: Check arguments before doing stuff in intel_execlists_submission. Also,
get rel_constants parsing right.
Signed-off-by: Oscar Mateo
From: Oscar Mateo oscar.ma...@intel.com
This is a hard one, since there is no direct hardware ring to
control when in Execlists.
We reuse intel_ring_idle here, but it should be fine as long
as i915_add_request does the ring thing.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
From: Ben Widawsky benjamin.widaw...@intel.com
A context switch occurs by submitting a context descriptor to the
ExecList Submission Port. Given that we can now initialize a context,
it's possible to begin implementing the context switch by creating the
descriptor and submitting it to ELSP
From: Oscar Mateo oscar.ma...@intel.com
The normal flip function places things in the ring in the legacy
way, so we either fix that or force MMIO flips always as we do in
this patch.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |2 ++
From: Oscar Mateo oscar.ma...@intel.com
The time has come, the Walrus said, to talk of many things.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
From: Oscar Mateo oscar.ma...@intel.com
We need to attend context switch interrupts from all rings. Also, fixed writing
IMR/IER and added HWSTAM at ring init time.
Notice that, if added to irq_enable_mask, the context switch interrupts would
be incorrectly masked out when the user interrupts are
From: Oscar Mateo oscar.ma...@intel.com
No mistery here: the seqno is still retrieved from the engine's
HW status page (the one in the default context. For the moment,
I see no reason to worry about other context's HWS page).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
From: Ben Widawsky b...@bwidawsk.net
This has turned out to be really handy in debug so far.
Update:
Since writing this patch, I've gotten similar code upstream for error
state. I've used it quite a bit in debugfs however, and I'd like to keep
it here at least until preemption is working.
From: Oscar Mateo oscar.ma...@intel.com
Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.
TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful
From: Michel Thierry michel.thie...@intel.com
Context switch (and execlist submission) should happen only when
other contexts are not active, otherwise pre-emption occurs.
To assure this, we place context switch requests in a queue and those
request are later consumed when the right context
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to schedule new contexts on interrupt when a previously submitted
context
From: Oscar Mateo oscar.ma...@intel.com
Very similar to the legacy add_request, only modified to account for
logical ringbuffer.
v2: Use MI_GLOBAL_GTT, as suggested by Brad Volkin.
v3: Unify render and non-render in the same function, as noticed by
Brad Volkin.
Signed-off-by: Oscar Mateo
From: Oscar Mateo oscar.ma...@intel.com
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests.
v2: The ring is, at this point, already being correctly re-programmed
for Execlists, and the hangcheck counters cleared.
v3: Daniel suggests to drop the
From: Oscar Mateo oscar.ma...@intel.com
v2: Warn and return if LRCs are not enabled.
v3: Grab the Execlists spinlock (noticed by Daniel Vetter).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 73 +++
From: Oscar Mateo oscar.ma...@intel.com
Dispatch_execbuffer's evil twin.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 28
drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++
2 files changed, 30 insertions(+)
diff
From: Oscar Mateo oscar.ma...@intel.com
Some legacy HW context code assumptions don't make sense for this new
submission method, so we will place this stuff in a separate file.
Note for reviewers: I've carefully considered the best name for this file
and this was my best option (other
From: Oscar Mateo oscar.ma...@intel.com
Now that we have the ability to allocate our own context backing objects
and we have multiplexed one of them per engine inside the context structs,
we can finally allocate and free them correctly.
Regarding the context size, reading the register to
From: Oscar Mateo oscar.ma...@intel.com
Up until recently, semaphores weren't enabled in BDW so we didn't care
about them. But then Rodrigo came and enabled them:
commit 521e62e49a42661a4ee0102644517dbe2f100a23
Author: Rodrigo Vivi rodrigo.v...@intel.com
drm/i915: Enable semaphores
From: Oscar Mateo oscar.ma...@intel.com
In the current Execlists feeding mechanism, full preemption is not
supported yet: only lite-restores are allowed (this is: the GPU
simply samples a new tail pointer for the context currently in
execution).
But we have identified an scenario in which a full
From: Oscar Mateo oscar.ma...@intel.com
Well, new-ish: if all this code looks familiar, that's because it's
a clone of the existing submission mechanism (with some modifications
here and there to adapt it to LRCs and Execlists).
And why did we do this instead of reusing code, one might wonder?
From: Oscar Mateo oscar.ma...@intel.com
Up until now, we have pinned every logical ring context backing object
during creation, and left it pinned until destruction. This made my life
easier, but it's a harmful thing to do, because we cause fragmentation
of the GGTT (and, eventually, we would run
From: Oscar Mateo oscar.ma...@intel.com
The batchbuffer that sets the render context state is submitted
in a different way, and from different places.
We needed to make both the render state preparation and free functions
outside accesible, and namespace accordingly. This mess is so that all
LR,
From: Oscar Mateo oscar.ma...@intel.com
Same as the legacy-style ring-flush.
v2: The BSD invalidate bit still exists in GEN8! Add it for the VCS
rings (but still consolidate the blt and bsd ring flushes into one).
This was noticed by Brad Volkin.
v3: The command for BSD and for other rings is
From: Oscar Mateo oscar.ma...@intel.com
Same as with the context, pinning to GGTT regardless is harmful (it
badly fragments the GGTT and can even exhaust it).
Unfortunately, this case is also more complex than the previous one
because we need to map and access the ringbuffer in several places
From: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
From: Oscar Mateo oscar.ma...@intel.com
Add theory of operation notes to intel_lrc.c and comments to externally
visible functions.
v2: Add notes on logical ring context creation.
v3: Use kerneldoc.
v4: Integrate it in the DocBook template.
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking for
contexts to squash together. Instead, share the burden by giving more
intelligence to the queue
From: Oscar Mateo oscar.ma...@intel.com
Logical rings do not need most of the initialization their
legacy ringbuffer counterparts do: we just need the pipe
control object for the render ring, enable Execlists on the
hardware and a few workarounds.
v2: Squash with: drm/i915: Extract pipe control
From: Oscar Mateo oscar.ma...@intel.com
As suggested by Daniel Vetter. The idea, in subsequent patches, is to
provide an alternative to these vfuncs for the Execlists submission
mechanism.
v2: Splitted into two and reordered to illustrate our intentions, instead
of showing it off. Also, remove
From: Tim Gore tim.g...@intel.com
commit 743dc7997aa9f5210055896940d87c88983dcda6
breaks the build under Android because version.h
is not created. This happens because the android
make executes from the ANDROID_BUILD_TOP directory
rather than from the directory containing the source
files, so we
If that won't work, you could just use a timer, or tie into some other
event that happens when the GPU is busy (e.g. execbuf or retire) instead
of trying to tie into the display side of things.
Jesse
On Tue, 15 Jul 2014 06:35:20 +
Sun, Daisy daisy@intel.com wrote:
Hi Daniel, Chris
I spent the day just cleaning up this patch series and testing. I
think it's ready for others to use and review. I've been running it on
two machines for a couple of days now and it's been solid.
I ran three different desktop environments (current Debian unstable versions):
XFCE 4.10
UXA and Glamor both share this function, so move it out of the UXA file.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/intel.h| 5 ++
src/uxa/intel_memory.c | 138 ++
src/uxa/intel_uxa.c| 158
Was using 'low_msc', which isn't defined anymore.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/intel_present.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/uxa/intel_present.c b/src/uxa/intel_present.c
index 18fcbf8..5f98da8 100644
---
---
src/uxa/intel_uxa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/uxa/intel_uxa.c b/src/uxa/intel_uxa.c
index b396188..717754f 100644
--- a/src/uxa/intel_uxa.c
+++ b/src/uxa/intel_uxa.c
@@ -758,6 +758,7 @@ free_priv:
goto free_priv;
}
+#if
GetScratchPixmapHeader should only be used for local memory pixmaps,
as used by PutImage and friends. That's because when you free the
scratch pixmap header, it doesn't actually free the pixmap; instead,
it gets stuffed in pScreen-pScratchPixmap and any private data stored
on it will be left
This adds glamor support back into the driver, but instad of going
through UXA, this uses it directly instead.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/intel.h | 17 +++
src/uxa/intel_display.c | 30 -
src/uxa/intel_dri.c | 20 +++
src/uxa/intel_driver.c |
Makes UXA no longer include calls to glamor acceleration functions.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/Makefile.am| 9 --
src/uxa/intel_dri.c| 60 +
src/uxa/intel_driver.c | 1 -
src/uxa/intel_uxa.c| 49 ---
src/uxa/intel_uxa.h|
intel_flush flushes any pending acceleration operations to the
hardware, just like intel_uxa_batch_submit does today except that it is
not uxa-specific.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/intel.h | 3 +++
src/uxa/intel_display.c | 11 +++
This eliminates the stubs in intel_glamor.h and replaces them with
ifdefs instead.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/intel_dri.c | 20 ++--
src/uxa/intel_driver.c | 6 ++
src/uxa/intel_glamor.h | 21 -
This just uses fb directly
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac| 24 -
src/Makefile.am | 9 +-
src/intel_module.c | 12 ++-
src/uxa/Makefile.am | 46 ++---
src/uxa/intel.h | 5 +
src/uxa/intel_display.c | 6 ++
Wait until the root window has been painted for the first time before
doing the modeset. This avoids flashing black while the root window
gets set up.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/intel.h | 2 ++
src/uxa/intel_display.c | 39
Make sure the pitch and tiling are correct.
Make sure there's a BO we can get at.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/intel_present.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/uxa/intel_present.c b/src/uxa/intel_present.c
index
On Wed, Jul 23, 2014 at 11:34:56PM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
In valleyview we have two pipe level color correction
properties:
1. CSC correction (wide gamut)
2. Gamma correction
What this patch does:
1. This patch adds
On Thu, Jul 24, 2014 at 04:08:41AM +, Sharma, Shashank wrote:
Hi Daniel,
Thanks for your time and comments.
The current design is exactly same as we discussed previously in the mail
chain, color manager is just the framework which does this job:
1. Create a DRM property for
On Wed, Jul 23, 2014 at 10:32:43PM +0200, Daniel Vetter wrote:
---
NEWS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/NEWS b/NEWS
index 1b5ee83ec849..4866d59b5619 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,12 @@ Release 1.8 (-xx-xx)
- As usual piles of new tests.
On 23 July 2014 15:11, Daniel Vetter dan...@ffwll.ch wrote:
On Sat, Jul 12, 2014 at 10:02:27AM +0530, sagar.a.kam...@intel.com wrote:
From: Borun Fu borun...@intel.com
On VLV, after i915_pm_suspend display power wells are staying
power ungated. So, after initiating mem sleep echo mem
Thanks for your time, and review comments Matt.
I appreciate the suggestions by you, Daniel.
But I need a few more details, and I have a few concerns with the design
you suggest, please find my comments inline.
Regards
Shashank
On 7/25/2014 6:13 AM, Matt Roper wrote:
On Thu, Jul 24, 2014 at
95 matches
Mail list logo
