You can use SELinux without Secure Boot and Secure Boot without SELinux. Secure Boot can make SELinux more effective, because you can use it to verify that the kernel is not tampered with, so you know that it is properly enforcing the SELinux policies. You could also verify cryptographically whether a policy is not tampered with, but I am not sure if that is currently supported.
The comparison between SELinux and SIP is a bit more complicated. SELinux is a security framework that allows you to write all kinds of policies, whereas SIP is a very specific set of defenses.
On of the main features of SIP is that it makes certain system paths unwritable for every process that doesn't have the right entitlements, including processes with PID 0 (root), unless they have the the necessary entitlements [1]. Since SELinux is a generic security framework, you can implement something similar to SIP's path protection using SELinux. For example, system paths could be labeled with a special label and writes can be restricted to processes with a particular SELinux context. More concretely, you could use SELinux to forbid that any process, including root processes, can write to a system path like /usr/bin. Then you could allow the security context in which DNF/RPM (the Fedora package manager) run to modify system paths like /usr/bin [2].
[1] SIP does more stuff, like disallowing unsigned kernel extensions, preventing code injection, etc.
[2] Russell Coker has set up an SSH machine for which he gives away the root password. But you can't do much with it, because the SELinux policy prevents you: https://www.coker.com.au/selinux/play.html
Secure Boot and SIP are about boot integrity preventing malware early on in the boot process [1]