Re: glamor_init: clamp GLSL to 120 if platform doesn't have instanced arrays

2018-05-15 Thread Dave Airlie 
On 16 May 2018 at 05:51, Lukas F. Hartmann  wrote:
> Hi,
>
> I upgraded Xwayland and the assorted libraries from git masters today,
> and noticed that glamor wouldn't work anymore on i.MX6/etnaviv. The
> error was:
>
> No provider of glVertexAttribDivisor found.  Requires one of:
> Desktop OpenGL 3.3
> OpenGL ES 3.0
> GL extension "GL_ANGLE_instanced_arrays"
> GL extension "GL_ARB_instanced_arrays"
> GL extension "GL_EXT_instanced_arrays"
> GL extension "GL_NV_instanced_arrays"
>
> The problem is that etnaviv offers GLSL 140 on GL 2.1 and glamor
> rendering assumes that glVertexAttribDivisor() is always available on
> GLSL>=130, which is not the case here. Forcing GLSL 120 makes glamor
> work fine again on this platform. After chatting with ajax in
> #xorg-devel, the following solution was proposed.

I'm not sure it's legal to expose GLSL 1.40 on GL 2.1.

Dave.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

glamor_init: clamp GLSL to 120 if platform doesn't have instanced arrays

2018-05-15 Thread Lukas F. Hartmann 
Hi,

I upgraded Xwayland and the assorted libraries from git masters today,
and noticed that glamor wouldn't work anymore on i.MX6/etnaviv. The
error was:

No provider of glVertexAttribDivisor found.  Requires one of:
Desktop OpenGL 3.3
OpenGL ES 3.0
GL extension "GL_ANGLE_instanced_arrays"
GL extension "GL_ARB_instanced_arrays"
GL extension "GL_EXT_instanced_arrays"
GL extension "GL_NV_instanced_arrays"

The problem is that etnaviv offers GLSL 140 on GL 2.1 and glamor
rendering assumes that glVertexAttribDivisor() is always available on
GLSL>=130, which is not the case here. Forcing GLSL 120 makes glamor
work fine again on this platform. After chatting with ajax in
#xorg-devel, the following solution was proposed.

This is my first time of submitting a patch, so please excuse me and
advise if I'm doing it wrong ;)

Cheers
Lukas (mntmn)

---
 glamor/glamor.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/glamor/glamor.c b/glamor/glamor.c
index 86935ed..d984d20 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -563,6 +563,14 @@ glamor_init(ScreenPtr screen, unsigned int flags)
 
 if (!glamor_check_instruction_count(gl_version))
 goto fail;
+
+/* Glamor rendering assumes that platforms with GLSL 130+
+ * have instanced arrays, but this is not always the case.
+ * etnaviv offers GLSL 140 with OpenGL 2.1.
+ */
+if (glamor_priv->glsl_version >= 130 &&
+!epoxy_has_gl_extension("GL_ARB_instanced_arrays"))
+glamor_priv->glsl_version = 120;
 } else {
 if (gl_version < 20) {
 ErrorF("Require Open GLES2.0 or later.\n");
-- 
2.15.1


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Stepping back

2018-05-15 Thread Keith Packard 
Alan Coopersmith  writes:

> While in person discussions can be efficient, I do wonder if limiting
> them to people who can travel to XDC is how we end up burning out the
> same folks over and over.

A good point. With corporate support for desktop computing seeming
fairly limited, I suspect we're going to need some creative ideas on how
to continue development.

> I don't think the world is yet ready to stop using X altogether, but
> it's getting harder and harder for us to keep X alive.

Adam and others have spent the last years reducing the code base. With
xf86-video-modesetting and xf86-input-libinput, we have at least reduced
the amount of work needed to just keep X running on new hardware.

But, there's always the general churn of bug fixes and minor
improvements, and those require management and testing to shepherd them
to a release.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Stepping back

2018-05-15 Thread Sérgio Basto 
On Tue, 2018-05-15 at 12:34 +0200, Michel Dänzer wrote:
> On 2018-05-14 09:50 PM, Adam Jackson wrote:
> > tl;dr: I will not be release manager for 1.21, nor for anything
> > thereafter either, and this time that's probably permanent.
> > 
> > I won't make this too long to read though, it's not complicated. In
> > a
> > technical sense, I don't feel that I've been an effective release
> > manager, evidenced if by nothing else than the wild gap between
> > projected and actual release dates for 1.20. I don't feel capable
> > of
> > being all of individual contributor, reviewer of last resort,
> > arbiter
> > of taste and technical direction, and tree sheriff; I certainly
> > don't
> > feel capable of fulfilling all those roles while working largely in
> > isolation.
> 
> I think you're being too hard on yourself here; you've done a
> tremendous
> job, thank you!

yeah , I also don't have any complain about you work :) 

> 
> > From the project's perspective, I don't think it's healthy for the
> > same
> > roles to continue to be held by the same few people.
> 
> That's certainly true.
> 
> 
> > And, personally, I've been more or less focused on xserver for well
> > over a decade, and I badly need a change of scenery.
> 
> I can relate to that feeling. :)
> 
> 
-- 
Sérgio M. B.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Stepping back

2018-05-15 Thread Adam Jackson 
On Tue, 2018-05-15 at 10:13 +0100, Daniel Stone wrote:

> We've been facing the same question in Wayland. Here's what I wrote up
> about what I think we should do with that:
>   https://lists.freedesktop.org/archives/wayland-devel/2018-May/038100.html
> 
> Personally I think having longer discussions and write-ups in
> bugs/issues would make the development a lot more accessible. The list
> is great and it does serve its purpose, but it throws up a barrier to
> entry: you have to be subscribed to the list and get all the mail, to
> participate in discussion. (And that's before you get to the barrier
> to entry of git-send-email etc.)
> 
> I don't really have enough of a stake to make suggestions for X
> development, but that might at least be a good starting point for
> spreading the load a bit.

I'd very much like to see us move to gitlab as much as we can. If
there's broad consensus around that I can spend some time getting
bugzilla and the wiki migrated, which would be a good opportunity to
rephrase bugs as issues and get some collective wisdom written down.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [ANNOUNCE] xorg-server 1.20.0

2018-05-15 Thread Adam Jackson 
On Tue, 2018-05-15 at 12:51 +0200, Thomas Klausner wrote:

> > Those specific fixes could probably be cherry-picked to the version
> > you're trying to build, but it may be worthwhile to update to git
> > master anyway.
> 
> I'm packaging for NetBSD, and we prefer to package tarballs, not git
> master. Perhaps someone can make a new release? 2.99.917 doesn't even
> compile against server version 1.19...

It's starting to be difficult to buy Intel hardware at retail that
2.99.917 can drive at all, it's been over three years since it was
released. The project looks fairly quiescent these days. I don't know
if Intel has some formal release process they want to use, but I figure
intel-gfx@ would be the place to ask (cc'd).

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [ANNOUNCE] xorg-server 1.20.0

2018-05-15 Thread Thomas Klausner 
On Mon, May 14, 2018 at 02:23:48PM -0400, Adam Jackson wrote:
> On Sat, 2018-05-12 at 07:48 +0200, Thomas Klausner wrote:
> > On Fri, May 11, 2018 at 03:40:18PM -0700, Matt Turner wrote:
> > > On Fri, May 11, 2018 at 2:28 PM, Thomas Klausner  wrote:
> > > > xf86-video-intel-2.99.917:
> > > > 
> > > > checking whether to include DRI1 support... no
> > > > configure: error: DRI1 requested but prerequisites not found
> > > > *** Error code 1
> > > 
> > > You probably just want to start using --disable-dri1 here.
> > 
> > Thanks, that lets me progress to a different error:
> 
> Your intel driver snapshot is a bit dated, I think:

Is there a newer one? I'll gladly update to the latest packaged
version.

> > --- sna_accel.lo ---
> > sna_accel.c:120:0: warning: "FontSetPrivate" redefined
> >  #define FontSetPrivate(font, idx, data) xfont2_font_set_private(font, idx, 
> > data)
> > 
> > In file included from sna_accel.c:40:0:
> > /scratch/x11/xf86-video-intel/work/.buildlink/include/X11/fonts/fontstruct.h:135:0:
> >  note: this is the location of the previous definition
> >  #define FontSetPrivate(pFont,n,ptr) ((n) > (pFont)->maxPrivate ? \
> 
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=4eaab17aec8ea66428087065901324f56df9020e

I already have that patch applied locally, that warning stays.

> > sna_accel.c: In function 'sna_create_gc':
> > sna_accel.c:16762:4: error: 'struct _GC' has no member named 
> > 'pRotatedPixmap'
> >   gc->pRotatedPixmap = 0;
> > ^~
> 
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=2452066b7771f120a1d03d9450c96565cf31de10

That fixes the build problem, thank you.

> Those specific fixes could probably be cherry-picked to the version
> you're trying to build, but it may be worthwhile to update to git
> master anyway.

I'm packaging for NetBSD, and we prefer to package tarballs, not git
master. Perhaps someone can make a new release? 2.99.917 doesn't even
compile against server version 1.19...

Thanks,
 Thomas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Stepping back

2018-05-15 Thread Michel Dänzer 
On 2018-05-15 07:43 AM, Alan Coopersmith wrote:
> On 05/14/18 12:58 PM, Keith Packard wrote:
>> Adam Jackson  writes:
>>
>>> As for what this means for tree management and future release plans,
>>> well, I can't answer that, that's sort of the point. There's a
>>> community discussion that needs to happen there, and my opinions can't 
>>> dominate that if I'm serious about stepping back.
>>
>> We can start discussions now, and I think we should plan on holding a
>> discussion about this during XDC in September.
> 
> While in person discussions can be efficient, I do wonder if limiting
> them to people who can travel to XDC is how we end up burning out the
> same folks over and over.
> 
> I don't have great answers as more of us step back like I did a few
> years back and Adam is doing now, but with few new folks coming into
> our maintainer fold in the past decade, we need to figure out how to
> both get more contributors and how to grow them into maintainers.
> 
> While Wayland is certainly making great strides, I don't think the world
> is yet ready to stop using X altogether, but it's getting harder and
> harder for us to keep X alive.

FWIW, since all major Linux distros are now using Wayland by default, I
do think it's a good time to transition the Xorg DDX to more of a
maintenance mode. Any significant new functionality should be developed
for Wayland first, adding it to Xorg as well should only be considered
second.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Stepping back

2018-05-15 Thread Michel Dänzer 
On 2018-05-14 09:50 PM, Adam Jackson wrote:
> tl;dr: I will not be release manager for 1.21, nor for anything
> thereafter either, and this time that's probably permanent.
> 
> I won't make this too long to read though, it's not complicated. In a
> technical sense, I don't feel that I've been an effective release
> manager, evidenced if by nothing else than the wild gap between
> projected and actual release dates for 1.20. I don't feel capable of
> being all of individual contributor, reviewer of last resort, arbiter
> of taste and technical direction, and tree sheriff; I certainly don't
> feel capable of fulfilling all those roles while working largely in
> isolation.

I think you're being too hard on yourself here; you've done a tremendous
job, thank you!


> From the project's perspective, I don't think it's healthy for the same
> roles to continue to be held by the same few people.

That's certainly true.


> And, personally, I've been more or less focused on xserver for well
> over a decade, and I badly need a change of scenery.

I can relate to that feeling. :)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Stepping back

2018-05-15 Thread Daniel Stone 
Hi,

On 15 May 2018 at 06:43, Alan Coopersmith  wrote:
> On 05/14/18 12:58 PM, Keith Packard wrote:
>> Adam Jackson  writes:
>>> tl;dr: I will not be release manager for 1.21, nor for anything
>>> thereafter either, and this time that's probably permanent.
>>
>> I'd like to thank you for all of the work you have done and with you all
>> the best in your next adventures.
>
> +1

+lots

Really appreciate the effort you made to herd everything into place
and go well out of your way to land everything.

>>> As for what this means for tree management and future release plans,
>>> well, I can't answer that, that's sort of the point. There's a
>>> community discussion that needs to happen there, and my opinions can't
>>> dominate that if I'm serious about stepping back.
>>
>> We can start discussions now, and I think we should plan on holding a
>> discussion about this during XDC in September.
>
> While in person discussions can be efficient, I do wonder if limiting
> them to people who can travel to XDC is how we end up burning out the
> same folks over and over.
>
> I don't have great answers as more of us step back like I did a few
> years back and Adam is doing now, but with few new folks coming into
> our maintainer fold in the past decade, we need to figure out how to
> both get more contributors and how to grow them into maintainers.

We've been facing the same question in Wayland. Here's what I wrote up
about what I think we should do with that:
  https://lists.freedesktop.org/archives/wayland-devel/2018-May/038100.html

Personally I think having longer discussions and write-ups in
bugs/issues would make the development a lot more accessible. The list
is great and it does serve its purpose, but it throws up a barrier to
entry: you have to be subscribed to the list and get all the mail, to
participate in discussion. (And that's before you get to the barrier
to entry of git-send-email etc.)

I don't really have enough of a stake to make suggestions for X
development, but that might at least be a good starting point for
spreading the load a bit.

> While Wayland is certainly making great strides, I don't think the world
> is yet ready to stop using X altogether, but it's getting harder and
> harder for us to keep X alive.

Ah yes, the year of Wayland on the desktop. ;)

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel