[Intel-gfx] Shared memory management

[Yegor Yefremov]

I need to know how to allocate 1Gb video memory. My system:

CPU: Intel Core i5-520M
Chipset: Intel QM57
OS: Ubuntu 11.10 64-bit
Kernel: Linux user-desktop 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7
14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

almost the same question was asked here:
http://lists.freedesktop.org/archives/intel-gfx/2011-February/009476.html.
But it is not answered. I've googled for this info and found some
threads, but still no valuable information on how Video RAM setting
can be changed from user space:

http://superuser.com/questions/371335/intel-vga-shared-memory
http://www.cyberciti.biz/faq/howto-find-linux-vga-video-card-ram/

etc.

As far as I can see there is no such info as (==) intel(0): VideoRam:
262144 KB in xorg.log. The only info I have is lspci output:

00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 18) (prog-if 00 [VGA controller])
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at fe00 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at f160 [size=8]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915

According to this thread
http://forums.pcpitstop.com/index.php?/topic/139320-setting-intel-shared-video-memory-on-laptop-suse-102/,
DVMT 2.0 allocates video ram as needed. But how can I see current
video memory usage? Customer application relies on having 1Gb video
RAM.

Thank you in advance.

Regards,
Yegor
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux intel and xorg status on i915GM hardware

[Eugeni Dodonov]

On Fri, Jan 6, 2012 at 05:45, Knut Petersen wrote:

>
> 2. 
> https://bugs.freedesktop.org/**show_bug.cgi?id=42300has
>  not been resolved
>

I believe Keith will queue the fix for this (which is the same as for
https://bugs.freedesktop.org/show_bug.cgi?id=41059 apparently) shortly.

-- 
Eugeni Dodonov

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: add an "off-dvi" HDMI audio mode

[Jesse Barnes]

On Fri, 6 Jan 2012 11:26:40 +0800
Wu Fengguang  wrote:

> Andrea,
> 
> Would you test this patch at convenient time?
> 
> Thanks,
> Fengguang
> 
> ---
> Subject: drm/i915: add an "off-dvi" HDMI audio mode
> Date: Fri Jan 06 11:04:00 CST 2012
> 
> When HDMI-DVI converter is used, it's not only necessary to turn off
> audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
> the DVI mode is mainly tied to audio functionality from end user POV,
> add a new "off-dvi" audio mode:
> 
>   xrandr --output HDMI1 --set audio off-dvi
> 
> Reported-by: Andrea Arcangeli 
> Signed-off-by: Wu Fengguang 
> ---

My only complaint here is that off-dvi isn't an intuitive name.  We
don't have any better way of detecting an HDMI->DVI converter with
other EDID bits perhaps?

A better name might be off-dvi-mode or off-dvi-only or something.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Jesse Barnes]

On Thu, 05 Jan 2012 19:10:43 -0800
Eric Anholt  wrote:

> On Thu,  5 Jan 2012 14:16:23 -0200, przan...@gmail.com wrote:
> > From: Paulo Zanoni 
> > 
> > This ioctl is used to signal the drivers that the screen is rotated,
> > not to make the drivers rotate the screen.
> >  - add a driver-specific "rotation_set" function
> >  - implement Intel's rotation_set by setting the right values to the
> >PIPECONF registers.
> > 
> > The idea is that when user-space does rotation, it can call this ioctl
> > to inform the Kernel that we have a rotation. This feature is needed
> > by the KVMr feature of VPro.
> 
> So am I following this right, that these register bits are used to
> communicate from one piece of software to another piece of software,
> across the virtualization boundary?

Right, but not for virtualization; these bits are read by the AMT
engine for its built-in KVM functionality.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: rip out the HWSTAM missed irq workaround

[Eugeni Dodonov]

On Thu, Jan 5, 2012 at 20:11, Daniel Vetter  wrote:

> With the new ducttape of much finer quality, this seems to be no
> longer necessary.
>
> Tested on my ivb and snb machine with the usual suspects of testcases.
>
> Signed-Off-by: Daniel Vetter 
>

Nothing like high-quality ducttape!

Reviewed-by: Eugeni Dodonov 
Tested-by: Eugeni Dodonov 

I wonder if we could drop the definitions of GEN6_*_HWSTAM from i915_reg.h
as well now...

-- 
Eugeni Dodonov

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Shared memory management

[Eric Anholt]

On Fri, 6 Jan 2012 09:30:13 +0100, Yegor Yefremov  
wrote:
> I need to know how to allocate 1Gb video memory. My system:

Applications can allocate arbitrary amounts of buffers that are
dynamically bound to the GPU.  The limit of what can be bound at for a
single draw call is defined by the hardware, so there are no user
controls.  The only information you get on that limit is:

dmesg | grep agp:
[2.283526] agpgart-intel :00:00.0: detected gtt size: 2097152K total, 
262144K mappable

so this system can map 2GB at once.


pgpPkZ2sovhn5.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Shared memory management

[Ben Widawsky]

On Fri, Jan 06, 2012 at 08:18:22AM -0800, Eric Anholt wrote:
> On Fri, 6 Jan 2012 09:30:13 +0100, Yegor Yefremov 
>  wrote:
> > I need to know how to allocate 1Gb video memory. My system:
> 
> Applications can allocate arbitrary amounts of buffers that are
> dynamically bound to the GPU.  The limit of what can be bound at for a
> single draw call is defined by the hardware, so there are no user
> controls.  The only information you get on that limit is:
> 
> dmesg | grep agp:
> [2.283526] agpgart-intel :00:00.0: detected gtt size: 2097152K total, 
> 262144K mappable
> 
> so this system can map 2GB at once.

mount debugfs
cat /sys/kernel/debug/dri/0/i915_gem_gtt
Will show how much is being used.



pgpgOM4NRzANV.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux intel and xorg status on i915GM hardware

[Adam Jackson]

On 1/6/12 2:45 AM, Knut Petersen wrote:


1: Xorg.0.log is full of (besides timestamp) identical EDID entries:
==

[ 2502.358] (II) intel(0): EDID vendor "ENC", prod id 5769
[ 2502.358] (II) intel(0): Using EDID range info for horizontal sync
[ 2502.358] (II) intel(0): Using EDID range info for vertical refresh
[ 2502.358] (II) intel(0): Printing DDC gathered Modelines:
[ 2502.358] (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328
1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
[ 2502.358] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056
600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 2502.358] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800
480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 2502.358] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900
400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 2502.358] (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184
1344 768 771 777 806 -hsync -vsync (48.4 kHz e)


Does this happen with no X apps running, just a naked X server?  If so 
you have something causing spurious hotplug interrupts.  If not, 
something in your session is querying the server a lot.


I believe gnome attempts to isolate calls to XRRGetScreenResources to 
gnome-settings-daemon for precisely this reason (only one app really 
needs to call it and the rest should query through the session bus).



5. Xorg fails to start without a manually created "Section Modules" in
config
=
see: https://bugs.freedesktop.org/show_bug.cgi?id=41208


You really do have a toolchain bug there.

- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] panning support

[Bob Tennent]

 >|> In general, how does one discover which versions of Intel integrated
 >|> graphics support panning? I have a Lenovo laptop that does and desktop
 >|> systems that don't.
 >|
 >|The intel driver supports panning for all chips it supports (excluding
 >|the ancient i810 series I suppose).  If you're seeing variation among
 >|chips it's because you're not running the same driver [1].

The same driver is installed but I wonder if the nvidia driver
interferes with the intel driver. (When the intel driver stopped
supporting Virtual and before xrandr 1.3, I had to buy a video card and
install the nvidia driver on the desktop systems.)

Bob T.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Removing TV Out modes.

[Jesse Barnes]

On Wed, 14 Dec 2011 21:10:07 -0200
Rodrigo Vivi  wrote:

> These modes are no longer needed or are not according to TV timing standards.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_tv.c |  122 
> ---
>  1 files changed, 0 insertions(+), 122 deletions(-)

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix TV Out refresh rate.

[Jesse Barnes]

On Wed, 14 Dec 2011 21:10:06 -0200
Rodrigo Vivi  wrote:

> TV Out refresh rate was half of the specification for almost all modes.
> Due to this reason pixel clock was so low for some modes causing flickering 
> screen.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_tv.c |   16 
>  1 files changed, 8 insertions(+), 8 deletions(-)
> 

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/43] drm/i915: protect force_wake_(get|put) with the gt_lock

[Keith Packard]

On Thu, 05 Jan 2012 21:41:34 -0800, Keith Packard  wrote:

> I talked with Eric about this and we decided that the whole splitting
> out of the i/o functions just doesn't make any sense. That makes this
> series very similar to Daniel's patches, so I'll rebase my bug fixes on
> top of those changes and send out a (shorter) series tomorrow.

And here's an updated version of my patches built on top of Daniel's:

The following changes since commit d06d2756a21a0c666f167ae9e4f13ef5f07f67d9:

  acpi/video: Don't restore backlight to 0 at boot time (2012-01-06 11:10:25 
-0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux forcewake-spinlock

Daniel Vetter (1):
  drm/i915: protect force_wake_(get|put) with the gt_lock

Daniel's patch (v3)


Keith Packard (3):
  drm/i915: Move reset forcewake processing to gen6_do_reset

This moves the forcewake code inside gen6_do_reset, at
the same time it changes from unconditionally calling
__gen6_gt_force_wake_get to using
dev_priv->display.force_wake_get. That could be broken
out as a separate patch -- it's just a bug.

  drm/i915: Hold gt_lock during reset
  drm/i915: Hold gt_lock across forcewake register reads

These two patches eliminate a race between chip reset
and other read operations. By holding the gt_lock during
all read operations, as well as across reset, we can
ensure that forcewake is active for all register
reads. Otherwise, right after chip reset, forcewake can
be inactive, but the internal forcewake_count may be
non-zero.

As a nice side-effect, this eliminates taking the
gt_lock twice during all register reads.

Please take a look and see if these are all reasonable additions to the
original patch and when it's ready, I'll push the whole sequence to
drm-intel-fixes.

-- 
keith.pack...@intel.com


pgpAuvzRPjx4m.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: paper over missed irq issues with force wake vodoo

[Keith Packard]

On Wed,  4 Jan 2012 17:52:10 +0100, Daniel Vetter  
wrote:

> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
>   notification interrupts by grabbing the force_wake in get_irq (and
>   dropping it in put_irq again).
> - ordering writes from the ring's CS by reading a CS register, ACTHD
>   seems to work.
> 
> Only the blt&bsd ring on ivb seem to be massively affected by this,
> but for paranoia do this dance also on the render ring and on snb
> (i.e. all gpus with forcewake).
> 
> Tested with Eric's glCopyPixels loop which without this patch scores a
> missed irq every few seconds.
> 
> This patch needs my forcewake rework to use a spinlock instead of
> dev->struct_mutex.

I've pushed these to the forcewake-spinlock branch in both my fdo and
kernel repositories. Please give that a try on IVB and SNB to make sure
things are working right.

I'd like to get these into master as well as being sent off to stable@
for 3.2.x

-- 
keith.pack...@intel.com


pgpZqn4LTqpjn.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/sdvo: always set positive sync polarity

[przanoni]

From: Paulo Zanoni 

This is a revert of 81a14b46846fea0741902e8d8dfcc6c6c78154c8.

We already set the mode polarity using the SDVO commands with struct
intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch.
The documentation, despite not clear, can also be interpreted in a way
that suggests this patch is needed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=4
Cc: sta...@kernel.org
Reviewed-by: Eric Anholt 
Reviewed-by: Jesse Barnes 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_sdvo.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)


The Reviewed-by tags were provided on IRC.


diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index f7b9268..e334ec3 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1066,15 +1066,13 @@ static void intel_sdvo_mode_set(struct drm_encoder 
*encoder,
 
/* Set the SDVO control regs. */
if (INTEL_INFO(dev)->gen >= 4) {
-   sdvox = 0;
+   /* The real mode polarity is set by the SDVO commands, using
+* struct intel_sdvo_dtd. */
+   sdvox = SDVO_VSYNC_ACTIVE_HIGH | SDVO_HSYNC_ACTIVE_HIGH;
if (intel_sdvo->is_hdmi)
sdvox |= intel_sdvo->color_range;
if (INTEL_INFO(dev)->gen < 5)
sdvox |= SDVO_BORDER_ENABLE;
-   if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
-   sdvox |= SDVO_VSYNC_ACTIVE_HIGH;
-   if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
-   sdvox |= SDVO_HSYNC_ACTIVE_HIGH;
} else {
sdvox = I915_READ(intel_sdvo->sdvo_reg);
switch (intel_sdvo->sdvo_reg) {
-- 
1.7.7.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix TV Out refresh rate.

[Keith Packard]

On Wed, 14 Dec 2011 21:10:06 -0200, Rodrigo Vivi  wrote:
> TV Out refresh rate was half of the specification for almost all modes.
> Due to this reason pixel clock was so low for some modes causing
> flickering screen.
>
>  Signed-off-by: Rodrigo Vivi 

And

>  These modes are no longer needed or are not according to TV timing standards.
>
>  Intel PRM Vol 3 - Display Registers Updated - Section 5 TV-Out
>  Programming / 5.2.1 Television Standards / 5.2.1.1 Timing tables
>
>  Signed-off-by: Rodrigo Vivi 

I've got these two queued on my machine. Once drm-next is merged to
master, drm-intel-fixes will be fast-forwarded to that point and these
fixes rebased on top of that.

There's still the 1080p modes which Chris has asked for an updated
changelog and a comment in the source for.

-- 
keith.pack...@intel.com


pgpuKk51f92P6.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/sdvo: always set positive sync polarity

[Keith Packard]

On Fri,  6 Jan 2012 19:45:34 -0200, przan...@gmail.com wrote:
> From: Paulo Zanoni 
> 
> This is a revert of 81a14b46846fea0741902e8d8dfcc6c6c78154c8.
> 
> We already set the mode polarity using the SDVO commands with struct
> intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch.
> The documentation, despite not clear, can also be interpreted in a way
> that suggests this patch is needed.

This is merged to my local repository, to be rebased when drm is merged
to master.

-- 
keith.pack...@intel.com


pgpnEvM8qVrqM.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx