[PATCH xserver 0/7] --disable-iglx

[Guilherme Melo]

> I don't intend to delete the IGLX code. My primary motivation for this
> series is to more clearly define the boundary between the code that
> enables direct contexts and the indirect renderer

Right then, it would be nice to have a clearer separation.

> If that need is because the customers of this app need it to work on
RHEL5, then by
> using indirect GLX to the host you're not actually testing that it
> works with a RHEL5 X stack.

Yes, that is our case. We are aware that it is not a complete RHEL5 test
(different linux kernel, X server, graphics drivers), but OpenGL is only a
small
part of these tests. And using a chroot we can have a uniform development
environment regardless of the host distribution or if it is a physical or
virtual machine.
So it still worth for us using IGLX, even though it does not really mimics
a real RHEL5

Anyway my concern was more about IGLX being completed removed in the near
future.
If that is not the case I would be glad to continue contributing patches to
fix the issues
we found.


Guilherme

On Mon, Apr 4, 2016 at 3:33 PM Adam Jackson <ajax at nwnk.net> wrote:

> On Fri, 2016-04-01 at 17:53 +0000, Guilherme Melo wrote:
> > Hi Adam,
> >
> > So it seems that the direction that is being taken is to eventually
> > drop indirect GLX.
> > In my company we make heavy usage of indirect contexts for running
> > GUI application tests.
> >
> > The reason why we use IGLX is that we run inside a CentOS/RedHat5
> > chroot. We need to support this distro but don't want to have it as
> > the host because it is too painful to work with it.
> >
> > With that setup I found two bugs with IGLX. One fix I submitted on ht
> > tps://patchwork.freedesktop.org/patch/78162/ and the other I did not
> > tested enough but can be found at https://github.com/gqmelo/xserver-
> > xorg/tree/gqmelo-1.17.2-custom
> >
> > So if this is really the direction that it is being taken, this
> > feature will be probably be much harder to use in the future. Then
> > would you have any other suggestion how to to run OpenGL applications
> > inside an old chroot?
> >
> > Also, is it worth that I continue submitting these patches?
>
> Yes, it is worthwhile. I'll take a look at integrating your patches,
> thanks for the reminder.
>
> I don't intend to delete the IGLX code. My primary motivation for this
> series is to more clearly define the boundary between the code that
> enables direct contexts and the indirect renderer, and the reason I
> want that is, ideally, to wire up glamor as the GLX provider and
> (potentially) be independent of Mesa internals.
>
> I'm a little confused about your question about RHEL5 chroots though,
> particularly the "need to support this distro" part. If that need is
> because the customers of this app need it to work on RHEL5, then by
> using indirect GLX to the host you're not actually testing that it
> works with a RHEL5 X stack. If that need is because you are the
> customer of the app and it's only certified on RHEL5, my instinct would
> be to ignore the certification, install it on a RHEL6 or RHEL7 host,
> resolve any functionality issues that happen to arise [1]. Which should
> be few, to the extent that it's an X11 app and not sensitive to, say,
> the init system in use.
>
> [1] - And maybe ask my vendor to certify on an OS that's less than nine
> years old.
>
> - ajax
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160404/e725a2a5/attachment.html>