On 01/21/2013 06:05 PM, Csillag wrote:
> But now, thanks to GIGABYTE's PR about Thunderbolt and 4K (
> http://www.gigabyte.com/MicroSite/323/4k.html ), I realized that it
> might be possible to use a "DisplayPort to Dual-DisplayPort Adapter" to
> split a DisplayPort 1.1 output into two channels, an
mesa-dev is a better place for this question.
Begin forwarded message:
Date: Mon, 21 Jan 2013 22:13:34 +0100
From: Marcel Witte
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] Very low performance when streaming textures
Hi,
I'm refering to the example of this article about streaming
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Monday, January 21, 2013 9:11 PM
> To: Wang, Xingchao
> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch; Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: HDMI/DP - ELD info
Do we want Convertor or Converter? This patch fixes the misspellings
if we want it spelled
properly.
Signed-off-by: Benjamin Kerensa
---
tools/intel_audio_dump.c | 50
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/tools/intel_a
On Mon, Jan 21, 2013 at 11:38:06PM +0100, Daniel Vetter wrote:
> On Sun, Jan 20, 2013 at 05:08:23PM +, Chris Wilson wrote:
> > During the initial bringup of IVB, we set the invalidation control to
> > the pre-IVB default of always invalidating TLBs on every flush:
> >
> > commit b095cd0a0ccdbc
Hi,
I am deciding the components on a new computer, and one of the most
important requirements is to have support for three monitors, under
GNU/Linux, with open-source drivers.
I know I can do this with AMD Eyefinity, but now I am trying to build an
Intel-based system.
So, can I do this with the
On Sun, Jan 20, 2013 at 05:08:23PM +, Chris Wilson wrote:
> During the initial bringup of IVB, we set the invalidation control to
> the pre-IVB default of always invalidating TLBs on every flush:
>
> commit b095cd0a0ccdbc00c9fd99d90b22f8563687971f
> Author: Jesse Barnes
> Date: Fri Aug 12 1
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 11 +--
drivers/gpu/drm/i915/i915_gem.c| 14 --
drivers/gpu/drm/i915/i915_gem_context.c| 4 +++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 ++
drivers/gpu/drm/i915/i915_
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++-
drivers/gpu/drm/i915/i915_gem.c | 6 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 56 ++---
3 files changed, 37 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 20 +---
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4c0e670..d462875 100
With the GMCH call in our dispatch table, we can now cut away two of the
remaining members in the intel_gtt shared struct.
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c | 36 --
drivers/gpu/drm/i915/i915_drv.h| 3 +--
drivers/gpu/
The GTT handling has changed from generation to generation. There was a
particularly large shift around the gen5 time frame. The GTT itself
those provides a few core functions which make it a nice candidate for a
dispatch table. A similar concepts exists in the AGP layer, and were it
not for design
Elaborating a bit more on what we can do with the vtable... still hoping
to get feedback.
Ben Widawsky (5):
drm/i915: Create a vtable for i915 gtt
drm/i915: Resume dissecting intel_gtt
drm/i915: Extract gtt stolen calculations
drm/i915: Extract clear_range to gtt_ops
drm/i915: Extract bi
Hi Wang,
Sorry for not getting back you sooner.
Thanks for clarifications and update.
About current pipe sorry for my confusion... Maybe to avoid confusions
like this and make it more clear we could have macros like:
#define AUDIO_OUTPUT_ENABLE(pipe) (AUDIO_OUTPUT_ENABLE_A << (pipe * 4))
#define
Hi,
I'm refering to the example of this article about streaming textures and using
Pixel Buffer Objects: http://www.songho.ca/opengl/gl_pbo.html
The PBO Unpack example (http://www.songho.ca/opengl/files/pboUnpack.zip) is
creating an "animated texture" and can switch between three modes: Direct
On Sun, 2013-01-20 at 17:08 +, Chris Wilson wrote:
> During the initial bringup of IVB, we set the invalidation control to
> the pre-IVB default of always invalidating TLBs on every flush:
>
> commit b095cd0a0ccdbc00c9fd99d90b22f8563687971f
> Author: Jesse Barnes
> Date: Fri Aug 12 15:28:32
On Sun, Jan 20, 2013 at 07:36:39PM -0800, Ben Widawsky wrote:
> On Sun, Jan 20, 2013 at 04:33:32PM +, Chris Wilson wrote:
> > On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1,
> > the hardware can not program the scanline values. Those scanline values
> > then control w
On Mon, Jan 21, 2013 at 10:25:36PM +0200, Imre Deak wrote:
> On Sun, 2013-01-20 at 16:11 +, Chris Wilson wrote:
> > This is a required workarounds for all products, especially on gen6+
> > where it causes the command streamer to fail to parse instructions
> > following a WAIT_FOR_EVENT. We use
On Sun, 2013-01-20 at 16:11 +, Chris Wilson wrote:
> This is a required workarounds for all products, especially on gen6+
> where it causes the command streamer to fail to parse instructions
> following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising
> between the GPU and the display
On Mon, Jan 21, 2013 at 12:06:44PM +, Damien Lespiau wrote:
> On Fri, Jan 18, 2013 at 09:48:33PM +0100, Daniel Vetter wrote:
> > I've somehow totally lost track of this series here. I've now slurped in
> > the first four patches up to "drm/i915: clear up wedged transitions". Can
> > you please
On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> So don't bother, but instead disable it by default to allow distros to
> unconditionally enable DMAR support.
Acked-By: David Woodhouse
It *really* winds me up that we
We already have the quirk entry for the mobile platform, but also
reports on some desktop versions. So be paranoid and set it
everywhere.
References:
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
Cc: sta...@vger.kernel.org
Cc: David Woodhouse
Reported-and-tested-by: M
* On 20.01.2013 11:49 PM, Daniel Vetter wrote:
> Thanks for testing, I've just submitted the patch for review. It
> should included in a -fixes tree soon and the get backported to
> stable kernels.
Thanks. :)
> Please let me know when this works solidly for you, so that I can
> put it into a rea
On Fri, Jan 18, 2013 at 06:37:09PM +0100, Daniel Vetter wrote:
> On Fri, Jan 18, 2013 at 6:11 PM, wrote:
> > From: Ville Syrjälä
> >
> > HSW no longer has the PIPECONF bit for limited range RGB output.
> > Instead the pipe CSC unit must be used to perform that task.
> >
> > The CSC pre offset ar
On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If the power well is disabled, we should not try to read its
> registers, otherwise we'll get "unclaimed register" messages.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 1
On Fri, Jan 18, 2013 at 06:29:05PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The current code was wrong in many different ways, so this is a full
> rewrite. We don't have "different power wells for different parts of
> the GPU", we have a single power well, but we have multiple register
On Mon, Jan 21, 2013 at 05:40:23AM +, Wang, Xingchao wrote:
> Hi Ville Syrjälä,
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Friday, January 18, 2013 9:14 PM
> > To: Wang, Xingchao
> > Cc: intel-gfx@lists.freedesktop.org; daniel.vet.
On Fri, Jan 18, 2013 at 09:48:33PM +0100, Daniel Vetter wrote:
> I've somehow totally lost track of this series here. I've now slurped in
> the first four patches up to "drm/i915: clear up wedged transitions". Can
> you please take a look at the two follow-up patches I've posted in reply
> to your
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/intel_ddi.c | 22 ++
drivers/gpu/drm/i
On Sun, Jan 20, 2013 at 07:36:39PM -0800, Ben Widawsky wrote:
> On Sun, Jan 20, 2013 at 04:33:32PM +, Chris Wilson wrote:
> > On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1,
> > the hardware can not program the scanline values. Those scanline values
> > then control w
30 matches
Mail list logo