| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from
shadertools; done separately) become "RHI APIs", following the concept
of QPA APIs.
Mirror completely what is done for QPA headers, but using the "rhi"
prefix for the headers. This involves updating syncqt to handle the
new category of headers. (a note on the regex: matching everything
starting with "qrhi" is not acceptable due to incorrectly matching
existing and future headers, hence specifying the four header names
explicitly)
There is going to be one difference to QPA: the documentation for
everything RHI is going to be public and part of the regular docs, not
hidden with \internal.
In addition to the header renaming and adding the comments and
documentation notes and warnings, there is one significant change
here: there is no longer a need to do API-specific includes, such as
qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a
single header that is then included from qrhi.h. This means that users
within Qt, and any future applications can just do #include
<rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no
other headers are needed.
There are no changes to functionality in this patch. Only the
documentation is expanded, quite a lot, to eliminate all qdoc warnings
and make the generated API docs complete. An example, with a quite
extensive doc page is added as well.
Task-number: QTBUG-113331
Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a library declares a logging category that needs to be used
by clients (e.g. via inline methods, macros, etc.), then the
logging category function generated by Q_DECLARE_LOGGING_CATEGORY
has to be exported.
We've seen this problem with Q_NAMESPACE, Q_GADGET, etc.: these
macros also declare functions or objects that in some cases need to
be exported.
And precisely like Q_NAMESPACE, Q_GADGET, etc., people end up
relying on the implementation details of Q_DECLARE_LOGGING_CATEGORY
(specifically, what does it expand to) in order to place the
export directives in the right place.
Introduce a more robust solution and apply it around qtbase.
Cleanup some minor code as a drive-by (remove `extern` and useless
semicolons).
[ChangeLog][QtCore][QLoggingCategory] Added the
Q_DECLARE_EXPORTED_LOGGING_CATEGORY macro, in order to allow dynamic
libraries to declare a logging category that can be then used by
client code.
Change-Id: I18f40cc937cfe8277b8d62ebc824c27a0773de04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We prefer the shared cache path, because there is no reason to give up
benefitting from sharing the content between applications. If that path
is not QFileInfo().isWritable(), we fall back to the local cache path.
However, there are reportedly systems with security solutions such as
AppArmor where the writable check passes and yet attempting to create a
file still fails. Then there is no cache in effect, because nothing ever
gets written out.
Handle this better: if writing the file fails and we still use our first
choice, the global cache location, fall back to the secondary choice
(the app-local path) and try again.
Pick-to: 6.2 6.1 5.15
Fixes: QTBUG-96789
Change-Id: Ifea32e9af0cf85aa70f3069256ed3d6a7e2fbe90
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Dalton Durst <dalton@ubports.com>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Applied to headers only. Source file to be changed separately.
Task-number: QTBUG-84469
Change-Id: Ic08a899321eaffc46b8461aaee3dbaa4d2c727a9
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
The QT_OPENGL_ES* macros are leftovers from an earlier,
ad hoc configuration system, which has since been
replaced by QT_CONFIG. To clean things up in Qt 6,
we use the new way instead.
Task-number: QTBUG-83467
Change-Id: I578dc7695bff9d5ee303b22e44f60fee22fe0c28
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-74409
Change-Id: I20dfafc0c9bf8e2b68b03e171d70c2cb4ad2bfaf
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The expectation for it is to function identically to what we get with
QOpenGLShaderProgram. (same environment variables, same logging
categories, etc.).
QOpenGLProgramBinaryCache is now shared between the QOpenGL convenience
classes (like QOpenGLShaderProgram) and QRhi. To achieve more modularity
and to prepare for QOpenGLShaderProgram and friends moving out of QtGui,
this class cannot depend on QOpenGLShader* anymore. This involves adding
some minor conversions between QRhi and QOpenGL enums for example.
Change-Id: I2f4664e074823ea536281aea8006a6db159a7381
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
| |
This class will likely be used by the OpenGL backend of QRhi as well.
Therefore, we need to make it more self-contained and independent.
Change-Id: If046ed41e25c70cc9abb45219b451f9179feaa1c
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
While there is likely no example of it in Qt itself, applications can
use QOpenGLShaderProgram instances on different threads. These instances
have nothing to do with each other but they do share a global cache object.
This becomes problematic without proper synchronization.
Change-Id: I80faf73f34af7e67349eee916bb3f216e22c07fd
Fixes: QTBUG-77469
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
| |
Change-Id: I4fb71471a7dd22441def1eb837857d245c3e3c5a
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Fix
QtGui: WARNING: qtbase/src/gui/opengl/qopenglprogrambinarycache_p.h does not have the "We mean it." warning
Amends change 85f868e73e4cf9dffe27b737f8dc3f5bb626ed04.
Change-Id: Id2e8c3e7ac4fa732c0a3d99faab91f08121fba96
Task-number: QTBUG-55496
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
Introduce a glProgramBinary-based disk cache in QOpenGLShaderProgram.
By switching the typical
program->addShaderFromSourceCode(QOpenGLShader::Vertex, ...)
program->addShaderFromSourceCode(QOpenGLShader::Fragment, ...)
invocations to
program->addCacheableShaderFromSourceCode(QOpenGLShader::Vertex, ...)
program->addCacheableShaderFromSourceCode(QOpenGLShader::Fragment, ...)
the compilation may be skipped via gl(Get)ProgramBinary and a disk
cache, when supported. Such QOpenGLShaderProgram instances will have
no QOpenGLShader instances attached. Instead, the entire program
binary (which is driver-specific) is loaded as-is.
Support means OpenGL ES 3.0 or the presence of
GL_ARB_get_program_binary, in combination with >= 1 supported binary
formats. Note that some drivers claim program binary support but
expose no formats. This amounts to no support in practice.
When support is not present, calling the new functions is equivalent
to the non-cacheable variants. If the OpenGL driver changes (vendor,
renderer, version strings), recompilation and storage of the new,
potentially incompatible binary program will happen transparently.
The cache can always be disabled by setting
QT_DISABLE_SHADER_DISK_CACHE=1 or the new application attribute
Qt::AA_DisableShaderDiskCache.
Location-wise the primary choice is the shared cache
(GenericCacheLocation). If this is not available or is not writable,
the per-process one (CacheLocation) is used instead.
In addition to the new public APIs in QOpenGLShaderProgram, the main
shader users in QtGui are migrated as well. (OpenGL paint engine,
glyph cache, blitter, eglfs mouse cursor). This means that any
application using QPainter on OpenGL or widgets with eglfs will
benefit from the improved startup times. Qt Quick will follow suit as
well.
[ChangeLog][QtGui][OpenGL] QOpenGLShaderProgram offers a built-in
program binary disk cache for systems with OpenGL ES 3.x or
GL_ARB_get_program_binary. This can lead to significant increases in
performance when it comes to application startup times for
example. Usage is opt-in for direct C++ users of the class, however
Qt's own main users of shaders, including Qt Quick and QPainter's
OpenGL engine, are migrated to use the new, cache-enabled APIs.
Opting out on application level is always possible via
Qt::AA_DisableShaderDiskCache.
Task-number: QTBUG-55496
Change-Id: I556f053d258bfa6887b1d5238c9f6396914c5421
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|