cpuid is available in user mode as well and it doesn't look like there
are going to be any x86 platforms with significantly different CPUs anytime
soon.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
GCC knows whether these functions need to be implemented using syscalls
(or more clever solutions like in Linux) and calls libgcc in such case.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
The less assembler in our sources the better. These functions wouldn't
be used very much since SupportDef.h inlines them, but the symbols should
be available.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Time to get rid of some asm code. Surprisingly, it appears that
on x86[_64] the emitted code for atomic_test_and_get() isn't as efficient
as it could be, even with -O2, but cmpxchg is so expensive that this slight
difference shouldn't matter much.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
If GCC knows what these functions are actually doing the resulting
code can be optimized better what is especially noticeable in case of
invocations of atomic_{or,and}() that ignore the result. Obviously,
everything is inlined what also improves performance.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
- Lazy initializing the fDecodedData variable fits best in
_ResetRawDecodedAudio() as fRawDecodedAudio is all about managing properties
of fDecodedData. So fDecodedData having some memory allocated is seen as a
property here.
- Updated documentation accordingly
- No functional change intended.
- For best performance the color conversion function expects a memory location
aligned to 32 bytes. Without that alignment the color conversion function
falls back to a slower conversion path. This fix was measured via
DO_PROFILING and tested with various 1080p video files.
- The first decoded video frame was always zero bytes large, due to passing the
wrong linesize to the color conversion function. The field containing the
right linesize (fHeader.u.raw_video.bytes_per_row) simply wasn't initialized
yet. Fix it by updating fHeader first before applying deinterlacing and color
converting to the decoded video frame.
Tested with mpeg2_decoder_test where the first picture now isn't empty
(black) anymore.
- Padding is required by FFMPEG for correct operation of all audio decoders.
FFMPEG performs some speed optimizations under the hood that may lead to
reading over the end of the chunk buffer wouldn't there have been padding
applied.
- Resolve TODOs by unifying fVideoChunkBuffer and fChunkBuffer back into
fChunkBuffer because audio path is responsible for freeing fChunkBuffer now.
Resolved TODOs apply to the replacing fVideoChunkBuffer variable by
fChunkBuffer, rename some methods by removing the "Video" part, collapse two
methods into one (_LoadNextChunkIfNeededAndAssignStartTime()).
No functional change intended.
- Enhance "logging stream to file" functionality to write to distinct logging
files for audio and video. Before this commit one could only log video
streams. But with unifying the _LoadNextChunkIfNeededAndAssignStartTime()
audio streams gained the logging functionality for free. But now audio and
video streams would be written in the same log file when watching a media
file containing both audio and video. This is prevented by the distinct
logging mentioned above.
- Update documentation accordingly.
- Main reasons for this refactoring of negotiation steps are to increase
readability and to be on par with the video path.
- Rearrange some negotiation steps in video path to be on par with audio path.
- Add documentation for the new method and update existing documentation
accordingly.
- No functional change intended.
- Fix max line length, switch statement style and some pointer comparisons in
if statements. No functional change intended.
Note: There may be more coding style violations lurking.
- Main purpose is to debug a/v synchronization issues by playing the dumped
mpeg ts data in alternative video players (like ffplay or MediaPlayer) and
see how those behave.
- The commit diffs shows some coding style violations (max. line length) that
show up throughout the whole DVBMediaNode class. Those will be fixed in the
next commit to keep a clean separation between the different code changes.
- Each PowerMonitor now exports a set of descriptors rather than
only a single one. This allows e.g. PowerButtonMonitor to watch
multiple possible button event sources rather than one.
This gets power button working again on some hardware that exports
multiple ACPI power buttons, but offers no obvious way to determine
which one is actually active/being used. In the long term though, it'd
be nice to have a well-defined kernel power event interface that an app
could subscribe to, rather than having to watch individual devfs
descriptors.
Thanks to tqh and korli for advice/review.
- On some hardware, both the fixed function FADT as well as the
device-based power interfaces are present. In such a case we
would fail to publish one or the other, depending on which was
enumerated first, since we'd always attempt to publish the same
name regardless. Now we differentiate the device name for fixed vs
device.
- Only enable fixed function for actual fixed devices.
- Improve tracing.
This still uses the request I had prepared earlier, not the new bulk
request which can get information for the entire package list in one
request. It also has no caching, so it runs for quite a while in the
background (dedicated thread, so hopefully no harm done by keeping it
enabled).
Thanks Augustin, for the parser!
