[Intel-gfx] [PATCH 2/2] intel: Add support for (possibly) unsynchronized maps.

This improves the performance of Mesa's GL_MAP_UNSYNCHRONIZED_BIT path in GL_ARB_map_buffer_range. Improves Unigine Tropics performance at 1024x768 by 0.958822% +/- 0.118466% (n=48). v2: Fix comment grammar. --- Updated commit message for retesting on the previous commit. It turns out last time

[Intel-gfx] [PATCH 1/2] intel: Fix error check for I915_PARAM_HAS_LLC.

drmIoctl returns -1 on error with errno set to the error value. Other users of it in this file just check for != 0, and only use errno when they need to send an error value on to the caller of the API. --- intel/intel_bufmgr_gem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff

Re: [Intel-gfx] [PATCH] drm/i915: Don't write DSPSURF for old chips

At Mon, 27 Feb 2012 14:08:28 +0100, Takashi Iwai wrote: > > At Mon, 27 Feb 2012 12:17:57 +, > Chris Wilson wrote: > > > > On Mon, 27 Feb 2012 12:39:24 +0100, Takashi Iwai wrote: > > > It seems that writing DSPSURF in intel_flush_display_plane() causes > > > the blank screen on some old lapto

[Intel-gfx] Recall: SandyBridge is finally whitewashed.

Zou, Nanhai would like to recall the message, "SandyBridge is finally whitewashed.". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] SandyBridge is finally whitewashed.

This is great news! Congratulation to the team. Thanks Zou Nanhai From: Zhu, Yongsheng Sent: 2012年2月28日 10:07 To: SSD-OTC WRT GPU Enabling and Optimization Team Subject: SandyBridge is finally whitewashed. The 2 patches for this were committed into Chromium trun

[Intel-gfx] [PATCH] drm/i915: merge gmbus and gpio i2c adpater into one

... and directly call the newly exported i2c bit-banging functions. The code is still pretty convoluted because we only set up the gpio i2c stuff when actually falling back, resulting in more complexity than necessary. This will be fixed up in the next patch. v2: Use exported i2c_bit_algo vtable

[Intel-gfx] [PATCH] drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo

I'd like to export the corresponding functions from the i2c core so that I can use them in fallback bit-banging in i915.ko v2: Adapt to new i2c export patch. Cc: nouv...@lists.freedesktop.org Signed-off-by: Daniel Vetter --- drivers/gpu/drm/nouveau/nouveau_i2c.c |8 1 files changed

[Intel-gfx] [PATCH] i2c: export bit-banging algo functions

i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons we need to be able to fall back to the bit-banging algo on gpio pins. The current code sets up a 2nd i2c controller for the same i2c bus using the bit-banging algo. This has a bunch of issues, the major one being that userspace

[Intel-gfx] [PATCH] drm/i915: make sprite buffer switching asynchronous

Move the vblank wait (needed to avoid displaying an unpinned frame) to a work handler. Special case benchmarks and other apps that may call set_plane at a high frequency: we can unpin their objects directly unless they're "live". Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_reg.h

Re: [Intel-gfx] [PATCH 3/7] i2c: export bit-banging algo functions

On Mon, Feb 27, 2012 at 11:20:40PM +0100, Jean Delvare wrote: > Hi Daniel, > > Sorry for the late reply. > > On Tue, 14 Feb 2012 22:37:21 +0100, Daniel Vetter wrote: > > i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons > > we need to be able to fall back to the bit-banging a

[Intel-gfx] [PATCH] drm/i915: delay fb unpins from sprites to the next vblank

Mutiple calls per frame are allowed, but we mustn't unpin the active fb until the next vblank or we may end up displaying garbage or someone else's buffer. So use the page flip unpin work handler to delay unpin of the buffer to a later time. This adds a new field to the unpin struct so we can tra

[Intel-gfx] [PATCH 2/2] drm/i915: remove vblank wait around sprite buffer changes

The docs made me paranoid about updating the surface reg too quickly, but experiements have shown it to be safe on the two supported platforms, so remove the waits to avoid blocking apps. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_sprite.c | 14 +- 1 files changed,

[Intel-gfx] [PATCH 1/2] drm/i915: fix color order for BGR formats on SNB

Had the wrong bits and field definitions. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/i915/i915_reg.h |2 +- drivers/gpu/drm/i915/intel_sprite.c |6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_r

[Intel-gfx] [PATCH] drm/i915: Handle request to map a very large buffer object

This patch sets an upper limit on the size of buffer object which can be mapped safely. Following bugs reported segmentation fault / assertion failure with large textures: https://bugs.freedesktop.org/show_bug.cgi?id=44970 https://bugs.freedesktop.org/show_bug.cgi?id=46303 This patch along with a

[Intel-gfx] [PATCH] intel: Fix a case when mapping large texture fails

This patch handles a case when mapping a large texture fails in drm_intel_gem_bo_map_gtt(). These changes avoid assertion failure later in the driver as reported in following bugs: https://bugs.freedesktop.org/show_bug.cgi?id=44970 https://bugs.freedesktop.org/show_bug.cgi?id=46303 Signed-off-by:

Re: [Intel-gfx] [PATCH] intel: Add support for (possibly) unsynchronized maps.

On Sat, 25 Feb 2012 12:00:07 +0100, Daniel Vetter wrote: > On Fri, Feb 24, 2012 at 07:53:22PM -0800, Eric Anholt wrote: > > This improves the performance of Mesa's GL_MAP_UNSYNCHRONIZED_BIT path > > in GL_ARB_map_buffer_range. Improves Unigine Tropics performance at > > 1024x768 by 2.06236% +/- 0

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Bump the inactive LRU on set-to-GTT-domain

On Mon, 27 Feb 2012 10:50:49 -0800, Eric Anholt wrote: > On Fri, 24 Feb 2012 21:13:39 +, Chris Wilson > wrote: > > @@ -2923,6 +2914,9 @@ i915_gem_object_set_to_gtt_domain(struct > > drm_i915_gem_object *obj, bool write) > > old_read_domains, > >

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Bump the inactive LRU on set-to-GTT-domain

On Fri, 24 Feb 2012 21:13:39 +, Chris Wilson wrote: > Currently, we only bump the LRU of an object when we bind into the GTT > for a page-fault. As the object may be used many times before its > mapping is zapped, we do not mark it as active as frequently as we > should. Userspace should be c

Re: [Intel-gfx] [PATCH] drm/i915: i2c: unconditionally set up gpio fallback

On Mon, Feb 27, 2012 at 15:22, Daniel Vetter wrote: > This way we can simplify the setup and teardown a bit. > > Because we don't actually allocate anything anymore for the force_bit > case, we can now convert that into a boolean. > > Also and the functionality supported by the bit-banging togeth

[Intel-gfx] [PATCH] drm/i915: i2c: unconditionally set up gpio fallback

This way we can simplify the setup and teardown a bit. Because we don't actually allocate anything anymore for the force_bit case, we can now convert that into a boolean. Also and the functionality supported by the bit-banging together with what gmbus can do, so that this doesn't randomly change

Re: [Intel-gfx] [PATCH 1/7] drm/i915: add dev_priv to intel_gmbus

On Tue, Feb 14, 2012 at 19:37, Daniel Vetter wrote: > This way we can free up the bus->adaptor.algo_data pointer and make it > available for use with the bitbanging fallback algo. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov __

[Intel-gfx] intel display desktop

Name    Intel(R) G33/G31 Express Chipset Family PNP Device ID    PCI\VEN_8086&DEV_29C2&SUBSYS_26831019&REV_10\3&11583659&0&10 Adapter Type    Intel(R) GMA 3100, Intel Corporation compatible Adapter Description    Intel(R) G33/G31 Express Chipset Family Adapter RAM    384,00 MB (402.653.184 bytes) I

Re: [Intel-gfx] [PATCH] drm/i915: Track dirtying of CPU cache for LLC

On Mon, Feb 27, 2012 at 05:10:24PM +, Chris Wilson wrote: > On Mon, 27 Feb 2012 17:30:19 +0100, Daniel Vetter wrote: > > On Fri, Feb 24, 2012 at 09:21:51PM +, Chris Wilson wrote: > > > Doing mixed rendering into the front/back scanout buffers lead to the > > > interesting rediscovery of cl

Re: [Intel-gfx] [PATCH 3/7] i2c: export bit-banging algo functions

Hi Jean, Can you please review and if you don't have any objectsion, ack this patch for merging through drm-intel-next? Imo that's the easiest way to merge this series. Thanks, Daniel On Tue, Feb 14, 2012 at 10:37:21PM +0100, Daniel Vetter wrote: > i915 has a hw i2c controller (gmbus) but for a

Re: [Intel-gfx] [PATCH 2/7] drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo

Hi Ben, Can you ack this patch for merging through drm-intel-next? Imo that's the easiest way to get it in (assuming you don't have any objections). Thanks, Daniel On Tue, Feb 14, 2012 at 10:37:20PM +0100, Daniel Vetter wrote: > I'd like to export the corresponding functions from the i2c core >

Re: [Intel-gfx] [PATCH] drm/i915: error_buffer->ring should be signed

On Thu, Feb 16, 2012 at 02:16:27PM +0300, Dan Carpenter wrote: > On Thu, Feb 16, 2012 at 11:03:29AM +0100, Daniel Vetter wrote: > > gcc seems to get uber-anal recently about these things. > > > > Sorry, I should have said that it's not a gcc warning, it's a > smatch thing. But also it's not uber

Re: [Intel-gfx] [PATCH] drm/i915: Track dirtying of CPU cache for LLC

On Mon, 27 Feb 2012 17:30:19 +0100, Daniel Vetter wrote: > On Fri, Feb 24, 2012 at 09:21:51PM +, Chris Wilson wrote: > > Doing mixed rendering into the front/back scanout buffers lead to the > > interesting rediscovery of clflushing when page-flipping. A painful > > experience indeed. > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Silence the error message from i915_wait_request()

On Wed, Feb 22, 2012 at 08:39:12PM +, Chris Wilson wrote: > This error message has since been superseded by the hangcheck, and does > not add any salient information beyond that already printed by hangcheck > discovering the GPU hang that lead to i915_wait_request() bombing out in > the first p

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove use of the autoreported ringbuffer HEAD position

On Wed, 8 Feb 2012 13:34:13 + Chris Wilson wrote: > This is a revert of 6aa56062eaba67adfb247cded244fd877329588d. > > This was originally introduced to workaround reads of the ringbuffer > registers returning 0 on SandyBridge causing hangs due to ringbuffer > overflow. The root cause here w

Re: [Intel-gfx] [git pull] Intel drm fixes

On Mon, 27 Feb 2012 08:08:13 -0800 Jesse Barnes wrote: > The following changes since commit > 3ac0eb6d62fde0a60a6c5c61e562af1db8fbf712: > > drm/radeon/kms/atom: dpms bios scratch reg updates (2012-02-22 10:30:06 > +) > > are available in the git repository at: > git://git.kernel.org/pu

Re: [Intel-gfx] [PATCH] drm/i915: use the new hdmi_force_audio enum more

On Fri, Feb 24, 2012 at 04:43:16PM +0800, Wu Fengguang wrote: > On Thu, Feb 23, 2012 at 05:14:47PM +0100, Daniel Vetter wrote: > > While fixing up a merge conflict with drm-next I've noticed that we > > use the same audio drm connector property also for dp and sdvo > > outputs. > > > > So put the

Re: [Intel-gfx] [PATCH 2/2] drm/i915: No need to search again after retiring requests

On Fri, Feb 24, 2012 at 12:27:22AM +, Chris Wilson wrote: > Retiring requests does not typically free up space in the aperture, > so the additional search is pointless. > > Signed-off-by: Chris Wilson Both queued for -next, thanks for the patches. -Daniel -- Daniel Vetter Mail: dan...@ffwll.

Re: [Intel-gfx] [PATCH] drm/i915: Track dirtying of CPU cache for LLC

On Fri, Feb 24, 2012 at 09:21:51PM +, Chris Wilson wrote: > Doing mixed rendering into the front/back scanout buffers lead to the > interesting rediscovery of clflushing when page-flipping. A painful > experience indeed. > > Signed-off-by: Chris Wilson Hm, I might be a bit dense here (again

[Intel-gfx] [git pull] Intel drm fixes

The following changes since commit 3ac0eb6d62fde0a60a6c5c61e562af1db8fbf712: drm/radeon/kms/atom: dpms bios scratch reg updates (2012-02-22 10:30:06 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel drm-intel-fixes Alban Browaeys

Re: [Intel-gfx] [PATCH] drm/i915: Don't write DSPSURF for old chips

At Mon, 27 Feb 2012 12:17:57 +, Chris Wilson wrote: > > On Mon, 27 Feb 2012 12:39:24 +0100, Takashi Iwai wrote: > > It seems that writing DSPSURF in intel_flush_display_plane() causes > > the blank screen on some old laptops like Dell D630 with 965GM. > > Since this operation is needed only f

Re: [Intel-gfx] [PATCH] drm/i915: Don't write DSPSURF for old chips

On Mon, 27 Feb 2012 12:39:24 +0100, Takashi Iwai wrote: > It seems that writing DSPSURF in intel_flush_display_plane() causes > the blank screen on some old laptops like Dell D630 with 965GM. > Since this operation is needed only for ILK+, make it conditional. The specs say that DSPASURF is the l

[Intel-gfx] [PATCH] drm/i915: Don't write DSPSURF for old chips

It seems that writing DSPSURF in intel_flush_display_plane() causes the blank screen on some old laptops like Dell D630 with 965GM. Since this operation is needed only for ILK+, make it conditional. Cc: [v3.1+] Signed-off-by: Takashi Iwai --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1

Re: [Intel-gfx] [PATCH] intel: Add support for (possibly) unsynchronized maps.

On Sun, 26 Feb 2012 12:28:09 -0800 Kenneth Graunke wrote: > On 02/25/2012 03:00 AM, Daniel Vetter wrote: > > On Fri, Feb 24, 2012 at 07:53:22PM -0800, Eric Anholt wrote: > >> This improves the performance of Mesa's GL_MAP_UNSYNCHRONIZED_BIT path > >> in GL_ARB_map_buffer_range. Improves Unigine

Re: [Intel-gfx] [PATCH] drm/i915/bios: Downgrade the "signature missing" DRM_ERROR to debug

On Fri, Feb 24, 2012 at 04:53:28PM +, Chris Wilson wrote: > As we warn the user later that we cannot find or load the VBIOS, > explaining why is an exercise in debugging. Shouting *ERROR* upsets > people and produces bug reports. > > Reported-by: Michael Rieder > Bugzilla: https://bugs.freede