Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=11&d=16

Friday, 16 November 2018

01:43:03 <pZombie> hello friends
01:43:15 <klange> hello pZombie
01:45:10 <pZombie> What is the technical term for people who have enough understanding of all branches in software development, enabling them to create a skeleton of a project and assign the right coders for each part to fill the skeleton with meat?
01:45:32 <_mjg> unicorn?
01:45:55 <pZombie> i like unicorn
01:46:01 <pZombie> they are probably just as rare
01:46:04 <klange> Architect
01:46:14 <_mjg> architect and/or team leader
01:46:21 <_mjg> depends on the nomenclature in places
01:46:49 <_mjg> team leader can be anyone from clueless to what you described
01:51:00 <eryjus> techical lead
01:51:02 <pZombie> I wonder if it is even possible for any human architect to create a proper skeleton for a complex project without having even messed around with trying to program parts himself. Personally when i try to program something i usually figure things out along the way and they are rarely exactly as i imagined them
01:52:51 <pZombie> I was imagining a website where architects would post their public domain or open source skeleton projects in visual form, split up in many parts, such that people with partial knowledge could add to the code easily
01:53:18 <eryjus> in a previous life, I was part of the leadership team that defined the SDLC and PMM.. the technical lead was 1 step below the project manager and was really the one that ran the project and deliverables -- and reported to the PM
01:53:35 <mischief> FULL STACK DEVELOPER
01:54:37 <klange> lol
01:55:26 <klange> You're not a real full stack developer unless you developed the full stack.
02:03:05 <pZombie> also this https://www.youtube.com/watch?v=fTJ5o_uW3eM
02:16:21 <pZombie> There seems to be something wrong with my motherboard or how (some) intel CPUs measure package power. Lowering my input voltage from 1.85v to 1.5v _RAISES_ the package power instead of lowering it as shown by hwmonitor or hwinfo. The temperatures of the CPU seem to be lower however, as expected when lowering the input voltage, going by the max fan speed shown when keeping the CPU below 60°C
02:17:42 <pZombie> I really need to get a watt-o-meter. Package power does not seem to be a reliable indicator, even for an estimate
02:30:43 <_mjg> is there a x86-64 cpu which does *NOT* provide sse2?
02:33:24 <geist> i dont think so. it's basically part of the arch
02:33:52 <geist> iirc the one thing that tends to be a filter of extremely early x86-64 cpus (early K8s) is cmpxchg16b
02:34:02 <geist> which i think came along a tiny bit later
02:35:47 <_mjg> ye, just want to be sure. ican plop a trivial sse2 memset in without checking what it is
02:36:04 <_mjg> unless it turns out that some fucked cpu somewhere runs without it
02:42:48 <_mjg> geist: so glibc assumes at least sse2
02:42:53 <_mjg> geist: will do the same
02:44:01 <chrisf> klange: weaksauce. not a real full stack developer unless you designed the hardware
02:45:21 <aalm> .theo
02:45:22 <glenda> I don't see that.
02:46:39 <bcos_> chrisf: The hard part of being a full stack web developer is using GOTO for everything (because you can't use function calls without overflowing the stack or making the stack "less full")
02:47:38 <aalm> given you've only got #ffffff there's not much you can do
03:31:43 <jjuran> I found full stacks a lot more appetizing before they became a web platform
04:19:12 <geist> i personally like full descending stacks
04:20:19 <klange> Stacks suck, we should build more queues.
04:20:30 <klange> Where is my web queue?
04:56:10 <jjuran> I was talking about pancakes
04:57:57 <graphitemaster> https://i.redd.it/hq077ahvbhy11.jpg
05:42:04 <jjuran> Do they run on nightmare fuel?
05:51:26 <geist> pancakes, covered with BLOOD
05:53:27 <bcos_> Hmm - Canadian tree blood
06:03:08 <graphitemaster> pancakes covered in blood is actually the name of a band
06:05:40 <klys> the eponymous pancake
06:16:50 <klange> got my CI builds going again, through docker https://github.com/klange/toaruos#building-with-docker
06:17:49 <klys> should the wiki know what docker is
06:19:04 <klange> the osdev wiki? i don't think it's within our scope
06:19:14 <klys> oh
06:19:15 <klange> unless you want to write a technical article about how it works
06:20:00 <Mutabah> Or maybe some simple instructions on automated CI testing of a kernel :)
06:20:16 <Mutabah> Hmm.. maybe I should do CI tests of my kernel, I have the automatic testing support already
06:21:14 <klange> I'm just bringing back builds for now - got the toolchain packed into a docker image that Travis can pull in ~15 seconds, which is much better than the 2 minutes it would spend getting the old one a year ago.
06:21:44 <klange> 30 seconds to build everything off of that, so 45 seconds actual work + travis's CI bringup times, not bad for a whole OS
06:23:10 <AndrewBC> containerization!
08:36:36 <graphitemaster> oh my god
08:36:56 <graphitemaster> someone shoot the guy who invented this assembler
08:36:57 <graphitemaster> <mov dest="rax">0xdeadbeef</mov>
08:37:03 <klange> nice
08:41:40 <lkurusa_> graphitemaster: some people like writing xml
08:41:42 <lkurusa_> apparently
08:49:29 <tnek> graphitemaster: what do immediates look like in that assembler?
08:59:46 <mrvn> that is an immediate
09:27:42 <geist> huh. i'd at least have gone with a <mov dest="rax" immed="0xdeadbeef">
09:27:44 <geist> or something
09:29:02 <klys> intel uses "imed", not sure if it matters
09:29:19 <mrvn> I assume it's an immediate since why would you derefence 0xdeadbeef?
09:30:31 <klys> yeah that isn't an example of a pointer
09:31:15 <graphitemaster> src is never inside the tag only destination is
09:31:44 <graphitemaster> or rather anything immediate or literal is outside the tag
09:31:47 <graphitemaster> that's what it looks like
09:33:35 <mrvn> graphitemaster: just rm -rf the whole thing.
09:34:26 <klys> assembly doesn't mean the same thing as markup
09:38:24 <lkurusa_> i am deadass glad we are not writing assembly like that in this day and age
09:46:38 <graphitemaster> high level assembler is just XML change my mind
09:47:00 <lkurusa_> gross
09:48:08 <mrvn> high level assembler is called C
09:49:52 <klys> extensible markup: a way of repute for data sets; assembly routine: a foundational macro for unoptimized algorithmic behavior.
09:50:58 <graphitemaster> <function name="main" return="int"><params><variable name="argc" type="int"/><variable name="argv" type="char**"/></params><statement type="return" expression="0"/></function>
09:51:01 <graphitemaster> there's XML C
09:52:26 <klys> so, assembly markup would make better sense than markup assembly; just you have to mean graceful assembly markup, or focused markups.
09:58:05 <lkurusa_> just because you can convert stuff into xml does not mean you should
09:58:13 <lkurusa_> i don't even know why xml caught on
09:58:18 <lkurusa_> it's hard for machines to parse
09:58:26 <lkurusa_> it's even harder for humans
09:58:42 <lkurusa_> well, that's subjective, but at least for me, xml doesn't look "good"
10:36:12 <SopaXorzTaker> Can I enumerate PCI Express devices from the real mode?
10:36:42 <SopaXorzTaker> Or would that require protected mode due to the extensive use of memory-mapped IO?
10:36:56 <SopaXorzTaker> lkurusa_, JSON doesn't look "good"
10:36:59 <SopaXorzTaker> XML is amazing
10:37:01 <mrvn> lkurusa_: It's bad, it's horrible, it's 200% overdesign. Obviously it was the new HYPE.
10:37:12 <SopaXorzTaker> but ASN.1 is much cooler than both of those!
10:37:22 <lkurusa_> SopaXorzTaker: I never said JSON looks good
10:37:25 <ybden> I was about to say, Poe's law
10:37:27 <ybden> thank god
10:37:42 <mrvn> SopaXorzTaker: you can enumerate pci devices but anything needing more than 512KiB ram would be a problem.
10:37:51 <SopaXorzTaker> mrvn, pci-e, not pci
10:38:08 <SopaXorzTaker> PCI devices can be enumerated using an I/O port
10:38:24 <SopaXorzTaker> and PCI Express requires accessing some fancy memory-mapped structures, apparently
10:38:32 * lkurusa_ wonders if the firmware knows about PCI-E devices?
10:38:49 <mrvn> sure it does. You can PXE boot from NICs for example.
10:39:22 <lkurusa> SopaXorzTaker: in that case - how about asking the BIOS for that information instead of manually enumerating it?
10:39:31 <lkurusa> that's assuming the bios/firmware exposes a function though...
10:39:40 <SopaXorzTaker> lkurusa, is the way of asking BIOS about PCI-E devices well-documented?
10:39:43 <mrvn> anything modern will have uefi
10:39:57 <lkurusa> SopaXorzTaker: check RBIL, maybe there's something
10:42:11 <SopaXorzTaker> I have exceptional levels of masochism and will struggle to implement everything in real mode
10:42:39 <SopaXorzTaker> lkurusa, RBIL is OAF and doesn't even mention the existence of PCI-E
10:42:50 <mrvn> I vote to have the source register alternate between being first and last for even and odd lines in the source.
10:42:54 <lkurusa> you're out of luck unless using efi
10:43:27 <lkurusa> i understand this real mode madness is for personal masochism?
10:48:12 <mrvn> why not go 64bit but use real mode bios calls for vga output?
10:48:31 <mrvn> real mode bios disk access too
10:51:24 <SopaXorzTaker> lkurusa, yesx
10:51:26 <SopaXorzTaker> yes*
10:51:51 <SopaXorzTaker> I want to write a completely real-mode IRC client using a similarly primitive TCP stack and a NIC driver
10:52:14 <lkurusa> fun!
10:52:20 <lkurusa> you're in for real mess though
10:52:24 <SopaXorzTaker> I know :P
10:52:24 <lkurusa> you probably already know
10:52:27 <lkurusa> yeah :D
10:52:41 <SopaXorzTaker> It would probably be unusable, and I swear this is not because of any paranoia or such
10:52:59 <mrvn> more fun to implement irc for an arduino
10:53:17 <SopaXorzTaker> mrvn, I actually happened to have an Arduino Ethernet once
10:53:32 <SopaXorzTaker> with the native libraries, wow, how fucking unusable that was
10:53:49 <SopaXorzTaker> 2 KB of RAM and a software IP stack don't mix well...
10:54:10 <mrvn> at least you know you can only do one frame at a time
10:54:47 <SopaXorzTaker> The Arduino approach of ignoring any out-of-memory conditions and oversimplifying everything to a bloated C++ dialect with libraries sucks hard too
10:54:51 <lkurusa> i have this risc-v board with 300Mhz lying around
10:54:53 <SopaXorzTaker> it's fucking embedded!
10:54:59 <lkurusa> should be able to bitbang ethernet
10:55:13 <SopaXorzTaker> lkurusa, someone did bitbang 10BASE-T on an AVR
10:55:14 <lkurusa> it's also arduino compatible
10:55:19 <lkurusa> holy shit
10:55:22 <lkurusa> that's crazy
10:55:24 <mrvn> O rather bit bang VGA output
10:55:27 <mrvn> I
10:55:34 <SopaXorzTaker> It's CNLohr, he's a living legend
10:55:43 <lkurusa> i should be able to bitbanh 10base-t on 300mhz without any problem
10:56:03 <mrvn> lkurusa: 240 cycles per byte so yeah
10:56:15 <SopaXorzTaker> He also made an ESP8266 produce an analog TV signal (modulated RF with color, not baseband!)...
10:56:26 <asymptotically> SopaXorzTaker: you don't have to use the weird arduino c++ ide, you can just call gcc and avrdude yourself
10:56:27 <lkurusa> oh my...
10:56:56 <SopaXorzTaker> lkurusa, imagine him in #osdev... :P
10:57:06 <mrvn> doing software radio transmission is fun too
10:58:37 <SopaXorzTaker> mrvn, SDR is incredible
10:59:00 <mrvn> SopaXorzTaker: well, SDR is receiving. I mean sending.
10:59:32 <SopaXorzTaker> mrvn, SDR as a topic covers both TX and RX
10:59:40 <SopaXorzTaker> It's all about converting digital samples to RF, basically
11:00:13 <SopaXorzTaker> There's a lot of SDR hardware, ranging from repurposed TV tuner sticks to dedicated solutions like the HackRF.
11:23:15 <mrvn> "No, no, a psychopath kills for no reason. I kill for money."
11:24:20 <SopaXorzTaker> mrvn, where does that come from?
11:24:34 <lkurusa> .theo
11:24:34 <glenda> There was once a better path.
11:24:35 <SopaXorzTaker> That quote sounds... oddly creepy and inappropriate to the current discussion
11:29:39 <SopaXorzTaker> ... mrvn?
11:30:04 <ybden> it comes from de raadt?
11:30:10 <ybden> Didn't know that de raadt was a hitman
11:31:14 <lkurusa> not a clue where it comes from and too lazy to find my mouse to google it
11:32:09 <SopaXorzTaker> ybden, 'de raadt'?
11:32:35 <ybden> https://en.wikipedia.org/wiki/Theo_de_raadt
11:33:07 <ybden> he's who the .theo quotes come from
11:34:35 <mrvn> SopaXorzTaker: Grosse Pointe Blank
11:37:49 <SopaXorzTaker> mrvn, how is it relevant?
11:44:56 <ybden> Is anything relevant?
11:45:07 <mrvn> SopaXorzTaker: it's unrelated
11:45:12 <mrvn> .roa
11:45:12 <glenda> 98 Every man has his price.
11:45:24 <mrvn> .oO(That's so fitting a hitman)
11:45:51 <SopaXorzTaker> mrvn, and why are we talking about hitmen again? :P
11:46:57 <mrvn> just a little light TV while eating lunch.
12:07:27 <graphitemaster> wtf is the endbr64 instruction
12:07:36 <graphitemaster> first time I've ever seen that
12:07:44 <graphitemaster> 1030: f3 0f 1e fa endbr64
12:07:53 <graphitemaster> I've seen a lot of x86 instructions but that one is new af
12:08:42 <graphitemaster> holy shit it's this https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
12:08:54 <graphitemaster> page 8
12:09:35 <lkurusa> woo
12:09:45 <lkurusa> i should read that document
12:09:45 <graphitemaster> damn gcc is already emitting this garbage
12:09:51 <graphitemaster> how do I turn it off
12:10:37 <lkurusa> -mno-cet maybe?
12:10:50 <graphitemaster> > GCC inserts ENDBR instruction at entries of all non-static functions by default
12:10:56 <graphitemaster> damn
12:11:06 <graphitemaster> 4 bytes per function wasted on what
12:11:57 <graphitemaster> so this is basically just to prevent ROP
12:12:13 <graphitemaster> I can't believe my CPU supports this
12:12:16 <graphitemaster> it's like 8 years old
12:13:35 <lkurusa> initial document came out in '16
12:13:53 <lkurusa> maybe your cpu does not support it, but the instruction encoding refers to a NOP-like instruction ?
12:14:02 <graphitemaster> yeah that's what the paper says
12:14:13 <graphitemaster> they're prepping the compilers to emit this first and next gen CPUs will support it
12:14:28 <graphitemaster> https://sourceware.org/git/?p=glibc.git;a=commit;h=f753fa7dea3367bd3eb7b543103ff8cda182a3fa
12:15:31 <lkurusa> i wonder how reliable this is
12:15:49 <lkurusa> and can i disable it at runtime
12:16:03 <lkurusa> would not be fun if due to a compiler error my previously working code breaks
12:16:14 <graphitemaster> seems to already be a problem
12:16:27 <graphitemaster> things like setjmp/longjmp breaking, exceptions and ifunc resolvers
12:16:34 <graphitemaster> are all new bugs ad a result of this
12:16:37 <graphitemaster> signal handlers too
12:16:46 <graphitemaster> this some new hot stuff
12:16:51 <lkurusa> importantly, can you speculatively exploit this:D
12:18:53 <perplexity> hey, can you guys give me a suggestive route to take in regards to a learning curve. I want to get into osdev, should i be systematically working my way up from learning about the system and its counterparts, then assembly, then onto c to get a true understanding or thats not absolutely necessary?
12:20:36 <graphitemaster> this may be a bit of spam but it's from a subscriber only article and super relevant to osdev
12:20:43 <graphitemaster> so just a warning
12:20:45 <graphitemaster> Beyond the design flaw identified above, there are also implementation problems with CET. One of them is related to the fact that the hardware has not one but two state machines to keep track of the IDLE/WAIT_FOR_ENDBRANCH states for user and kernel mode code, respectively. Only one state machine is active at a time depending on the privilege level of the currently executing code; the other state machine is suspended. There is
12:20:46 <graphitemaster> however no mention in the documentation how this hidden state is saved and restored when the privilege boundary is crossed by a system call, interrupts, etc.
12:20:46 <graphitemaster> This in particular seems to make it impossible for a kernel to switch contexts between threads since it may very well happen that the outgoing thread was interrupted in a different state than what the incoming thread would like to resume in, triggering an instant Control Protection fault upon returning from the kernel to userland. The same problem arises with UNIX style signal delivery and other similar asynchronous userland code
12:20:49 <graphitemaster> invocations. Hopefully this is merely an oversight in the documentation and not the design itself.
12:23:46 <lkurusa> Ouch!
12:23:53 <lkurusa> well that does sound sketchy
12:23:58 <lkurusa> perplexity: hey!
12:24:10 <lkurusa> perplexity: make sure to have a good understanding of what's involved, i.e. by reading some books
12:24:19 <lkurusa> the wiki has plenty of resources to help you get started
12:24:28 <lkurusa> ... and we are here to help you along the way
12:39:32 <perplexity> lkurusa: ok beautiful
12:39:35 <perplexity> thanks a lot
12:51:08 <SopaXorzTaker> Can anyone help me source the documentation of RTL8168?
01:43:19 <qwertyuiop12345> Hey
01:43:38 <qwertyuiop12345> Does reading mathematics books lessen your programming performance for the rest of the day?
02:06:26 <aalm> .theo
02:06:27 <glenda> You know, you have an option available to you regarding this. You could come to the conclusion that you are not entitled and stop posting, and it will work out better in the long term. I did not read anything more you said.
02:06:39 <aalm> .roa
02:06:40 <glenda> 82 The flimsier the product, the higher the price.
02:08:55 <Jari--> Is fopen("A:", "rb"); a legit way?
02:09:41 * Jari-- thinks he should buy a memory stick
02:09:52 <Jari--> my current one displays a blank device
02:09:54 <Jari--> does not work
03:32:05 <abysslurker> o/
03:32:50 <abysslurker> programming interviews over the phone are stressful
03:33:24 <bcos_> More or less stressful than an "in person" interview?
03:36:49 <_mjg> problem with over the phone is that people like to assume you aregoogling shit
03:37:01 <_mjg> wellone of many :-P
03:37:07 <_mjg> how did it go?
03:41:21 <abysslurker> bcos_: just started interviewing so haven't experience those yet.
03:41:35 <bcos_> Ah - OK
03:42:14 <abysslurker> _mjg: I just asked the interview whether I could look something up on cppreference
03:43:01 <abysslurker> _mjg: interview went pretty well, but some silly mistakes due to nerves
03:43:47 <abysslurker> interviewer seemend positive, so hopefully I'll get to do an onsite.
03:44:11 <abysslurker> for now I can relax and do some osdev though
03:44:35 <abysslurker> feels great to program without someone judging everything you do
03:45:02 <_mjg> interviewers are supposed to be positive no matter what
03:45:18 <abysslurker> pls
03:45:28 * _mjg == mr supportive
03:45:49 <_mjg> a good gauge to see how the interviwe is going is to see how difficulty of questions changes
03:46:23 <abysslurker> which is really hard when you are also trying to focus on not messing up
03:46:48 <_mjg> ye, it's for evaluation afterwards
03:47:22 <_mjg> unfortunately some people will point out your mistakes and others will never do it, just change the subject
03:47:32 <_mjg> easier to gauge f2f
03:48:40 <abysslurker> felt like the exercise couldn't be made harder anymore, but I also wasted some time dealing with C++ errors and not properly renaming everything after copying code to work on the next version.
03:49:28 <lkurusa> did you choose C++?
03:49:32 <abysslurker> yes
03:49:59 <lkurusa> interesting
03:50:01 <abysslurker> might be a mistake in hindsight, but it is what I'm most comfortable with.
03:50:08 <lkurusa> i always did the algo interviews in python
03:50:16 <lkurusa> lower level interviews in C
03:50:21 <lkurusa> didn't want to be hassled with C++ crap
03:52:01 <abysslurker> C++ is fine imo, it's just that those huge unreadable errors make me look like an idiot who doesn't know how to program.
03:52:14 <abysslurker> tiny mistake -> huge error message
03:52:24 <lkurusa> wait until you do a coding interview in haskell :D
03:52:39 <abysslurker> I have Haskell listed on my resume
03:52:42 <lkurusa> there was one problem where the haskell equivalent was a one liner
03:52:42 <abysslurker> might be a mistake
03:53:05 <lkurusa> it's not
03:53:25 <lkurusa> i guess you know how to do basic stuff in it and you have the core idea of folding, recursion wrapped around your head
03:53:26 <abysslurker> I'm completely fine with programming in Haskell, but doing interviews in Haskell sounds like my worst nightmare
03:53:37 <lkurusa> Right
03:54:07 <bcos_> abysslurker: The trick with interviews is to realise you have nothing to lose - worst case is "no change" (you don't get a job you already didn't have)
03:54:31 <abysslurker> I'd like to get a job though
03:54:44 <abysslurker> preferably an interesting one
03:55:30 <abysslurker> and the latter I can actually lose. not with one interview, but there are a finite number of interesting jobs out there.
03:56:12 <pixelherodev> Are there many jobs nowadays where os dev knowledge is useful?
03:56:16 <abysslurker> and even smaller number of interesting jobs looking for new grads
03:56:18 <abysslurker> in november
03:56:26 <lkurusa> pixelherodev: Apple is looking for folks
03:56:31 <pixelherodev> Huh
03:56:37 <lkurusa> i image google and ms would do the same
03:56:39 <pixelherodev> Just them?
03:56:46 <lkurusa> Red Hat also always does look for OS people
03:56:47 <pixelherodev> Yeah, I'm not thinking for the present at all
03:56:49 <abysslurker> red hat, errr, ibm probably
03:56:54 <lkurusa> shut up :D
03:56:55 <qwertyuiop12345> If you want to work on mobile service provider, ISP, and other such companies then come to the third-world. In my country you'd pass the interviews with flying colors if you knew most basic Java and you'd make 20x the average salary of the country.
03:57:09 <_mjg> rh has terrible pay
03:57:12 <bcos_> abysslurker: I mostly don't care about it much - regardless of what the job is, you're selling your time for $ and doing something that you'll learn to hate
03:57:14 <bcos_> ;-)
03:57:19 <_mjg> don't go there unlessyoua re on a mission
03:57:22 <lkurusa> _mjg: still?
03:57:23 <pixelherodev> qwertyuiop12345, I imagine there's terrible downsides to doing that though
03:57:28 <_mjg> lkurusa: as always
03:57:29 <abysslurker> doing actualy osdev is pretty limited, but there are plenty of jobs where you need similar skills.
03:57:35 <qwertyuiop12345> pixelherodev: Yes, of course
03:57:41 <lkurusa> i worked there '14-'15 as an intern and heard complaints about this
03:57:48 <lkurusa> there were some on memo-list too i think
03:58:00 <abysslurker> bcos_: work is 1/3th of my day, and 1/2 of the hours awake, so I'd rather do something somewhat interesting.
03:58:21 <_mjg> lkurusa: rh did not create offices in backward cities to pay :-P
03:58:45 <lkurusa> the brno office was great
03:58:47 <bcos_> abysslurker: What is your favourite food, and how would you feel eating that food every day for 10 years?
03:58:47 <abysslurker> qwertyuiop12345: and what's your country?
03:58:53 <qwertyuiop12345> abysslurker: Azerbaijan
03:58:59 <_mjg> lkurusa: definitely not in terms of pay
03:59:08 <lkurusa> _mjg: don't tell me! :D
03:59:09 <_mjg> lkurusa: or anyother office for that matter
03:59:09 <qwertyuiop12345> Certainly don't come here if you can't tolerate stupid people
03:59:23 <abysslurker> bcos_: it's better eating your favorite food every day than eating your least favorite food every day.
03:59:45 <lkurusa> _mjg: the mission of RH was great though
03:59:47 <bcos_> abysslurker: There isn't much difference after a few weeks
03:59:48 <lkurusa> i felt highly energized
03:59:51 <lkurusa> loved that aspect
03:59:54 <_mjg> dude
03:59:57 <qwertyuiop12345> RH is dead
03:59:58 <_mjg> it's just mgmt exploiting people
04:00:05 <abysslurker> bcos_: I look forward to being disappointed
04:00:15 <qwertyuiop12345> Anytime you feel something you are being manipulated
04:00:17 <_mjg> same old as in other corps, except smaller pay
04:00:20 <bcos_> abysslurker: (you learn to tolerate the bad food, or learn to dislike the favourite food)
04:00:24 <lkurusa> ah
04:00:40 <lkurusa> my red hat is still on my desk lol
04:00:41 <qwertyuiop12345> bcos_: Or you learn to tolerate disliking your favorite food
04:01:42 <bcos_> At the end of the day it just becomes "time+stress -> $$"
04:01:50 <qwertyuiop12345> If you can't get sex in your country then come to mine, you'll get shitload of it
04:02:11 <abysslurker> well, the company I'm currently interviewing with seems really interesting, so I'll just hope (or pretend) that it will stay the same
04:02:25 <lkurusa> abysslurker: best of luck!
04:02:33 <qwertyuiop12345> It is funny when you talk about having a job as something optional
04:02:54 <bcos_> Optional?
04:02:57 <qwertyuiop12345> I mean, how do you even survive without a job?
04:03:05 <qwertyuiop12345> Do you grow your own food?
04:03:13 <abysslurker> bcos_: $$ isn't the most important factor at this point for me, career growth is more important. at the end of the career there is more $$
04:03:27 <lkurusa> qwertyuiop12345: one can always just fund their own company
04:03:37 <lkurusa> with the right idea, that should be profitable
04:03:44 <qwertyuiop12345> If you don't enjoy high-level development and just do it for $$ then you'll be miserable
04:03:45 <abysslurker> moving back in at parents is a good way to survive (for a short while)
04:04:13 <abysslurker> qwerty: I think bcos_'s point is that you'll be miserable either way
04:04:20 <qwertyuiop12345> No one is going to pay you to interface with x86 interfaces, unless you are lucky
04:04:45 <abysslurker> luckily that's not the only interesting thing out there
04:04:48 <qwertyuiop12345> I feel pretty okay right now, doing mostly Java and other such crap. At least compared to what I felt like before
04:05:06 <qwertyuiop12345> Sure it's miserable at times
04:05:24 <qwertyuiop12345> But I can't say that having no job is less miserable
04:05:31 <abysslurker> I'd rather not be a "java developer", i'd rather by a "software engineer" who happens to work with java
04:06:07 <pixelherodev> I bet some of the Java developers regret being Java developers instead if engineers who happen to work with Java XD
04:06:10 <qwertyuiop12345> 90% of my company runs on Java and PL/SQL
04:06:32 <FireFly> I wish job titles wouldn't be so arbitrary
04:06:35 <qwertyuiop12345> Outside of first-world, most of the world relies on shit like Java, C#, and stored procedures
04:07:00 <qwertyuiop12345> Cuz they don't make technology outside of first-world, second-world and third-world just uses tech for business purposes
04:07:52 <qwertyuiop12345> Making websites is considered "high-tech" here
04:07:56 <abysslurker> programming languages are just tools, if they aren't too terrible then i'll be fine with whatever
04:08:14 <qwertyuiop12345> They are not all the same kind of tools
04:08:20 <abysslurker> making CRUD websites is considered high tech everywhere
04:08:27 <qwertyuiop12345> You can't fiddle with bits using Java
04:08:32 <abysslurker> most VC-backed startups just make fancy websites
04:09:06 <qwertyuiop12345> You can barely fiddle with the hardware that runs your software on Java
04:09:59 <abysslurker> qwertyuiop12345: that's not necessarily an issue though, I love not having to think about hardware when programming in Haskell
04:10:31 <qwertyuiop12345> All one can make that way is same old tried bullshit
04:11:09 <qwertyuiop12345> I guess that's not so much different from using C anyway
04:11:27 <abysslurker> Spark is written in Java, I wouldn't classify that as the same old tried bullshit
04:11:30 <qwertyuiop12345> Like, seriously, there's nothing novel to program anymore
04:11:36 <qwertyuiop12345> We are just hammering for efficiency now
04:12:02 <qwertyuiop12345> Why Spark specifically
04:12:09 <abysslurker> I don't agree with that at all
04:13:06 <abysslurker> 95% of the programming jobs are reinventing the wheel in a fancy new framework, but the other 5% aren't
04:13:11 <qwertyuiop12345> Right now I've got to make a CRUD for my company using Spring Boot and Angular
04:14:13 <qwertyuiop12345> abysslurker: That 5% is more like 0.05% that is done is some parts of USA and EU
04:14:20 <qwertyuiop12345> s/is/in/
04:14:55 <abysslurker> yeah, Azerbaijan probably doesn't have those jobs
04:15:10 <qwertyuiop12345> I doubt places like Russia do either
04:15:38 <abysslurker> Yandex maybe?
04:15:39 <qwertyuiop12345> If they do then maybe in some government-funded pockets making military tech
04:15:50 <qwertyuiop12345> That can be considered a military tech too lol
04:16:14 <abysslurker> TIL Yandex is half-Dutch
04:16:52 <abysslurker> do they actually have offices here, or is just for tax evasion? i'd rather not go to their website if possible
04:17:00 <qwertyuiop12345> Biggest problem in my country of 10 million is about finding and retaining talent. As the most reputed tech company of the country we can't seem to find single semi-decent junior worth hiring even though we need several
04:18:03 <qwertyuiop12345> abysslurker: Most of the corrupt countries are sustained by the first-world. The only incentive for dictators and other tyrant to be that way is the fact that they can nest money in real countries and retreat without having to live in the shithole they have created
04:18:19 <abysslurker> to be fair most companies having issues fining good new grads
04:18:37 <qwertyuiop12345> "good new grad" means someone who can use a package manager here
04:19:01 <abysslurker> ok, those are probably not the unicorns I was thinking about
04:20:16 <abysslurker> most interesting companies here in the netherlands are unfortunately not actively looking for new grads
04:21:27 <abysslurker> btw, if anyone here works at an interesting company in the EU which is looking for new grads, hit me up :)
04:22:12 <qwertyuiop12345> Why not come to Azerbaijan
04:22:17 <qwertyuiop12345> I can get you a job
04:22:19 * lkurusa yawns
04:22:31 * abysslurker yawns
04:22:40 <qwertyuiop12345> abysslurker: Cmon man, you'll be raped several times at worst
04:22:57 <lkurusa> Complaining doesn't get you anywhere
04:23:10 <qwertyuiop12345> Nor does working
04:23:22 <qwertyuiop12345> I've been scheming for more than 2 decades
04:24:05 <rain1> so many insane people end up in this chat
04:24:46 <lkurusa> rain1: people doing osdev tend to have some form of insanity
04:24:57 <qwertyuiop12345> I'm insane because I don't fit into this country
04:25:04 <qwertyuiop12345> I was pretty sane when I was like younger
04:25:11 <abysslurker> *cough* Terry A. David *cough*
04:25:14 <qwertyuiop12345> Just couldn't handle it
04:25:21 <qwertyuiop12345> Davis*
04:25:27 <lkurusa> qwertyuiop12345:
04:25:28 <_mjg> why do you stay there? family?
04:25:38 <qwertyuiop12345> 1. Worthless passport
04:25:40 <lkurusa> (apologies that was a mistake)
04:25:41 <qwertyuiop12345> 2. Very low salaries
04:25:57 <qwertyuiop12345> 3. System that refuses to give me a diploma
04:26:06 <qwertyuiop12345> 4. Forced conscription, gotta pay bribes
04:26:24 <qwertyuiop12345> 5. Can't even breathe to think clearly
04:26:31 <qwertyuiop12345> 6. Inbred genes
04:26:36 <qwertyuiop12345> I could go on
04:26:57 <_mjg> i'm sorry but you read like the j-something person who comes to troll
04:27:06 <qwertyuiop12345> Not me
04:27:10 <abysslurker> i remember this rant about azerbaijan, are you the same guy?
04:27:14 <qwertyuiop12345> Maybe
04:27:15 <_mjg> not saying this is necessarily wrong
04:27:40 <qwertyuiop12345> I'm probably the only guy in Azerbaijan that ever used IRC
04:27:56 <lkurusa> this attitude doesn't get you anywhere
04:27:58 * lkurusa yawns again
04:28:02 <abysslurker> this might be the first time I'd unironically recommend someone to watch jordan peterson's lectures
04:28:09 <qwertyuiop12345> That guy is crazy
04:28:16 <qwertyuiop12345> He says dumb shit
04:29:09 <pixelherodev> *This* is *exactly* what I expected to see when I switched to the osdev channel lol
04:29:14 <qwertyuiop12345> I make 5$/hour and that's like 10x the average salary around here
04:29:25 <qwertyuiop12345> I write Typescript, Java, Go, C++, SQL, and whatnot
04:29:36 <qwertyuiop12345> I create infrastructure and shit out a lot of CRUDs
04:29:37 <abysslurker> pixelherodev: my apologies, it mostly isn't like this.
04:29:39 <qwertyuiop12345> Fix lots of legacy shitcodes
04:29:43 <qwertyuiop12345> Yet 5$/hour
04:29:51 <qwertyuiop12345> Can't even get a tourist visa to anywhere sane
04:30:15 <pixelherodev> abysslurker, I'm aware
04:30:20 <pixelherodev> Long time lurker on here
04:30:27 <pixelherodev> Haven't really done much OSDev until this week though
04:30:27 <lkurusa> Not being granted a tourist visa seems odd
04:30:37 <lkurusa> what's the reason for refusal?
04:30:52 <qwertyuiop12345> Cuz a lot of these people around me are high-risk for illegal overstaying
04:31:02 <qwertyuiop12345> (or they are just low-value people, idk)
04:31:11 <lkurusa> ... but you should be able to prove that you won't overstay
04:31:16 <qwertyuiop12345> Hahahahaha
04:31:20 <lkurusa> i.e. by a mortgage, family, friends, workplace
04:31:21 <qwertyuiop12345> Can't do that in Azerbaijan
04:31:25 <abysslurker> to switch to osdev: does anyone know if the latest version of qemu supports tsc-deadline mode for the APIC? i really cant be arsed to calibrate the APIC timers
04:31:47 <bcos_> abysslurker: You want to calibrate TSC instead?
04:31:52 <qwertyuiop12345> Why does mortgage, family, friends, workplace matters in a shithole
04:32:20 * lkurusa yawns for the final time
04:33:08 <qwertyuiop12345> Seriously, I have never seen a sane country in my whole life
04:33:14 <abysslurker> bcos_: if the TSC is running in constant-rate mode I won't have to do that, I just have to figure its frequency.
04:33:40 <qwertyuiop12345> It looks very other-worldly when I look at dem streets on Youtube
04:34:14 <qwertyuiop12345> anyway
04:34:16 <qwertyuiop12345> bye
04:34:19 <abysslurker> cya
04:34:28 <qwertyuiop12345> you want to see me again?
04:34:48 <abysslurker> if you keep that rant to yourself, why not?
04:35:14 <qwertyuiop12345> fucker I need a fucking visa
04:35:23 <rain1> fuck!
04:35:34 <qwertyuiop12345> why is it so fucking hard to get
04:35:42 <qwertyuiop12345> like I wanna go there and work like a good citizen
04:35:55 <qwertyuiop12345> what's so hard about this
04:36:22 <qwertyuiop12345> do you have answers?
04:36:37 <abysslurker> wait, you are the same guy. we have already discussed this before
04:36:45 <pixelherodev> Yes. a bunch of OSdevers have the magical answers to all the world's problems.
04:36:47 <pixelherodev> </sarcasm>
04:37:16 <qwertyuiop12345> There's no problem though, just irrationality
04:37:18 <abysslurker> i'm 24 years old, I know literally nothing about how the world works.
04:37:28 <pixelherodev> irrationality is a problem.
04:37:52 <pixelherodev> I'm 17. I know literally everything about how the world works.
04:37:54 <qwertyuiop12345> wouldn't you be angry if you were me?
04:37:56 <abysslurker> irrationality is what makes us human, the world would be boring if everything was natural
04:38:02 <pixelherodev> True
04:38:03 <abysslurker> *rational
04:38:13 <bcos_> Expectations are a problem (e.g. expecting a rational world)
04:38:27 <pixelherodev> qwertyuiop12345, not really, but I'm not exactly a great model of human behavior
04:38:50 <abysslurker> i'd imagine everything is rational if you look from god's perspective at the world
04:39:06 <pixelherodev> Why be angry? All it does is make you *more* miserable. It's not going to help you in any way.
04:39:23 <abysslurker> and imo that's good way to think about it even if you aren't religious
04:39:36 <pixelherodev> I don't see it that way
04:39:45 <qwertyuiop12345> Fuck, all I ever get is some random tirade
04:39:57 <pixelherodev> We're basically a hair trigger away from extinction
04:40:15 <abysslurker> change what you can change, accept what you can't.
04:40:31 <abysslurker> qwerty: well what did you expect when you came here to rant?
04:40:51 <qwertyuiop12345> You don't necessarily plan ahead when you have exhausted all options
04:41:05 <pixelherodev> I suggest you read up on the time a restaurant employee who was delivering food to an America nuclear base noticed that it was completely unlocked and he could literally see the bombs from the outside while approaching
04:41:10 <qwertyuiop12345> You just scream down any channel that might be open
04:41:43 <abysslurker> or you try to accept things, no matter how hard that is
04:41:48 <pixelherodev> or the time America accidentally dropped a nuke on California.
04:41:58 <pixelherodev> and literally considered it a miracle it didn't go off.
04:42:16 <abysslurker> pixelherodev: wasn't that north carolina?
04:42:20 <pixelherodev> ... maybe.
04:42:25 <pixelherodev> probably.
04:42:37 <abysslurker> https://en.wikipedia.org/wiki/1961_Goldsboro_B-52_crash
04:42:39 <abysslurker> this?
04:42:42 <pixelherodev> Or how about when Russia thought we'd launched a nuke at them and almost nuked us?
04:43:05 <pixelherodev> Yeah probably
04:43:07 <pixelherodev> `Information newly declassified in 2013 showed that one of the bombs came very close to detonating.`
04:43:57 <pixelherodev> So forgive me if I don't think the world can be considered rational
04:44:33 <abysslurker> pixelherodev: Stanislav Petrov's story is amazing
04:45:12 <abysslurker> to be fair, I'm not sure if he was rational, he had no reason to believe those bleeps on the screen weren't nukes
04:45:38 <pixelherodev> DIdn't he say it was because he didn't think we were that stupid or something?
04:49:41 <qwertyuiop12345> Man
04:49:42 <qwertyuiop12345> FUCK
04:49:55 <qwertyuiop12345> This has to be a fucking joke
04:50:50 <qwertyuiop12345> I spend time here when I should be coding
04:50:58 <qwertyuiop12345> My bones hurt
04:51:08 <qwertyuiop12345> I just can't get up and face reality
04:51:34 <qwertyuiop12345> My insides hurt from unhealthy food
04:51:38 <qwertyuiop12345> and bad posture
04:51:48 <qwertyuiop12345> I just can't get up and face the fucking reality
04:52:14 <CrystalMath> what reality?
04:52:23 <pixelherodev> Doesn't mean you need to complain about it here of all places
04:52:23 <qwertyuiop12345> This fucking room and the things I have to do
04:52:33 <pixelherodev> THIS IS NOT THE PLACE FOR THIS CONVERSATION
04:52:36 <qwertyuiop12345> If I don't complain here then reality seeps in
04:52:46 <lkurusa> pixelherodev: +1
04:53:15 <qwertyuiop12345> Why can't I just fucking get on a plane and leave
04:53:31 <pixelherodev> You're not paying attention to us. I see that now.
04:53:53 <qwertyuiop12345> I really don't want to be controlled by these corrupt fucks
04:54:00 <qwertyuiop12345> It's nauseating
04:54:11 <bcos_> Erm
04:54:21 <bcos_> qwertyuiop12345: Which corrupt fucks would you rather be controlled by?
04:54:27 <qwertyuiop12345> Not these
04:54:37 <qwertyuiop12345> Cuz they are slaves of some other corrupt fucks
04:54:41 <qwertyuiop12345> I need first-order controllers
04:54:41 <CrystalMath> then you have lots of options open
04:55:08 <qwertyuiop12345> I'm literally melting here
04:55:13 <pixelherodev> Anyone know of any games that run as kernels?
04:55:17 <bcos_> qwertyuiop12345: The solution to "grass is always greener" is to find somewhere that has no grass, so that you can be happy with your brown and ugly grass.
04:55:25 <pixelherodev> Only one I know of is GRUB Invaders
04:55:27 <CrystalMath> pixelherodev: every DOS game ever :P
04:55:29 <qwertyuiop12345> SHUT. THE. FUCK. UP
04:55:43 <pixelherodev> Let me amend that
04:55:45 <qwertyuiop12345> I need those clean streets
04:55:55 <qwertyuiop12345> I can't tolerate this anymore
04:55:59 <pixelherodev> Any games that run as kernels that can be booted by modern bootloaders?
04:56:14 <pixelherodev> Or that have been made in the last, say, five years?
04:56:24 <qwertyuiop12345> TempleOS games run on kernel mode
04:56:29 <pixelherodev> Not what I meant
04:56:47 <pixelherodev> Not *in kernel mode*
04:56:50 <pixelherodev> *as kernels*
04:57:00 <qwertyuiop12345> TempleOS is one big game
04:57:06 <pixelherodev> E.g. multiboot-compliant games?
04:57:23 <CrystalMath> pixelherodev: there's one called Amnesia
04:57:27 <CrystalMath> you boot it instead of DOS
04:57:29 <qwertyuiop12345> Windows 10 is game about protecting your privacy
04:57:42 <CrystalMath> pixelherodev: it was actually really cool
04:57:51 <CrystalMath> pixelherodev: for the 8086
04:58:07 <qwertyuiop12345> Man, I don't even give a shit about 8086
04:58:22 <qwertyuiop12345> Really dumb shit
04:58:23 <pixelherodev> So does this mean I'm the first one to create a multiboot-compliant *game* anytime recently?
04:58:27 <CrystalMath> qwertyuiop12345: then i guess you've reached the pinnacle of apathy
04:58:27 <qwertyuiop12345> Yes
04:59:02 <qwertyuiop12345> I've reached the pinnacle of fucking anger
04:59:18 <qwertyuiop12345> I'm so angry my bones hurt
05:00:30 <rain1> what happened?
05:00:40 <qwertyuiop12345> Life happened
05:00:56 <rain1> oh i have that too
05:01:02 <qwertyuiop12345> Mine is much better
05:01:22 <qwertyuiop12345> I'm so angry I feel like I'll leave my body any second now
05:01:31 <CrystalMath> qwertyuiop12345: if you're from azerbaijan, you can visit my country without a visa
05:01:39 <qwertyuiop12345> CrystalMath: What country is that?
05:01:44 <CrystalMath> serbia
05:01:49 <qwertyuiop12345> Lol
05:01:52 <qwertyuiop12345> No ty.
05:02:08 <qwertyuiop12345> I have enough slavs in my life
05:02:27 <qwertyuiop12345> I have enough slavs pestering me for 10 lifetimes
05:02:33 <isaacwoods> and the guy talks about intolerance...
05:02:44 <qwertyuiop12345> Slavs invented intolerance
05:03:19 <lkurusa> isaacwoods: this attitude will take them nowhere, i have no idea what they said cause i've put on an /ignore lol
05:03:30 <lkurusa> but i can kinda feel
05:03:44 <isaacwoods> do we have a rule against outright racist, I feel we're getting fairly close
05:03:50 <isaacwoods> racism*
05:04:15 <qwertyuiop12345> There's guy that sits in front of me on office and talks about murdering this or that race all day long
05:04:19 <qwertyuiop12345> And it's socially acceptable
05:04:24 <isaacwoods> lkurusa: and ooh, forgot about /ignore - thanks!
05:04:32 <qwertyuiop12345> And many other who talk about how gay people don't belong here cuz it's my country
05:04:50 <qwertyuiop12345> I'm so sick of it all
05:05:01 <qwertyuiop12345> And there's no fucking escape
05:05:05 <qwertyuiop12345> Day in day out
05:05:09 <qwertyuiop12345> Surrounded by bigots
05:05:46 <CrystalMath> that's quite a huge generalization... i've met various people from various places, and i didn't notice that tolerance is tied to nationality or race
05:06:06 <CrystalMath> but more to other things like education
05:06:38 <qwertyuiop12345> I wish I had a chance to get an education
05:06:45 <qwertyuiop12345> All I got is propaganda and bullshit
05:06:49 <qwertyuiop12345> And I fucking hate it
05:07:03 <qwertyuiop12345> Never took them seriously, thought they were fools
05:07:09 <isaacwoods> qwerty: don't repeat the cycle here then, or you're no better than that guy in front of you
05:07:17 <qwertyuiop12345> But now I can't leave and I'm fucking angry
05:07:23 <qwertyuiop12345> isaacwoods: sorry
05:07:32 <qwertyuiop12345> Can I get a visa now?
05:11:49 <qwertyuiop12345> My country literally made a national hero out of guy that murdered another guy with axe on the grounds that he was Armenian
05:12:23 <qwertyuiop12345> https://en.wikipedia.org/wiki/Ramil_Safarov
05:19:12 <geist> well okay then.
05:21:12 <CompanionCube> surprised he didn't get b&
05:23:12 <pixelherodev> Thanks for the reminder about /ignore.
05:25:27 <geist> yah i would have gotten to it had i woken up earlier
05:28:25 <_mjg> he left just bofre you arrived
05:28:32 <geist> yah
05:28:39 <_mjg> coincidence? i don't thinkso
05:28:53 <geist> oh no was i sleep-ircing?
05:33:01 <_mjg> i don't think sleeping was involved
05:33:31 <_mjg> still, if the dude was actually serious(?) that's rather worrisome stuff
05:33:50 <CrystalMath> _mjg: the Ramil Safarov story seems to be true
05:41:25 <geist> yah. humans suck
05:44:09 <lkurusa> that's a true story yeah
05:44:32 <lkurusa> hungary extradited him to azerbaijan
05:49:06 <abysslurker> wow I missed a big rant
05:49:24 <abysslurker> is this going be a thing now? an azerbaijan rant every few weeks?
05:49:43 <geist> i hope it's not the new type of entertainment around here
05:50:00 <abysslurker> yawning is a much better form of entertainment
05:50:09 <geist> all in all it's been pretty quiet here the last few months, and i'm perfectly okay with that
05:50:26 <geist> our resident Estonian went quiet a few months back
05:50:43 <abysslurker> only a few months ago?
05:51:00 <abysslurker> I think that guy was here a year ago
05:51:09 <geist> yeah i think he was still active this summer
05:51:15 <geist> NH summer that is
05:53:15 <abysslurker> everybody loves a good village idiot
05:55:35 <geist> anwyay, how about those computers
05:55:43 <geist> with their computing
05:56:15 * bauen1 yawns
05:57:50 * bcos_ has determined that the main reason (gaming) computers don't have "smell generators" is that you need a way to quickly evacuate the old air when the smell changes
05:58:06 <bcos_> :-)
05:58:45 <bcos_> (other than that, you'd probably only need 5 scents to cover all smells, for the same reason you only need 3 colours to generate all colours)
06:03:27 <_mjg> computers are terrible
06:03:41 <_mjg> i need a part-time gig doing something higher-level
06:03:51 <_mjg> but preferably not CRUD in azerbaijan
06:34:00 <bauen1> bcos_: just have some oversized cooling fans for a gpu that delivers 2000 fps, that way you have a way to blow away the air quickly and something totally useless to brag about
06:43:19 <chrisf> bcos_: you have a faulty assumption
06:45:14 <chrisf> bcos_: we have a ton of different odor receptors
06:46:03 <glauxosdever> Wow. The logs
06:51:23 <bcos_> chrisf: I don't think it works like that - e.g. maybe 600 different receptors wired up to 5 signals
06:55:36 <isaacwoods> bcos_: humans have ~1000 different glomeruli, each of which is thought to be responsible for a different odor
06:57:05 <isaacwoods> smells activate one or more glomeruli, so you'd need a bunch of chemicals to simulate it properly
06:58:08 <bcos_> And?
06:59:07 <bcos_> Lets say you have 200 sensors to detect various acidic molecules that all put a signal on the one single "acidic" wire to your brain.
06:59:37 <bcos_> ..and 200 sensors that detect sweet molecules with one single "sweet" signal to your brain, and...
07:00:03 <isaacwoods> yeah but it's a bunch more than 5 - finding affordable and non-toxic chemicals for the whole odor map is a pita
07:00:14 <bcos_> The number of specific types of sensors is irrelevant. The number of wires/signals to the brain is what matters
07:00:17 <isaacwoods> which is probably why consumer smell generators don't exist
07:00:37 <isaacwoods> no as in there's thousands of "wires to the brain"
07:02:21 <bcos_> isaacwoods: I don't beleive that at all
07:11:09 <mrvn> it's also not one wire per signal but multiple wires firing at different frequencies.
07:11:30 <mrvn> and also not firing.
07:11:45 <bcos_> I tend to think of it as analogue signals (an amplitude per wire)
07:12:16 <bcos_> ..where 3 wires = millions of colours, and 5 wires = trillions of smells
07:13:34 <bcos_> (and where 100 wires would be so many possibilities that it's too far fetched to consider plausible)
07:14:17 <mrvn> bcos_: and the eye has what? Millions of wires?
07:14:27 <bcos_> (..in a "so much precision that you can tell what someone at every day for a month when they fart" way)
07:14:35 <bcos_> mrvn: They eye has 4
07:14:49 <bcos_> ..but only 3 that matter in normal conditions
07:15:33 <isaacwoods> I think they're strictly digital by themselves - neurones either depolarise or they don't
07:15:40 <isaacwoods> then you have summation between groups of wires
07:20:28 <bcos_> isaacwoods: Probably something like "frequency triggered = amplitude"
07:20:37 <bcos_> Hrm. They eye would have "4*millions" because it's directional (4*number of directions, sort of)
07:20:55 * bcos_ wonders if smell happens in stereo
07:21:05 <bcos_> ..might need 10 wires
07:24:25 <chrisf> you're still radically underestimating the dimensionality of this thing.
07:26:28 <bcos_> Am I? Sight = 3 dimensions, taste = 5 dimensions, balance = 3 dimensions, hearing = 2 dimensions, and somehow you think smell is 100 dimensions?
07:29:02 <isaacwoods> apparently each optic nerve can have up to 1.7 million axons to the brain - I don't get the 3 dimensions thing
07:29:32 <bcos_> Without directionality "sight" just becomes "colour"
07:29:53 <bcos_> colour = 3 dimensions (e.g. "red, green, blue")
07:30:16 <isaacwoods> true, but that information alone doesn't make up sight
07:30:19 <isaacwoods> you have rods
07:30:31 <isaacwoods> and then placement of cells, which the brain knows about because all the axons
07:33:01 <bcos_> Again, the 4th signal (from the rods) is irrelevant in normal conditions (only used for low light/darkness)
07:38:16 * bcos_ should do some science - e.g. mix sugar, vinager and rose petals in boiling water, and see if you can tell the difference between that and the smell of fruit
07:38:53 <bcos_> (e.g. oranges)
07:42:24 <mrvn> bcos_: balance is more like 12
07:42:52 <mrvn> bcos_: If not 18. Linear and angular position, velocity and acceleration
07:43:24 <bcos_> ?
07:43:51 <bcos_> velocity and acceleration can be detemined by the "rate of change in signal over time" and doesn't need any wires of its own
07:44:10 <bcos_> Wait.. not velocity. Humans can't sense that at all
07:44:39 <mrvn> bcos_: what about wind?
07:44:54 <bcos_> That'd be sense of touch, not sense of balance
07:45:05 <mrvn> it's used by balance too
07:45:36 <bcos_> ?
07:46:07 <mrvn> at least I believe that you lean into wind explicitly and not just implicitly.
07:46:57 <mrvn> well, only way to tell would be to trigger the touch sensors like there is wind without there being any. Would you still lean into it?
07:47:34 <bcos_> Easier is to stop being naked..
07:48:17 <bcos_> (do people who wear full wet-suits for diving fall over in the wind?)
07:48:54 <mrvn> bcos_: I don't believe the touch sensor is the only feedback that makes you lean into the wind. Just a shortcut to react faster.
07:49:29 <bcos_> I think "sense of balance" is misnamed and should be called "sense of gravity"
07:49:52 <mrvn> sense of acceleration or sense of force. Doesdn't have to be gravity.
07:50:04 <bcos_> (it tells you which direction is "down", and your brain makes adjustments to maintain balance)
07:50:27 <bcos_> Hrm
07:50:59 <mrvn> The acceleration sensors in your ear play a major part though. Just look how confused astronauts get when it cuts out in space.
07:51:03 <bcos_> it tells you which direction is "down", and your brain combines that with lots of other input (sight, touch, ...) and makes adjustments (of muscles) to maintain balance
07:56:14 <rakesh4545> Hello.
07:56:26 <rain1> hey
08:01:53 <rakesh4545> Hello rain1.
08:04:55 <mrvn> anyone know if clang can produce PC relative code?
08:06:31 <rakesh4545> I need some links explaining about drivers. How they are built. The generic ones esp.
08:07:06 <mrvn> That's so huge a topic to be meaningless. It's mostly a design decision on your part.
08:09:13 <bcos_> rakesh4545: A driver is glue between the (hardware) interface that the device provides and the (software) interface/abstraction that the OS wants. How the glue works depends on what it's glueing (what the interfaces on both sides are)
08:09:53 <mischief> an array of structs with function pointers is a good start, or some variation of that
08:11:49 <mrvn> yeah, most people use inheritance and virtual functions for drivers. In C that means a struct with function pointers. The drivers fills out the struct and registers the struct with the generic drivers interface.
08:13:19 <mrvn> You have a tiny struct Driver, then a struct BlockDevice { struct Driver driver; other functions; }, struct SATABlockDevice { struct BlockDevice block_device; even more other functions; } and so on.
08:15:39 <pZombie> hello friends
08:15:43 <rakesh4545> So is there some standard used. Because windows or linux knows how to display things no matter what the hardware is. It does the same thing on ur pc what it does on mine.
08:17:12 <bcos_> For graphics; boot loader can (should) set up a generic framebuffer (using VBE on BIOS or UGA/GOP on UEFI), and OS can use that as "no driver fall back"
08:18:01 <pZombie> Given a GPU that can render 100 frames per second in a game. A cable connection from the GPU to the Monitor which allows for 100 frames per second to be passed through and a 100hz monitor. Our game just started and renders the first frame in 10ms on the GPU....
08:18:01 <mrvn> rakesh4545: that's a design decision. Linux has a device abstraction that is a TTY. Anything that's a TTY can display text and read input. It has things like a width and height and such. All the drivers for hardware that display text (including serial ports or ethernet console) register as a TTY device.
08:18:01 <bcos_> ..which means, it can draw stuff but can't support other stuff (vertical sync, GPU, movie decoder, ...)
08:18:24 <pZombie> How long will it take for the first frame to appear on our monitor screen, assuming negligible pixel response time
08:18:36 <pZombie> ?
08:19:11 <mrvn> pZombie: does the monitor start displaying the pixels as you send them? Or does it write them in a buffer and then displays them when they are all transmitted?
08:19:23 <bcos_> pZombie: If video card send pixels to monitor at a rate of 60 frames per second, then it'd take up to 1/60th of a second for a pixel to actually be visible
08:19:38 <pZombie> bcos - wrong answer i think
08:19:39 <bcos_> (after it's set in display memory)
08:19:40 <mrvn> pZombie: do you use a fixed refresh time or one of the two modes to send a refresh command to the monitor as needed?
08:19:53 <pZombie> mrvn - good question. Are there type of monitors which handle this differently?
08:19:57 <mrvn> pZombie: yes.
08:20:23 <mrvn> pZombie: All TFT monitors nowadays buffer the frame because they support scaling it to the monitor size.
08:20:42 <mrvn> At least I think they buffer it and don't scale it on the fly.
08:21:41 <bcos_> I'd assume they have a "line buffer" (e.g. enough for 1920 pixels if the native resoloution is 1920*1600)
08:21:46 <pZombie> mrvn - Ok, but buffering the frame should not cause any meaningful extra millisecond lag, IF the electronics are very fast at reading the buffer and translating it to pixel changes, no?
08:22:06 <mrvn> pZombie: it means you have to wait for it all to be transmitted before you start displaying it.
08:23:11 <mrvn> if you transmit the frame continiously with 100fps then it takes 1/100th of a second to transmit the frame. Only then it scales and displays it. Or it only buffers a line (or two for interpolating) and then scales and displays that. Thats 1/100/lines
08:23:50 <mrvn> If you transmit the frame faster and pause between frames to get 100fps then the timing changes again.
08:24:06 <pZombie> mrvn - Versus starting to switch the pixels as they are getting in sounds like this would cause a lot of tearing, especially with low HZ displays. Having half the old and half the new frame at the same time on your monitor in a slow update, waiting for all pixels to make it through the cable
08:24:21 <mrvn> DVI, HDMI, DisplayPort have different protocols and speeds for transmission.
08:24:37 <mrvn> pZombie: TFTs don't have HZs.
08:25:36 <pZombie> mrvn - well, their specifications contain HZs, even if they don't. The point is, that you would end up with an image that contains parts of the old frame and the new frame for quite a few milliseconds
08:25:58 <pZombie> vs buffering the image first close to the monitor and then doing a faster almost instant switch if the electronics are speedy enough
08:26:00 <mrvn> pZombie: no. You would simply update the display as pixels come in.
08:26:50 <pZombie> mrvn - that update takes time, as cables have a limited bandwidth, so i don't see how you countered my statement
08:27:18 <mrvn> pZombie: I believe the tearing you see is because the GFX card updates the frame buffer while it also transmits it to the monitor. So you transmit part of the new and part of the old frame buffer.
08:28:13 <pZombie> tearing is when the image on your monitor has pixels of the old frame and new frame mixed up for time intervals which are noticable
08:28:53 <mrvn> pZombie: yes. But the monitor does not receive the image at 100FPS and display it at 200FPS or so. So it never has to display have old and half new.
08:29:26 <pZombie> ok, let me go to extremes to make a point.
08:29:47 <pZombie> Let us assume our cable from the gpu to the monitor can only pass one frame per second through it
08:29:51 <mrvn> pZombie: it can just start upadting the first 100 lines and then pause to wait for more pixels to come in.
08:30:06 <pZombie> and we use the first method, of showing the pixels as they come
08:30:08 <mrvn> pZombie: then the monitor would only update the pixels of the TFT once a second.
08:30:44 <pZombie> it would take a full second to update all pixels. At 0.5 seconds, half of your monitor pixels would be of the old frame and half of the new frame
08:31:10 <mrvn> pZombie: If fully buffered you would see the image blink once a second (because the monitor can update much faster internally). If line buffered you would see the update roll from top to bottom.
08:31:59 <pZombie> whereas if you buffered all pixels first, and given fast electronics, you would never end up with tearing, even with a cable that can only pass through 1 frame per second
08:32:25 <pZombie> but that was not where i was getting at... we got sidetracked a bit
08:32:39 <mrvn> pZombie: In practice you still end up with tearing because the game updates the frame buffer mid send in the gfx card.
08:33:16 <pZombie> back to the initial setup. GPU computing 100 fps, monitor at 100hz and cable that has a 100fps bandwidth capability
08:33:53 <mrvn> pZombie: then the delay is between 1/100+s and <length of cable in foot>ns.
08:34:46 <pZombie> game starts, computes the first frame. It takes 10ms. The frame is stored on the GPU ram. Now i have to send it through the cable. It will take 10ms to get through it. So the frame should appear at my monitor FULLY in 20ms at best, given fast electronics and negligible pixel response time, correct or wrong?
08:35:06 <pZombie> actually i think that is wrong
08:35:24 <pZombie> it will take 30ms total, if cables can be thought of as water pipes
08:35:37 <pZombie> but i don'T really know
08:35:48 <mrvn> pZombie: as said, depends on the buffering. The line buffering bcos_ suggested would have less delay.
08:36:27 <mrvn> pZombie: also how fast can the monitor update all the cells in the TFT once it has data to display.
08:36:57 <bcos_> With no buffering at all, monitor displays pixels as soon as they're received, so "top left" pixel would be visible almost instantly and "bottom right" pixel will take ~1/100th of a second to be visible
08:37:00 <mrvn> Could be: 10ms render, 10ms transmit to monitor, 10ms transmit to pixels.
08:37:06 <pZombie> mrvn - we assume the monitor can do that instantly for the argument's sake
08:37:40 <pZombie> as i see it, 10ms render, 10ms to fill the pipe(cable), 10ms for all to exit the pipe - 30ms
08:37:51 <mrvn> pZombie: the pipe isn't 10ms long.
08:38:21 <mrvn> pZombie: electrons in a wire move at 1 foot / ns.
08:38:24 <pZombie> the bandwidth limit makes it 10ms long for a frame to pass through it fully is my understanding
08:38:46 <aalm> ugh
08:38:49 <mrvn> pZombie: that's the "10ms to fill the pipe"
08:38:54 <bcos_> 10 ms to render, up to 10 ms doing nothing waiting for vertical sync, 10 ms to send to monitor and have it displayed/visible
08:39:18 <mrvn> pZombie: it exits the pipe as soon as you send basically.
08:39:21 <pZombie> vsync is off
08:39:51 <pZombie> mrvn - that makes no sense (to me)
08:40:06 <mrvn> pZombie: vsync is never off unless you use one of the two variable update protocols.
08:40:17 <pZombie> if pixels send through the pipe would exit on the other side almost instantaneously, then the bandwidth would be almost infinite
08:40:21 <pZombie> sent*
08:40:44 <bcos_> pZombie: You're confusing bandwidth and latency there..
08:40:53 <pZombie> i don't think i am
08:40:56 <pZombie> but could be
08:41:30 <mrvn> pZombie: Imagine a road full of cars, bumper to bumper. Now you push in a new car on one end. When will a car come out the other end?
08:41:51 <mrvn> pZombie: when will the car you just pushed in come out the other end if you keep pushing cars?
08:42:37 <pZombie> mrvn - as soon as i push in a new car (new pixel), but that new pixel will take 10ms to come out on the other side as there are pixels in front of it that need to be pushed out first
08:43:04 <pZombie> just because our game renders the first pixel, does not mean the pipe/cable was empty. It contains cars/pixels that need to be pushed out first
08:43:23 <mrvn> pZombie: yeah. And that's not at all how cables work. :)
08:44:05 <mrvn> pZombie: Because what you do is push a trillion cars into the cable for a single pixel.
08:44:46 <mrvn> pZombie: or rather the car you push in doesn't hold the pixel. The fact that you pushed in a car holds the pixel. That a car comes out the other end means there is a pixel.
08:45:12 <mrvn> For a white pixel push in a car, for a black pixel don't push one in.
08:45:36 <aalm> push me a rainbow
08:46:25 <mrvn> pZombie: I would say the time the signal spends in the cable can be ignored.
08:46:42 <pZombie> i was thinking water pipes. Let's say my water pipe system can push 10 liters of water per second from one end to the other. My GPU prepares a new batch of 10 liters it is about to send through the pipe system...
08:46:52 <aalm> mrvn++ waterpipes--
08:47:21 <mrvn> pZombie: but you don't color the water and wait for the water at the output to change color. You send pulses by either adding water or pausing.
08:47:25 <pZombie> in the pipe there are already 10 liters old water that will take a second to exit at the end, while i push in the new water
08:47:44 <pZombie> the new water took 1 second to enter the pipe while the old water was pushed out at 10 liters per second
08:47:58 <pZombie> it will take another second for the new water to exit out
08:48:17 <pZombie> but then again, maybe the analogy of water pipes to cables does not hold
08:48:28 <mrvn> pZombie: what if the water flows at 1/3rd * 300000km/s?
08:48:33 <bcos_> pZombie: Latency of signals through copper is a fraction of the speed of light - maybe 10 nanoseconds for a 2 meter cable
08:48:50 <mrvn> bcos_: afaik it's 1ns per foot.
08:49:30 <bcos_> We have faster light here in southern hemisphere! :-)
08:49:36 <pZombie> 1ns per foot is correct, but if we assumed that all pixels would make it through the cable at 1ns per foot, then you would end up with unlimited bandwidth almost
08:50:05 <mrvn> pZombie: no. because you have to hold the signals for a lot longer than 1ns for the receiver to notice it.
08:50:28 <aalm> no no, let's focus on the cable alone xD
08:50:37 <aalm> *pipe
08:50:57 <mrvn> pZombie: bandwidth vs. latency
08:50:57 <bcos_> The thing is that the speed of the signal through copper is mostly irrelevant - sender and receiver are both too slow to handle that so "pixel clock" is typically MHz rather than THz
08:51:29 <bcos_> ..and for practical purposes you can assume that when sender sends the receiver receives "instantly"
08:51:30 <pZombie> just assume the pixel clock can be infinitely fast, as it only distracts from the point
08:51:31 <aalm> bcos_, are you saying the size of the pipe doesn't matter, if it's copper?
08:51:43 <mrvn> The bigger problem is also signal degradation rather then the time delay for it to come out.
08:52:17 <bcos_> Square waves (digital signals) are awful
08:52:49 <pZombie> focus on why there is a bandwidth limitation for cables, when as you say, all pixels just fly through it at 1/3rd the speed of light?
08:53:22 <mrvn> pZombie: because your sensor is too slow to read THz signals and because a square wave at 1THz would come out as randomg noise.
08:53:28 <beeman> hi
08:53:35 <beeman> bootstrapping/bootstrap is what loads the OS, right?
08:53:47 <beeman> or that's what loading the power up?
08:53:55 <mrvn> beeman: bootloader/bios/EFI is what loads the OS
08:54:00 <beeman> ok thx
08:54:08 <bcos_> pZombie: Let's start from the start - analogue signals, where you have a digital-to-analogue converter on sender that's horrifically slow and (maybe, if not a CRT) an analogue-to-digital converter on the other end that's horrifically slow
08:54:10 <beeman> mrvn: why you put slash? is bootloader and bios the same?
08:54:15 <mrvn> beeman: bootstraping is what the OS does between being loaded and running
08:54:40 <beeman> mrvn: the bootstrapping is inside the OS right? because BIOS can't have it. the bios loads the MBR, righth?
08:54:41 <beeman> right*
08:55:12 <mrvn> beeman: bios is a PC thing. EFI mostly too. ARM for example have some verry trivial code in hardware to load the bootloader. The bootloader then sets up the DRAM for example and loads the OS.
08:55:29 <beeman> you are mixing in a lot of things
08:55:54 <mrvn> beeman: the exact whay some hardware starts up depends on the hardware. So lets start there: What hardware are you interested in?
08:56:41 <beeman> mrvn: what do you mean by that? was just trying to understand bootstrap/bootstrapping term better
08:57:26 <pZombie> bcos_ are you saying that the bandwidth limitations of a cable are due to slow DACs and ADCs?
08:57:30 <mrvn> beeman: well, then bootstraping is the part between the OS being loaded and the OS running.
08:58:28 <beeman> so is boostrapping program inside the OS?
08:58:41 <beeman> you just copy the sentence and paste it again..
08:58:49 <mrvn> beeman: yes, the bootstraping part of the OS is inside the OS.
08:58:55 <pZombie> because if not, i think it is just muddying the waters. Just assume we have extremely fast DACs and ADCs
08:59:17 <bcos_> pZombie: I'm saying that between sender and receiver the cable itself isn't the bottleneck - the problem is that the electronics in the sender and in the receiver need to be able to keep up
08:59:20 <mrvn> pZombie: then the signal will still have limits imposed by physics.
08:59:44 <mrvn> pZombie: you can't make the DACs and ADCs extremly fast. There is a limit on their speed.
08:59:50 <mrvn> (as well)
09:00:30 <pZombie> well, the question was, if DACs and ADCs have anything to do whatsoever with the max potential bandwidth a cable can have
09:00:52 <mrvn> pZombie: do you know this? https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
09:01:28 <mrvn> pZombie: That basically says how fast your DAC/ADC have to be to see the signal.
09:01:32 <pZombie> not really and i doubt i will be able to understand this quickly
09:02:03 <pZombie> then let me ask differently
09:02:22 <aalm> #osdev
09:02:33 <pZombie> given i could get arbitrary fast DACs and ADCs, would then i be able to get arbitrary high bandwidth on any given cable?
09:03:18 <mrvn> pZombie: no. Because of other factors involed. Like noise. At the arbitrary high end you get quantum effects.
09:06:17 <pZombie> i am not sure still if the water pipe analogy does not stand, given bandwidth limitations, be it because of ADCs/DACs and or other factors. So i think it will be 30ms still, from rendering the initial frame to it arriving at the monitor fully.
09:06:28 <mrvn> pZombie: but lets say you could detect a single electron in the cable. Then your latency would still be 1ns/foot and your bandwidth the number of electrons you can push into the cable per second.
09:08:07 <bcos_> pZombie: I think half the problem here is that you're still thinking in terms of "atomic update of entire frame" (when in reality it's a continuous stream of pixels all the way from display memory to user's eyeballs)
09:08:19 <mrvn> pZombie: Lets use a differen analogy. Say you print out the image, put it in a cannon ball and shoot that across. It takes you 1s to print the image and load the cannon. The cannon ball then flies for 0.1s to reach the other side.
09:09:14 <mrvn> pZombie: you only manage 1fps but the cannon ball still only needs 0.1s to fly. The cable adds basically no delay.
09:09:58 <pZombie> bcos_ is it as continuous as you imagine it to be? The GPU first renders the first frame and keeps all the pixels on the RAM. It cannot just render 1 pixel of the first frame and start sending it already through the cable, can it?
09:10:14 <mrvn> pZombie: why not?
09:10:53 <bcos_> pZombie: You render and put it into display memory however you like; but then from display memory to user's eyeballs it's a continuous stream of pixels
09:10:54 <pZombie> mrvn, well, i was asking. Is that how it works? Does the GPU not buffer the first frame fully first before starting to send it?
09:11:04 <mrvn> pZombie: that really depends on what you do
09:11:31 <bcos_> pZombie: Think of a video card as a "while(running) { wait for rising edge of pixel clock(); shove next pixel down the cable() }" loop
09:11:32 <mrvn> pZombie: usualy all the buffering happens in your game.
09:13:47 <bcos_> pZombie: For games; a "right-ish" way (assuming 100 Hz) is to predict what should be visible in 15 ms time, then spend 10 ms rendering it, then send it to monitor so that the first (top left) pixel is seen 5 ms earlier than it should, middle pixel is right on time, and last (bottom right) pixel is seen 5 ms late.
09:14:01 <bcos_> ..of course doing things right is hard so most people just do it wrong
09:14:25 <bcos_> (specifically, they don't predict what should be seen in the future and end up with ~15 ms latency)
09:14:26 <mrvn> pZombie: As bcos says the traditional way for a video card is an endless loop: while(true) { wait_for_vsync(); for(y=0; y<height; y++) { wait_for_hysnc(); for (x=0; x<width; x++) { wait_for_pixel_clock(); send_pixel(x,y); }}}}
09:15:06 <mrvn> bcos_: plus they miss the vsync and the display starts a full 30ms late.
09:15:15 <mrvn> but not every time
09:17:01 <mrvn> pZombie: But as I mentioned there are 2 alternative ways for video cards to work where it's basically: while(true) { wait_for_game_to_send_framebuffer(); send_frame_at_max_speed(); }
09:18:20 <pZombie> is it even possible to render a few pixels of a frame and send them in advance before the rest of the frame is finished, when considering lightning effects and other stuff, where lightning on one part of the frame is dependent on another part?
09:18:33 <mrvn> bcos_: do you know any game that would render the frame in such a way that the top lines are at t=0 and bottom lines at t=30ms?
09:19:22 <mrvn> pZombie: a lot of the time you render a few frames and the composit them together. Only that last stage sends an image.
09:20:00 <mrvn> pZombie: Like you render the 3D landscape, the instruments of your plane and a fixed cockpit frame and then you composite them together to create the image.
09:20:24 <mrvn> pZombie: The composition at the end can render and send each pixel.
09:22:47 <mrvn> pZombie: also note: I don't believe there is a "This is how all cards work in the past, now and forver more."
09:23:35 <AIOP> Does the raspberry pi have a text mode driver?
09:23:41 <pZombie> in my example with the GPU capable of 100 fps, taking 10ms for a frame, how long would that last composition part take in relation to the former parts? I assume a small percentage
09:23:45 <mrvn> AIOP: no.
09:24:17 <mrvn> pZombie: If it's done pixel by pixel then it would take 10ms.
09:24:17 <AIOP> mrvn: do you know the doc I can find the memory address of the vram?
09:24:18 <pZombie> which would mean that you could not start sending pixels until you get to the composition part
09:24:49 <pZombie> mrvn, that makes no sense
09:24:51 <mrvn> AIOP: There is only RAM. The GPU has a mailbox where you can request a framebuffer address.
09:25:22 <mrvn> pZombie: each pixel might take no time at all with tons of pause between but it would generate the pixels at the speed it sends them.
09:25:37 <pZombie> mrvn - first you have to finish rendering the 3d landscape, the instruments, fixed cockpit frame as in your example, before you can start compositing
09:25:40 <AIOP> mrvn: do you have a mwe or something?
09:25:41 <chrisf> 3d workloads typically /do not/ make use of overlay capabilities in the display pipe.
09:25:44 <pZombie> or did i not understand it correctly?
09:25:53 <mrvn> AIOP: google for it. There are tons of examples
09:25:57 <AIOP> ok
09:26:06 <mrvn> pZombie: that's the 10ms your game takes to render the frame.
09:26:41 <bcos_> mrvn: I've thought about doing "one line at a time rendering" (e.g. first line for 15 ms in advance, next line for 15.1 ms in advance, ...) - it becomes extremely expensive due to all the initial stuff (transformations before you can rasterise)
09:26:56 <mrvn> bcos_: yeah.
09:27:05 <pZombie> i give up. Maybe i am too stupid to understand it but i cannot make sense of what you say
09:27:36 <mrvn> pZombie: lets say rendering the 3D landscape takes 1s. So the game renders at 1FPS. But the car would still composite at 100fps to send to the monitor
09:27:44 <mrvn> s/car/card/
09:28:04 <mrvn> pZombie: that's different stages in a sometimes long pipeline of rendering and composition.
09:29:55 <mrvn> pZombie: The delay there would be 1s + 1/100s + 4ns cable + 1/10000s scaling in TFT or something.
09:31:26 <pZombie> i would like to see a visual computer simulation of the whole process, from the 3d landscape, cockpit, instrument etc being rendered, with exact time intervals, to the composited frame making it onto the GPU screen buffer, to the pixels(electrons) moving through the cable , making it to the electronics which then switch the pixels on the monitor
09:31:35 <pZombie> all with exact timings
09:31:38 <mrvn> bcos_: with picture-in-picture features in monitors wouldn't the monitor have to buffer each frame. Or would it update the picture-in-picture at it's own refresh rate in parallel to the full image?
09:32:15 <mrvn> pZombie: then go to e.g. nvidia and get their internal design and algorithms and make such a simulation.
09:32:28 <bcos_> mrvn: Not sure - probably buffers the little picture
09:32:57 <bcos_> (would have to scale that down a lot anyway)
09:33:46 <mrvn> bcos_: which makes me think it simply puts each input signal into a framebuffer and then composits them (+ onscreen menu and such) on the fly.
09:35:06 <mrvn> pZombie: you could make a program that sends rainbow colors to the gfx card and then has an optical sensor to read out the color from the monitor and make a graph of the delay bewteen setting color and it showing up.
09:36:10 <mrvn> pZombie: I bet the results would differ quite a bit from card to card and monitor to monitor.
09:36:58 <pZombie> and i would not really get the data i am looking for as pixel response times are not negligible
09:37:41 <pZombie> also electronics on the monitor are not infinitely fast
09:39:56 <pZombie> what i was interested in is the time it takes, for the first frame of a computer game to arrive at the other end of the cable basically, which then would be displayed instantly on the monitor having ultra fast pixels/electronics
09:52:13 <mrvn> Just had another thought while cooking dinner. Aren't there cards out there that raytrace every pixel on the fly?
09:53:12 <pZombie> to raytrace a pixel, you first need the full image, don't you?
09:54:29 <pZombie> the full "3d image" that is
09:56:03 <pZombie> but i guess that one does not take long. Updating the game state
09:57:48 <mrvn> pZombie: 3D objects and transformations. Can take a lot of CPU to generate those.
09:58:29 <pZombie> usually they don't though. Depends on the game i guess. Updating the game state usually takes a lot less than the actual rendering process
09:59:05 <mrvn> pZombie: the CPU usualy also does some preprocessing. Like eliminating objects that won't be visible.
09:59:47 <mrvn> "If door.is_open() then include door.room_behind_door" kind of things too
10:00:07 <mrvn> uploading textures as needed too
10:09:36 <mrvn> pZombie: If I find some time on monday I might build something for the RPi to take a signal on an GPIO pin, turn the framebuffer black of white, output the signal back on a second GPIO pin and a photo diode to read the signal from a monitor and connect those to a osciloscope.
10:16:28 <pZombie> that would be cool, though i think i was definitely wrong with my water pipe analogy
10:16:55 <AIOP> Thanks mrvn I got a solution up
10:16:56 <pZombie> the only question remaining is if the graphics card would start sending pixels before it completes the whole frame
10:20:38 <pZombie> My final question would have been if there is any latency to be gained, if one was to directly place the GPU next to the monitor electronics and have the monitor pixels/switcher connect straight to the adequate screen buffer address of the GPU
10:21:24 <pZombie> any meaningful latency*
10:26:31 <pZombie> actually, i am not even certain if i was wrong. I think i need a brain re-calibration
10:39:48 <jjuran> To raytrace a single pixel, you must first model the universe.
10:47:22 <pZombie> https://i.imgur.com/DXweX.jpg