Bug#1068206: ITP: jolt -- A multi core friendly rigid body physics and collision detection library, written in C++, suitable for games and VR applications.
Package: wnpp Severity: wishlist Owner: Bret Curtis X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jolt Version : 4.0.2 Upstream Contact: Jorrit Rouwe * URL : https://github.com/jrouwe/JoltPhysics * License : MIT Programming Lang: C++ Description : A multi core friendly rigid body physics and collision detection library, written in C++, suitable for games and VR applications. A multi core friendly rigid body physics and collision detection library suitable for games and VR applications, used by Horizon Forbidden West. Extra Info: This is already in use by several other project, of which is OpenMW which will eventually require this physics library.
Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library
Package: wnpp Severity: wishlist Owner: Bret Curtis X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : VulkanSceneGraph Version : 0.1.10 Upstream Author : Robert Osfield * URL : https://github.com/vsg-dev/VulkanSceneGraph * License : MIT/X Programming Lang: C++ Description : VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library built upon Vulkan graphics/compute API. The project aims to bring the performance of Vulkan to the wider developer community by providing a modern, high quality software library that is easy to use and focused on making the development of high performance graphics and compute applications a productive and fun experience. Sharing the same lead author as the OpenSceneGraph, all the lessons about software quality, performance and the needs of application developers are applied to VulkanSceneGraph to provide a distillation of what a next gen scene graph needs to be. Extra Info: - VSG will be used by OpenMW as it is a replacement for the current OSG library. - osgEarth will probably transition to vsgEarth as well. - Co-maintainers from OSG welcome. - I would maintain it and hopefully members of the games-team as well. - Sponsors always welcome.
Re: tracking OpenGL support for specific boards
> > Many of those chipsets you list, as I understand, have a mesa driver > > for them that support opengl and gles. > > Such as freedreno which supports A4XX series. https://mesamatrix.net/ > > > > Keep in mind, only the proprietary drivers seem to not support opengl > > while the hardware is perfectly capable of doing so. > > Not necessarily. > If the manufacturer specifies OpenGL ES support, then - on the hardware > level - it is a GLES renderer and may or may not support the entire > OpenGL specification natively. It usually requires considerable work to > make GLES hardware support OpenGL. > Eric Anhold can tell you all about the hard work he has put into > bastardising his VC4 mesa driver to make up for the lack of hardware > support: > When Eric jumped from Intel to Broadcom, I was there at the beginning of his VC4 work doing testing and getting OpenMW running on the RPi. One of our conversations revolved around why only GLES support and not full GL support in the binary blob and his answer was that VC4 can do both but only to a point, it depends entirely on what the hardware is capable of. VC4 is fully capable of OpenGL 2.1 but with a few more extensions that were GLES 2.0 specific. No bastardisation. His biggest hurdle (still?) is dealing with the fact that the VC4 has no memory space protection because there is no MMU. He has to use a CMA which is _very_ slow and has had to put in a ton of work to get that working. [1] That has nothing to do with what the GPU was capable of in terms of GL/GLES. You can't have GLES 2.0 without first having GLES 1.1 which is backwards compatible with OpenGL 1.5 in hardware. That is why I stated that it is the driver developer that makes the decision as to what is exposed which is a cost/price decision of the company pushing the hardware. If they only have to target GLES then why expose GL? Less time to market and less money spent in development? Take for example the S3TC opengl extension: EXT_texture_compression_s3tc This is not supported in hardware which is the reason, even after the patent was expired, that Eric (or anyone) could not implement it. Broadcom simply didn't bother (cost cutting?). So if you ever have texture that loads in with a S3TC, all you'll see is pink (or whatever is used as alpha). There is no, if extension doesn't exist, we'll just emulate it in software in VC4. I would be seriously flabbergasted if there was a chipset out there that supported GLES2, that on hardware, wasn't capable of at least OpenGL 1.5. I'm talking about on hardware, not a proprietary binary blog that only exposes GLES. > https://github.com/anholt/mesa/wiki/VC4-OpenGL-support > I know, I've posted this several time in previous Qt related threads. :) Cheers, Bret [1] https://dri.freedesktop.org/docs/drm/gpu/vc4.html
Re: tracking OpenGL support for specific boards
On Tue, Nov 27, 2018 at 3:58 PM Stefan Monnier wrote: > > >> What would help further would be for such information having references > >> to sources, and each information point be referencable (not only the > >> dataset as a whole). > > Isn't this already done for us here? > > https://gpuinfo.org/ > > I don't see any reference to sources. > Also I see it as "Ubuntu" and "Arch" as OSes, whereas I'd rather see the > status of the underlying driver so I can easily extrapolate from it to > what will happen in any particular GNU/Linux distribution. > > The database describes itself as "an online tool for developers that > want to check out GPU hardware capabilites", so it seems to be focused > on hardware, whereas I think we need something that focuses on > the drivers. Have you looked at https://mesamatrix.net/ ? That is a list of drivers, not exhaustive because VC4 and other's are not currently tracked. However Freedreno that supports all Adreno A4XX hardware does have a debian package for armel and armhf. Is that perhaps something to look into? Here is the wikipedia page for Adreno and it lists the opengl support per chipset: https://en.wikipedia.org/wiki/Adreno ^-- it's fairly complete and says that they too fall under Freedreno Then there is this for Mali400/450: https://gitlab.freedesktop.org/lima/mesa Cheers, Bret
Re: tracking OpenGL support for specific boards
> > https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls > > > > Any feedback, correction and addition that could benefit this discussion > > would be appreciated. > > Great that you collected that dataset, and put it public. > > What would help further would be for such information having references > to sources, and each information point be referencable (not only the > dataset as a whole). > Isn't this already done for us here? https://gpuinfo.org/ If anything, it should be used to fill in that list. Many of those chipsets you list, as I understand, have a mesa driver for them that support opengl and gles. Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/ Keep in mind, only the proprietary drivers seem to not support opengl while the hardware is perfectly capable of doing so. Cheers, Bret
Re: Upcoming Qt switch to OpenGL ES on arm64
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 > surely hardware which claims to implement GLES is at liberty to only > implement that subset and would therefore not necessarily support > OpenGL. > > Ian. > I believe this is a purely a driver/firmware distinction. So whoever implements this is at liberty to do whatever they want so long as the hardware supports it. Meaning that if something advertises GLESv2 support then it has, at least, OpenGL 2.0 support in hardware because without that, they couldn't have supported GLESv1. GLES1.1 is fixed-function pipeline that is compatible with OpenGL 2.0, you're not going to create hardware to support GLES1.1 that doesn't also support at least OpenGL 2.0 GLESv2 is another beast, it dropped fixed-function pipeline because that was the spec, but it is still a software implementation and doesn't mean that it no longer exists in hardware. Take for example the Nvidia Tegra: https://opengles.gpuinfo.org/displayreport.php?id=690 <-- SHIELD Android TV which happens to be a Tegra SoC supports OpenGL ES 3.2 https://opengl.gpuinfo.org/displayreport.php?id=2377 <-- Tegra as integrated with CPU (nvgpu), supports OpenGL 4.6.0 Similar (if not the same?) hardware, running aarch64, the only real difference is the driver. That being said, I would love to hear from someone who actually makes these things to comment. It is entirely possible that there is a chip out there that supports GLES 3.2 and only that in hardware. I would be amazed but I'm reluctant to ever use the words never and ever. So far, the hardware that supports that are[1]: Adreno 420 and newer AMD GCN-architecture Intel HD Graphics Skylake and higher Mali-T760 and newer Nvidia GeForce 400 series (Fermi) As I said, I would be amazed if these GPUs didn't support some minimal version OpenGL in hardware. As I said elsewhere, most free and open-source drivers (mesa) support both some version of GLES along with some version of GL. [2] Cheers, Bret [1] https://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_3.2_2 [2] https://mesamatrix.net/
Re: Upcoming Qt switch to OpenGL ES on arm64
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 > of having decent graphical performances for all Qt based-applications on > hardware that only support GLES and not Desktop OpenGL. > This is the wrong assumption because if your hardware supports GLES, then it also supports GL. It is only the proprietary module/driver/firmware that exposes the GLES only. Take a look at all the mesa drivers, they all support OpenGL and GLES. > That kind of hardware does exist now and people who try to use Debian > on it will be disappointed because even LXQt will feel sluggish on them. > The hardware that supports GLES also supports OpenGL because GLES is a subset of OpenGL. I find it very hard to believe that the hardware somehow performs differently, if anything, the difference probably comes from the proprietary module/driver/firmware. > This is not a easy decision to make, in the ideal world we would support > both Qt stack but this is not realistic and we have to make a choice. > It is not an easy decision to make. I grant you that. > > In my opinion, Debian as a universal operating system should make choice > #1 so that most hardware bought by most users work well with most > applications. Getting 2% more applications or 20% more performance on the > applications at the cost of 50% of the users not being able to use their > hardware with decent performance is not the correct choice. > I find it hard to believe that Debian, as a universal operating system, would sacrifice software and freedom because some 3rd party software only supports GLES or that they implemented OpenGL poorly. I do however understand that there is a time/effort trade off here. Qt supports both already but only one or the other and currently not both at the same time. My only question then becomes, what is going to happen when support for Vulkan lands. Are we going to have the same discussion? The work will eventually have to be done. Cheers, Bret
Re: Upcoming Qt switch to OpenGL ES on arm64
> 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 accelerated X11 or Wayland, you need > > the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will > > work on a RPi system, which as of 2015 has over 5 million units > > shipped. This is not an insignificant user base. > > Can you back up this claim with some external documentation? > Or at least pointer the appropriate part of the code? > > https://github.com/anholt/mesa/wiki/VC4-OpenGL-support says that the > VC4 hardware is a GLES 2.0 renderer and it would seem strange that > the mesa driver for it would not support OpenGL ES. > If your hardware supports GLESv2 then by definition your hardware also supports at least OpenGL 2.1 so please correct me if I'm wrong but all open-source mesa drivers support both OpenGL and GLES to some degree and only proprietary drivers support only GLES. If you start only shipping packages with only GLES support then you're going to begin dropping packages that only support Desktop GL but would otherwise work perfectly fine on that architecture. The switch to GLES has the only benefit of supporting proprietary firmware/software which isn't exactly DFSG friendly. The VC4 is not an GLES exclusive renderer, it supports OpenGL up to 2.1 and GLES 2. That information comes from same link I have posted earlier in this thread that you have just posted now. What I'm saying is that without the VC4 mesa driver then you're stuck with llvmpipe making the RPi not very useful as a Desktop and then to only ship software with GLES only support then excludes other software that would otherwise work with VC4. I'm am admittedly biased because I'm also an upstream developer of such an application (OpenMW) that only works with Desktop GL, that being said, it is by far not the only one. There are others like openjk and opentesarena just off the top of my head. From our point of view, GLES isn't an option. For GLES only devices, we use a shim that does its best to translate GL2 calls to their equivalent in GLESv2, but that is really dodgy. From our point of view, the next step is Vulkan so we only want to target "Desktop" OpenGL and Vulkan for maximum coverage because it is a waste of time to _also_ support GLES when Vulkan can be used for both Desktop and Mobile. Cheers, Bret
Re: Upcoming Qt switch to OpenGL ES on arm64
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 means zippy. I strongly suspect that moving back from GLES would move it > from "reasonable for limited use" to "pointless". Please don't do anything to > make things even slower. > > Scott K > It's because of the VC4 mesa driver that the RPi is usable for you, reasonable for limited use. Not using VC4, but the CPU based llvmpipe, is what makes it pointless and almost too slow to use as a desktop. If you don't have VC4 enabled, I suggest you give it a try, it's a world of difference. 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] The problem is that there are applications that make use of Qt that do not support GLES while Qt can support both. So these things can't be shipped on armel and armhf and now possibly arm64. What applications does Debian have in its repo that only support GLES? Cheers, Bret [1] https://github.com/anholt/mesa/wiki/VC4-OpenGL-support
Re: Upcoming Qt switch to OpenGL ES on arm64
> > > > 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 as possible unless there is a > > way to provide for both on all archtictures. > > Well, f you can prove this for armhf and/or armel, we can certainly do it. > The Raspberry Pi is armhf. What would you like me to prove? Sadly I can't help you with armel, but with armhf, according to some sources the number of RPi's sold in the last 5 years is 12 million [1]. Admidetly, not all of them will be used as a desktop, but it is still nothing to sneeze at and it is shame that we've had to prevent compiling OpenMW on armhf and armel just because Qt was compiled against GLES. We've had to introduce "libqt5opengl5-dev, libqt5opengl5-desktop-dev [armel armhf]" in the debian/control file as a result. [2] This makes sure that OpenMW can't ever be built on on armel and armhf with "BD-Uninstallable". [3] openmw build-depends on missing: - libqt5opengl5-desktop-dev:armhf ^-- sad state of affairs that this even exists! [1] https://www.theverge.com/circuitbreaker/2017/3/17/14962170/raspberry-pi-sales-12-5-million-five-years-beats-commodore-64 [2] https://salsa.debian.org/games-team/openmw/blob/master/debian/control#L12 [3] https://buildd.debian.org/status/package.php?p=openmw
Re: Upcoming Qt switch to OpenGL ES on arm64
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 can't be built for. Before the GLESv2 switch, OpenMW > > worked just fine on arm* hardware, including the Raspberry Pi/Raspbian with > > the VC4 mesa driver that has OpenGL 2.0 support. > > ...one thing is running and quite another is: how well does it performs when > doing 100% CPU-based OpenGL? Are your users *really* interested to use your > application when all drawing must be CPU-based? There is a misunderstanding here and also in this thread. The Raspberry Pi has the VC4 GPU which is hardware accelerated Desktop OpenGL 2.1 via the VC4 Mesa driver.[1] This driver is fully open-source unlike the binary blob it comes with that only supports GLESv2, but not via X11 nor Wayland. So the only way to support Qt with hardware (not software) accelerated GL on the RPi is with the VC4 mesa driver and Desktop GL. As for OpenMW running on a RPi, it is fully hardware (GPU) accelerated via the VC4 driver. It runs pretty darn well. You can walk around Morrowind (with mods) right now at 25fps @ 1080p using a GPU-based VC4[1] OpenGL 2.0 renderer. 60fps in interiors. This is on a Raspberry Pi 2, likely better with the RPi3 with VC4 being EoL, the next iteration of the RPi will likely be VC5/6 that is arm64. > > I beg you, please either reverse the GLES decision in Qt or provide two > > separate packages for GL or GLES support. > > I'm afraid providing two set ups is a non-go (alas, we would be doing that > already and avoiding all this). And I don't there are many armel/armhf users > with hardware Desktop OpenGL in their boards. > 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 as possible unless there is a way to provide for both on all archtictures. Cheers, Bret [1] https://github.com/anholt/mesa/wiki/VC4
Re: Upcoming Qt switch to OpenGL ES on arm64
> > 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 migrating away from armel to arm64) and this has > forced a move from 'mobile' OpenGLES to 'Desktop' OpenGL. The result of > which is that because that platform (and those like it) do not have > hardware acceleration for OpenGL but DO for OpenGLES you think we should > change the whole architecture for your use case." > 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 accelerated X11 or Wayland, you need the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will work on a RPi system, which as of 2015 has over 5 million units shipped. This is not an insignificant user base. IMHO, the decision to switch away from 'Desktop' OpenGL to GLES was the wrong decision and should be reversed until a solution is found to support both. Cheers, Bret
Bug#913828: ITP: recastnavigation -- Navigation-mesh Toolset for Games
Package: wnpp Severity: wishlist Owner: Bret Curtis * Package name: recastnavigation Version : 1.5.1 Upstream Author : Ben Hymers * URL : https://github.com/recastnavigation/recastnavigation * License : Zlib Programming Lang: C++ Description : Navigation-mesh Toolset for Games Recast is state of the art navigation mesh construction toolset for games. Recast is accompanied with Detour, a path-finding and spatial reasoning toolkit. You can use any navigation mesh with Detour, but of course the data generated with Recast fits perfectly. The package is useful because it is already used in many editors such as Unity and Unreal Editor and as a result used in many AAA games. It is also used in OpenMW, the open world RPG engine. I plan on maintaining the package along with upstream developers on salsa along with the other packages I maintain. If there are others that would like to help, great! I'm looking for a sponsor to help review and upload when ready. Cheers, Bret Curtis
Re: Bug#727195: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind
On Wed, Oct 23, 2013 at 12:38 PM, Jonathan Dowland wrote: > clone 727195 -1 > reassign -1 game-data-packager > retitle -1 game-data-packager: please support packaging Morrowind data > found -1 22 > thanks > > Hi Bret, > > Would you consider/have you considered joining the Debian Games Team? > I seem to recall this being discussed in the team at some point. (Team > mailing list CCed). > Apologies for the double RTP bug, nullmailer hiccup. I'm already signed up via Alioth and have the package ready to be uploaded here: git.debian.org/git/pkg-games/openmw.git I'm being mentored by Scott Howard, which has been a trial by fire experience. :) > On Wed, Oct 23, 2013 at 10:46:38AM +0200, Bret Curtis wrote: >> Reimplementation of The Elder Scrolls III: Morrowind >> OpenMW is a reimplementation of the Bethesda Game Studios game >> The Elder Scrolls III: Morrowind. >> . >> The Morrowind "Data Files" from the original game are required to play. > > Which implies it must go into contrib, rather than main. > You're right, it should go in contrib until our (OpenMW) Example Suite (ES) is ready. For the time being, it should also be put in experimental until we the 1.0 release. > We use a tool "game-data-packager" to help with installing such data > files on Debian systems. Support for Morrowind data files should perhaps > be a wishlist bug for game-data-packager. Cloning accordingly. > > It would be worth having a think about how the package dependencies > should be set up here. Can the engine be used with alternative data? > The doom packages have a particular scheme for interworking, and the > Quake packages have another. > As mentioned above, our ES is in development which allows for TCs and other content to be used with OpenMW without Morrowind assets. At this time however, OpenMW is only useful with Morrowind. > Thanks > > -- > Jonathan Dowland > > > -- > To UNSUBSCRIBE, email to debian-devel-games-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20131023103844.ga15...@bryant.redmars.org > Thanks much! Cheers, Bret -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+lhz98ejodnitecallatlea+7g2cygtmzcv4p7tqpbegqk...@mail.gmail.com
Bug#727195: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind
Package: wnpp Severity: wishlist Owner: Bret Curtis * Package name: OpenMW Version : 0.26.0 Upstream Author : Marc Zinnschlag * URL : http://www.openmw.org/ * License : GPLv3 Programming Lang: C++ Description : Reimplementation of The Elder Scrolls III: Morrowind Reimplementation of The Elder Scrolls III: Morrowind OpenMW is a reimplementation of the Bethesda Game Studios game The Elder Scrolls III: Morrowind. . The Morrowind "Data Files" from the original game are required to play. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131023084638.567.37225.reportbug@Redqueen
Bug#727194: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind game engine
Package: wnpp Severity: wishlist Owner: Bret Curtis * Package name: OpenMW Version : 0.26.0 Upstream Author : Marc Zinnschlag * URL : http://www.openmw.org/ * License : GPLv3 Programming Lang: C++ Description : Reimplementation of The Elder Scrolls III: Morrowind game engine OpenMW is a reimplementation of the Bethesda Game Studios game The Elder Scrolls III: Morrowind. . The Morrowind "Data Files" from the original game are required to play. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131021144143.730.82010.reportbug@Redqueen
