Adds support for showing individual pixels and zooming in on the
image itself. All ready to be used for showing the actual original
pixel values, rather than the fake qimage pixels which it shows
right now.
Min-Yu Huang [Mon, 19 Aug 2013 14:41:52 +0000 (15:41 +0100)]
Take GL_SAMPLER_BINDING in consideration.
Fixed the issue that GL_SAMPLER_BINDING is only shown globally under
'Parameters' for the last activated texture unit. We should show
GL_SAMPLER_BINDING for each texture unit.
In this change, we also introduce GL_SAMPLER under each texture unit if
the sampler is bound.
Nigel Stewart [Fri, 12 Jul 2013 14:30:41 +0000 (09:30 -0500)]
glretrace: GLX and WGL support for ES2/EGL traces.
I was able to glretrace Gears for Android on x86 Linux with
NVIDIA (non-DRI supporting) driver by enabling
GLX_CONTEXT_ES2_PROFILE_BIT_EXT for the
glXCreateContextAttribsARB path.
Unfortunately eglretrace via Mesa es2/egl doesn't seem
to be compatible the NVIDIA desktop driver.
Improvements in AttribArray / attrib/list code generation.
- Treat unknown keys the same way while counting elements and while
processing them (they are assumed to be followed by an int value).
- Support custom terminators.
- Serialize the terminator.
- Reduce the line count of generated code a bit.
- Add forgotten begin/endElement() around writing the keys.
- Improve comment wording.
Peter Lohrmann [Mon, 8 Jul 2013 12:20:31 +0000 (13:20 +0100)]
Delete the file object if the trace file could not be loaded due to being an unsupported (newer) version.
Fix small memory leak / assert if a trace file can't be loaded due to
being recorded with a newer version number than qapitrace. In this
scenario, there is no error message that gets shown in the UI, but the
title bar is updated with the trace file name, so the situation is very
confusing.
Introduce AttribArray, a code generator for pseudo-type attrib_list.
Also use it for glXCreateConfigAttribsARB, which gives the expected
correct dumps in qapitrace and glretrace dump.
Nothing needs to change in dump code because it just reads whatever
types were written during tracing. Writing different types into
different array elements is allowed by the format, and it turns out
that even older versions of apitrace will correctly display dumps
created with this patch.
Nigel Stewart [Mon, 24 Jun 2013 20:40:44 +0000 (15:40 -0500)]
common: Add platform #ifdefs for non-cmake build convenience.
The cmake CMakeLists.txt file has logic for including or excluding certain
compilation units based on the platform: Windows, Linux or Mac OS X.
Other build systems are not as clever, it is convenient to also wrap
platform-specifics with #ifdef _WIN32 ... #endif to keep things simple on
the build side.
Nigel Stewart [Tue, 2 Jul 2013 22:34:00 +0000 (23:34 +0100)]
Resolve some MS compiler warnings (in picky mode)
warning C4267: 'argument' : conversion from 'size_t' to 'DWORD', possible loss of data
warning C4244: 'return' : conversion from 'double' to 'int', possible loss of data
The root cause of the problem was a bug in the implementation of
getZygoteProcessName. When the wrap.$procname approach is used, reading
/proc/cmdline produces "$procname\0/system/bin\0--application\0"... (with
embedded zero characters).
Fixed by simply not supplying length argument to the truncate call, which will
truncate to strlen(). The same bug is also present in getProcessName.
Carl Worth [Mon, 11 Mar 2013 20:22:05 +0000 (13:22 -0700)]
Use skiplist-based FastCallSet within trace::CallSet
The FastCallSet supports only ranges step of 1 and freq of
FREQUENCY_ALL, so store any such ranges there, and store all other
ranges in the existing, linear list of CallRange.
For manually entered call sets on the command line, the performance
hit of the linear lookup was not generally a problem. But when taking
the (potentially huge) output of "apitrace trim --print-callset" the
performance hit made things quite painful. This makes things usable
again.
Carl Worth [Mon, 11 Mar 2013 19:14:06 +0000 (12:14 -0700)]
Extend trim::CallSet with a new range-based add method.
Previously, individual calls had to be added one-at-a-time. This was
adequate for trimming functionality where one call is examined at a
time.
But I'm now wanting to use this same CallSet code to dramatically
optimize the performance of callset specifications on the apitrace
command-line, (in particular large callsets resulting from "apitrace
trim --print-callset"). In this case, we really want to add entire
call ranges rather than just one call at a time.
Carl Worth [Wed, 22 Aug 2012 18:59:12 +0000 (11:59 -0700)]
trim: Use custom skiplist for required list (instead of std::set<unsigned>)
The std::set<unsigned>::insert method has been dominating profile
output for trimming large traces. Meanwhile, the access patterns of
TraceAnalyzer on the required list is extremely structured; it often
adds the next sequential integer. So we can optimize this data
structure dramatically with two additions:
1. Store ranges rather than single elements, so that the addition of
a new number can expand an existing range rather than inserting a
new element.
2. Remember the most recent element looked-up so that we can check
it first and not do any new lookup for in-order accesses.
With these two changes we get O(1) behavior for the access pattern of
adding sequential integers. For other cases we can still get
logarithmic behavior, but we can keep N dramatically smaller.
Unfortunately, we can't implement either change (that I can see) with
STL. I don't see any way to support lookup with range-based elements
in any STL data structure.
So here, I implement a skip-list based callset data structure. It
provides optimization (1) above and affords an easy implementation of
(2) as well, (though that is postponed to a later commit).
The skip-list implementation is ported from a C version which Keith
Packard and I implemented for cairo, and with the identical license as
the license of apitrace. The reference I used is the commit named c2509f8a721ec489e1b44fa8a68be165363787a7 in the cairo repository.
In addition to changing from C to C++, I implemented range-based
elements.
Do not call trimDirectory() on the proc_name of Zygote processes, because
a Zyogote process name never contains a path separator. The proc_name of
a Zygote process is the application's package name (such as
com.exampe.myapp) because ActivityManager rewrites argv[0].
There exists an undiagnosed problem with trimDirectory, but I have been
unsuccessful diagnosing it. On the other hand, the call to trimDirectory
isn't needed and its removal fixes the bug's symptoms.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
José Fonseca [Mon, 10 Jun 2013 07:05:29 +0000 (08:05 +0100)]
gltrace: Expose marker functions when tracing is disabled.
Matches the output of change proposed by Peter Lohrmann in issue #138,
but with slightly less new code.
This is achieved by adding a new hook point, doInvokeFunction (could not
think of a better name), used to generate the call to the real function,
both when trace is enabled or disabled.
Gregory Hainaut [Sun, 9 Jun 2013 08:06:28 +0000 (09:06 +0100)]
gltrace: Prevent crash in _glGetDebugMessageLog_length (issue #140).
The function was not being called correctly from glGetDebugMessageLog
(and others).
From the spec the GL function:
lengths is an array provided by the application and count is the
maximum number of message that the driver will report into attribute
array (ie lengths). That mean if the driver report 3 messages only
lengths[0 to 2] are valid, others part are not valid and could have
random data.
José Fonseca [Tue, 4 Jun 2013 15:59:21 +0000 (16:59 +0100)]
retrace: Remove the -c/--compare=PREFIX .
That is, remove the ability to compare images while replaying.
For several reasons:
- This duplicates diff-images command.
- It is less versatile -- it is unable to output diff images.
- It will be necessary to change how snapshots are done to properly
accommodate APIs that have no concept of current context, like
Direct3D APIs, so the less fat on this code the better.