Re: [Intel-gfx] [PATCH 1/3] drm/i915: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote: On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote: Those fields are supposed to be a good default value for the cursor size, intended for the case where the hardware doesn't support 64x64 cursors, for use with a hw agnostic DDX driver for instance. We're fine with 64x64 cursors though and don't need to set those fields (DRM core will return 64 is we don't). If we declare 256x256, that generic driver will use a big buffer for the cursor, without any good reason. How does userspace now know that 256x256 cursors are support for HiDPI? It doesn't currently? a property on the cursor plane with the list of supported formats in the brave new full drm_plane world seems like a good option to me. -- Damien ___ 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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote: Those fields are supposed to be a good default value for the cursor size, intended for the case where the hardware doesn't support 64x64 cursors, for use with a hw agnostic DDX driver for instance. We're fine with 64x64 cursors though and don't need to set those fields (DRM core will return 64 is we don't). If we declare 256x256, that generic driver will use a big buffer for the cursor, without any good reason. How does userspace now know that 256x256 cursors are support for HiDPI? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 02:59:18PM +, Damien Lespiau wrote: On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote: On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote: Those fields are supposed to be a good default value for the cursor size, intended for the case where the hardware doesn't support 64x64 cursors, for use with a hw agnostic DDX driver for instance. We're fine with 64x64 cursors though and don't need to set those fields (DRM core will return 64 is we don't). If we declare 256x256, that generic driver will use a big buffer for the cursor, without any good reason. How does userspace now know that 256x256 cursors are support for HiDPI? It doesn't currently? a property on the cursor plane with the list of supported formats in the brave new full drm_plane world seems like a good option to me. Userspace currently uses this method to determine the largest cursor supported by the driver. That userspace is inept at resize the cursor bo as required is a probably that won't be solved by simply exposing it later. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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: Don't set mode_config's cursor size
On Tue, 2014-03-25 at 14:59 +, Damien Lespiau wrote: On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote: On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote: Those fields are supposed to be a good default value for the cursor size, intended for the case where the hardware doesn't support 64x64 cursors, for use with a hw agnostic DDX driver for instance. We're fine with 64x64 cursors though and don't need to set those fields (DRM core will return 64 is we don't). If we declare 256x256, that generic driver will use a big buffer for the cursor, without any good reason. How does userspace now know that 256x256 cursors are support for HiDPI? It doesn't currently? a property on the cursor plane with the list of supported formats in the brave new full drm_plane world seems like a good option to me. How do we handle cursor size cap that was added with http://lists.freedesktop.org/archives/dri-devel/2014-February/053770.html. Will change i-g-t kms_cursor_crc accordingly as well since it depends on this cap. ___ 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: Don't set mode_config's cursor size
On Tue, 2014-03-25 at 14:49 +, Damien Lespiau wrote:
Those fields are supposed to be a good default value for the cursor
size, intended for the case where the hardware doesn't support 64x64
cursors, for use with a hw agnostic DDX driver for instance.
We're fine with 64x64 cursors though and don't need to set those fields
(DRM core will return 64 is we don't). If we declare 256x256, that
generic driver will use a big buffer for the cursor, without any good
reason.
Cc: Sagar Kamble sagar.a.kam...@intel.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 80dd1c2..7a47657 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10557,8 +10557,6 @@ static void intel_crtc_init(struct drm_device *dev,
int pipe)
intel_crtc-max_cursor_width = CURSOR_WIDTH;
intel_crtc-max_cursor_height = CURSOR_HEIGHT;
}
- dev-mode_config.cursor_width = intel_crtc-max_cursor_width;
- dev-mode_config.cursor_height = intel_crtc-max_cursor_height;
I thought drm_getcap should return the max cursor size, using these two
fields.
--Imre
drm_mode_crtc_set_gamma_size(intel_crtc-base, 256);
for (i = 0; i 256; i++) {
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Don't set mode_config's cursor size
Those fields are supposed to be a good default value for the cursor
size, intended for the case where the hardware doesn't support 64x64
cursors, for use with a hw agnostic DDX driver for instance.
We're fine with 64x64 cursors though and don't need to set those fields
(DRM core will return 64 is we don't). If we declare 256x256, that
generic driver will use a big buffer for the cursor, without any good
reason.
Cc: Sagar Kamble sagar.a.kam...@intel.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 80dd1c2..7a47657 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10557,8 +10557,6 @@ static void intel_crtc_init(struct drm_device *dev, int
pipe)
intel_crtc-max_cursor_width = CURSOR_WIDTH;
intel_crtc-max_cursor_height = CURSOR_HEIGHT;
}
- dev-mode_config.cursor_width = intel_crtc-max_cursor_width;
- dev-mode_config.cursor_height = intel_crtc-max_cursor_height;
drm_mode_crtc_set_gamma_size(intel_crtc-base, 256);
for (i = 0; i 256; i++) {
--
1.8.3.1
___
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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 03:09:16PM +, Chris Wilson wrote: On Tue, Mar 25, 2014 at 02:59:18PM +, Damien Lespiau wrote: On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote: On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote: Those fields are supposed to be a good default value for the cursor size, intended for the case where the hardware doesn't support 64x64 cursors, for use with a hw agnostic DDX driver for instance. We're fine with 64x64 cursors though and don't need to set those fields (DRM core will return 64 is we don't). If we declare 256x256, that generic driver will use a big buffer for the cursor, without any good reason. How does userspace now know that 256x256 cursors are support for HiDPI? It doesn't currently? a property on the cursor plane with the list of supported formats in the brave new full drm_plane world seems like a good option to me. Userspace currently uses this method to determine the largest cursor supported by the driver. That userspace is inept at resize the cursor bo as required is a probably that won't be solved by simply exposing it later. That doesn't seem to be the intention of the original patch? http://lists.freedesktop.org/archives/dri-devel/2014-February/053770.html Are you saying the Intel DDX currently derives a different meaning to the intented behaviour? in which case it can still be changed to not do that? -- Damien ___ 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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 04:05:29PM +, Damien Lespiau wrote: On Tue, Mar 25, 2014 at 03:09:16PM +, Chris Wilson wrote: On Tue, Mar 25, 2014 at 02:59:18PM +, Damien Lespiau wrote: On Tue, Mar 25, 2014 at 02:54:56PM +, Chris Wilson wrote: On Tue, Mar 25, 2014 at 02:49:30PM +, Damien Lespiau wrote: Those fields are supposed to be a good default value for the cursor size, intended for the case where the hardware doesn't support 64x64 cursors, for use with a hw agnostic DDX driver for instance. We're fine with 64x64 cursors though and don't need to set those fields (DRM core will return 64 is we don't). If we declare 256x256, that generic driver will use a big buffer for the cursor, without any good reason. How does userspace now know that 256x256 cursors are support for HiDPI? It doesn't currently? a property on the cursor plane with the list of supported formats in the brave new full drm_plane world seems like a good option to me. Userspace currently uses this method to determine the largest cursor supported by the driver. That userspace is inept at resize the cursor bo as required is a probably that won't be solved by simply exposing it later. That doesn't seem to be the intention of the original patch? http://lists.freedesktop.org/archives/dri-devel/2014-February/053770.html For the record, 16:30 agd5f ickle, our GPUs don't have selectable cursor sizes 16:31 agd5f so on the newer ones, xf86-video-modesetting, etc. would allocate a 64x64 cursor and it would look squashed and funky since the hw expects 128x128 Which means I was confused when I thought part of the reasoning was indeed HiDPI support. (I'm still seem to remember that was part of the argument for large cursors anyway.) Are you saying the Intel DDX currently derives a different meaning to the intented behaviour? in which case it can still be changed to not do that? I still disagree though. This provides all the information I need to support variable sized cursors and we can use large cursors today. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote: For the record, 16:30 agd5f ickle, our GPUs don't have selectable cursor sizes 16:31 agd5f so on the newer ones, xf86-video-modesetting, etc. would allocate a 64x64 cursor and it would look squashed and funky since the hw expects 128x128 Which means I was confused when I thought part of the reasoning was indeed HiDPI support. (I'm still seem to remember that was part of the argument for large cursors anyway.) Are you saying the Intel DDX currently derives a different meaning to the intented behaviour? in which case it can still be changed to not do that? I still disagree though. This provides all the information I need to support variable sized cursors and we can use large cursors today. I'd love the game to be about defining clear semantics more than by interpreting that value this way, I got what I always wanted :) We can resolve that today with MAX_CURSOR_WIDTH, MAX_CURSOR_HEIGHT caps as well (if you're alluding at the fact that drm_planes may still be a few decades away). We'll still need to expose the full list of supported cursor sizes for compositors at some point or another, my preferred way would be with a property in the exposed cursor drm_plane. -- Damien ___ 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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote: Are you saying the Intel DDX currently derives a different meaning to the intented behaviour? in which case it can still be changed to not do that? I still disagree though. This provides all the information I need to support variable sized cursors and we can use large cursors today. Note that I won't fight if you find it useful and people are fine with that new meaning. Can we just throw a patch actually documented what you want those values to be? The WM patch still needs to take the actual cursor size though. Keeping those global limits on the crtc struct still looks weird. -- Damien ___ 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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
For the record,
16:30 agd5f ickle, our GPUs don't have selectable cursor sizes
16:31 agd5f so on the newer ones, xf86-video-modesetting, etc. would
allocate a 64x64 cursor and it would look squashed and funky since the
hw expects 128x128
Which means I was confused when I thought part of the reasoning was
indeed HiDPI support. (I'm still seem to remember that was part of the
argument for large cursors anyway.)
Are you saying the Intel DDX currently derives a different meaning to
the intented behaviour? in which case it can still be changed to not do
that?
I still disagree though. This provides all the information I need to
support variable sized cursors and we can use large cursors today.
I'd love the game to be about defining clear semantics more than by
interpreting that value this way, I got what I always wanted :)
We can resolve that today with MAX_CURSOR_WIDTH, MAX_CURSOR_HEIGHT caps
as well (if you're alluding at the fact that drm_planes may still be a
few decades away).
We'll still need to expose the full list of supported cursor sizes for
compositors at some point or another, my preferred way would be with a
property in the exposed cursor drm_plane.
For the record I'll restate my comment here about the larger problem:
Atm we have no way for userspace to figure out per-plane limits on
sizes/strides, we only expose a lists of supported pixel formats.
Imo exposing cursor limits is just part of this larger issue, so if we can
get the current stuff working with some legalese, then I'm ok with that.
Solving the larger issue is much more work, and it's better to have a few
more odd cases working than not. For planes I guess we could have a few
limits:
min/max width height in pixels
min/max stride
alignment of stride
And a pile of flags
- needs pot stride/width/height
- needs square size
That should be enough to cover most single-plane things. For multiplanar I
guess we might either just need 2nd/3rd set of those or some additional
stuff expressed in flags (e.g. subsampled strides must be half of the Y
stride). Or we'll throw our hands in the air for multi-planar for now ;-)
Or we simply do this per-pixel format with one for each framebuffer plane,
i.e.
struct drm_get_plane_fb_limits {
uint32_t plane_id; /* in */
uint32_t fourcc; /* in */
struct drm_plane_limits limits[MAX_FOURCC_PLANES];
/* the stuff above for all possible planes of a fourcc code */
}
Saner drivers could then return the same thing for all fourccs codes in
their backend.
Just something to ponder.
Adding dri-devel, maybe we can get this discussion started.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
On Tue, Mar 25, 2014 at 04:57:04PM +, Damien Lespiau wrote:
On Tue, Mar 25, 2014 at 04:38:24PM +, Chris Wilson wrote:
For the record,
16:30 agd5f ickle, our GPUs don't have selectable cursor sizes
16:31 agd5f so on the newer ones, xf86-video-modesetting, etc. would
allocate a 64x64 cursor and it would look squashed and funky since the
hw expects 128x128
Which means I was confused when I thought part of the reasoning was
indeed HiDPI support. (I'm still seem to remember that was part of the
argument for large cursors anyway.)
Are you saying the Intel DDX currently derives a different meaning to
the intented behaviour? in which case it can still be changed to not do
that?
I still disagree though. This provides all the information I need to
support variable sized cursors and we can use large cursors today.
I'd love the game to be about defining clear semantics more than by
interpreting that value this way, I got what I always wanted :)
We can resolve that today with MAX_CURSOR_WIDTH, MAX_CURSOR_HEIGHT caps
as well (if you're alluding at the fact that drm_planes may still be a
few decades away).
We'll still need to expose the full list of supported cursor sizes for
compositors at some point or another, my preferred way would be with a
property in the exposed cursor drm_plane.
For the record I'll restate my comment here about the larger problem:
Atm we have no way for userspace to figure out per-plane limits on
sizes/strides, we only expose a lists of supported pixel formats.
Imo exposing cursor limits is just part of this larger issue, so if we can
get the current stuff working with some legalese, then I'm ok with that.
Solving the larger issue is much more work, and it's better to have a few
more odd cases working than not. For planes I guess we could have a few
limits:
min/max width height in pixels
min/max stride
alignment of stride
And a pile of flags
- needs pot stride/width/height
- needs square size
Already new ones:
- stride must match width*bpp
This will be fun if we ever do it ...
-Daniel
That should be enough to cover most single-plane things. For multiplanar I
guess we might either just need 2nd/3rd set of those or some additional
stuff expressed in flags (e.g. subsampled strides must be half of the Y
stride). Or we'll throw our hands in the air for multi-planar for now ;-)
Or we simply do this per-pixel format with one for each framebuffer plane,
i.e.
struct drm_get_plane_fb_limits {
uint32_t plane_id; /* in */
uint32_t fourcc; /* in */
struct drm_plane_limits limits[MAX_FOURCC_PLANES];
/* the stuff above for all possible planes of a fourcc code */
}
Saner drivers could then return the same thing for all fourccs codes in
their backend.
Just something to ponder.
Adding dri-devel, maybe we can get this discussion started.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
Or we simply do this per-pixel format with one for each framebuffer plane,
i.e.
struct drm_get_plane_fb_limits {
uint32_t plane_id; /* in */
uint32_t fourcc; /* in */
struct drm_plane_limits limits[MAX_FOURCC_PLANES];
/* the stuff above for all possible planes of a fourcc code */
}
Saner drivers could then return the same thing for all fourccs codes in
their backend.
Some of the limits are definitely per format. Plane max dimensions are a
good example of a limit that can change per-format (8bpp Vs 10bpp to be
contained within the same max bandwidth of the hw).
--
Damien
___
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: Don't set mode_config's cursor size
On Tue, Mar 25, 2014 at 7:51 PM, Damien Lespiau
damien.lesp...@intel.com wrote:
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
Or we simply do this per-pixel format with one for each framebuffer plane,
i.e.
struct drm_get_plane_fb_limits {
uint32_t plane_id; /* in */
uint32_t fourcc; /* in */
struct drm_plane_limits limits[MAX_FOURCC_PLANES];
/* the stuff above for all possible planes of a fourcc code */
}
Saner drivers could then return the same thing for all fourccs codes in
their backend.
Some of the limits are definitely per format. Plane max dimensions are a
good example of a limit that can change per-format (8bpp Vs 10bpp to be
contained within the same max bandwidth of the hw).
One thing I've completely missed btw is scaling limits. How we then
need to factor in bandwidth I have no idea about ... I guess at one
point it boils down to try it and give up if it doesn't work. And I
think we need a few scaling related flags like can't scale at all or
sub-sampling restrictions. Who knows ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
