[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-07-05 Thread Ville Syrjälä 
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
> > On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote:
> > > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > > > On Thu, 24 May 2012 21:08:58 +0300
> > > > ville.syrjala at linux.intel.com wrote:
> > > > 
> > > > > From: Ville Syrj?l? 
> > > > > 
> > > > > Take fb->offset[0] into account when calculating the linear and tile 
> > > > > x/y
> > > > > offsets.
> > > > > 
> > > > > For non-tiled surfaces fb->offset[0] is simply added to the linear
> > > > > byte offset.
> > > > > 
> > > > > For tiled surfaces treat fb->offsets[0] as a byte offset into the
> > > > > linearized view of the surface. So we end up converting fb->offsets[0]
> > > > > into additional x and y offsets.
> > > > 
> > > > Do you have code using a non-zero offsets[0]?  At least for current
> > > > code that would indicate some kind of problem... though hopefully we'll
> > > > be adding planar support back again sometime soon.
> > > 
> > > I did have some test app that used offsets[] at some point, but tbh I
> > > didn't excercise these changes with it.
> > > 
> > > I have a sort of semi working skeleton of a test app which I just modify
> > > for various use cases as need arises. I really should try to clean it up
> > > a bit and generalize it so that it wouldn't need constant code changes
> > > to test different scenarios.
> > 
> > Yeah, I want these little test apps as testcases in i-g-t.
> 
> Ping about these testcases, ported to i-g-t ...

Sorry, haven't had time to look at those. I'm going on vacation after
tomorrow but I'll add a task to the list so I won't forget about this.

-- 
Ville Syrj?l?
Intel OTC

[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-07-05 Thread Daniel Vetter 
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote:
> > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > > On Thu, 24 May 2012 21:08:58 +0300
> > > ville.syrjala at linux.intel.com wrote:
> > > 
> > > > From: Ville Syrj?l? 
> > > > 
> > > > Take fb->offset[0] into account when calculating the linear and tile x/y
> > > > offsets.
> > > > 
> > > > For non-tiled surfaces fb->offset[0] is simply added to the linear
> > > > byte offset.
> > > > 
> > > > For tiled surfaces treat fb->offsets[0] as a byte offset into the
> > > > linearized view of the surface. So we end up converting fb->offsets[0]
> > > > into additional x and y offsets.
> > > 
> > > Do you have code using a non-zero offsets[0]?  At least for current
> > > code that would indicate some kind of problem... though hopefully we'll
> > > be adding planar support back again sometime soon.
> > 
> > I did have some test app that used offsets[] at some point, but tbh I
> > didn't excercise these changes with it.
> > 
> > I have a sort of semi working skeleton of a test app which I just modify
> > for various use cases as need arises. I really should try to clean it up
> > a bit and generalize it so that it wouldn't need constant code changes
> > to test different scenarios.
> 
> Yeah, I want these little test apps as testcases in i-g-t.

Ping about these testcases, ported to i-g-t ...
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-07-05 Thread Daniel Vetter 
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
 On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
  On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
   On Thu, 24 May 2012 21:08:58 +0300
   ville.syrj...@linux.intel.com wrote:
   
From: Ville Syrjälä ville.syrj...@linux.intel.com

Take fb-offset[0] into account when calculating the linear and tile x/y
offsets.

For non-tiled surfaces fb-offset[0] is simply added to the linear
byte offset.

For tiled surfaces treat fb-offsets[0] as a byte offset into the
linearized view of the surface. So we end up converting fb-offsets[0]
into additional x and y offsets.
   
   Do you have code using a non-zero offsets[0]?  At least for current
   code that would indicate some kind of problem... though hopefully we'll
   be adding planar support back again sometime soon.
  
  I did have some test app that used offsets[] at some point, but tbh I
  didn't excercise these changes with it.
  
  I have a sort of semi working skeleton of a test app which I just modify
  for various use cases as need arises. I really should try to clean it up
  a bit and generalize it so that it wouldn't need constant code changes
  to test different scenarios.
 
 Yeah, I want these little test apps as testcases in i-g-t.

Ping about these testcases, ported to i-g-t ...
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-07-05 Thread Ville Syrjälä 
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote:
 On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote:
  On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
   On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
On Thu, 24 May 2012 21:08:58 +0300
ville.syrj...@linux.intel.com wrote:

 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Take fb-offset[0] into account when calculating the linear and tile 
 x/y
 offsets.
 
 For non-tiled surfaces fb-offset[0] is simply added to the linear
 byte offset.
 
 For tiled surfaces treat fb-offsets[0] as a byte offset into the
 linearized view of the surface. So we end up converting fb-offsets[0]
 into additional x and y offsets.

Do you have code using a non-zero offsets[0]?  At least for current
code that would indicate some kind of problem... though hopefully we'll
be adding planar support back again sometime soon.
   
   I did have some test app that used offsets[] at some point, but tbh I
   didn't excercise these changes with it.
   
   I have a sort of semi working skeleton of a test app which I just modify
   for various use cases as need arises. I really should try to clean it up
   a bit and generalize it so that it wouldn't need constant code changes
   to test different scenarios.
  
  Yeah, I want these little test apps as testcases in i-g-t.
 
 Ping about these testcases, ported to i-g-t ...

Sorry, haven't had time to look at those. I'm going on vacation after
tomorrow but I'll add a task to the list so I won't forget about this.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread Ville Syrjälä 
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> On Thu, 24 May 2012 21:08:58 +0300
> ville.syrjala at linux.intel.com wrote:
> 
> > From: Ville Syrj?l? 
> > 
> > Take fb->offset[0] into account when calculating the linear and tile x/y
> > offsets.
> > 
> > For non-tiled surfaces fb->offset[0] is simply added to the linear
> > byte offset.
> > 
> > For tiled surfaces treat fb->offsets[0] as a byte offset into the
> > linearized view of the surface. So we end up converting fb->offsets[0]
> > into additional x and y offsets.
> 
> Do you have code using a non-zero offsets[0]?  At least for current
> code that would indicate some kind of problem... though hopefully we'll
> be adding planar support back again sometime soon.

I did have some test app that used offsets[] at some point, but tbh I
didn't excercise these changes with it.

I have a sort of semi working skeleton of a test app which I just modify
for various use cases as need arises. I really should try to clean it up
a bit and generalize it so that it wouldn't need constant code changes
to test different scenarios.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread ville.syrj...@linux.intel.com 
From: Ville Syrj?l? 

Take fb->offset[0] into account when calculating the linear and tile x/y
offsets.

For non-tiled surfaces fb->offset[0] is simply added to the linear
byte offset.

For tiled surfaces treat fb->offsets[0] as a byte offset into the
linearized view of the surface. So we end up converting fb->offsets[0]
into additional x and y offsets.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_display.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9df15ee..f4338cb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1826,6 +1826,7 @@ static int i9xx_update_plane(struct drm_crtc *crtc, 
struct drm_framebuffer *fb,
unsigned long Start, Offset;
u32 dspcntr;
u32 reg;
+   unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, 0);

switch (plane) {
case 0:
@@ -1885,12 +1886,14 @@ static int i9xx_update_plane(struct drm_crtc *crtc, 
struct drm_framebuffer *fb,
I915_WRITE(reg, dspcntr);

Start = obj->gtt_offset;
-   Offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
+   Offset = fb->offsets[0] + y * fb->pitches[0] + x * cpp;

DRM_DEBUG_KMS("Writing base %08lX %08lX %d %d %d\n",
  Start, Offset, x, y, fb->pitches[0]);
I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
if (INTEL_INFO(dev)->gen >= 4) {
+   y += fb->offsets[0] / fb->pitches[0];
+   x += fb->offsets[0] % fb->pitches[0] / cpp;
I915_MODIFY_DISPBASE(DSPSURF(plane), Start);
I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
I915_WRITE(DSPADDR(plane), Offset);
@@ -1913,6 +1916,7 @@ static int ironlake_update_plane(struct drm_crtc *crtc,
unsigned long Start, Offset;
u32 dspcntr;
u32 reg;
+   unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, 0);

switch (plane) {
case 0:
@@ -1970,7 +1974,10 @@ static int ironlake_update_plane(struct drm_crtc *crtc,
I915_WRITE(reg, dspcntr);

Start = obj->gtt_offset;
-   Offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
+   Offset = fb->offsets[0] + y * fb->pitches[0] + x * cpp;
+
+   y += fb->offsets[0] / fb->pitches[0];
+   x += fb->offsets[0] % fb->pitches[0] / cpp;

DRM_DEBUG_KMS("Writing base %08lX %08lX %d %d %d\n",
  Start, Offset, x, y, fb->pitches[0]);
@@ -5993,7 +6000,7 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
goto err;

/* Offset into the new buffer for cases of shared fbs between CRTCs */
-   offset = crtc->y * fb->pitches[0] + crtc->x * fb->bits_per_pixel/8;
+   offset = fb->offsets[0] + crtc->y * fb->pitches[0] + crtc->x * 
fb->bits_per_pixel/8;

ret = intel_ring_begin(ring, 6);
if (ret)
@@ -6039,7 +6046,7 @@ static int intel_gen3_queue_flip(struct drm_device *dev,
goto err;

/* Offset into the new buffer for cases of shared fbs between CRTCs */
-   offset = crtc->y * fb->pitches[0] + crtc->x * fb->bits_per_pixel/8;
+   offset = fb->offsets[0] + crtc->y * fb->pitches[0] + crtc->x * 
fb->bits_per_pixel/8;

ret = intel_ring_begin(ring, 6);
if (ret)
-- 
1.7.3.4

[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread Daniel Vetter 
On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote:
> On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > On Thu, 24 May 2012 21:08:58 +0300
> > ville.syrjala at linux.intel.com wrote:
> > 
> > > From: Ville Syrj?l? 
> > > 
> > > Take fb->offset[0] into account when calculating the linear and tile x/y
> > > offsets.
> > > 
> > > For non-tiled surfaces fb->offset[0] is simply added to the linear
> > > byte offset.
> > > 
> > > For tiled surfaces treat fb->offsets[0] as a byte offset into the
> > > linearized view of the surface. So we end up converting fb->offsets[0]
> > > into additional x and y offsets.
> > 
> > Do you have code using a non-zero offsets[0]?  At least for current
> > code that would indicate some kind of problem... though hopefully we'll
> > be adding planar support back again sometime soon.
> 
> I did have some test app that used offsets[] at some point, but tbh I
> didn't excercise these changes with it.
> 
> I have a sort of semi working skeleton of a test app which I just modify
> for various use cases as need arises. I really should try to clean it up
> a bit and generalize it so that it wouldn't need constant code changes
> to test different scenarios.

Yeah, I want these little test apps as testcases in i-g-t.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread Jesse Barnes 
On Thu, 24 May 2012 21:08:58 +0300
ville.syrjala at linux.intel.com wrote:

> From: Ville Syrj?l? 
> 
> Take fb->offset[0] into account when calculating the linear and tile x/y
> offsets.
> 
> For non-tiled surfaces fb->offset[0] is simply added to the linear
> byte offset.
> 
> For tiled surfaces treat fb->offsets[0] as a byte offset into the
> linearized view of the surface. So we end up converting fb->offsets[0]
> into additional x and y offsets.

Do you have code using a non-zero offsets[0]?  At least for current
code that would indicate some kind of problem... though hopefully we'll
be adding planar support back again sometime soon.

-- 
Jesse Barnes, Intel Open Source Technology Center

[PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread ville . syrjala 
From: Ville Syrjälä ville.syrj...@linux.intel.com

Take fb-offset[0] into account when calculating the linear and tile x/y
offsets.

For non-tiled surfaces fb-offset[0] is simply added to the linear
byte offset.

For tiled surfaces treat fb-offsets[0] as a byte offset into the
linearized view of the surface. So we end up converting fb-offsets[0]
into additional x and y offsets.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9df15ee..f4338cb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1826,6 +1826,7 @@ static int i9xx_update_plane(struct drm_crtc *crtc, 
struct drm_framebuffer *fb,
unsigned long Start, Offset;
u32 dspcntr;
u32 reg;
+   unsigned int cpp = drm_format_plane_cpp(fb-pixel_format, 0);
 
switch (plane) {
case 0:
@@ -1885,12 +1886,14 @@ static int i9xx_update_plane(struct drm_crtc *crtc, 
struct drm_framebuffer *fb,
I915_WRITE(reg, dspcntr);
 
Start = obj-gtt_offset;
-   Offset = y * fb-pitches[0] + x * (fb-bits_per_pixel / 8);
+   Offset = fb-offsets[0] + y * fb-pitches[0] + x * cpp;
 
DRM_DEBUG_KMS(Writing base %08lX %08lX %d %d %d\n,
  Start, Offset, x, y, fb-pitches[0]);
I915_WRITE(DSPSTRIDE(plane), fb-pitches[0]);
if (INTEL_INFO(dev)-gen = 4) {
+   y += fb-offsets[0] / fb-pitches[0];
+   x += fb-offsets[0] % fb-pitches[0] / cpp;
I915_MODIFY_DISPBASE(DSPSURF(plane), Start);
I915_WRITE(DSPTILEOFF(plane), (y  16) | x);
I915_WRITE(DSPADDR(plane), Offset);
@@ -1913,6 +1916,7 @@ static int ironlake_update_plane(struct drm_crtc *crtc,
unsigned long Start, Offset;
u32 dspcntr;
u32 reg;
+   unsigned int cpp = drm_format_plane_cpp(fb-pixel_format, 0);
 
switch (plane) {
case 0:
@@ -1970,7 +1974,10 @@ static int ironlake_update_plane(struct drm_crtc *crtc,
I915_WRITE(reg, dspcntr);
 
Start = obj-gtt_offset;
-   Offset = y * fb-pitches[0] + x * (fb-bits_per_pixel / 8);
+   Offset = fb-offsets[0] + y * fb-pitches[0] + x * cpp;
+
+   y += fb-offsets[0] / fb-pitches[0];
+   x += fb-offsets[0] % fb-pitches[0] / cpp;
 
DRM_DEBUG_KMS(Writing base %08lX %08lX %d %d %d\n,
  Start, Offset, x, y, fb-pitches[0]);
@@ -5993,7 +6000,7 @@ static int intel_gen2_queue_flip(struct drm_device *dev,
goto err;
 
/* Offset into the new buffer for cases of shared fbs between CRTCs */
-   offset = crtc-y * fb-pitches[0] + crtc-x * fb-bits_per_pixel/8;
+   offset = fb-offsets[0] + crtc-y * fb-pitches[0] + crtc-x * 
fb-bits_per_pixel/8;
 
ret = intel_ring_begin(ring, 6);
if (ret)
@@ -6039,7 +6046,7 @@ static int intel_gen3_queue_flip(struct drm_device *dev,
goto err;
 
/* Offset into the new buffer for cases of shared fbs between CRTCs */
-   offset = crtc-y * fb-pitches[0] + crtc-x * fb-bits_per_pixel/8;
+   offset = fb-offsets[0] + crtc-y * fb-pitches[0] + crtc-x * 
fb-bits_per_pixel/8;
 
ret = intel_ring_begin(ring, 6);
if (ret)
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread Jesse Barnes 
On Thu, 24 May 2012 21:08:58 +0300
ville.syrj...@linux.intel.com wrote:

 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Take fb-offset[0] into account when calculating the linear and tile x/y
 offsets.
 
 For non-tiled surfaces fb-offset[0] is simply added to the linear
 byte offset.
 
 For tiled surfaces treat fb-offsets[0] as a byte offset into the
 linearized view of the surface. So we end up converting fb-offsets[0]
 into additional x and y offsets.

Do you have code using a non-zero offsets[0]?  At least for current
code that would indicate some kind of problem... though hopefully we'll
be adding planar support back again sometime soon.

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

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread Ville Syrjälä 
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
 On Thu, 24 May 2012 21:08:58 +0300
 ville.syrj...@linux.intel.com wrote:
 
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  Take fb-offset[0] into account when calculating the linear and tile x/y
  offsets.
  
  For non-tiled surfaces fb-offset[0] is simply added to the linear
  byte offset.
  
  For tiled surfaces treat fb-offsets[0] as a byte offset into the
  linearized view of the surface. So we end up converting fb-offsets[0]
  into additional x and y offsets.
 
 Do you have code using a non-zero offsets[0]?  At least for current
 code that would indicate some kind of problem... though hopefully we'll
 be adding planar support back again sometime soon.

I did have some test app that used offsets[] at some point, but tbh I
didn't excercise these changes with it.

I have a sort of semi working skeleton of a test app which I just modify
for various use cases as need arises. I really should try to clean it up
a bit and generalize it so that it wouldn't need constant code changes
to test different scenarios.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

2012-05-24 Thread Daniel Vetter 
On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote:
 On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
  On Thu, 24 May 2012 21:08:58 +0300
  ville.syrj...@linux.intel.com wrote:
  
   From: Ville Syrjälä ville.syrj...@linux.intel.com
   
   Take fb-offset[0] into account when calculating the linear and tile x/y
   offsets.
   
   For non-tiled surfaces fb-offset[0] is simply added to the linear
   byte offset.
   
   For tiled surfaces treat fb-offsets[0] as a byte offset into the
   linearized view of the surface. So we end up converting fb-offsets[0]
   into additional x and y offsets.
  
  Do you have code using a non-zero offsets[0]?  At least for current
  code that would indicate some kind of problem... though hopefully we'll
  be adding planar support back again sometime soon.
 
 I did have some test app that used offsets[] at some point, but tbh I
 didn't excercise these changes with it.
 
 I have a sort of semi working skeleton of a test app which I just modify
 for various use cases as need arises. I really should try to clean it up
 a bit and generalize it so that it wouldn't need constant code changes
 to test different scenarios.

Yeah, I want these little test apps as testcases in i-g-t.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel