Hi,
On 11/27/18 2:38 AM, Re4son wrote:
>
> I have previously compiled this excel sheet with data relevant to this thread:
>
> https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls
>
> Any feedback, correction and addition that could benefit this discussion
> would be
Hello,
On Thu, 29 Nov 2018, Adrian Bunk wrote:
> Qt already supports runtime ES/non-ES in the same library build on
> Windows [2], something like that might also be doable for Linux if
> anyone (Linaro? Canonical?) with a real interest in that would work
> on making it happen.
>
> Some of the
On Wed, Nov 28, 2018 at 12:32:51PM -0800, Steve Langasek wrote:
> I would caution against prematurely optimizing for build-time. Yes,
> building the entire source package twice is a waste of resources, but it's
> probably a drop in the bucket.
My mail concert was not build-time, but our
On Wed, Nov 28, 2018 at 11:46:21PM +0200, Adrian Bunk wrote:
> On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
> >...
> > Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> > stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
> >...
>
On 2018-11-27 21:19 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > prepare dual stack packages that use the symbols file magic from
> > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> >
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> > $ grep-dctrl -n -sSource:Package -FDepends \
> > -e
> > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> >
On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
>...
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
>...
Is there some rationale documented somewhere why this wasn't used in
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> The amount of packages will probably be larger in the current sid,
> but it should not be more than 20 packages.
> Plus there are packages which are using
On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> $ grep-dctrl -n -sSource:Package -FDepends \
> -e
> 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> 5\.[0-9.]*\))(?|$),' \
>
>
Hi Steve and all,
On Tue, Nov 27, 2018 at 03:39:58PM -0800, Steve Langasek wrote:
> It is actually fairly easy to answer this question as well: simply identify
> all the packages in the archive that depend on one of the known dual-stack
> libraries, prepare dual stack packages that use the
Hi Steve!
El miércoles, 28 de noviembre de 2018 04:00:52 -03 Steve Langasek escribió:
[snip]
> > At this point I really feel that, except I am missing something, double
> > building is just not a good idea :-/
>
> Ok, I don't think you've understood then. Perhaps a further example from
> the
Hey
> Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
>
> I think we should aim to provide the best possible experience with the free
> software ecosystem. The experience with proprietary drivers should be the
> second priority, if priority at all.
>
AFAIU by building Qt with GLES
On Tue, Nov 27, 2018 at 10:13:06PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez
> Meyer escribió:
> [snip]
> > > > prepare dual stack packages that use the symbols file magic from
> > > > Ubuntu, rebuild all the
On Wed, Nov 28, 2018 at 7:30 AM Lisandro Damián Nicanor Pérez Meyer wrote:
> Just curious: is there any project alive for the PowerVR SGX530 ?
There used to be a very brief effort around PowerVR devices but it
looks like that has died now. Some of the project site was captured by
archive.org and
El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
[snip]
> > > prepare dual stack packages that use the symbols file magic from
> > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > packages which are libraries and which end
El martes, 27 de noviembre de 2018 21:19:20 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
>
> Meyer wrote:
> [snip]
>
> > > Yes, we are :-)
El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
[snip]
> > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > maintainer). He points me out that those 7
On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg->
> > 2ubuntu4~1
> > And here is the list of all packages that required dual-stack at least as of
> > 2017, when Ubuntu stopped
El martes, 27 de noviembre de 2018 17:19:32 -03 Dmitry Shachnev escribió:
> Hi Rohan!
>
> On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> > [...]
> >
> > I concur here. It was correctly pointed out in another reply that by using
> > OpenGL we're specifically catering to software
El domingo, 25 de noviembre de 2018 21:18:39 -03 Paul Wise escribió:
> On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> > Both Dmitry and I just learned that the RPI has the VC4 driver which
> > enables it to do hardware acceleration for Desktop OpenGL, we must admit
>
Hi Steve!
First of all: thanks for chiming in!
El martes, 27 de noviembre de 2018 19:06:27 -03 Steve Langasek escribió:
> Hi Lisandro,
[snip]
> > This waterfall schema means *multiple* libraries would have to start doing
> > this two-binaries thing, as Ubuntu devs discovered. But remember that
Hi Lisandro,
On Fri, Nov 23, 2018 at 11:05:11PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Andy: explicitly CCing you because I think it answers part of a question you
> did but in another part of the thread.
> El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
Hi Rohan!
On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> [...]
>
> I concur here. It was correctly pointed out in another reply that by using
> OpenGL we're specifically catering to software that doesn't support
> GLES while making performance worse for mature applications that
>
On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> Steve Langasek writes:
> > Long ago I heard rumors of development work on mesa that would allow it to
> > function as a proxy library, so that apps would link against libGL as needed
> > and the GL implementation would use a
Hey
On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog wrote:
>
> Hello Lisandro,
>
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution, but I
> believe you took the wrong decision. Please consider
Hi,
On 2018-11-27 02:46 +, Wookey wrote:
> >
> > Well, that's at very least an interesting data point. So yes, they exist,
> > but
> > they are new and expensive. Can I assume that this means most of our arm64
> > users do not yet get to them?
> Not yet, no although I think you can just
Hi,
On 26/11/18 11:54 pm, Riku Voipio wrote:
> On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
>> were in the week-end). I was aware of the discussion but did not
>> had the time to chime in, yet I was the person who re-opened the bug
>> #881333 in the first place.
>
>> I also
Hi,
On 26/11/18 8:58 pm, Riku Voipio wrote:
> On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
>
>> The real issue here is that *many* arm64 boards currently do not support
>>
On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
wrote:
> So: what's the best outcome for our *current* users? Again, pick only one.
here's a perspective that may not have been considered: how much
influence and effect on purchasing decisions would the choice made
have?
we
On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> >
> > My main desktop is now an arm64 machine with an nvidia PCI graphics
> > card. These are fairly new (and currently expensive), but I have
> > reason to
Steve Langasek writes:
> Long ago I heard rumors of development work on mesa that would allow it to
> function as a proxy library, so that apps would link against libGL as needed
> and the GL implementation would use a hardware-accelerated GLES driver where
> possible, falling back to software
On Mon, Nov 26, 2018 at 12:21:25PM -0500, Alan Corey wrote:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program? Supply both libraries?
Because this requires providing two separate *stacks* of source packages,
one for GL and one for GLES, which from
On Sat, 2018-11-24 at 21:51 +0100, Adam Borowski wrote:
> On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> > On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> > [...]
> > > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > > user-space driver,
Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
compile your program? Supply both libraries? ES gives an enormous
performance boost to little machines that need it, desktop OpenGL is
more pretty pictures.
On 11/26/18, Lisandro Damián Nicanor Pérez Meyer wrote:
> El lunes,
El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?
It's a Qt build-time option. This in an upstream choice, not ours and not up
to us to fix.
> Supply both libraries?
Already answered
Try glxgears and es2gears on few different platforms. On a Pi 3b
glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
screen HD video while the CPU idles (on a Pi). The GPU is more
capable than the CPU. You
El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> Hello Lisandro,
>
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution,
Our (team-wide) pleasure. This is something we have been
Hello Ian,
On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell wrote:
>
> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> > The hardware that supports GLES also supports OpenGL because GLES is
> > a subset of OpenGL.
>
> I'm confused by this inference. If GLES is a subset of OpenGL then
>
On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
> were in the week-end). I was aware of the discussion but did not
> had the time to chime in, yet I was the person who re-opened the bug
> #881333 in the first place.
> I also invited someone else who is working on a concrete
On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> The hardware that supports GLES also supports OpenGL because GLES is
> a subset of OpenGL.
I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that
Quoting Raphael Hertzog (2018-11-26 12:37:57)
> Software can be fixed/improved to also work with OpenGL ES. However
> hardware, once bought, cannot be fixed to support Desktop OpenGL when
> it has been designed for OpenGL ES only.
Is some _hardware_ really "designed for OpenGL ES only"?
I
Hello Lisandro,
TLDR: thank you for starting this discussion, it was required as it's not
an easy decision to take as there is no realistic perfect solution, but I
believe you took the wrong decision. Please consider deferring the
decision to the technical committe by seeking his advice (point
Hi!
On Mon, Nov 26, 2018 at 11:40 AM Raphael Hertzog wrote:
> >
> > What applications does Debian have in its repo that only support GLES?
>
> Wrong question. Maybe it makes sense for you at the application level for
> the application that are hooking into OpenGL directly. But we are speaking
>
Hello,
On Sat, 24 Nov 2018, bret curtis wrote:
> Moving Qt back to using Desktop GL from GLES is going to have zero
> impact performance on the RPi since the VC4 supports up to OpenGL 2.1
> and and GLES 2.0 [1]
That's a different claim to what you made in a former message.
> The problem is that
> On Sat, 24 Nov 2018, bret curtis wrote:
> > This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> > hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> > shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> > if you plan on having hardware
On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I can put Radeon or
Hi,
On Fri, 23 Nov 2018, Dmitry Shachnev wrote:
> According to config_help.txt [1], Qt uses ES2 by default on Windows.
Interesting.
> But as Lisandro says, such a change in Debian will break many packages
> (which are currently broken on ARM only), so we are definitely not
> considering it at
Hello Bret,
On Sat, 24 Nov 2018, bret curtis wrote:
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having
On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> Both Dmitry and I just learned that the RPI has the VC4 driver which enables
> it to do hardware acceleration for Desktop OpenGL, we must admit that this is
> a game changer in many ways, even if we are talking on just
On Sun, Nov 25, 2018 at 06:28:45AM +0100, Tollef Fog Heen wrote:
> ]] Adam Borowski
>
> > Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both
> > glxgears and es2gears_x11 work fine. I don't think anyone is going to run a
> > modern desktop environment on a machine older than
Hi everyone!
We the Qt maintainers have reached a decision with respect to this topic. We
reached debian-devel in order to get an idea of what other fellow Debian users
and developers think of this subject. We would *really* like to thank you all
for chiming in and discussing this in quite a
]] Adam Borowski
> Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both
> glxgears and es2gears_x11 work fine. I don't think anyone is going to run a
> modern desktop environment on a machine older than that.
>
> But that's an Intel card -- with nVidia, stuff 3 years old gets
Hey Scott,
On Sat, Nov 24, 2018 at 9:01 PM Scott Kitterman wrote:
>
> On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
>
> We have a Rasberry Pi working as a desktop here at my house. It's quite
> usable as long as you only try to do a few things at a time, but it's not by
> any
On Sat, Nov 24, 2018 at 09:51:49PM +0100, Adam Borowski wrote:
> On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> > On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> > > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > > user-space driver, which
On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> [...]
> > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > user-space driver, which is an open source stack if you don't count the
> > GPU
On 2018-11-24, Adrian Bunk wrote:
> libqt5gui5 has > 1k rdeps
I think this is a fact that many people haven't grasped.
And some of those are libraries...
/Sune
On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
> > > There are more than 5 million Raspberry Pis were sold as of February
> > > 2015.
> > > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > > enabled!
> > >
> > > I'm of the opinion that the switch away from
> >
> > There are more than 5 million Raspberry Pis were sold as of February 2015.
> > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > enabled!
> >
> > I'm of the opinion that the switch away from Desktop OpenGL to GLES was a
> > huge mistake and should be reversed as soon
On Sat, Nov 24, 2018 at 02:40:37PM +0100, Matthias Klose wrote:
> On 24.11.18 11:26, Andy Simpkins wrote:
> >> So, again: which of the two flavors is the one that benefits more of our
> >> user
> >> base?
> >
> > BOTH are possible so why dictate only one?
> >
> > I would like to see OpenGLES
On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
[...]
> Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> user-space driver, which is an open source stack if you don't count the
> GPU firmware. It should be comparable to the situation on Intel integrated
> GPUs
Would packaging Regal solve any of this?
https://github.com/p3/regal
It claims to implement OpenGL on top of OpenGL ES, but I don't know if
it is complete enough or efficient enough to be useful in this context.
Dmitry Shachnev wrote:
We do not have a final list yet, but packages that may
Lisandro Damián Nicanor Pérez Meyer wrote:
El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
I have an embedded Intel card right now :)
Same here, 10 years old machine with an embedded Intel video card. I don't
think I can expect it to work with GLES.
Wikipedia says
On 2018-11-24 at 10:21, Simon McVittie wrote:
> On Sat, 24 Nov 2018 at 15:10:47 +0100, Adam Borowski wrote:
>
>> I don't have access to any non-embedded Intel cards
>
> Do those exist? I thought Intel only made GPUs that are integrated
> into their CPUs (the "HD Graphics" series). Presumably
On Sat, 24 Nov 2018 at 15:10:47 +0100, Adam Borowski wrote:
> I don't have access to any non-embedded Intel cards
Do those exist? I thought Intel only made GPUs that are integrated into
their CPUs (the "HD Graphics" series). Presumably that's what you meant
when you said embedded?
As far as I
El sábado, 24 de noviembre de 2018 10:40:37 -03 Matthias Klose escribió:
> On 24.11.18 11:26, Andy Simpkins wrote:
> >> So, again: which of the two flavors is the one that benefits more of our
> >> user base?
> >
> > BOTH are possible so why dictate only one?
> >
> > I would like to see OpenGLES
El sábado, 24 de noviembre de 2018 11:23:51 -03 bret curtis escribió:
> Hello Lisandro!
>
> > Yes, that's a drawback we are not hiding. Applications needing Desktop
> > OpenGL would be left out. But...
>
> Sorry, but this is just not acceptable. There has to be another way.
>
> > > If you say
On 24/11/18 14:14, bret curtis wrote:
>>> But even here in this place I have seen *a lot* of "cheap" arm64 boards.
>>> Yes,
>>> the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
>>> precisely not the fastest thing around.
>>
>> "I have a Raspberry Pi (or similar mobile
Hi Andy!
El sábado, 24 de noviembre de 2018 07:26:34 -03 Andy Simpkins escribió:
> On 24/11/2018 02:05, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Andy: explicitly CCing you because I think it answers part of a question
> > you did but in another part of the thread.
> >
> > El viernes, 23 de
Hello Lisandro!
> Yes, that's a drawback we are not hiding. Applications needing Desktop OpenGL
> would be left out. But...
>
Sorry, but this is just not acceptable. There has to be another way.
>
> > If you say that arm64 has to be GLESv2 as well, then that is yet another
> > arch that OpenMW
> > But even here in this place I have seen *a lot* of "cheap" arm64 boards.
> > Yes,
> > the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
> > precisely not the fastest thing around.
>
> "I have a Raspberry Pi (or similar mobile class system that
> has migrated / is
On Sat, Nov 24, 2018 at 01:09:35PM +, Simon McVittie wrote:
> On Fri, 23 Nov 2018 at 23:12:19 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> > > I have an embedded Intel card right now :)
> >
> > Same here,
On 24.11.18 11:26, Andy Simpkins wrote:
>> So, again: which of the two flavors is the one that benefits more of our user
>> base?
>
> BOTH are possible so why dictate only one?
>
> I would like to see OpenGLES available on all architectures
>
> I would like to see OpenGL available on all
On Fri, 23 Nov 2018 at 23:12:19 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> > I have an embedded Intel card right now :)
>
> Same here, 10 years old machine with an embedded Intel video card. I don't
> think I
On 24/11/2018 02:05, Lisandro Damián Nicanor Pérez Meyer wrote:
Andy: explicitly CCing you because I think it answers part of a question you
did but in another part of the thread.
El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
On Fri, Nov 23, 2018 at 03:27:57AM
Hi Bret!
El viernes, 23 de noviembre de 2018 11:14:34 -03 psi...@gmail.com escribió:
> Just chiming in here as package maintainer of an effected package, OpenMW
> and also an upstream developer of said software, along with contributor to
> OpenSceneGraph.
>
> Here are some related open bugs
El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> > W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > > I would still like to know if the upcoming arm64 desktop devices have
> > > any problems
Hi Wookey!
El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> > Hello,
> >
> > > - Qt is tied to either Desktop or GLES: yes
> > >
> > > So we need to pick one. The question is then which one will benefit our
> > >
Andy: explicitly CCing you because I think it answers part of a question you
did but in another part of the thread.
El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
> On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
[snip]
> >Can you build two
On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> > - Qt is tied to either Desktop or GLES: yes
> >
> > So we need to pick one. The question is then which one will benefit our
> > users
> > most.
> >
> > So far I personally know 0 people with an arm64 board with PCI slots,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Just chiming in here as package maintainer of an effected package, OpenMW
and also an upstream developer of said software, along with contributor to
OpenSceneGraph.
Here are some related open bugs involving Qt and GLESv2 and arm*:
On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > I would still like to know if the upcoming arm64 desktop devices have
> > any problems working with OpenGL ES.
>
> Arm64 desktop systems use Radeon or NVidia cards with same
On Fri, Nov 23, 2018 at 12:25:51PM +0100, Julien Cristau wrote:
> > According to config_help.txt [1], Qt uses ES2 by default on Windows.
> > It probably means that it will work fine with most desktop video cards.
> >
> > But as Lisandro says, such a change in Debian will break many packages
> >
W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> I would still like to know if the upcoming arm64 desktop devices have
> any problems working with OpenGL ES.
Arm64 desktop systems use Radeon or NVidia cards with same opensource
drivers as x86-64 systems. So you can check how it goes with
On Fri, Nov 23, 2018 at 09:34:44AM +, Andy Simpkins wrote:
> I do understand that there would be a lot of effort required to support OGL
> and OGLES but as you have already pointed out "you are doing this already"
> because OGL is provided for all platforms except armel & armhf which have
>
On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote:
> I think a better question would be: Does it improve, or disable, decent
> video support for the dozens of arm64 cards in the r-pi format, such as
> the arm64 based $44 rock64? [...]
As far as I know Raspberry Pi 3 and similar devices
On 11/23/18 12:18 PM, Dmitry Shachnev wrote:
> On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
>> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
>> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
>> architectures, to stop the special-casing
On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
> architectures, to stop the special-casing madness, instead of making it
> spread? :)
According
Quoting John Paul Adrian Glaubitz :
Granted, I don’t really know what the real world distribution of
embedded and desktop/server/laptop devices of arm64 is. But I could
imagine that there will be more arm64 devices in the future which
are desktops, servers or laptops.
There is e.g. this
On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
>Hello,
>пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
>:
>>
>> Hi! Please let me reply first to your last part:
>>
>> > Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
>> >
On 23/11/2018 00:17, Lisandro Damián Nicanor Pérez Meyer wrote:
Hi! Please let me reply first to your last part:
Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
exclusive from an install POV, but give the end user the choice which to
install? Why should we have one
Hello,
пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
:
>
> Hi! Please let me reply first to your last part:
>
> > Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
> > exclusive from an install POV, but give the end user the choice which to
> > install?
Hi! Please let me reply first to your last part:
> Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
> exclusive from an install POV, but give the end user the choice which to
> install? Why should we have one Architecture forced down a path
> different to another
On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
>> Hi all!
>>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
>> ES support. At the moment we are building it with OpenGL ES on
El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> Hi all!
>
> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
> ES support. At the moment we are building it with OpenGL ES on armel and
> armhf, and with desktop OpenGL on all other
El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau escribió:
> On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL ES support. At the moment we are
El jueves, 22 de noviembre de 2018 18:51:20 -03 John Paul Adrian Glaubitz
escribió:
> > On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz
> > wrote:>
> > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL ES
El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> > The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
> > ES support. At the moment we are building it with OpenGL ES on armel and
> > armhf,
On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with desktop OpenGL on all
> On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz
> wrote:
>
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with
W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
> support. At the moment we are building it with OpenGL ES on armel and armhf,
> and with desktop OpenGL on all other architectures.
>
> However we have received a
1 - 100 of 101 matches
Mail list logo