All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Packard <keithp@keithp.com>
To: Eric Anholt <eric@anholt.net>, mesa3d-dev@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension
Date: Tue, 05 Nov 2013 15:47:02 -0800	[thread overview]
Message-ID: <86ppqe5s3t.fsf@miki.keithp.com> (raw)
In-Reply-To: <87zjpifwc3.fsf@eliezer.anholt.net>


[-- Attachment #1.1: Type: text/plain, Size: 3123 bytes --]

Eric Anholt <eric@anholt.net> 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@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

  reply	other threads:[~2013-11-05 23:47 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05  2:23 [PATCH 0/8] Add DRIimage-based DRI3/Present loader Keith Packard
2013-11-05  2:23 ` [PATCH 1/8] drivers/dri/common: A few dri2 functions are not actually DRI2 specific Keith Packard
2013-11-05  2:23 ` [PATCH 2/8] dri/intel: Split out DRI2 buffer update code to separate function Keith Packard
2013-11-05  2:23 ` [PATCH 3/8] dri/intel: Add explicit size parameter to intel_region_alloc_for_fd Keith Packard
2013-11-05 22:23   ` Kristian Høgsberg
2013-11-06  0:52     ` Keith Packard
2013-11-07  5:17     ` Christopher James Halse Rogers
2013-11-07  5:42       ` Keith Packard
2013-11-05  2:23 ` [PATCH 4/8] Define __DRI_IMAGE_FORMAT_SARGB8 Keith Packard
2013-11-05  2:23 ` [PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_* Keith Packard
2013-11-05  3:01   ` Jordan Justen
2013-11-05  4:11     ` Keith Packard
2013-11-05 22:53       ` Jordan Justen
2013-11-05 22:35   ` Kristian Høgsberg
2013-11-06  0:54     ` Keith Packard
2013-11-05  2:23 ` [PATCH 6/8] dri/i915, dri/i965: Use driGLFormatToImageFormat and driImageFormatToGLFormat Keith Packard
2013-11-05 22:37   ` [PATCH 6/8] dri/i915,dri/i965: " Kristian Høgsberg
2013-11-05  2:23 ` [PATCH 7/8] dri: add __DRIimageLoaderExtension and __DRIimageDriverExtension Keith Packard
2013-11-05 20:05   ` Eric Anholt
2013-11-05 23:47     ` Keith Packard [this message]
2013-11-05 22:59   ` Kristian Høgsberg
2013-11-06  0:59     ` Keith Packard
2013-11-06  2:48       ` Kristian Høgsberg
2013-11-06  6:25   ` Kristian Høgsberg
2013-11-06 14:55     ` Keith Packard
2013-11-06 16:17       ` Kristian Høgsberg
2013-11-06 18:09         ` Keith Packard
2013-11-06 19:06           ` Kristian Høgsberg
2013-11-06 19:29             ` Keith Packard
2013-11-05  2:23 ` [PATCH 8/8] Add DRI3+Present loader Keith Packard
2013-11-05 23:10   ` Eric Anholt
2013-11-06  2:32     ` Keith Packard
2013-11-05 16:40 ` [PATCH 0/8] Add DRIimage-based DRI3/Present loader Keith Packard
2013-11-05 20:04   ` Eric Anholt
2013-11-05 22:09     ` Kristian Høgsberg
2013-11-05 23:54     ` Keith Packard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ppqe5s3t.fsf@miki.keithp.com \
    --to=keithp@keithp.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=mesa3d-dev@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.