Since config_manager is basically a stub, and even VirtualBox
doesn't publish the serial ports as PCI devices, we must probe for them.
Ideally config_manager would find them in the device manager tree
which would have been populated from the PnP BIOS or even ACPI tables...
Let's hope we won't loose data because it.
We have to cache the value of IIR read from IsInterruptPending(),
because some conditions are acknowledged only by reading it...
This reverts commit 34dbbb65fd.
Instead, we can remove thos from HaikuBuildCompatibility and things will work fine, unless one try t build Haiku on BeOS (this isn't
supported anymore) or a very old Haiku which esdon't have those.
* Radeon chips since Bonaire use a different PCI register base
address. Select the correct one depending on chipset generation
(values from Linux driver).
* Makes radeon_hd work for newer APUs/GPUs (tested with Kabini APU).
Pawel changed the implementation but I see no reason to make those available only from C++, so it must be an oversight.
Fixes building Haiku on Haiku which otherwise hits a mismatch in build compatibility headers.
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.
François Revol