> 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 <a...@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 >
_______________________________________________ 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