On Mon, Nov 25, 2013 at 09:08:50PM +0200, Ville Syrjälä wrote:
On Mon, Nov 25, 2013 at 10:10:28AM -0800, Ben Widawsky wrote:
On Mon, Nov 25, 2013 at 06:06:18PM +, Chris Wilson wrote:
On Mon, Nov 25, 2013 at 09:54:35AM -0800, Ben Widawsky wrote:
Since the beginning, the functions
On Mon, Nov 25, 2013 at 06:38:53PM -0800, Ben Widawsky wrote:
On Mon, Nov 25, 2013 at 11:25:10PM +, Chris Wilson wrote:
On Mon, Nov 25, 2013 at 02:17:55PM -0800, Ben Widawsky wrote:
On Thu, Nov 21, 2013 at 04:00:17PM +, Chris Wilson wrote:
On Thu, Nov 21, 2013 at 01:47:32PM
On Mon, Nov 25, 2013 at 09:54:41AM -0800, Ben Widawsky wrote:
To be able to effectively use the GGTT object lookup function, we don't
want to warn when there is no GGTT mapping. Let the caller deal with it
instead.
Originally, I had intended to have this behavior, and has not
introduced the
On Mon, Nov 25, 2013 at 09:54:42AM -0800, Ben Widawsky wrote:
This was found by code inspection. If the GTT setup fails then we are
left without properly tearing down the drm_mm.
Hopefully this never happens.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
On Tue, Nov 26, 2013 at 01:41:57PM +0530, kirankumar wrote:
changing DP AUX control timeout to 600 instead of 400 for BDW.
DP spec says 400 us, so a notch more context in the commit message would
be appreciated. E.g. if this is used to work around dp aux failures, then
the commit message _must_
On Fri, Nov 22, 2013 at 12:46:40PM -0800, Jesse Barnes wrote:
On Fri, 22 Nov 2013 20:35:24 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
I believe, and an evening of i-g-t, that our original workaround for the
missed interrupts on Sandybridge, that of holding forcewake whilst we
Hi Chris,
We are using single write fifo for the multiple power wells. Since Valleyview
as only supports only one write fifo.
Thanks
Deepak
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Monday, November 25, 2013 8:18 PM
To: S, Deepak
Cc:
Yes Jesse, this is a warning fix.
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Monday, November 25, 2013 10:09 PM
To: S, Deepak
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Enabling DebugFS for valleyview
forcewake
As the execbuffer dispatch grows ever more complex and involves multiple
stages of moving objects into the aperture, we need to take greater care
that we do not evict our execbuffer objects prior to dispatch. This is
relatively simple as we can just keep the objects pinned for not just
the
On Tue, Nov 26, 2013 at 11:23:15AM +, Chris Wilson wrote:
As the execbuffer dispatch grows ever more complex and involves multiple
stages of moving objects into the aperture, we need to take greater care
that we do not evict our execbuffer objects prior to dispatch. This is
relatively
On Mon, Nov 25, 2013 at 03:51:15PM -0800, Jesse Barnes wrote:
And move it up in the file for earlier usage.
v2: add pre-gen4 support as well (Chris)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open
On Mon, Nov 25, 2013 at 03:51:17PM -0800, Jesse Barnes wrote:
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
On Mon, Nov 25, 2013 at 03:51:18PM -0800, Jesse Barnes wrote:
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration
On Mon, Nov 25, 2013 at 03:51:19PM -0800, Jesse Barnes wrote:
We want to preserve the BIOS/bootloader contents for later.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Decided this was better than my bikeshed,
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson,
Doing it early prevents moving and relocating objects in vain
for contexts that won't get any GPU time.
Reported-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 38 ++--
1
On Tue, Nov 26, 2013 at 04:14:33PM +0200, Mika Kuoppala wrote:
Doing it early prevents moving and relocating objects in vain
for contexts that won't get any GPU time.
Reported-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
Reviewed-by: Chris
2013/11/26 Chris Wilson ch...@chris-wilson.co.uk:
On Mon, Nov 25, 2013 at 06:38:53PM -0800, Ben Widawsky wrote:
On Mon, Nov 25, 2013 at 11:25:10PM +, Chris Wilson wrote:
On Mon, Nov 25, 2013 at 02:17:55PM -0800, Ben Widawsky wrote:
On Thu, Nov 21, 2013 at 04:00:17PM +, Chris Wilson
On Tue, 26 Nov 2013 13:57:10 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Nov 25, 2013 at 03:51:17PM -0800, Jesse Barnes wrote:
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached
On Tue, 26 Nov 2013 14:09:48 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Nov 25, 2013 at 03:51:18PM -0800, Jesse Barnes wrote:
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow
From: Brad Volkin bradley.d.vol...@intel.com
The command parser needs to know a few things about certain commands
in order to process them correctly. Add structures for storing that
information.
OTC-Tracker: AXIA-4631
Change-Id: I50b98c71c6655893291c78a2d1b8954577b37a30
Signed-off-by: Brad
From: Brad Volkin bradley.d.vol...@intel.com
For commands that aren't in the parser's tables, we get the length
based on standard per-ring command encodings for specific opcode ranges.
These functions just return the bitmask and the parser will extract the
actual length value.
OTC-Tracker:
From: Brad Volkin bradley.d.vol...@intel.com
PIPE_CONTROL and MI_FLUSH_DW have bits that would write to the
hardware status page. There are no users of this today and it
seems unsafe.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 30
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index
From: Brad Volkin bradley.d.vol...@intel.com
So userspace can query the kernel for command parser support.
OTC-Tracker: AXIA-4631
Change-Id: I58af650db9f6753c2dcac9c54ab432fd31db302f
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
From: Brad Volkin bradley.d.vol...@intel.com
A variety of checks we want to do amount to verifying that a given
bit or bits are set/clear in a given dword of a command. For now,
allow a small but arbitrary number of bitmasks for each command.
OTC-Tracker: AXIA-4631
Change-Id:
From: Brad Volkin bradley.d.vol...@intel.com
Various commands that access memory have a bit to determine whether
the graphics address specified in the command should use the GGTT or
PPGTT for translation. These checks ensure that the bit indicates
PPGTT translation.
Most of these checks use the
From: Brad Volkin bradley.d.vol...@intel.com
Certain commands are always disallowed from userspace. This adds
the ability for the command parser to detect such commands and
reject batch buffers containing them.
OTC-Tracker: AXIA-4631
Change-Id: I000b0df4d441ec80b607a50d35e83418cdfd38b3
From: Brad Volkin bradley.d.vol...@intel.com
These commands allow userspace to affect global state.
OTC-Tracker: AXIA-4631
Change-Id: I80a22c9cd83181790d2a9064e70ea09326691b66
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 15 +--
From: Brad Volkin bradley.d.vol...@intel.com
OTC-Tracker: AXIA-4631
Change-Id: I6747457e1fe7494bd42787af51198fcba398ad78
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 30 +++---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
3 files
From: Brad Volkin bradley.d.vol...@intel.com
These registers are currently used by mesa for blitting and
for transform feedback extensions.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 33 +
From: Brad Volkin bradley.d.vol...@intel.com
MI_USER_INTERRUPT: We're rejecting other interrupt-generating mechanisms
MI_LOAD_SCAN_LINES_*: The DDX is the only user of these and protects
them behind the I915_EXEC_SECURE flag, so we probably shouldn't let others
use these.
Signed-off-by: Brad
From: Brad Volkin bradley.d.vol...@intel.com
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_* commands allow userspace
access to registers. Only certain registers should be allowed for such
access, so enable checking for those commands.
OTC-Tracker: AXIA-4631
Change-Id:
From: Brad Volkin bradley.d.vol...@intel.com
Certain OpenGL features (e.g. transform feedback, performance monitoring)
require userspace code to submit batches containing commands such as
MI_LOAD_REGISTER_IMM to access various registers. Unfortunately, some
generations of the hardware will noop
From: Brad Volkin bradley.d.vol...@intel.com
At this point the parser just implements the mechanics of finding
commands in the batch buffer and looking them up in the parser tables.
It rejects poorly formed batches (e.g. no MI_BATCH_BUFFER_END command,
containing unrecognized commands, etc) but
From: Brad Volkin bradley.d.vol...@intel.com
Add command tables defining irregular length commands for each ring.
This requires a few new command opcode definitions.
OTC-Tracker: AXIA-4631
Change-Id: I064bceb457e15f46928058352afe76d918c58ef5
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
From: Brad Volkin bradley.d.vol...@intel.com
The length mask is different for each ring and the size can vary,
so we should duplicate the definition with the correct encoding
for each ring.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 35
From: Brad Volkin bradley.d.vol...@intel.com
These registers and commands will be used by mesa for the
GL_AMD_performance_monitor extension.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 27 +++
From: Brad Volkin bradley.d.vol...@intel.com
Some OpenGL/media features require userspace to perform register
accesses from batch buffers on Gen hardware.
To enable this, each ring gets a whitelist of registers that userspace
may access from a batch buffer. With this patch, no whitelists are
From: Brad Volkin bradley.d.vol...@intel.com
These checks prevent userspace from using certain commands to
access registers or generate interrupts.
OTC-Tracker: AXIA-4631
Change-Id: Ic6367ae98272495ba874c22abd4824fbced0abca
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
From: Brad Volkin bradley.d.vol...@intel.com
OTC-Tracker: AXIA-4631
Change-Id: Id178f67338d00c23ca4e8fc9499313dba93d2c5c
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 34 +
drivers/gpu/drm/i915/i915_drv.h
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
include/drm/i915_drm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c1914d6..525dc27 100644
--- a/include/drm/i915_drm.h
+++
From: Brad Volkin bradley.d.vol...@intel.com
Start with a simple testcase that should pass.
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/gem_exec_parse.c | 140 +
3
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
tests/gem_exec_parse.c | 81 ++
1 file changed, 81 insertions(+)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
tests/gem_exec_parse.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index d4136db..0eb328c 100644
---
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
This is just a theoretical issue, but we need to do this to prevent the
WARN in pipe_from_connector at suspend time.
https://bugs.freedesktop.org/show_bug.cgi?id=71978
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
1 file changed, 2
On Mon, Nov 25, 2013 at 03:51:15PM -0800, Jesse Barnes wrote:
And move it up in the file for earlier usage.
v2: add pre-gen4 support as well (Chris)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 53
++--
On Tue, Nov 26, 2013 at 08:51:22AM -0800, bradley.d.vol...@intel.com wrote:
+static const struct drm_i915_cmd_descriptor*
+find_cmd_in_table(const struct drm_i915_cmd_table *table,
+ u32 cmd_header)
+{
+ int i;
+
+ for (i = 0; i table-count; i++) {
+
On Tue, Nov 26, 2013 at 09:29:32AM -0800, Chris Wilson wrote:
On Tue, Nov 26, 2013 at 08:51:22AM -0800, bradley.d.vol...@intel.com wrote:
+static const struct drm_i915_cmd_descriptor*
+find_cmd_in_table(const struct drm_i915_cmd_table *table,
+ u32 cmd_header)
+{
+ int i;
On Tue, 26 Nov 2013 19:28:27 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Mon, Nov 25, 2013 at 03:51:15PM -0800, Jesse Barnes wrote:
And move it up in the file for earlier usage.
v2: add pre-gen4 support as well (Chris)
Signed-off-by: Jesse Barnes
On Mon, Nov 25, 2013 at 03:51:17PM -0800, Jesse Barnes wrote:
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
On Tue, Nov 26, 2013 at 02:09:48PM +, Chris Wilson wrote:
On Mon, Nov 25, 2013 at 03:51:18PM -0800, Jesse Barnes wrote:
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth
On Tue, Nov 26, 2013 at 09:38:55AM -0800, Volkin, Bradley D wrote:
On Tue, Nov 26, 2013 at 09:29:32AM -0800, Chris Wilson wrote:
On Tue, Nov 26, 2013 at 08:51:22AM -0800, bradley.d.vol...@intel.com wrote:
+static const struct drm_i915_cmd_descriptor*
+find_cmd_in_table(const struct
On Mon, Nov 25, 2013 at 03:51:15PM -0800, Jesse Barnes wrote:
And move it up in the file for earlier usage.
v2: add pre-gen4 support as well (Chris)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 53
++--
On Tue, Nov 26, 2013 at 09:13:41AM -0800, Jesse Barnes wrote:
This is just a theoretical issue, but we need to do this to prevent the
WARN in pipe_from_connector at suspend time.
https://bugs.freedesktop.org/show_bug.cgi?id=71978
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Picked
On Tue, Nov 26, 2013 at 08:51:37AM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
The length mask is different for each ring and the size can vary,
so we should duplicate the definition with the correct encoding
for each ring.
Jumping in here since
On Tue, 26 Nov 2013 18:43:53 +0100
Daniel Vetter dan...@ffwll.ch wrote:
+ plane_config-fb-base.pitches[0] =
+ intel_framebuffer_pitch_for_width(dev_priv,
+ plane_config-fb-base.width,
+
On Tue, Nov 19, 2013 at 11:36:58AM +0530, Vandana Kannan wrote:
Dynamic Refresh Rate Switching (DRRS) is a power conservation feature which
enables switching between low and high refresh rates based on the usage
scenario. This feature is applicable for internal eDP panel.
On Tue, 26 Nov 2013 18:54:04 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Nov 26, 2013 at 02:09:48PM +, Chris Wilson wrote:
On Mon, Nov 25, 2013 at 03:51:18PM -0800, Jesse Barnes wrote:
Retrieve current framebuffer config info from the regs and create an fb
object for the
2013/11/25 Imre Deak imre.d...@intel.com:
v2: rebase on latest kernel + debug info on domain use counts
v3: address review comments from Paulo
All my comments got implemented or got some nice explanations, so, for
the series:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Imre Deak (7):
On Tue, Nov 26, 2013 at 09:56:09AM -0800, Chris Wilson wrote:
On Tue, Nov 26, 2013 at 09:38:55AM -0800, Volkin, Bradley D wrote:
On Tue, Nov 26, 2013 at 09:29:32AM -0800, Chris Wilson wrote:
On Tue, Nov 26, 2013 at 08:51:22AM -0800, bradley.d.vol...@intel.com
wrote:
+static const
On Tue, Nov 26, 2013 at 10:08:48AM -0800, Chris Wilson wrote:
On Tue, Nov 26, 2013 at 08:51:37AM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
The length mask is different for each ring and the size can vary,
so we should duplicate the definition
On Tue, Nov 26, 2013 at 09:09:04AM +0100, Daniel Vetter wrote:
This is one of the nice pieces that I've never ported from the old
make based test runner. Note that we only use the result of the check
when actually running the testcases so that enumerating tests still
works as non-root on
On Tue, Nov 26, 2013 at 04:46:54PM -0200, Paulo Zanoni wrote:
2013/11/25 Imre Deak imre.d...@intel.com:
v2: rebase on latest kernel + debug info on domain use counts
v3: address review comments from Paulo
All my comments got implemented or got some nice explanations, so, for
the series:
This should just be a debug. Add another debug msg to the inherit path
while we're at it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_fbdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
Hi Brad,
On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
Certain OpenGL features (e.g. transform feedback, performance monitoring)
require userspace code to submit batches containing commands such as
On Tue, Nov 26, 2013 at 11:05:57AM -0800, Ben Widawsky wrote:
On Tue, Nov 26, 2013 at 09:09:04AM +0100, Daniel Vetter wrote:
This is one of the nice pieces that I've never ported from the old
make based test runner. Note that we only use the result of the check
when actually running the
On Tue, Nov 26, 2013 at 08:46:19PM +0100, Daniel Vetter wrote:
On Tue, Nov 26, 2013 at 11:05:57AM -0800, Ben Widawsky wrote:
On Tue, Nov 26, 2013 at 09:09:04AM +0100, Daniel Vetter wrote:
This is one of the nice pieces that I've never ported from the old
make based test runner. Note that
On Tue, Nov 26, 2013 at 11:49:43AM -0800, Ben Widawsky wrote:
Only in the make target he created, not in piglit itself. Imo we should
have all the testrunner logic in one place, i.e. in the piglit sources.
-Daniel
Damien, can you comment? I could have sworn you said something different
On Tue, Nov 26, 2013 at 8:53 PM, Damien Lespiau
damien.lesp...@intel.com wrote:
On Tue, Nov 26, 2013 at 11:49:43AM -0800, Ben Widawsky wrote:
Only in the make target he created, not in piglit itself. Imo we should
have all the testrunner logic in one place, i.e. in the piglit sources.
Chris Wilson ch...@chris-wilson.co.uk writes:
[PATCH 1/4] Support 64-bit MSC values. Handle kernel vageries about
Some spurious assignments that appear to intentially drop the error code
could be clarified,
I can't find any dropped error codes in this patch to add comments to,
please
On Tue, Nov 26, 2013 at 08:55:40PM +0100, Daniel Vetter wrote:
On Tue, Nov 26, 2013 at 8:53 PM, Damien Lespiau
damien.lesp...@intel.com wrote:
On Tue, Nov 26, 2013 at 11:49:43AM -0800, Ben Widawsky wrote:
Only in the make target he created, not in piglit itself. Imo we should
have all
On Tue, Nov 26, 2013 at 11:35:38AM -0800, Daniel Vetter wrote:
Hi Brad,
On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
Certain OpenGL features (e.g. transform feedback, performance monitoring)
require userspace
This is one of the nice pieces that I've never ported from the old
make based test runner. Note that we only use the result of the check
when actually running the testcases so that enumerating tests still
works as non-root on arbitrary machines.
v2: Fail the tests harder.
Cc: Ben Widawsky
On Tue, Nov 26, 2013 at 9:02 PM, Ben Widawsky b...@bwidawsk.net wrote:
The problem is that generating the testlist (or printing the commands)
is a feature QA actually relies on. I also use it occasionally to
quickly test igt library changes. So we can't bail that early. My
patch bails fairly
On Tue, 26 Nov 2013 15:10:22 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 11 Nov 2013 10:23:24 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Nov 06, 2013 at 12:51:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 06, 2013 at 02:36:35PM +0800, Chon Ming Lee wrote:
On Mon, 11 Nov 2013 10:23:24 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Nov 06, 2013 at 12:51:05PM +0200, Ville Syrjälä wrote:
On Wed, Nov 06, 2013 at 02:36:35PM +0800, Chon Ming Lee wrote:
vlv_dpio_read/write should be describe more in PHY centric instead of
display controller
If we end up calling the shrinker, which in turn requires the OOM
killer, we may end up infinitely waiting for a process to die if the OOM
chooses. The case that this prevents occurs in execbuf. The forked
variants of gem_evict_everything is a good way to hit it. This is
exacerbated by Daniel's
On Tue, Nov 26, 2013 at 04:55:50PM -0800, Ben Widawsky wrote:
If we end up calling the shrinker, which in turn requires the OOM
killer, we may end up infinitely waiting for a process to die if the OOM
chooses. The case that this prevents occurs in execbuf. The forked
variants of
On Tue, Nov 26, 2013 at 05:10:38PM -0800, Ben Widawsky wrote:
On Tue, Nov 26, 2013 at 04:55:50PM -0800, Ben Widawsky wrote:
If we end up calling the shrinker, which in turn requires the OOM
killer, we may end up infinitely waiting for a process to die if the OOM
chooses. The case that this
On Tue, 2013-11-26 at 20:35 +0100, Daniel Vetter wrote:
Hi Brad,
On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
Certain OpenGL features (e.g. transform feedback, performance monitoring)
require userspace code
On Tue, 2013-11-26 at 13:24 -0700, Volkin, Bradley D wrote:
On Tue, Nov 26, 2013 at 11:35:38AM -0800, Daniel Vetter wrote:
Hi Brad,
On Tue, Nov 26, 2013 at 08:51:17AM -0800, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
Certain OpenGL features
On Tue, Nov 26, 2013 at 04:55:50PM -0800, Ben Widawsky wrote:
If we end up calling the shrinker, which in turn requires the OOM
killer, we may end up infinitely waiting for a process to die if the OOM
chooses. The case that this prevents occurs in execbuf. The forked
variants of
On Wed, Nov 27, 2013 at 5:23 AM, Ben Widawsky b...@bwidawsk.net wrote:
On Tue, Nov 26, 2013 at 04:55:50PM -0800, Ben Widawsky wrote:
If we end up calling the shrinker, which in turn requires the OOM
killer, we may end up infinitely waiting for a process to die if the OOM
chooses. The case that
On Tue, Nov 26, 2013 at 08:23:46PM -0800, Ben Widawsky wrote:
On Tue, Nov 26, 2013 at 04:55:50PM -0800, Ben Widawsky wrote:
If we end up calling the shrinker, which in turn requires the OOM
killer, we may end up infinitely waiting for a process to die if the OOM
chooses. The case that this
On Wed, Nov 27, 2013 at 12:18 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, 26 Nov 2013 15:10:22 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 11 Nov 2013 10:23:24 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Nov 06, 2013 at 12:51:05PM +0200, Ville Syrjälä
This patch doesn't seem to be the panacea that I had hoped, although
I've yet to thoroughly test if it actually improves some of the other
tests which caused trouble.
What occurs is the following (assume just 2 procs)
1. proc A gets to execbuf while out of memory, gets struct_mutex.
2. OOM killer
On Tue, Nov 26, 2013 at 11:23:15AM +, Chris Wilson wrote:
As the execbuffer dispatch grows ever more complex and involves multiple
stages of moving objects into the aperture, we need to take greater care
that we do not evict our execbuffer objects prior to dispatch. This is
relatively
89 matches
Mail list logo
