#479 closed defect (fixed)
Compositor faulty on arm32, mips32, ppc32
Reported by: | Martin Decky | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 0.6.0 |
Component: | helenos/lib/softfloat | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: | #464, #497 |
Description (last modified by )
On arm32, mips32 and ppc32, the compositor service runs, but no application windows are shown. This can be either caused by a bug in the compositor itself, some of the GUI-related libraries or possibly in the libsoftfloat library. On the other hand, sparc64 works fine.
The viability and possibility to replace floating point arithmetic with simpler and faster fixed point arithmetic (or even plain integer arithmetic) in the GUI-related libraries should be also investigated.
Change History (9)
comment:1 by , 13 years ago
Description: | modified (diff) |
---|---|
Summary: | Compositor faulty on arm32, mips32 → Compositor faulty on arm32, mips32, ppc32 |
comment:2 by , 12 years ago
follow-up: 5 comment:3 by , 12 years ago
There is also ticket #464, which may be contributing to this on some of the platforms. This is also just a mere speculation.
comment:4 by , 12 years ago
See also: | → #464, #497 |
---|
comment:5 by , 12 years ago
There is also ticket #464, which may be contributing to this on some of the platforms.
Not on mips32 and ppc32. These platforms should make no use of the hardware FPU and should rely on libsoftfloat completely, because of the -msoft-float compiler flag.
comment:6 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This should be fixed as of mainline,1723. The culprit was uint_to_double() conversion.
comment:7 by , 12 years ago
Milestone: | → 0.5.1 |
---|
comment:8 by , 12 years ago
Note to whoever wants to try this: be patient as it takes some time for the GUI and also the vterm window to show up when using softfloats for these architectures.
comment:9 by , 12 years ago
Component: | helenos/unspecified → helenos/lib/softfloat |
---|
The observations in #497 just slightly increase the probability that the issues are not caused by libsoftfloat, 32-bit addition floating point and subtraction is probably working correctly in libsoftfloat. Of course, 64-bit doubles and all operations with them need to be investigated before making any conclusions.