[Bug 71239] New: Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 Priority: medium Bug ID: 71239 Assignee: dri-devel at lists.freedesktop.org Summary: Metro Last Light quits(?) on r600g Severity: normal Classification: Unclassified OS: Linux (All) Reporter: sobkas at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa Metro Last Light quits(?) on r600g. While trying to run Metro Last Light on VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba] game quit with exit code 53. Wasn't able to use apitrace to find anything, neither gdb. Any ideas? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/9e890bc4/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #1 from John Bridgman --- Are there any error logs from the application itself ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/01e4cff0/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #2 from Krzysztof A. Sobiecki --- Created attachment 88659 --> https://bugs.freedesktop.org/attachment.cgi?id=88659&action=edit strings of MetroLL -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/51a6bdc0/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #3 from Krzysztof A. Sobiecki --- (In reply to comment #1) > Are there any error logs from the application itself ? Not even a single pip. Heard it might be a OpenGL 4 game. Will look at it closer tomorrow. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/2ab1b455/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #4 from Krzysztof A. Sobiecki --- Created attachment 88660 --> https://bugs.freedesktop.org/attachment.cgi?id=88660&action=edit It's cloning itself? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/4df51bfb/attachment.html>
[Bug 63391] Radeon RS880 doesn't resume from suspend with radeon dpm enabled
https://bugzilla.kernel.org/show_bug.cgi?id=63391 Tasev Nikola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INSUFFICIENT_DATA -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH 3/3] drm/i915: Clean up if drm_sysfs_connector_add() fails
On Tue, Nov 05, 2013 at 09:23:46AM +0200, Jani Nikula wrote:
> On Mon, 04 Nov 2013, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l?
> >
> > While we can now call drm_sysfs_connector_remove() even if
> > drm_connector_sysfs_add() failed, it would seem better for
> > the user to know that something went wrong. So instead of
> > ignoring drm_sysfs_connector_add() return value, checl it
> > and fail the whole connector registration.
>
> I think I'd rather see a cleanup of the init time fail paths first,
> using the regular kernel goto style. Which I also don't think should be
> a huge priority. Whaddaya think?
In my dream world we could solve most of this with devres.c. Requires us
to fix the drm midlayer first though, and I'd guess that the interaction
with the shadow attach stuff could be interesting ...
-Daniel
>
> Cheers,
> Jani.
>
>
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > drivers/gpu/drm/i915/intel_crt.c | 10 +-
> > drivers/gpu/drm/i915/intel_ddi.c | 5 -
> > drivers/gpu/drm/i915/intel_dp.c | 6 +-
> > drivers/gpu/drm/i915/intel_drv.h | 2 +-
> > drivers/gpu/drm/i915/intel_dsi.c | 9 -
> > drivers/gpu/drm/i915/intel_dvo.c | 8 +++-
> > drivers/gpu/drm/i915/intel_hdmi.c | 16 +---
> > drivers/gpu/drm/i915/intel_lvds.c | 7 ++-
> > drivers/gpu/drm/i915/intel_sdvo.c | 36 +---
> > drivers/gpu/drm/i915/intel_tv.c | 10 +-
> > 10 files changed, 91 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_crt.c
> > b/drivers/gpu/drm/i915/intel_crt.c
> > index 2e01bd3..be8a024 100644
> > --- a/drivers/gpu/drm/i915/intel_crt.c
> > +++ b/drivers/gpu/drm/i915/intel_crt.c
> > @@ -773,6 +773,7 @@ void intel_crt_init(struct drm_device *dev)
> > struct intel_crt *crt;
> > struct intel_connector *intel_connector;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > + int error;
> >
> > /* Skip machines without VGA that falsely report hotplug events */
> > if (dmi_check_system(intel_no_crt))
> > @@ -836,7 +837,14 @@ void intel_crt_init(struct drm_device *dev)
> >
> > drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
> >
> > - drm_sysfs_connector_add(connector);
> > + error = drm_sysfs_connector_add(connector);
> > + if (error) {
> > + drm_encoder_cleanup(&crt->base.base);
> > + drm_connector_cleanup(connector);
> > + kfree(intel_connector);
> > + kfree(crt);
> > + return;
> > + }
> >
> > if (!I915_HAS_HOTPLUG(dev))
> > intel_connector->polled = DRM_CONNECTOR_POLL_CONNECT;
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 31f4fe2..687e333 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1375,7 +1375,10 @@ intel_ddi_init_hdmi_connector(struct
> > intel_digital_port *intel_dig_port)
> > return NULL;
> >
> > intel_dig_port->hdmi.hdmi_reg = DDI_BUF_CTL(port);
> > - intel_hdmi_init_connector(intel_dig_port, connector);
> > + if (!intel_hdmi_init_connector(intel_dig_port, connector)) {
> > + kfree(connector);
> > + return NULL;
> > + }
> >
> > return connector;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index c8515bb..eb01be7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3603,7 +3603,11 @@ intel_dp_init_connector(struct intel_digital_port
> > *intel_dig_port,
> > ironlake_panel_vdd_work);
> >
> > intel_connector_attach_encoder(intel_connector, intel_encoder);
> > - drm_sysfs_connector_add(connector);
> > + error = drm_sysfs_connector_add(connector);
> > + if (error) {
> > + drm_connector_cleanup(connector);
> > + return false;
> > + }
> >
> > if (HAS_DDI(dev))
> > intel_connector->get_hw_state =
> > intel_ddi_connector_get_hw_state;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9d2624f..a944d6e 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -760,7 +760,7 @@ static inline void intel_fbdev_restore_mode(struct
> > drm_device *dev)
> >
> > /* intel_hdmi.c */
> > void intel_hdmi_init(struct drm_device *dev, int hdmi_reg, enum port port);
> > -void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
> > +bool intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
> >struct intel_connector *intel_connector);
> > struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
> > bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index d25
[PATCH 2/3] drm/sysfs: Don't pollute connector->kdev if drm_connector_sysfs_add() fails
On Mon, 04 Nov 2013, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> Currently if drm_connector_sysfs_add() fails, it can leave connector->kdev
> populated with an ERR_PTR value, or pointing to an already freed device.
> Use a temporarary kdev pointer during drm_connector_sysfs_add(), and
> only set connector->kdev if the function succeeds. This avoids oopsing
> if drm_connector_sysfs_remove() gets called for a connector where
> drm_connector_sysfs_add() previously failed.
s/connector_sysfs/sysfs_connector/g
> Give drm_sysfs_device_add() the same treatment for the sake of
> consistency.
Maybe that one should have the if (minor->kdev) return 0; part too if
consistency is what you're after.
The above addressed and you've got
Reviewed-by: Jani Nikula
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_sysfs.c | 43 +--
> 1 file changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 1a35ea5..a82dc8b 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -370,6 +370,7 @@ static struct bin_attribute edid_attr = {
> int drm_sysfs_connector_add(struct drm_connector *connector)
> {
> struct drm_device *dev = connector->dev;
> + struct device *kdev;
> int attr_cnt = 0;
> int opt_cnt = 0;
> int i;
> @@ -378,22 +379,22 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
> if (connector->kdev)
> return 0;
>
> - connector->kdev = device_create(drm_class, dev->primary->kdev,
> - 0, connector, "card%d-%s",
> - dev->primary->index,
> drm_get_connector_name(connector));
> + kdev = device_create(drm_class, dev->primary->kdev,
> + 0, connector, "card%d-%s",
> + dev->primary->index,
> drm_get_connector_name(connector));
> DRM_DEBUG("adding \"%s\" to sysfs\n",
> drm_get_connector_name(connector));
>
> - if (IS_ERR(connector->kdev)) {
> - DRM_ERROR("failed to register connector device: %ld\n",
> PTR_ERR(connector->kdev));
> - ret = PTR_ERR(connector->kdev);
> + if (IS_ERR(kdev)) {
> + DRM_ERROR("failed to register connector device: %ld\n",
> PTR_ERR(kdev));
> + ret = PTR_ERR(kdev);
> goto out;
> }
>
> /* Standard attributes */
>
> for (attr_cnt = 0; attr_cnt < ARRAY_SIZE(connector_attrs); attr_cnt++) {
> - ret = device_create_file(connector->kdev,
> &connector_attrs[attr_cnt]);
> + ret = device_create_file(kdev, &connector_attrs[attr_cnt]);
> if (ret)
> goto err_out_files;
> }
> @@ -410,7 +411,7 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
> case DRM_MODE_CONNECTOR_Component:
> case DRM_MODE_CONNECTOR_TV:
> for (opt_cnt = 0; opt_cnt <
> ARRAY_SIZE(connector_attrs_opt1); opt_cnt++) {
> - ret = device_create_file(connector->kdev,
> &connector_attrs_opt1[opt_cnt]);
> + ret = device_create_file(kdev,
> &connector_attrs_opt1[opt_cnt]);
> if (ret)
> goto err_out_files;
> }
> @@ -419,21 +420,23 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
> break;
> }
>
> - ret = sysfs_create_bin_file(&connector->kdev->kobj, &edid_attr);
> + ret = sysfs_create_bin_file(&kdev->kobj, &edid_attr);
> if (ret)
> goto err_out_files;
>
> /* Let userspace know we have a new connector */
> drm_sysfs_hotplug_event(dev);
>
> + connector->kdev = kdev;
> +
> return 0;
>
> err_out_files:
> for (i = 0; i < opt_cnt; i++)
> - device_remove_file(connector->kdev, &connector_attrs_opt1[i]);
> + device_remove_file(kdev, &connector_attrs_opt1[i]);
> for (i = 0; i < attr_cnt; i++)
> - device_remove_file(connector->kdev, &connector_attrs[i]);
> - device_unregister(connector->kdev);
> + device_remove_file(kdev, &connector_attrs[i]);
> + device_unregister(kdev);
>
> out:
> return ret;
> @@ -501,6 +504,7 @@ EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> int drm_sysfs_device_add(struct drm_minor *minor)
> {
> char *minor_str;
> + struct device *kdev;
>
> if (minor->type == DRM_MINOR_CONTROL)
> minor_str = "controlD%d";
> @@ -509,13 +513,16 @@ int drm_sysfs_device_add(struct drm_minor *minor)
> else
> minor_str = "card%d";
>
> - minor->kdev = device_create(drm_class, minor->dev->dev,
> - MKDEV(DRM_MAJOR, minor->index),
> -
[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Tuesday, November 05, 2013 12:44 AM
> To: Inki Dae
> Cc: Thierry Reding; Laurent Pinchart; dri-devel; Sylwester Nawrocki;
> St?phane Marchesin
> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>
> On Mon, Nov 4, 2013 at 6:30 AM, Inki Dae wrote:
> > 2013/11/4 Thierry Reding :
> >> On Tue, Oct 29, 2013 at 08:46:03PM -0700, St?phane Marchesin wrote:
> >>> On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa
> wrote:
> >>>
> >>> > Hi Sean,
> >>> >
> >>> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:
> >>> > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa
>
> >>> > wrote:
> >>> > > > Hi,
> >>> > > >
> >>> > > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> >>> > > >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie
>
> >>> > wrote:
> >>> > > >> > I think we need to start considering a framework where
> >>> > > >> > subdrivers
> >>> > > >> > just
> >>> > > >> > add drm objects themselves, then the toplevel node is
> >>> > > >> > responsible
> >>> > > >> > for
> >>> > > >> > knowing that everything for the current configuration is
> >>> > > >> > loaded.
> >>> > > >>
> >>> > > >> It would be nice to specify the various pieces in dt, then
> have
> >>> > > >> some
> >>> > > >> type of drm notifier to the toplevel node when everything
> has
> >>> > > >> been
> >>> > > >> probed. Doing it in the dt would allow standalone
> >>> > > >> drm_bridge/drm_panel
> >>> > > >> drivers to be transparent as far as the device's drm
> driver is
> >>> > > >> concerned.
> >>> > > >>
> >>> > > >> Sean
> >>> > > >>
> >>> > > >> > I realise we may need to make changes to the core drm to
> allow
> >>> > > >> > this
> >>> > > >> > but we should probably start to create a strategy for
> fixing
> >>> > > >> > the
> >>> > > >> > API
> >>> > > >> > issues that this throws up.
> >>> > > >> >
> >>> > > >> > Note I'm not yet advocating for dynamic addition of nodes
> once
> >>> > > >> > the
> >>> > > >> > device is in use, or removing them.
> >>> > > >> >>>
> >>> > > >> >>> I do wonder if we had some sort of tag in the device tree
> for any
> >>> > > >> >>> nodes
> >>> > > >> >>> involved in the display, and the core drm layer would read
> that
> >>> > > >> >>> list,
> >>> > > >> >>> and when every driver registers tick things off, and when
> the
> >>> > > >> >>> last
> >>> > > >> >>> one
> >>> > > >> >>> joins we get a callback and init the drm layer, we'd of
> course
> >>> > > >> >>> have
> >>> > > >> >>> the
> >>> > > >> >>> basic drm layer setup prior to that so we can add the
> objects as
> >>> > > >> >>> the
> >>> > > >> >>> drivers load. It might make development a bit trickier as
> you'd
> >>> > > >> >>> need
> >>> > > >> >>> to make sure someone claimed ownership of all the bits for
> init
> >>> > > >> >>> to
> >>> > > >> >>> proceed.>>
> >>> > > >> >>
> >>> > > >> >> Yeah, that's basically what the strawman looked like in my
> head.
> >>> > > >> >>
> >>> > > >> >> Instead of a property in each node, I was thinking of having
> a
> >>> > > >> >> separate gfx pipe nodes that would have dt pointers to the
> various
> >>> > > >> >> pieces involved in that pipe. This would allow us to
> associate
> >>> > > >> >> standalone entities like bridges and panels with encoders in
> dt
> >>> > > >> >> w/o
> >>> > > >> >> doing it in the drm code. I *think* this should be Ok with
> the dt
> >>> > > >> >> guys
> >>> > > >> >> since it is still describing the hardware, but I think we'd
> have
> >>> > > >> >> to
> >>> > > >> >> make sure it wasn't drm-specific.
> >>> > > >> >
> >>> > > >> > I suppose the question is how much dynamic pipeline
> construction
> >>> > > >> > there
> >>> > > >> > is,
> >>> > > >> >
> >>> > > >> > even on things like radeon and i915 we have dynamic clock
> generator
> >>> > > >> > to
> >>> > > >> > crtc to encoder setups, so I worry about static lists per-
> pipe, so
> >>> > > >> > I
> >>> > > >> > still think just stating all these devices are needed for
> display
> >>> > > >> > and
> >>> > > >> > a list of valid interconnections between them, then we can
> have the
> >>> > > >> > generic code model drm crtc/encoders/connectors on that list,
> and
> >>> > > >> > construct the possible_crtcs /possible_clones etc at that
> stage.
> >>> > > >>
> >>> > > >> I'm, without excuse, hopeless at devicetree, so there are
> probably
> >>> > > >> some violations, but something like:
> >>> > > >>
> >>> > > >> display-pipelines {
> >>> > > >>
> >>> > > >> required-elements = <&bridge-a &panel-a &encoder-x &encoder-y
> >>> > > >>
> >>> > > >> &crtc-x &crtc-y>;
> >>> > > >>
> >>> > > >> pipe1 {
> >>> > > >>
> >>> > > >> bridge = <&bridge-a>;
> >>> > > >> encoder = <&encoder-x>;
> >>> > > >> crtc = <&crtc-y>;
> >>> > > >>
> >>> > > >> };
> >>> > > >> pipe2 {
> >>>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 Mike Lothian changed: What|Removed |Added CC||mike at fireburn.co.uk --- Comment #5 from Mike Lothian --- I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me I'm guessing this game needs either the GLSL 1.50 version or Geometry shaders can anyone with Ivybridge or Haswell confirm that the game runs correctly with Mesa 10 / master. I'm stuck with i965 on Sandybridge and r600g -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/ab997b32/attachment-0001.html>
[Bug 63391] Radeon RS880 doesn't resume from suspend with radeon dpm enabled
https://bugzilla.kernel.org/show_bug.cgi?id=63391 --- Comment #10 from Tasev Nikola --- Hi, I tested final 3.12 and the bug is still there. I 'm closing this bug because for me is not a big issue, i just disabled dpm and my system is stable. I hear that in next 3.13 kernel the dpm will be enabled by default, i hope that the kernel parameter will still exist so i can disable it. I don't no how to help moore to debug this so for now i'm closing this bug. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 3/3] drm/i915: Clean up if drm_sysfs_connector_add() fails
On Mon, 04 Nov 2013, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> While we can now call drm_sysfs_connector_remove() even if
> drm_connector_sysfs_add() failed, it would seem better for
> the user to know that something went wrong. So instead of
> ignoring drm_sysfs_connector_add() return value, checl it
> and fail the whole connector registration.
I think I'd rather see a cleanup of the init time fail paths first,
using the regular kernel goto style. Which I also don't think should be
a huge priority. Whaddaya think?
Cheers,
Jani.
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/intel_crt.c | 10 +-
> drivers/gpu/drm/i915/intel_ddi.c | 5 -
> drivers/gpu/drm/i915/intel_dp.c | 6 +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_dsi.c | 9 -
> drivers/gpu/drm/i915/intel_dvo.c | 8 +++-
> drivers/gpu/drm/i915/intel_hdmi.c | 16 +---
> drivers/gpu/drm/i915/intel_lvds.c | 7 ++-
> drivers/gpu/drm/i915/intel_sdvo.c | 36 +---
> drivers/gpu/drm/i915/intel_tv.c | 10 +-
> 10 files changed, 91 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 2e01bd3..be8a024 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -773,6 +773,7 @@ void intel_crt_init(struct drm_device *dev)
> struct intel_crt *crt;
> struct intel_connector *intel_connector;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + int error;
>
> /* Skip machines without VGA that falsely report hotplug events */
> if (dmi_check_system(intel_no_crt))
> @@ -836,7 +837,14 @@ void intel_crt_init(struct drm_device *dev)
>
> drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
>
> - drm_sysfs_connector_add(connector);
> + error = drm_sysfs_connector_add(connector);
> + if (error) {
> + drm_encoder_cleanup(&crt->base.base);
> + drm_connector_cleanup(connector);
> + kfree(intel_connector);
> + kfree(crt);
> + return;
> + }
>
> if (!I915_HAS_HOTPLUG(dev))
> intel_connector->polled = DRM_CONNECTOR_POLL_CONNECT;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 31f4fe2..687e333 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1375,7 +1375,10 @@ intel_ddi_init_hdmi_connector(struct
> intel_digital_port *intel_dig_port)
> return NULL;
>
> intel_dig_port->hdmi.hdmi_reg = DDI_BUF_CTL(port);
> - intel_hdmi_init_connector(intel_dig_port, connector);
> + if (!intel_hdmi_init_connector(intel_dig_port, connector)) {
> + kfree(connector);
> + return NULL;
> + }
>
> return connector;
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c8515bb..eb01be7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3603,7 +3603,11 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
> ironlake_panel_vdd_work);
>
> intel_connector_attach_encoder(intel_connector, intel_encoder);
> - drm_sysfs_connector_add(connector);
> + error = drm_sysfs_connector_add(connector);
> + if (error) {
> + drm_connector_cleanup(connector);
> + return false;
> + }
>
> if (HAS_DDI(dev))
> intel_connector->get_hw_state =
> intel_ddi_connector_get_hw_state;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9d2624f..a944d6e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -760,7 +760,7 @@ static inline void intel_fbdev_restore_mode(struct
> drm_device *dev)
>
> /* intel_hdmi.c */
> void intel_hdmi_init(struct drm_device *dev, int hdmi_reg, enum port port);
> -void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
> +bool intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
> struct intel_connector *intel_connector);
> struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
> bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index d257b09..16684b5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -535,6 +535,7 @@ bool intel_dsi_init(struct drm_device *dev)
> struct drm_display_mode *fixed_mode = NULL;
> const struct intel_dsi_device *dsi;
> unsigned int i;
> + int error;
>
> DRM_DEBUG_KMS("\n");
>
> @@ -598,11 +599,17 @@ bool intel_dsi_init(struct drm_device *dev)
>
> intel_con
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #12 from Chris --- I believe kernel-3.8 and 3.11 already have these patches, but it looks like doesn't work. (In reply to comment #5) > I would consider having a look at bug 43655, it might be related. Could you > try workaround proposed in comment 8 (bug 43655#c8) or comment 13 (bug > 43655#c13)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/53cb/attachment.html>
[PATCH v4 2/2] drm: omap: Enable DT support for DMM
On Friday 01 November 2013 06:10 AM, Mark Rutland wrote:
> On Tue, Oct 15, 2013 at 08:04:20AM +0100, Archit Taneja wrote:
>> Enable use of DT for DMM/Tiler.
>>
>> Originally worked on by Andy Gross
>>
>> Cc: Andy Gross
>> Cc: DRI Development
>> Signed-off-by: Archit Taneja
>> ---
>> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> index acf6678..59f17de 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> @@ -968,12 +968,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
>> };
>> #endif
>>
>> +#if defined(CONFIG_OF)
>> +static const struct of_device_id dmm_of_match[] = {
>> +{ .compatible = "ti,omap4-dmm", },
>> +{ .compatible = "ti,omap5-dmm", },
>> +{},
>> +};
>> +#else
>> +#define dmm_of_match NULL
>> +#endif
>> +
>> struct platform_driver omap_dmm_driver = {
>> .probe = omap_dmm_probe,
>> .remove = omap_dmm_remove,
>> .driver = {
>> .owner = THIS_MODULE,
>> .name = DMM_DRIVER_NAME,
>> +.of_match_table = dmm_of_match,
>
> If you use of_match_ptr(dmm_of_match) here you don't need the #else case
> above.
Thanks for the tip. I'll make this update.
Archit
[Intel-gfx] [PATCH 1/3] drm/sysfs: Remove stale comments about calling drm_sysfs_connector_add() multiple times
On Mon, 04 Nov 2013, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> drm_connector_sysfs_add() explicitly checks if connector->kdev
> is already populated and returns success. So it clearly now allows
> being called multiple times. Remove some stale comments to the contrary.
>
> Signed-off-by: Ville Syrj?l?
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_sysfs.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index db1c8f9..1a35ea5 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -366,11 +366,6 @@ static struct bin_attribute edid_attr = {
> * properties (so far, connection status, dpms, mode list & edid) and
> * generate a hotplug event so userspace knows there's a new connector
> * available.
> - *
> - * Note:
> - * This routine should only be called *once* for each registered connector.
> - * A second call for an already registered connector will trigger the BUG_ON
> - * below.
> */
> int drm_sysfs_connector_add(struct drm_connector *connector)
> {
> @@ -383,7 +378,6 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
> if (connector->kdev)
> return 0;
>
> - /* We shouldn't get called more than once for the same connector */
> connector->kdev = device_create(drm_class, dev->primary->kdev,
> 0, connector, "card%d-%s",
> dev->primary->index,
> drm_get_connector_name(connector));
> --
> 1.8.1.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #6 from Krzysztof A. Sobiecki --- (In reply to comment #5) > I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 > MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me > > I'm guessing this game needs either the GLSL 1.50 version or Geometry > shaders can anyone with Ivybridge or Haswell confirm that the game runs > correctly with Mesa 10 / master. I'm stuck with i965 on Sandybridge and r600g With your override I was able to start new game and to walk around D6 for a bit. Will post my config file. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/6f7f231c/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #7 from Krzysztof A. Sobiecki --- Created attachment 88675 --> https://bugs.freedesktop.org/attachment.cgi?id=88675&action=edit Config file -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/19adfde6/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #8 from Krzysztof A. Sobiecki --- (In reply to comment #5) > I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 > MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me > When I force only MESA_GLSL_VERSION_OVERRIDE=150 it also works, but I automatically switch to OpenGL 3.2. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/20124aa5/attachment.html>
[PATCH v2] drm/i915: Make AGP support optional
From: Ville Syrj?l?
We only depend on the intel-gtt module for GTT frobbign on older gens.
The intel_agp module is optional, except for UMS and some old XvMC
userland on gen3. So make AGP support optional. As before, we will
fail the i915 init for UMS and gen3 KMS the same as before if
intel_agp isn't around.
intel-gtt.c is left with a somewhat ugly ifdef mess, but I'm going
to save that for a later cleaning.
At least my gen2 still works with the patch and CONFIG_AGP=n.
v2: Make i915 depend on X86 and PCI, and intel-gtt depend on PCI
Signed-off-by: Ville Syrj?l?
---
drivers/char/Makefile | 2 +-
drivers/char/agp/Kconfig| 5 +
drivers/char/agp/Makefile | 2 +-
drivers/char/agp/intel-gtt.c| 18 ++
drivers/gpu/drm/i915/Kconfig| 6 --
drivers/gpu/drm/i915/i915_drv.c | 4
6 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 7ff1d0d..2d68054 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -50,7 +50,7 @@ obj-$(CONFIG_GPIO_TB0219) += tb0219.o
obj-$(CONFIG_TELCLOCK) += tlclk.o
obj-$(CONFIG_MWAVE)+= mwave/
-obj-$(CONFIG_AGP) += agp/
+obj-y += agp/
obj-$(CONFIG_PCMCIA) += pcmcia/
obj-$(CONFIG_HANGCHECK_TIMER) += hangcheck-timer.o
diff --git a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig
index d8b1b57..c528f96 100644
--- a/drivers/char/agp/Kconfig
+++ b/drivers/char/agp/Kconfig
@@ -68,6 +68,7 @@ config AGP_AMD64
config AGP_INTEL
tristate "Intel 440LX/BX/GX, I8xx and E7x05 chipset support"
depends on AGP && X86
+ select INTEL_GTT
help
This option gives you AGP support for the GLX component of X
on Intel 440LX/BX/GX, 815, 820, 830, 840, 845, 850, 860, 875,
@@ -155,3 +156,7 @@ config AGP_SGI_TIOCA
This option gives you AGP GART support for the SGI TIO chipset
for IA64 processors.
+config INTEL_GTT
+ tristate
+ depends on X86 && PCI
+
diff --git a/drivers/char/agp/Makefile b/drivers/char/agp/Makefile
index 8eb56e2..604489b 100644
--- a/drivers/char/agp/Makefile
+++ b/drivers/char/agp/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_AGP_HP_ZX1) += hp-agp.o
obj-$(CONFIG_AGP_PARISC) += parisc-agp.o
obj-$(CONFIG_AGP_I460) += i460-agp.o
obj-$(CONFIG_AGP_INTEL)+= intel-agp.o
-obj-$(CONFIG_AGP_INTEL)+= intel-gtt.o
+obj-$(CONFIG_INTEL_GTT)+= intel-gtt.o
obj-$(CONFIG_AGP_NVIDIA) += nvidia-agp.o
obj-$(CONFIG_AGP_SGI_TIOCA)+= sgi-agp.o
obj-$(CONFIG_AGP_SIS) += sis-agp.o
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index b8e2014..078968d 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -94,6 +94,7 @@ static struct _intel_private {
#define IS_IRONLAKEintel_private.driver->is_ironlake
#define HAS_PGTBL_EN intel_private.driver->has_pgtbl_enable
+#if IS_ENABLED(CONFIG_AGP_INTEL)
static int intel_gtt_map_memory(struct page **pages,
unsigned int num_entries,
struct sg_table *st)
@@ -168,6 +169,7 @@ static void i8xx_destroy_pages(struct page *page)
__free_pages(page, 2);
atomic_dec(&agp_bridge->current_memory_agp);
}
+#endif
#define I810_GTT_ORDER 4
static int i810_setup(void)
@@ -209,6 +211,7 @@ static void i810_cleanup(void)
free_gatt_pages(intel_private.i81x_gtt_table, I810_GTT_ORDER);
}
+#if IS_ENABLED(CONFIG_AGP_INTEL)
static int i810_insert_dcache_entries(struct agp_memory *mem, off_t pg_start,
int type)
{
@@ -289,6 +292,7 @@ static void intel_i810_free_by_type(struct agp_memory *curr)
}
kfree(curr);
}
+#endif
static int intel_gtt_setup_scratch_page(void)
{
@@ -647,7 +651,9 @@ static int intel_gtt_init(void)
return -ENOMEM;
}
+#if IS_ENABLED(CONFIG_AGP_INTEL)
global_cache_flush(); /* FIXME: ? */
+#endif
intel_private.stolen_size = intel_gtt_stolen_size();
@@ -671,6 +677,7 @@ static int intel_gtt_init(void)
return 0;
}
+#if IS_ENABLED(CONFIG_AGP_INTEL)
static int intel_fake_agp_fetch_size(void)
{
int num_sizes = ARRAY_SIZE(intel_fake_agp_sizes);
@@ -689,6 +696,7 @@ static int intel_fake_agp_fetch_size(void)
return 0;
}
+#endif
static void i830_cleanup(void)
{
@@ -801,6 +809,7 @@ static int i830_setup(void)
return 0;
}
+#if IS_ENABLED(CONFIG_AGP_INTEL)
static int intel_fake_agp_create_gatt_table(struct agp_bridge_data *bridge)
{
agp_bridge->gatt_table_real = NULL;
@@ -825,6 +834,7 @@ static int intel_fake_agp_configure(void)
return 0;
}
+#endif
static bool i830_check_flags(unsigned int flags)
{
@@ -863,6 +873,7 @@ void intel_gtt_insert_sg_entries(struct sg_table *st,
}
EXPORT_SYMBOL(intel_gtt_insert_sg_en
[Bug 71259] New: Richland-999B : OpenGL Games/Demos fail to render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=71259 Priority: medium Bug ID: 71259 Assignee: dri-devel at lists.freedesktop.org Summary: Richland-999B : OpenGL Games/Demos fail to render correctly Severity: major Classification: Unclassified OS: All Reporter: hysvats at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 88687 --> https://bugs.freedesktop.org/attachment.cgi?id=88687&action=edit xorg.log Driver Stack Details: = 1)Kernel-3.11.0-12-generic 2)drm-2.4.46 3)Mesa-10.0.0-devel 4)Xorg-server-1.14.3 5)xf86-video-ati- git 6)glamor-0.5.1 7)LLVM-3.3 System Configuration: = Asic/Chipset : Richland Scrapper Lite AMD Radeon HD 8310G(999B) O.S. : Ubuntu-13.10 (64 bit) Steps to Reproduce : = 1) Install ut2004-demo with Phoronix-test-suite 2) phoronix-test-suite run ut2004-demo Observed: == 1) The game/demo is rendered incorrectly (Screenshot attached). 2) The issue is also observed for other apps like Padman etc. 3) The issue is not observed with Richland Scrapper HD 8450G(9995) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/a67b2688/attachment.html>
[Bug 71259] Richland-999B : OpenGL Games/Demos fail to render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=71259 --- Comment #1 from samit vats --- Created attachment 88688 --> https://bugs.freedesktop.org/attachment.cgi?id=88688&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/d5af52d3/attachment-0001.html>
[Bug 71259] Richland-999B : OpenGL Games/Demos fail to render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=71259 --- Comment #2 from samit vats --- Created attachment 88689 --> https://bugs.freedesktop.org/attachment.cgi?id=88689&action=edit screenshot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/56c3d535/attachment.html>
[Bug 71259] Richland-999B : OpenGL Games/Demos fail to render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=71259 Fabio Pedretti changed: What|Removed |Added Attachment #88689|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/ce58fb21/attachment.html>
[PATCH 1/5] drm/radeon: rework and fix reset detection v2
Am 03.11.2013 13:15, schrieb Rafa? Mi?ecki: > 2013/10/29 Christian K?nig : >> From: Christian K?nig >> >> Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT. >> Consolidate the two wait sequence implementations into just one function. >> Activate all waiters and remember if the reset was already done instead of >> trying to reset from only one thread. > With this patch I can't suspend my Samsung with: > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] > nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720] > anymore. > > The backlight goes off, activity LED goes off and then nothing. > Machine is still running and other lights (power, wifi, keyboard, > touchpad) are still working. Seems like a lockup to me. Does the attached patch help? Cheers, Christian. -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-radeon_fence_wait_empty_locked.patch Type: text/x-diff Size: 1028 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/8416f7ea/attachment.patch>
[PATCH] drm/radeon: fix radeon_fence_wait_empty_locked
From: Christian K?nig
Don't block forever if there is nothing to wait for.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index b8f68b2..281d14c 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -510,6 +510,9 @@ int radeon_fence_wait_empty_locked(struct radeon_device
*rdev, int ring)
int r;
seq[ring] = rdev->fence_drv[ring].sync_seq[ring];
+ if (!seq[ring])
+ return 0;
+
r = radeon_fence_wait_seq(rdev, seq, false, false);
if (r) {
if (r == -EDEADLK)
--
1.8.1.2
[PATCH 1/5] drm/radeon: rework and fix reset detection v2
2013/11/5 Christian K?nig : > Am 03.11.2013 13:15, schrieb Rafa? Mi?ecki: > >> 2013/10/29 Christian K?nig : >>> >>> From: Christian K?nig >>> >>> Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT. >>> Consolidate the two wait sequence implementations into just one function. >>> Activate all waiters and remember if the reset was already done instead >>> of >>> trying to reset from only one thread. >> >> With this patch I can't suspend my Samsung with: >> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] >> nee ATI Blackcomb [Radeon HD 6900M series] [1002:6720] >> anymore. >> >> The backlight goes off, activity LED goes off and then nothing. >> Machine is still running and other lights (power, wifi, keyboard, >> touchpad) are still working. Seems like a lockup to me. > > > Does the attached patch help? It does, thanks! -- Rafa?
[PATCH] drm/radeon: fix radeon_fence_wait_empty_locked
2013/11/5 Christian K?nig : > From: Christian K?nig > > Don't block forever if there is nothing to wait for. > > Signed-off-by: Christian K?nig Tested-by: Rafa? Mi?ecki -- Rafa?
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #32 from bgunteriv at gmail.com --- can you give us an update on this issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/5238ca29/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #19 from Laurent carlier --- Now Sanctuary works fine with llvm-3.4svn r194070 / mesa-git 86cdff5 @ PITCAIN Brutal Legend / Serious Sam 3 are still problematic -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/19136da2/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #9 from Krzysztof A. Sobiecki --- (In reply to comment #8) > (In reply to comment #5) > > I can confirm setting MESA_GL_VERSION_OVERRIDE=3.2 > > MESA_GLSL_VERSION_OVERRIDE=150 gets the game to start for me > > > When I force only MESA_GLSL_VERSION_OVERRIDE=150 it also works, but I automatically switch to OpenGL 3.2. => but it automatically switches to OpenGL 3.2. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/c9689fdd/attachment-0001.html>
[PATCH 0/8] Add DRIimage-based DRI3/Present loader
Keith Packard writes: > This sequence first adds a a couple of new DRIimage extensions to the > dri/common, dri/i915 and dri/i965 directories which define a > loader-independent API for managing window system operations. > > The last patch adds a new DRI3000 loader using those new interfaces. I've figured out that I can also re-use dri2CreateNewScreen2 for the image driver bits, as long as I change that function to also look up the image loader. That means there are *no* new dri_util functions needed. To recap, the changes needed to support using the DRIimageExtension interfaces for allocating buffers from the driver in the loader are: DRIimageDriverExtension A proper subset of DRIdri2DriverExtension, which uses the same five functions involved in creating new objects: /* Common DRI functions, shared with DRI2 */ __DRIcreateNewScreen2createNewScreen2; __DRIcreateNewDrawable createNewDrawable; __DRIcreateNewContextcreateNewContext; __DRIcreateContextAttribscreateContextAttribs; __DRIgetAPIMask getAPIMask; DRIimageLoaderExtension Contains just two functions, one to allocate buffers and one to copy the fake front to the real front when flushing stuff. /** * Allocate color buffers. * * \param driDrawable * \param width Width of allocated buffers * \param height Height of allocated buffers * \param format one of __DRI_IMAGE_FORMAT_* * \param stamp Address of variable to be updated when * getBuffers must be called again * \param loaderPrivate The loaderPrivate for driDrawable * \param buffer_maskSet of buffers to allocate * \param buffersReturned buffers */ int (*getBuffers)(__DRIdrawable *driDrawable, int *width, int *height, unsigned int format, uint32_t *stamp, void *loaderPrivate, uint32_t buffer_mask, struct __DRIimageList *buffers); /** * Flush pending front-buffer rendering * * Any rendering that has been performed to the * fake front will be flushed to the front * * \param driDrawableDrawable whose front-buffer is to be flushed * \param loaderPrivate Loader's private data that was previously passed * into __DRIdri2ExtensionRec::createNewDrawable */ void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void *loaderPrivate); Each driver will need to have a path to use the image loader to get color buffers using the DRIimageLoaderExtension getBuffers function. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/1166c68b/attachment.pgp>
[PATCH] avivotool: fix dumping HDMI blocks on DCE2, DCE3 and DCE3.2
Signed-off-by: Rafa? Mi?ecki
---
avivotool.c | 30 --
radeon_reg.h |8 +---
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/avivotool.c b/avivotool.c
index 4c5c1ce..f5b3f72 100644
--- a/avivotool.c
+++ b/avivotool.c
@@ -1697,13 +1697,31 @@ void radeon_cmd_regs(const char *type)
SHOW_REG(R600_AUDIO_PIN_WIDGET_CNTL);
SHOW_REG(R600_AUDIO_STATUS_BITS);
- printf("\nHDMI block at 0x%x:\n", R600_HDMI_BLOCK1);
- for (i = R600_HDMI_BLOCK1; i < R600_HDMI_BLOCK1 + 0xf0; i += 4)
- SHOW_UNKNOWN_REG(i);
+ if (IS_DISPLAY_DCE3(card_info)) {
+ printf("\nHDMI block at 0x%x:\n", DCE3_HDMI_BLOCK0);
+ for (i = DCE3_HDMI_BLOCK0; i <= DCE3_HDMI_BLOCK0 + 0xf0; i += 4)
+ SHOW_UNKNOWN_REG(i);
+ if (card_info && card_info->chip_family >= CHIP_FAMILY_RV730) {
+ for (i = DCE3_HDMI_BLOCK0 + 0x200; i <= DCE3_HDMI_BLOCK0 +
0x210; i += 4)
+ SHOW_UNKNOWN_REG(i);
+ }
- printf("\nHDMI block at 0x%x:\n", R600_HDMI_BLOCK3);
- for (i = R600_HDMI_BLOCK3; i < R600_HDMI_BLOCK3 + 0xf0; i += 4)
- SHOW_UNKNOWN_REG(i);
+ printf("\nHDMI block at 0x%x:\n", DCE3_HDMI_BLOCK1);
+ for (i = DCE3_HDMI_BLOCK1; i <= DCE3_HDMI_BLOCK1 + 0xf0; i += 4)
+ SHOW_UNKNOWN_REG(i);
+ if (card_info && card_info->chip_family >= CHIP_FAMILY_RV730) {
+ for (i = DCE3_HDMI_BLOCK1 + 0x200; i <= DCE3_HDMI_BLOCK1 +
0x210; i += 4)
+ SHOW_UNKNOWN_REG(i);
+ }
+ } else {
+ printf("\nHDMI block at 0x%x:\n", DCE2_HDMI_BLOCK0);
+ for (i = DCE2_HDMI_BLOCK0; i <= DCE2_HDMI_BLOCK0 + 0xf0; i += 4)
+ SHOW_UNKNOWN_REG(i);
+
+ printf("\nHDMI block at 0x%x:\n", DCE2_HDMI_BLOCK1);
+ for (i = DCE2_HDMI_BLOCK1; i <= DCE2_HDMI_BLOCK1 + 0xf0; i += 4)
+ SHOW_UNKNOWN_REG(i);
+ }
}
}
diff --git a/radeon_reg.h b/radeon_reg.h
index ea5b6bc..06136e3 100644
--- a/radeon_reg.h
+++ b/radeon_reg.h
@@ -3063,9 +3063,11 @@
#define R600_AUDIO_STATUS_BITS 0x73d8
/* HDMI base register addresses */
-#define R600_HDMI_BLOCK1 0x7400
-#define R600_HDMI_BLOCK2 0x7700
-#define R600_HDMI_BLOCK3 0x7800
+#define DCE2_HDMI_BLOCK0 0x7400
+#define DCE2_HDMI_BLOCK1 0x7700
+/* DCE3 second instance starts at 0x7800 */
+#define DCE3_HDMI_BLOCK0 0x7400
+#define DCE3_HDMI_BLOCK1 0x7800
#define RADEON_MC_ARB_CNTL 0x18c
#define RADEON_PWRMAN_MISC 0x16
--
1.7.10.4
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #28 from Matthew Dawson --- I think this may have been solved with the latest ddx for ati. I was originally using version 7.0 (or earlier) along with the latest mesa (9.2, rc or gold) and glamor (0.5). With KDE I would get frequent slow downs, with X consuming a full CPU core. Using perf, I noticed it spent all of its time in a memcpy, and using gdb I found it was copying memory between textures in glamor. Upgrading to the latest ddx (7.2), all speed issues in KDE (including konsole) mostly disappeared. X no longer uses cpu like it did before. For those still seeing speed problems, what version of the ati ddx are you using? And if you upgrade to 7.2, do your speed problems go away? I'm using Gentoo with an HD7970. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/d39c5b7d/attachment.html>
[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
ffer_rendering || brw->is_front_buffer_reading ||
> !back_rb) && front_rb)
> + buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
> +
> + if (back_rb)
> + buffer_mask |= __DRI_IMAGE_BUFFER_BACK;
> +
> + (*screen->image.loader->getBuffers) (drawable,
> +&drawable->w,
> +&drawable->h,
> +driGLFormatToImageFormat(format),
> +&drawable->dri2.stamp,
> +drawable->loaderPrivate,
> +buffer_mask,
> +&images);
> +
> + if (images.front) {
> + assert(front_rb);
> + intel_update_image_buffer(brw,
> +drawable,
> +front_rb,
> +images.front,
> +__DRI_IMAGE_BUFFER_FRONT);
> + }
> + if (images.back)
> + intel_update_image_buffer(brw,
> +drawable,
> +back_rb,
> +images.back,
> +__DRI_IMAGE_BUFFER_BACK);
> +}
Style nit: we try and put braces around multi-line things like this,
even if they are a single statement.
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h
> b/src/mesa/drivers/dri/i965/brw_context.h
> index bec4d6b..1ecbfb7 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1477,14 +1477,14 @@ void intel_prepare_render(struct brw_context *brw);
> void intel_resolve_for_dri2_flush(struct brw_context *brw,
>__DRIdrawable *drawable);
>
> -bool brwCreateContext(gl_api api,
> - const struct gl_config *mesaVis,
> - __DRIcontext *driContextPriv,
> - unsigned major_version,
> - unsigned minor_version,
> - uint32_t flags,
> - unsigned *error,
> - void *sharedContextPrivate);
> +GLboolean brwCreateContext(gl_api api,
> + const struct gl_config *mesaVis,
> + __DRIcontext *driContextPriv,
> + unsigned major_version,
> + unsigned minor_version,
> + uint32_t flags,
> + unsigned *error,
> + void *sharedContextPrivate);
Unrelated change.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/a1e60928/attachment.pgp>
[PATCH 0/8] Add DRIimage-based DRI3/Present loader
Keith Packard writes: > Keith Packard writes: > >> This sequence first adds a a couple of new DRIimage extensions to the >> dri/common, dri/i915 and dri/i965 directories which define a >> loader-independent API for managing window system operations. >> >> The last patch adds a new DRI3000 loader using those new interfaces. > > I've figured out that I can also re-use dri2CreateNewScreen2 for the > image driver bits, as long as I change that function to also look up the > image loader. That means there are *no* new dri_util functions needed. > > To recap, the changes needed to support using the DRIimageExtension > interfaces for allocating buffers from the driver in the loader are: > > DRIimageDriverExtension > > A proper subset of DRIdri2DriverExtension, which uses > the same five functions involved in creating new objects: > >/* Common DRI functions, shared with DRI2 */ >__DRIcreateNewScreen2createNewScreen2; >__DRIcreateNewDrawable createNewDrawable; >__DRIcreateNewContextcreateNewContext; >__DRIcreateContextAttribscreateContextAttribs; >__DRIgetAPIMask getAPIMask; It seems like we could just stick these things in __DRI_CORE as opposed to having another new extension to look up. The downside I see there is bugs in the server, which have patches at xserver-driinterface-versions of my tree. (Unfortunately, I'm having a hard time building the server currently, so no testing yet). Having a new extension whose name has nothing to do with the functions in it seems really weird. Also, apologies for not having done this myself for my CreateNewScreen2 change. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/94e49172/attachment.pgp>
[Bug 61891] Cannot switch off Radeon 6400M with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=61891 --- Comment #6 from madcatx at atlas.cz --- Created attachment 113521 --> https://bugzilla.kernel.org/attachment.cgi?id=113521&action=edit dmesg from 3.12 final -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 61891] Cannot switch off Radeon 6400M with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=61891 --- Comment #7 from madcatx at atlas.cz --- I just updated to 3.12 final and it is happening again. The problem seemed to be fixed in 3.12-rc2 and I switched back to stable releases then. New dmesg log attached... -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 61891] Cannot switch off Radeon 6400M with vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=61891 --- Comment #8 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #29 from darkbasic --- Raster never had an high cpu usage, the backend which had high cpu usage was native. I use DDX from git and it wasn't fixed a few days ago, maybe the commit which fixed it has been committed in the past few days? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/04281ecd/attachment-0001.html>
[Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader
On Tue, Nov 05, 2013 at 12:04:32PM -0800, Eric Anholt wrote: > Keith Packard writes: > > > Keith Packard writes: > > > >> This sequence first adds a a couple of new DRIimage extensions to the > >> dri/common, dri/i915 and dri/i965 directories which define a > >> loader-independent API for managing window system operations. > >> > >> The last patch adds a new DRI3000 loader using those new interfaces. > > > > I've figured out that I can also re-use dri2CreateNewScreen2 for the > > image driver bits, as long as I change that function to also look up the > > image loader. That means there are *no* new dri_util functions needed. > > > > To recap, the changes needed to support using the DRIimageExtension > > interfaces for allocating buffers from the driver in the loader are: > > > > DRIimageDriverExtension > > > > A proper subset of DRIdri2DriverExtension, which uses > > the same five functions involved in creating new objects: > > > >/* Common DRI functions, shared with DRI2 */ > >__DRIcreateNewScreen2createNewScreen2; > >__DRIcreateNewDrawable createNewDrawable; > >__DRIcreateNewContextcreateNewContext; > >__DRIcreateContextAttribscreateContextAttribs; > >__DRIgetAPIMask getAPIMask; > > It seems like we could just stick these things in __DRI_CORE as opposed > to having another new extension to look up. The downside I see there is > bugs in the server, which have patches at xserver-driinterface-versions > of my tree. (Unfortunately, I'm having a hard time building the server > currently, so no testing yet). Having a new extension whose name has > nothing to do with the functions in it seems really weird. It may make more sense to just extend the existing interfaces, but when we discussed DRIimageDriverExtension, the idea was that we could phase out DRIdri2Extension. I think that still makes sense but introducing more extensions doesn't make this interface better. The way this was done originally was that we have DRIcoreExtension which provided DRI1 support. The DRIdri2Extension extension replaces some of the core functions (it has a createNewScreen that doesn't take a sarea handle, for example...) and allows a loader to implement DRI2, but you have to use both extensions. DRIswrastExtension works in a similar for swrast. The idea was to share the core functionality, but it's obviously messy to have to mix two extensions to get things working. If we're introducing a new extension, I'd suggest we move the functions from DRIcoreExtension that we still use into this new extension and make it completely replace DRIcoreExtension and DRIdri2Extension. The functions from the core extension we still use are: void (*destroyScreen)(__DRIscreen *screen); const __DRIextension **(*getExtensions)(__DRIscreen *screen); int (*getConfigAttrib)(const __DRIconfig *config, unsigned int attrib, unsigned int *value); int (*indexConfigAttrib)(const __DRIconfig *config, int index, unsigned int *attrib, unsigned int *value); void (*destroyDrawable)(__DRIdrawable *drawable); int (*copyContext)(__DRIcontext *dest, __DRIcontext *src, unsigned long mask); void (*destroyContext)(__DRIcontext *context); int (*bindContext)(__DRIcontext *ctx, __DRIdrawable *pdraw, __DRIdrawable *pread); int (*unbindContext)(__DRIcontext *ctx); and if we add those to DRIimageDriverExtension the loader only needs to look for that and the DRIimage extension. Of course, the implementation is already in dri_util.c, we just need to set the function pointers to the DRIcoreExtension functions we share. Kristian
[PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd
On Mon, Nov 04, 2013 at 06:23:23PM -0800, Keith Packard wrote:
> Instead of assuming that the size will be height * pitch, have the caller pass
> in the size explicitly.
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/i915/intel_regions.c | 4 ++--
> src/mesa/drivers/dri/i915/intel_regions.h | 2 +-
> src/mesa/drivers/dri/i915/intel_screen.c | 2 +-
> src/mesa/drivers/dri/i965/intel_regions.c | 4 ++--
> src/mesa/drivers/dri/i965/intel_regions.h | 1 +
> src/mesa/drivers/dri/i965/intel_screen.c | 2 +-
> 6 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.c
> b/src/mesa/drivers/dri/i915/intel_regions.c
> index 44f7030..9f5b89e 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.c
> +++ b/src/mesa/drivers/dri/i915/intel_regions.c
> @@ -209,6 +209,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> + GLuint size,
>int fd, const char *name)
> {
> struct intel_region *region;
> @@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> int ret;
> uint32_t bit_6_swizzle, tiling;
>
> - buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
> - fd, height * pitch);
> + buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);
The 3.12 kernel let's you get the bo size from lseek on the dma_buf
fd. I added libdrm support for getting the size that, and if that
works, it overrides the user provided size:
http://cgit.freedesktop.org/mesa/drm/commit/?id=9c52c3dc4763336884277d8005eac7e6efb77600
3.12 is the first kernel where dma_buf fd passing works reliably
anyway and the first kernel with render-nodes, so it's not worth the
trouble to try to make this work for older kernels.
Regardless, this patchs looks good.
Reviewed-by: Kristian H?gsberg
> if (buffer == NULL)
>return NULL;
> ret = drm_intel_bo_get_tiling(buffer, &tiling, &bit_6_swizzle);
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.h
> b/src/mesa/drivers/dri/i915/intel_regions.h
> index 5c612a9..6bc4a42 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.h
> +++ b/src/mesa/drivers/dri/i915/intel_regions.h
> @@ -91,7 +91,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> - int fd, const char *name);
> + GLuint size, int fd, const char *name);
>
> bool
> intel_region_flink(struct intel_region *region, uint32_t *name);
> diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
> b/src/mesa/drivers/dri/i915/intel_screen.c
> index 3f54752..085e894 100644
> --- a/src/mesa/drivers/dri/i915/intel_screen.c
> +++ b/src/mesa/drivers/dri/i915/intel_screen.c
> @@ -653,7 +653,7 @@ intel_create_image_from_fds(__DRIscreen *screen,
>return NULL;
>
> image->region = intel_region_alloc_for_fd(intelScreen,
> - 1, width, height,
> + 1, width, height, height *
> strides[0],
> strides[0], fds[0], "image");
> if (image->region == NULL) {
>free(image);
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.c
> b/src/mesa/drivers/dri/i965/intel_regions.c
> index a6b80fd..3920f4f 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.c
> +++ b/src/mesa/drivers/dri/i965/intel_regions.c
> @@ -209,6 +209,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pitch,
> + GLuint size,
>int fd, const char *name)
> {
> struct intel_region *region;
> @@ -216,8 +217,7 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> int ret;
> uint32_t bit_6_swizzle, tiling;
>
> - buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr,
> - fd, height * pitch);
> + buffer = drm_intel_bo_gem_create_from_prime(screen->bufmgr, fd, size);
> if (buffer == NULL)
>return NULL;
> ret = drm_intel_bo_get_tiling(buffer, &tiling, &bit_6_swizzle);
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.h
> b/src/mesa/drivers/dri/i965/intel_regions.h
> index f08a113..05dfef3 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.h
> +++ b/src/mesa/drivers/dri/i965/intel_regions.h
> @@ -92,6 +92,7 @@ struct intel_region *
> intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint cpp,
>GLuint width, GLuint height, GLuint pi
[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*
On Mon, Nov 04, 2013 at 06:23:25PM -0800, Keith Packard wrote:
> The __DRI_IMAGE_FORMAT codes are used by the image extension, drivers need to
> be able to translate between them. Instead of duplicating this translation in
> each driver, create a shared version.
I'll take the bait... before the i915/i965 split, this code was only
needed in this one place. All other drivers are gallium drivers which
need to convert to galliums enum pipe_format instead of the gl_format
enum. Anyway, the code certainly looks more at home in dri_util.c.
Reviewed-by: Kristian H?gsberg
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/common/dri_util.c | 62
> ++
> src/mesa/drivers/dri/common/dri_util.h | 6
> 2 files changed, 68 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index 95c8b41..76c8ae5 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -792,3 +792,65 @@ driUpdateFramebufferSize(struct gl_context *ctx, const
> __DRIdrawable *dPriv)
>assert(fb->Height == dPriv->h);
> }
> }
> +
> +uint32_t
> +driGLFormatToImageFormat(gl_format format)
> +{
> + switch (format) {
> + case MESA_FORMAT_RGB565:
> + return __DRI_IMAGE_FORMAT_RGB565;
> + case MESA_FORMAT_XRGB:
> + return __DRI_IMAGE_FORMAT_XRGB;
> + case MESA_FORMAT_ARGB2101010:
> + return __DRI_IMAGE_FORMAT_ARGB2101010;
> + case MESA_FORMAT_XRGB2101010_UNORM:
> + return __DRI_IMAGE_FORMAT_XRGB2101010;
> + case MESA_FORMAT_ARGB:
> + return __DRI_IMAGE_FORMAT_ARGB;
> + case MESA_FORMAT_RGBA_REV:
> + return __DRI_IMAGE_FORMAT_ABGR;
> + case MESA_FORMAT_RGBX_REV:
> + return __DRI_IMAGE_FORMAT_XBGR;
> + case MESA_FORMAT_R8:
> + return __DRI_IMAGE_FORMAT_R8;
> + case MESA_FORMAT_GR88:
> + return __DRI_IMAGE_FORMAT_GR88;
> + case MESA_FORMAT_NONE:
> + return __DRI_IMAGE_FORMAT_NONE;
> + case MESA_FORMAT_SARGB8:
> + return __DRI_IMAGE_FORMAT_SARGB8;
> + default:
> + return 0;
> + }
> +}
> +
> +gl_format
> +driImageFormatToGLFormat(uint32_t image_format)
> +{
> + switch (image_format) {
> + case __DRI_IMAGE_FORMAT_RGB565:
> + return MESA_FORMAT_RGB565;
> + case __DRI_IMAGE_FORMAT_XRGB:
> + return MESA_FORMAT_XRGB;
> + case __DRI_IMAGE_FORMAT_ARGB2101010:
> + return MESA_FORMAT_ARGB2101010;
> + case __DRI_IMAGE_FORMAT_XRGB2101010:
> + return MESA_FORMAT_XRGB2101010_UNORM;
> + case __DRI_IMAGE_FORMAT_ARGB:
> + return MESA_FORMAT_ARGB;
> + case __DRI_IMAGE_FORMAT_ABGR:
> + return MESA_FORMAT_RGBA_REV;
> + case __DRI_IMAGE_FORMAT_XBGR:
> + return MESA_FORMAT_RGBX_REV;
> + case __DRI_IMAGE_FORMAT_R8:
> + return MESA_FORMAT_R8;
> + case __DRI_IMAGE_FORMAT_GR88:
> + return MESA_FORMAT_GR88;
> + case __DRI_IMAGE_FORMAT_SARGB8:
> + return MESA_FORMAT_SARGB8;
> + case __DRI_IMAGE_FORMAT_NONE:
> + return MESA_FORMAT_NONE;
> + default:
> + return MESA_FORMAT_NONE;
> + }
> +}
> diff --git a/src/mesa/drivers/dri/common/dri_util.h
> b/src/mesa/drivers/dri/common/dri_util.h
> index 5b56061..fd40769 100644
> --- a/src/mesa/drivers/dri/common/dri_util.h
> +++ b/src/mesa/drivers/dri/common/dri_util.h
> @@ -271,6 +271,12 @@ struct __DRIdrawableRec {
> } dri2;
> };
>
> +extern uint32_t
> +driGLFormatToImageFormat(gl_format format);
> +
> +extern gl_format
> +driImageFormatToGLFormat(uint32_t image_format);
> +
> extern void
> dri2InvalidateDrawable(__DRIdrawable *drawable);
>
> --
> 1.8.4.2
>
[PATCH 6/8] dri/i915,dri/i965: Use driGLFormatToImageFormat and driImageFormatToGLFormat
On Mon, Nov 04, 2013 at 06:23:26PM -0800, Keith Packard wrote:
> Remove private versions of these functions
Reviewed-by: Kristian H?gsberg
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/i915/intel_screen.c | 53 ++-
> src/mesa/drivers/dri/i965/intel_screen.c | 63
> ++--
> 2 files changed, 8 insertions(+), 108 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
> b/src/mesa/drivers/dri/i915/intel_screen.c
> index 085e894..12113c7 100644
> --- a/src/mesa/drivers/dri/i915/intel_screen.c
> +++ b/src/mesa/drivers/dri/i915/intel_screen.c
> @@ -244,32 +244,8 @@ intel_allocate_image(int dri_format, void *loaderPrivate)
> image->dri_format = dri_format;
> image->offset = 0;
>
> -switch (dri_format) {
> -case __DRI_IMAGE_FORMAT_RGB565:
> - image->format = MESA_FORMAT_RGB565;
> - break;
> -case __DRI_IMAGE_FORMAT_XRGB:
> - image->format = MESA_FORMAT_XRGB;
> - break;
> -case __DRI_IMAGE_FORMAT_ARGB:
> - image->format = MESA_FORMAT_ARGB;
> - break;
> -case __DRI_IMAGE_FORMAT_ABGR:
> - image->format = MESA_FORMAT_RGBA_REV;
> - break;
> -case __DRI_IMAGE_FORMAT_XBGR:
> - image->format = MESA_FORMAT_RGBX_REV;
> - break;
> -case __DRI_IMAGE_FORMAT_R8:
> - image->format = MESA_FORMAT_R8;
> - break;
> -case __DRI_IMAGE_FORMAT_GR88:
> - image->format = MESA_FORMAT_GR88;
> - break;
> -case __DRI_IMAGE_FORMAT_NONE:
> - image->format = MESA_FORMAT_NONE;
> - break;
> -default:
> +image->format = driImageFormatToGLFormat(dri_format);
> +if (image->format == 0) {
> free(image);
> return NULL;
> }
> @@ -318,27 +294,6 @@ intel_setup_image_from_dimensions(__DRIimage *image)
> image->tile_y = 0;
> }
>
> -static inline uint32_t
> -intel_dri_format(GLuint format)
> -{
> - switch (format) {
> - case MESA_FORMAT_RGB565:
> - return __DRI_IMAGE_FORMAT_RGB565;
> - case MESA_FORMAT_XRGB:
> - return __DRI_IMAGE_FORMAT_XRGB;
> - case MESA_FORMAT_ARGB:
> - return __DRI_IMAGE_FORMAT_ARGB;
> - case MESA_FORMAT_RGBA_REV:
> - return __DRI_IMAGE_FORMAT_ABGR;
> - case MESA_FORMAT_R8:
> - return __DRI_IMAGE_FORMAT_R8;
> - case MESA_FORMAT_RG88:
> - return __DRI_IMAGE_FORMAT_GR88;
> - }
> -
> - return MESA_FORMAT_NONE;
> -}
> -
> static __DRIimage *
> intel_create_image_from_name(__DRIscreen *screen,
>int width, int height, int format,
> @@ -396,7 +351,7 @@ intel_create_image_from_renderbuffer(__DRIcontext
> *context,
> image->data = loaderPrivate;
> intel_region_reference(&image->region, irb->mt->region);
> intel_setup_image_from_dimensions(image);
> - image->dri_format = intel_dri_format(image->format);
> + image->dri_format = driGLFormatToImageFormat(image->format);
>
> rb->NeedsFinishRenderTexture = true;
> return image;
> @@ -450,7 +405,7 @@ intel_create_image_from_texture(__DRIcontext *context,
> int target,
> image->format = obj->Image[face][level]->TexFormat;
> image->data = loaderPrivate;
> intel_setup_image_from_mipmap_tree(intel, image, iobj->mt, level,
> zoffset);
> - image->dri_format = intel_dri_format(image->format);
> + image->dri_format = driGLFormatToImageFormat(image->format);
> if (image->dri_format == MESA_FORMAT_NONE) {
>*error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
>free(image);
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index b89b1a5..f9339c1 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -298,38 +298,8 @@ intel_allocate_image(int dri_format, void *loaderPrivate)
> image->dri_format = dri_format;
> image->offset = 0;
>
> -switch (dri_format) {
> -case __DRI_IMAGE_FORMAT_RGB565:
> - image->format = MESA_FORMAT_RGB565;
> - break;
> -case __DRI_IMAGE_FORMAT_XRGB:
> - image->format = MESA_FORMAT_XRGB;
> - break;
> -case __DRI_IMAGE_FORMAT_ARGB2101010:
> - image->format = MESA_FORMAT_ARGB2101010;
> - break;
> -case __DRI_IMAGE_FORMAT_XRGB2101010:
> - image->format = MESA_FORMAT_XRGB2101010_UNORM;
> - break;
> -case __DRI_IMAGE_FORMAT_ARGB:
> - image->format = MESA_FORMAT_ARGB;
> - break;
> -case __DRI_IMAGE_FORMAT_ABGR:
> - image->format = MESA_FORMAT_RGBA_REV;
> - break;
> -case __DRI_IMAGE_FORMAT_XBGR:
> - image->format = MESA_FORMAT_RGBX_REV;
> - break;
> -case __DRI_IMAGE_FORMAT_R8:
> - image->format = MESA_FORMAT_R8;
> - break;
> -case __DRI_IMAGE_FORMAT_GR88:
> - image->format = MESA_FORMAT_GR88;
> - break;
> -case __DRI_IMAGE_FORMAT_NONE:
> - im
[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*
On Mon, Nov 4, 2013 at 8:11 PM, Keith Packard wrote: > Jordan Justen writes: >> After patch 6, this will add SARGB8, right? So, maybe add this to the >> commit message, or separate out adding SARGB8 into a separate commit? > > I added the SARGB8 define in patch 4; is there some other separation you > think would be warranted? I was just noting that a side effect of patch five is adding support for SARGB8. When you remove the code in patch 6, and use these, you've now added support for this new format. Not important, but I thought it might be worth noting in the commit message. Actually probably noting it in the commit message for patch 6 is better since the change happens at that point. -Jordan
[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
On Mon, Nov 04, 2013 at 06:23:27PM -0800, Keith Packard wrote:
> These provide an interface between the driver and the loader to allocate
> color buffers through the DRIimage extension interface rather than through a
> loader-specific extension (as is used by DRI2, for instance).
>
> The driver uses the loader 'getBuffers' interface to allocate color buffers.
>
> The loader uses the createNewScreen2, createNewDrawable, createNewContext,
> getAPIMask and createContextAttribs APIS (mostly shared with DRI2).
>
> This interface will work with the DRI3 loader, and should also work with GBM
> and other loaders so that drivers need not be customized for each new loader
> interface, as long as they provide this image interface.
>
> Signed-off-by: Keith Packard
> ---
> include/GL/internal/dri_interface.h | 112 +
> src/mesa/drivers/dri/common/dri_util.c| 113 +
> src/mesa/drivers/dri/common/dri_util.h| 6 ++
> src/mesa/drivers/dri/i915/intel_context.c | 111 -
> src/mesa/drivers/dri/i915/intel_mipmap_tree.c | 33
> src/mesa/drivers/dri/i915/intel_mipmap_tree.h | 8 ++
> src/mesa/drivers/dri/i915/intel_screen.c | 1 +
> src/mesa/drivers/dri/i965/brw_context.c | 114
> --
> src/mesa/drivers/dri/i965/brw_context.h | 16 ++--
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 61 ++
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 8 ++
> src/mesa/drivers/dri/i965/intel_screen.c | 5 +-
> 12 files changed, 568 insertions(+), 20 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 907aeca..8fc1fa6 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,10 @@ typedef struct __DRIdri2LoaderExtensionRec
> __DRIdri2LoaderExtension;
> typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
> typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>
> +
> +typedef struct __DRIimageLoaderExtensionRec __DRIimageLoaderExtension;
> +typedef struct __DRIimageDriverExtensionRec __DRIimageDriverExtension;
> +
> /*@}*/
>
>
> @@ -1288,4 +1292,112 @@ typedef struct __DRIDriverVtableExtensionRec {
> const struct __DriverAPIRec *vtable;
> } __DRIDriverVtableExtension;
>
> +/**
> + * Image Loader extension. Drivers use this to allocate color buffers
> + */
> +
> +#define __DRI_DRIVER_EXTENSIONS "__driDriverExtensions"
> +
> +enum __DRIimageBufferMask {
> + __DRI_IMAGE_BUFFER_BACK = (1 << 0),
> + __DRI_IMAGE_BUFFER_FRONT = (1 << 1)
> +};
> +
> +struct __DRIimageList {
> + __DRIimage *back;
> + __DRIimage *front;
> +};
> +
> +#define __DRI_IMAGE_LOADER "DRI_IMAGE_LOADER"
> +#define __DRI_IMAGE_LOADER_VERSION 1
> +
> +struct __DRIimageLoaderExtensionRec {
> +__DRIextension base;
> +
> + /**
> +* Allocate color buffers.
> +*
> +* \param driDrawable
> +* \param width Width of allocated buffers
> +* \param height Height of allocated buffers
> +* \param format one of __DRI_IMAGE_FORMAT_*
> +* \param stamp Address of variable to be updated when
> +* getBuffers must be called again
> +* \param loaderPrivate The loaderPrivate for driDrawable
> +* \param buffer_maskSet of buffers to allocate
> +* \param buffersReturned buffers
> +*/
> + int (*getBuffers)(__DRIdrawable *driDrawable,
> + int *width, int *height,
We can drop width and height now and just get it from either of the
returned images. Format is a function of the __DRIconfig and doesn't
change, so we could make that something you can query from the config
in the interest of further reducing the number of arguments.
I'll give this a try with the GBM and Wayland EGL backends now.
Kristian
> + unsigned int format,
> + uint32_t *stamp,
> + void *loaderPrivate,
> + uint32_t buffer_mask,
> + struct __DRIimageList *buffers);
> +
> +/**
> + * Flush pending front-buffer rendering
> + *
> + * Any rendering that has been performed to the
> + * fake front will be flushed to the front
> + *
> + * \param driDrawableDrawable whose front-buffer is to be flushed
> + * \param loaderPrivate Loader's private data that was previously passed
> + * into __DRIdri2ExtensionRec::createNewDrawable
> + */
> +void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void
> *loaderPrivate);
> +};
> +
> +/**
> + * DRI extension.
> + */
> +
> +//struct gl_context;
> +//struct dd_function_table;
> +
> +typedef __DRIscreen *
> +(*__DRIcreateNewScreen2)(int screen, int fd,
> + const __DRIextension **ex
[Bug 71282] New: Cannot authenticate second libva client
https://bugs.freedesktop.org/show_bug.cgi?id=71282 Priority: medium Bug ID: 71282 Assignee: dri-devel at lists.freedesktop.org Summary: Cannot authenticate second libva client Severity: normal Classification: Unclassified OS: Linux (All) Reporter: rekjanov at epiphan.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: General Product: DRI Created attachment 88733 --> https://bugs.freedesktop.org/attachment.cgi?id=88733&action=edit Test program Environment: * ubuntu 12.04.3 LTS with 3.8 kernel * No X11, pure DRM * libva 0.34 * libdrm 2.4.43 * regular user account, no CAP_SYS_ADMIN, but in 'video' group * A simple program, which calls vaInitialize and then sleeps for several seconds. * Intel video hardware (Ivy Bridge) Problem: If another test program instance is started while the first is sleeping, it fails in va_getDriverName. Debugging and source review shows that the first instance is authenticated automatically, because it gets the master. Second instance tries to authenticate using authmagic, but fails because auth magic ioctl is marked as DRM_AUTH - so you need to be already authenticated in order to authenticate! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/f5b1ffac/attachment.html>
[PATCH 8/8] Add DRI3+Present loader
if (error) {
> + free(error);
> + }
No need for NULL-checking free().
Same 2 comments apply to the next 2 functions.
> + return 0;
> + }
> + *major = reply->major_version;
> + *minor = reply->minor_version;
> + free(reply);
> + return 1;
> +}
> +static const __DRIimageLoaderExtension imageLoaderExtension = {
> + {__DRI_IMAGE_LOADER, __DRI_IMAGE_LOADER_VERSION},
> + .getBuffers = dri3_get_buffers,
> + .flushFrontBuffer = dri3_flush_front_buffer,
> +};
> +
> +static void
> +dri3_bind_tex_image(Display * dpy,
> + GLXDrawable drawable,
> + int buffer, const int *attrib_list)
> +{
> + struct glx_context *gc = __glXGetCurrentContext();
> + struct dri3_context *pcp = (struct dri3_context *) gc;
> + __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
> + struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
> + struct dri3_screen *psc;
> +
> + if (pdraw != NULL) {
> + psc = (struct dri3_screen *) base->psc;
> +
> + if (psc->f &&
> + psc->f->base.version >= 3 && psc->f->invalidate)
> + psc->f->invalidate(pdraw->driDrawable);
> +
> + XSync(dpy, false);
> + if (psc->texBuffer->base.version >= 2 &&
> + psc->texBuffer->setTexBuffer2 != NULL) {
> + (*psc->texBuffer->setTexBuffer2) (pcp->driContext,
> +pdraw->base.textureTarget,
> +pdraw->base.textureFormat,
> +pdraw->driDrawable);
> + }
> + else {
> + (*psc->texBuffer->setTexBuffer) (pcp->driContext,
> + pdraw->base.textureTarget,
> + pdraw->driDrawable);
> + }
> + }
> +}
Tab indentation :(
I'd really like to see less loader code duplication. But if you have
to, at least don't support old setTexBuffer when you know the driver's
new enough that it's got DRI3.
> +static void
> +dri3_release_tex_image(Display * dpy, GLXDrawable drawable, int buffer)
> +{
> +#if __DRI_TEX_BUFFER_VERSION >= 3
> + struct glx_context *gc = __glXGetCurrentContext();
> + struct dri3_context *pcp = (struct dri3_context *) gc;
> + __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
> + struct glx_display *dpyPriv = __glXInitialize(dpy);
> + struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
> + struct dri3_display *pdp =
> + (struct dri3_display *) dpyPriv->dri3Display;
> + struct dri3_screen *psc;
> +
> + if (pdraw != NULL) {
> + psc = (struct dri3_screen *) base->psc;
> +
> + if (psc->texBuffer->base.version >= 3 &&
> + psc->texBuffer->releaseTexBuffer != NULL) {
> + (*psc->texBuffer->releaseTexBuffer) (pcp->driContext,
> + pdraw->base.textureTarget,
> + pdraw->driDrawable);
> + }
> + }
> +#endif
Remove the #ifdef. You're in the tree, you know its value.
> +}
> +
> +static const struct glx_context_vtable dri3_context_vtable = {
> + dri3_destroy_context,
> + dri3_bind_context,
> + dri3_unbind_context,
> + dri3_wait_gl,
> + dri3_wait_x,
> + DRI_glXUseXFont,
> + dri3_bind_tex_image,
> + dri3_release_tex_image,
> + NULL, /* get_proc_address */
> +};
> +
> +static void
> +dri3_bind_extensions(struct dri3_screen *psc, struct glx_display * priv,
> + const char *driverName)
> +{
> +// const struct dri3_display *const pdp = (struct dri3_display *)
> priv->dri3Display;
more commented leftovers.
> + const __DRIextension **extensions;
> + unsigned mask;
> + int i;
> +
> + extensions = psc->core->getExtensions(psc->driScreen);
> +
> + __glXEnableDirectExtension(&psc->base, "GLX_SGI_video_sync");
> + __glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control");
> + __glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control");
> + __glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read");
> +
> + /*
> +* GLX_INTEL_swap_event is broken on the server side, where it's
> +* currently unconditionally enabled. This completely breaks
> +* systems running on drivers which don't support that extension.
> +* There's no way to test for its presence on this side, so instead
> +* of disabling it unconditionally, just disable it for drivers
> +* which are known to not support it, or for DDX drivers supporting
> +* only an older (pre-ScheduleSwap) version of DRI2.
> +*
> +* This is a hack which is required until:
> +* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
> +* is merged and updated xserver makes it's way into distros:
> +*/
> +// if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
> +// __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
> +// }
more commented leftovers. Are you dropping swap_event support?
> +
> + mask = psc->image_driver->getAPIMask(psc->driScreen);
> +
> + __glXEnableDirectExtension(&psc->base, "GLX_ARB_create_context");
> + __glXEnableDirectExtension(&psc->base, "GLX_ARB_create_context_profile");
> +
> + if ((mask & (1 << __DRI_API_GLES2)) != 0)
> + __glXEnableDirectExtension(&psc->base,
> + "GLX_EXT_create_context_es2_profile");
> +
> + for (i = 0; extensions[i]; i++) {
> + if ((strcmp(extensions[i]->name, __DRI_TEX_BUFFER) == 0)) {
> + psc->texBuffer = (__DRItexBufferExtension *) extensions[i];
> + __glXEnableDirectExtension(&psc->base, "GLX_EXT_texture_from_pixmap");
> + }
> +
> + if ((strcmp(extensions[i]->name, __DRI2_FLUSH) == 0)) {
> + psc->f = (__DRI2flushExtension *) extensions[i];
> + /* internal driver extension, no GL extension exposed */
> + }
> +
> + if ((strcmp(extensions[i]->name, __DRI2_CONFIG_QUERY) == 0))
> + psc->config = (__DRI2configQueryExtension *) extensions[i];
> +
> + if (((strcmp(extensions[i]->name, __DRI2_THROTTLE) == 0)))
> + psc->throttle = (__DRI2throttleExtension *) extensions[i];
> +
> + if (strcmp(extensions[i]->name, __DRI2_ROBUSTNESS) == 0)
> + __glXEnableDirectExtension(&psc->base,
> +"GLX_ARB_create_context_robustness");
> + }
> +}
> +
This is horribly duplicated with dri2, but that's also horribly
duplicated with EGL's dri3. I really think we need to do a
dri_loader_common between all of them with a bunch of this crap.
> + tmp = getenv("LIBGL_SHOW_FPS");
> + psc->show_fps = tmp && strcmp(tmp, "1") == 0;
Dead code.
> +/*
> + * Allocate, initialize and return a __DRIdisplayPrivate object.
> + * This is called from __glXInitialize() when we are given a new
> + * display pointer.
> + */
> +_X_HIDDEN __GLXDRIdisplay *
> +dri3_create_display(Display * dpy)
> +{
> + struct dri3_display *pdp;
> + int i;
> +
> + pdp = malloc(sizeof *pdp);
> + if (pdp == NULL)
> + return NULL;
> +
> + if (!dri3_query_version(dpy, &pdp->dri3Major, &pdp->dri3Minor))
> + goto no_extension;
> +
> + if (!present_query_version(dpy, &pdp->presentMajor, &pdp->presentMinor))
> + goto no_extension;
> +
> + pdp->base.destroyDisplay = dri3_destroy_display;
> + pdp->base.createScreen = dri3_create_screen;
> +
> + i = 0;
> +
> + pdp->loader_extensions[i++] = &imageLoaderExtension.base;
> +
trailing whitespace
> diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
> new file mode 100644
> index 000..2873919
> --- /dev/null
> +++ b/src/glx/dri3_priv.h
> +
> +struct dri3_buffer {
> + __DRIimage *image;
> + uint32_t pixmap;
> + uint32_t sync_fence;
> + int32_t *shm_fence;
> + GLbooleanbusy;
Can we get some comments on what these 3 fields do? These
synchronization details were a huge part of the dri3 discussions, and I
know you've gone several ways about things in the process of
development, but I see just a single comment about what fences do:
+ /* Mark the buffer as idle */
That's... not enough.
> +struct dri3_drawable
> +{
> + /* For WaitMSC */
> + uint32_t present_msc_request_serial;
> + uint32_t present_msc_event_serial;
> +
whitespace
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/65066d87/attachment-0001.pgp>
[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
Eric Anholt writes: > Most of my review was going to be whining about yet another (broken) > copy of dri2CreateNewScreen2. Sounds like you've fixed that. Yup, figured that out all on my own after I re-read the code -- the only difference was that I need to look for the DRIimageLoader hooks, which I now just do in the shared function. >> + >> +#define __DRI_DRIVER_EXTENSIONS "__driDriverExtensions" > > This looks like rebase fail Removed. >> +//struct gl_context; >> +//struct dd_function_table; > > Looks like development leftovers. Removed. > Maybe append "Func" to the typedefs so they don't look like just another > struct in the declarations? And since they're supposed to be the same > function pointers as in the __DRIswrastExtensionRec and > __DRIdri2ExtensionRec, change them to this typedef, too? I've moved the typedefs, renamed them and stuck that part of the patch in the first patch of the series that renames the functions. > It looks like getBuffers could just be two getBuffer calls, except for > the updating of width and height. Have you looked into doing things > that way at all? Yes, that was the way I started doing it. There are two reasons for doing it in a single call: 1) Pixmaps always need a front buffer, and the driver doesn't know which drawables are pixmaps. 2) Deleting buffers when changing modes. I'd need to add another function to let the driver delete unused buffers. Overall, I liked moving more buffer management logic to the loader and out of the driver, so I followed the DRI2 API here. > Style nit: we try and put braces around multi-line things like this, > even if they are a single statement. Fixed. >> -bool >> +GLboolean >> brwCreateContext(gl_api api, >> const struct gl_config *mesaVis, >> __DRIcontext *driContextPriv, ... >>__DRIdrawable *drawable); >> >> -bool brwCreateContext(gl_api api, >> - const struct gl_config *mesaVis, >> - __DRIcontext *driContextPriv, >> - unsigned major_version, >> - unsigned minor_version, >> - uint32_t flags, >> - unsigned *error, >> - void *sharedContextPrivate); >> +GLboolean brwCreateContext(gl_api api, >> + const struct gl_config *mesaVis, >> + __DRIcontext *driContextPriv, >> + unsigned major_version, >> + unsigned minor_version, >> + uint32_t flags, >> + unsigned *error, >> + void *sharedContextPrivate); ... > > Unrelated change? Pulled out to a separate patch -- the return type for createContext is GLboolean, not bool, and my compiler was whinging. I've pushed these changes, along with a bunch of new comments in dri3_glx.c to my dri3 branch. I can send the new series to the list if that would be helpful. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/b2a07031/attachment.pgp>
[PATCH 0/8] Add DRIimage-based DRI3/Present loader
Eric Anholt writes: > It seems like we could just stick these things in __DRI_CORE as opposed > to having another new extension to look up. Having the driver expose this new extension is how I tell that the driver is going to actually call the __DRIimage-based loader; the alternative to a new extension would be to stick a flag in the __DRI_CORE structure. > The downside I see there is > bugs in the server, which have patches at xserver-driinterface-versions > of my tree. (Unfortunately, I'm having a hard time building the server > currently, so no testing yet). Having a new extension whose name has > nothing to do with the functions in it seems really weird. It defines the interface to a driver which will be using the image loader to allocate color buffers if available. The fact that the image loader and DRI2 loader can both share the same driver interface is a happy coincidence. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/22b7b40b/attachment.pgp>
[PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd
Kristian H?gsberg writes: > The 3.12 kernel let's you get the bo size from lseek on the dma_buf > fd. I added libdrm support for getting the size that, and if that > works, it overrides the user provided size: Yeah, I'm happy just sending the size and not trusting that the kernel will have the new API; back-porting happens... > Regardless, this patchs looks good. > > Reviewed-by: Kristian H?gsberg Thanks! -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/1bfb99a4/attachment.pgp>
[PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*
Kristian H?gsberg writes: > I'll take the bait... before the i915/i965 split, this code was only > needed in this one place. All other drivers are gallium drivers which > need to convert to galliums enum pipe_format instead of the gl_format > enum. Anyway, the code certainly looks more at home in dri_util.c. Yeah, the i915/i965 split wasn't fun to rebase across at all. Oh well, I'm sure it was for the best :-) > Reviewed-by: Kristian H?gsberg Thanks! -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/f66e4529/attachment.pgp>
[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
Kristian H?gsberg writes: > We can drop width and height now and just get it from either of the > returned images. Format is a function of the __DRIconfig and doesn't > change, so we could make that something you can query from the config > in the interest of further reducing the number of arguments. Sure would be nice if there were simpler ways than calling the getAttribs function though; I'm tempted to just leave these params in as every single driver will need those values and passing them back here will make the driver code shorter. > I'll give this a try with the GBM and Wayland EGL backends now. Cool. Having two backends using this same interface would really help out. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131105/ec8095ad/attachment.pgp>
[PATCH 8/8] Add DRI3+Present loader
Eric Anholt writes:
I've pushed a patch responding to these comments to my dri3 branch and
will send that out shortly. I will merge those changes with the original
DRI3+Present loader patch so that there is only one commit when the
review process is complete.
> I think I'm going to be griping about code duplication...
Yeah, I'm really not sure what to do about that. The alternative would
be to refactor the DRI2 backend and then land the DRI3 backend on top of
some shared code, but frankly I'm not that excited about breaking DRI2.
Do you want me to actually go ahead and try to do that?
> Patches need to land in XCB and get released before this can land. I
> don't even see patches on the xcb list yet.
I sent out the patches to the xorg-devel list today after reworking and
cleaning them up. I'd forgotten that there was a separate xcb list.
>> +
>> +#define DRIVER_MAP_DRI3_ONLY
>
> What does this define do?
It is designed to be used in case there are two drivers for a chipset,
one DRI2 one and one DRI3 one. Much like the DRIVER_MAP_GALLIUM_ONLY
flag. It's not currently being used at all, so it should probably just
get removed until necessary.
> '{' on a separate line, please.
Fixed.
> This looks completely like dri2_create_context, except for missing
> rendertype validation and a different calloc size.
Yup. It's cult-n-paste. Note that the license at the top of the file
tries to make it clear that *lots* of the code in this file was copied
[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
On Tue, Nov 5, 2013 at 4:59 PM, Keith Packard wrote: > Kristian H?gsberg writes: > > >> We can drop width and height now and just get it from either of the >> returned images. Format is a function of the __DRIconfig and doesn't >> change, so we could make that something you can query from the config >> in the interest of further reducing the number of arguments. > > Sure would be nice if there were simpler ways than calling the > getAttribs function though; I'm tempted to just leave these params in as > every single driver will need those values and passing them back here > will make the driver code shorter. I would say that it's more important to keep the interfaces between components as simple as possible, even if it incurs a little inconvenience inside the driver. But it's a non-issue, since inside the driver you can just access them as image->width/height. >> I'll give this a try with the GBM and Wayland EGL backends now. > > Cool. Having two backends using this same interface would really help > out. I got this running now and I found a few other things. I'll reply to the patch again. Kristian
[PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
On Mon, Nov 04, 2013 at 06:23:27PM -0800, Keith Packard wrote:
> These provide an interface between the driver and the loader to allocate
> color buffers through the DRIimage extension interface rather than through a
> loader-specific extension (as is used by DRI2, for instance).
>
> The driver uses the loader 'getBuffers' interface to allocate color buffers.
>
> The loader uses the createNewScreen2, createNewDrawable, createNewContext,
> getAPIMask and createContextAttribs APIS (mostly shared with DRI2).
>
> This interface will work with the DRI3 loader, and should also work with GBM
> and other loaders so that drivers need not be customized for each new loader
> interface, as long as they provide this image interface.
>
> Signed-off-by: Keith Packard
> ---
> include/GL/internal/dri_interface.h | 112 +
> src/mesa/drivers/dri/common/dri_util.c| 113 +
> src/mesa/drivers/dri/common/dri_util.h| 6 ++
> src/mesa/drivers/dri/i915/intel_context.c | 111 -
> src/mesa/drivers/dri/i915/intel_mipmap_tree.c | 33
> src/mesa/drivers/dri/i915/intel_mipmap_tree.h | 8 ++
> src/mesa/drivers/dri/i915/intel_screen.c | 1 +
> src/mesa/drivers/dri/i965/brw_context.c | 114
> --
> src/mesa/drivers/dri/i965/brw_context.h | 16 ++--
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 61 ++
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 8 ++
> src/mesa/drivers/dri/i965/intel_screen.c | 5 +-
> 12 files changed, 568 insertions(+), 20 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 907aeca..8fc1fa6 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,10 @@ typedef struct __DRIdri2LoaderExtensionRec
> __DRIdri2LoaderExtension;
> typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
> typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>
> +
> +typedef struct __DRIimageLoaderExtensionRec __DRIimageLoaderExtension;
> +typedef struct __DRIimageDriverExtensionRec __DRIimageDriverExtension;
> +
> /*@}*/
>
>
> @@ -1288,4 +1292,112 @@ typedef struct __DRIDriverVtableExtensionRec {
> const struct __DriverAPIRec *vtable;
> } __DRIDriverVtableExtension;
>
> +/**
> + * Image Loader extension. Drivers use this to allocate color buffers
> + */
> +
> +#define __DRI_DRIVER_EXTENSIONS "__driDriverExtensions"
> +
> +enum __DRIimageBufferMask {
> + __DRI_IMAGE_BUFFER_BACK = (1 << 0),
> + __DRI_IMAGE_BUFFER_FRONT = (1 << 1)
> +};
> +
> +struct __DRIimageList {
> + __DRIimage *back;
> + __DRIimage *front;
> +};
> +
> +#define __DRI_IMAGE_LOADER "DRI_IMAGE_LOADER"
> +#define __DRI_IMAGE_LOADER_VERSION 1
> +
> +struct __DRIimageLoaderExtensionRec {
> +__DRIextension base;
> +
> + /**
> +* Allocate color buffers.
> +*
> +* \param driDrawable
> +* \param width Width of allocated buffers
> +* \param height Height of allocated buffers
> +* \param format one of __DRI_IMAGE_FORMAT_*
> +* \param stamp Address of variable to be updated when
> +* getBuffers must be called again
> +* \param loaderPrivate The loaderPrivate for driDrawable
> +* \param buffer_maskSet of buffers to allocate
> +* \param buffersReturned buffers
> +*/
> + int (*getBuffers)(__DRIdrawable *driDrawable,
> + int *width, int *height,
> + unsigned int format,
> + uint32_t *stamp,
> + void *loaderPrivate,
> + uint32_t buffer_mask,
> + struct __DRIimageList *buffers);
> +
> +/**
> + * Flush pending front-buffer rendering
> + *
> + * Any rendering that has been performed to the
> + * fake front will be flushed to the front
> + *
> + * \param driDrawableDrawable whose front-buffer is to be flushed
> + * \param loaderPrivate Loader's private data that was previously passed
> + * into __DRIdri2ExtensionRec::createNewDrawable
> + */
> +void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void
> *loaderPrivate);
> +};
> +
> +/**
> + * DRI extension.
> + */
> +
> +//struct gl_context;
> +//struct dd_function_table;
> +
> +typedef __DRIscreen *
> +(*__DRIcreateNewScreen2)(int screen, int fd,
> + const __DRIextension **extensions,
> + const __DRIextension **driver_extensions,
> + const __DRIconfig ***driver_configs,
> + void *loaderPrivate);
> +
> +typedef __DRIdrawable *
> +(*__DRIcreateNewDrawable)(__DRIscreen *screen,
> + const __DRIconfig *config,
> +
