<air>
wow, I had my second moderna shot on may 1st, only 36% of the state is fully vaccinated, and all mandates were lifted in early may. it is sad that other places can be slower to receive it but not have as many morons who wont get it
<gog>
i misquoted the stats earlier, iceland is at 177,000 are fully vaccinated, and just shy of 260,000 have had at least one dose
<gog>
of the 295,000 people age 16+ who will be vaccinated
bradd has quit [Ping timeout: 265 seconds]
bradd has joined #osdev
Sos has quit [Quit: Leaving]
isaacwoods has quit [Quit: WeeChat 3.2]
aquijoule_ has joined #osdev
freakazoid333 has joined #osdev
richbridger has quit [Ping timeout: 265 seconds]
chartreuse has joined #osdev
silverwhitefish has quit [Remote host closed the connection]
silverwhitefish has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3-dev]
gog has quit [Ping timeout: 252 seconds]
myon98 has quit [Quit: Bouncer maintainance...]
mctpyt has joined #osdev
mctpyt has quit [Ping timeout: 252 seconds]
sts-q has quit [Ping timeout: 272 seconds]
sts-q has joined #osdev
mctpyt has joined #osdev
mctpyt has quit [Read error: Connection reset by peer]
mctpyt has joined #osdev
chartreuse has quit [Ping timeout: 258 seconds]
chartreuse has joined #osdev
chartreuse has quit [Ping timeout: 244 seconds]
srjek_ has quit [Ping timeout: 250 seconds]
silverwhitefish has quit [Remote host closed the connection]
<bslsk05>
github.com: dgos/kernel/unittest at master · doug65536/dgos · GitHub
<doug16k>
if all tests pass, it does a graceful power off, and qemu exits with 0, if any fail, it does arch_ungraceful_stop() and x86 triple faults it
<doug16k>
and qemu exits nonzero
<doug16k>
but only if a unit test result port is set in boot parameters
<geist>
not too bad
<geist>
sadly the clean shutdown with error is not available on all arches
<doug16k>
there is probably a more universal way, similar to the graceful off
<doug16k>
I noticed that virt has some GPIO for that
<geist>
actually not that i know of. we went through that process at work because we like to do the same thing
<geist>
you can PSCI power off on ARM, but no way to pass some sort of error code through
<doug16k>
can't you hardware reset?
<geist>
PSCI yes
<geist>
but then that's ARM. other arches dont always have something like that
<doug16k>
can you tell other arches "no reset"
<geist>
not that i know of. that has to actually be wired up, and for the most part they arent
<doug16k>
what I am getting at is the guest resetting itself and qemu command line option -no-reset
<geist>
qemu is highly inconsistent between machines
<geist>
yes, i know
<doug16k>
yeah I thought it might be all hardcoded per arch
<geist>
a) not all arches/machine combos i know of actually implement a 'reset'
<geist>
and b) i dunno if the -no-reset really wires through for anything but PC
<geist>
especially since for a lot of arches there's not really a consistent concept of 'reset'
<doug16k>
yeah, but you can always fall back to C64 style "reset": turn it off and on again
<geist>
sure, but qemu hasn't necessarily wird that up
<doug16k>
yeah
<geist>
but more to the point the whole 'pass the error code through' as AFAIK a unique feature to that debug device on PC
<doug16k>
c64 did have a reset in the cartridge port
<geist>
on qemu-emuated-PC that is
<doug16k>
you can do that yourself with a sidechannel
<geist>
oh sure. obviously real machines have reset lines, but the ability to reset something from the cpu and for it to actually be bothered to be wired up in qemu is not consistent
<doug16k>
just send a line to serial and then power off
<geist>
right. so i think we just spent 10 minutes looping around to say 'yeah that's neat but you can't rely on it'
<doug16k>
I could have made it always graceful off and rely solely on the serial
<geist>
and thus, 'need to implement side channel'
<doug16k>
I realized that
<geist>
which is what we do on fuchsia CQ/CI
<doug16k>
I just take advantage of simpler way to just fail or succeed the whole qemu process
<geist>
yep!
<doug16k>
it's a bug that there is no paravirtualized "kill qemu" on every arch
<doug16k>
a guest should be able to say "I am utterly broken, stop running me"
<geist>
yah, kill qemu + error code is the really neat one, but that'll be difficult when it's trying to emulate a specific machine
<geist>
indeed. also the notion of the triple fault like situation like you get on x86 is also not universal
<geist>
many arches, riscs in particular, are designed to have no such invalid state
<doug16k>
x86 actually tells the mainboard when it has triple faulted
<geist>
yah
<geist>
has a 'i fucked up' line
<doug16k>
pretty elaborate
<doug16k>
did you know that it triple faults in real mode if you push with sp < 2?
<doug16k>
I was amazed when I learned that. never noticed
<graphitemaster>
Been doing graphics for years and I only just learnt that AMD binary shaders are just regular ELF32s.
<graphitemaster>
Like, DXBC is stored in the .text section >_>
<geist>
doug16k: huh, just cauyse they didnt' want to deal with wraparound?
<graphitemaster>
This is the first time I've ever actually seen an ELF used for the thing it was designed for :P
<doug16k>
geist, it tries to push the interrupt frame, and it can't do that either, so it tries to push double fault interrupt frame, can't do that either. same reason as in protected mode
<doug16k>
it must push
<graphitemaster>
Because obviously they're used for executable code on POSIX systems, but like, everyone else invents their own format when designing executable code for other platforms. WASM does not use ELF, Java does not use ELF, etc.
<geist>
ah and it's not legal for the SP to wrapa around as it goes below 0?
<doug16k>
yeah sp never wraps around
<doug16k>
at least not on 386+
<doug16k>
286 is probably nitpicky too. no idea what 8086 does
<doug16k>
I don't think a double fault existed in 8086 time
<doug16k>
first fault is stack fault. then double fault, then reset
<doug16k>
stack fault isn't a task gate or IST slotted IDT entry so it keeps using crap sp
<doug16k>
I think it is just not allowed because the segment limit check doesn't make any sense in a wraparound
<doug16k>
I am glad the load/store pipelines don't need to deal with that crap
<doug16k>
what's the highest byte touched in a push to 1? 0 right? so limit check is nonsense
<doug16k>
it would pass the limit test no matter what and would have touched offset 0xffff
<doug16k>
or more f for 32 bit
<doug16k>
I wonder if long mode does it
<doug16k>
there shouldn't even be a limit check of any kind
<doug16k>
if the first 4KB and last 4KB were mapped, it might let a push span it
<doug16k>
hgoel[m], test_set.cc is my best set of tests (tests my AVL tree thoroughly (it's almost 100% std set/map compatible))
<doug16k>
worst thing about implementing BST is, it will seem to be totally fine, when it is catastrophically broken. you must test it
<doug16k>
I had to keep escalating the tests until the point where I implemented next_permutation and try every order
<doug16k>
exhaustive
myon98 has joined #osdev
myon98 has quit [Client Quit]
myon98 has joined #osdev
<doug16k>
8086 only defined up to int 4, 5-31 are all reserved
* doug16k
waves at IBM
<doug16k>
32-255 were available and IBM took 8-15 reserved vectors for PIC
<geist>
yep, someone goofed bigtime
<geist>
notice when the second PIC was added they realized that and mapped them at 0x70 or something out of the way
<geist>
also note the BIOS chewed up vectors from 16-31 as well
<geist>
and DOS, etc
<doug16k>
yeah, the APIC hardware only enforces that hardware sends vector >= 0x10, not >= 0x20
<doug16k>
I always thought that was odd
<geist>
if you look carefully it's obviously not a total disaster that the later vectors that intel added didn't completely collide in terrible ways
<geist>
but you can imagine, for example, that if some memory management thing wanted to trap a #PF it'd have to deal with whatever BIOS vector is at 14
<doug16k>
yeah, you could put the PIC on top of there, if you don't mind spending a bazillion cycles reading the ISR register of PIC to see whether it was an IRQ
<geist>
looks like, uh, serial port services
<geist>
actually yiuo know we were talking the other day about how slow it seems that console bios output is
<geist>
which vector is that?
<doug16k>
0x10 is screen one
<doug16k>
if you mean bios call
<geist>
yes
<geist>
and what cpu vector is 0x10?
<doug16k>
interrupt 0x10
<geist>
math fault?
<doug16k>
oh I see
<geist>
so maybe that's part of why 0x10 bios call is slow, it has to actually do do some nonsense to disambiguate a math fault
<kazinsal>
math I think yeah
<kazinsal>
0x11 is alignment and 0x12 is mce
<doug16k>
0x10 is invalid TSS
<kazinsal>
can't remember what the upper ones are
<geist>
bios 11h and 12h are some little used one
<geist>
'returns equipment list' and 'returns conventional memory size'
<geist>
of course bios vector 13h is annoying, since it lines up with #GP
<geist>
and it's the disk routines
<geist>
anyway, i honestly dunno what the standard technique is inside the bios code to disambiguate it being a real #GP or a bios call
<doug16k>
I just said
<geist>
goes back to reads the PC to see if it's a int instruction?
<doug16k>
you read the ISR register of PIC
<geist>
no #GP.. not interrupt
<doug16k>
oh that
<geist>
interrupt, sure, that's easy
<doug16k>
you don't
<geist>
the higher ones are the ones i'm talking about. 16+
Arthuria has joined #osdev
<geist>
got added later, etc
<doug16k>
you just let it lock up
<geist>
oh wait, i'm off anyway
<doug16k>
yeah, you could check the 2 bytes before the return address and see if it is int opcode
<geist>
thinking decimal vs hex
<geist>
#GP is hex 0xd
<geist>
stuff up above 16 are stuff like math fault, machine check, aligment check, etc
<doug16k>
I fully expect a bios to not care at all if it was GP or something
<geist>
so yeah okay. PF and #GP you'd solve with the PIC read
<geist>
yah a dos program that wanted to catch #GP would probably just temporarily install its own vector or something anyway
Arthuria has quit [Read error: Connection reset by peer]
<geist>
shows the table, and shows the first 5 in use, the next 27 reserved
<doug16k>
if they gave you a whole 64KB IVT with 16384 vectors, would IBM still have used 8-15? :D
<geist>
also of course there's no double fault or anything then, so i guess an 8086 would just go off in the weeds and die
<doug16k>
yeah it probably just wrapped around and put a byte at 0xffff and the upper one at 0
<doug16k>
8086 also had stupid push sp behaviour. it pushed the new sp, not the original sp
<geist>
let see... on the output pins it had a set of pins for status
<geist>
possible it could have had a 'i'm locked up' status that you could build logic for...
<doug16k>
I'm not sure this one did a shutdown cycle. that probably started in 80286
<geist>
yah think so. probably just simple enough that there's no invalid state it can get into
<geist>
no segment faults, no page faults, etc
<geist>
it just keeps going even if it's completely messed up
<geist>
oh interesting, this manual is talking about the 8288 Bus Controller
<doug16k>
yeah. back then they just locked up
<doug16k>
presumably stuck in some hopeless loop in weeds
<geist>
seems that you can strap a pin on the 8086 and it siwtches some of the usual SRAM style control lines (RD/WR/etc) to an alternate set of control pins
<geist>
to talk to the 8288 which then drives your bus (and presumably does more)
<geist>
they call it Maximum Mode
<doug16k>
yeah I am looking at the instruction queue status thing
<geist>
you strap the MN/MX pin to select that
<doug16k>
I guess they knew it would starve for instructions and gave way to measure how bad in hardware
<geist>
yah when in max mode it uses S0-S2 pins to tell the extneral controller what it's up to
<geist>
makes sense. 8 states
<geist>
one of them *is* halt. but probably HLT if that was implemented back then
<doug16k>
ah! the thing I am reading is for the coprocessor opcodes
<geist>
oh the coprocessor interface is really neat. i remember staring at that a few years ago
<geist>
it's 'neat' in a terrible way, but neat anyway
<geist>
like not particularly elegant at all, but gets the job done
<doug16k>
yeah hlt was always there
<doug16k>
amazes me that they made it asynchronous
<doug16k>
you could actually schedule the fpu ops into the integer stuff and it would overlap
<geist>
yah
<doug16k>
is kvm gdb utterly broken now?
<doug16k>
I can hit the first breakpoint, but continue or step from there kills it
<doug16k>
the guest resets and you stop at reset entry point in gdb
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
<doug16k>
I also noticed that gcc O2 generates some really dumb stuff sometimes, but -O never does
<doug16k>
-O does what you said
<doug16k>
gcc is still moronic about mixing integer and float sse/avx operations
<doug16k>
in 11.1
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
<doug16k>
it will movdqa then next istruction store it with movaps, adding a cycle of latency for nothing
<doug16k>
oh get this: if you make a 512 bit vector with gcc's generic vector type thing, and use that on a maching with avx, the compiler uses 128 bit instructions
<doug16k>
totally moronic
Arthuria has quit [Read error: Connection reset by peer]
<doug16k>
it'll do 4 128 bit things
Arthuria has joined #osdev
<doug16k>
even on znver2
<kazinsal>
probably just trying to play it super safe
<doug16k>
I guess if they keep it from going berserk with hundreds of shuffles, they consider it working as intended
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
<kazinsal>
what with the whole thing where as soon as an avx instruction enters the pipeline your clocks get binned down a step or two so your 105 W TDP CPU doesn't temporarily become a 150 W TDP CPU
<doug16k>
if you use 256 bit vectors it uses avx
<kazinsal>
(and only becomes a 125 W TDP CPU instead)
<doug16k>
512 bit vector and it uses sse
<doug16k>
intel ya
<doug16k>
my cpu boosts just as much in prime95 as any other time
<doug16k>
that is hammering back to back mad
<doug16k>
er, fma
<doug16k>
will be interesting to see, if zen4 has avx512, whether amd does the downclock
<doug16k>
I get about 4.3GHz in prime95, 3.5GHz base
<doug16k>
when it gets to the insane ones that hit cache 100% it pulls it down to maybe 4.0
<doug16k>
I have a B+ tree implementation that is a power virus. if you insert 1M rec/sec on all cpus it is worse than prime95
<doug16k>
it's very branch free. it saturates the hell out of it
<doug16k>
being really hard on memory is worse for power than vectors
<doug16k>
the cache almost always works amazing, so it usually isn't using a lot
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
<doug16k>
as long as you are just hard enough on memory to saturate it, but not so hard on it that you stall waiting for it often
<doug16k>
basically keeping up with prefetcher so it never stops doing memory bursts
<doug16k>
in normal programs, there is a burst of misses, then insane numbers of hits between messes
<doug16k>
it'll be all lopsided too. most code almost never misses, and a small amount of code misses almost every time
<moon-child>
or if you are missing a ton, probably super efficient because you spend all your time waiting
<doug16k>
yeah if you miss bad to back you are almost idling
<doug16k>
long runs of code without mispredict will saturate it pretty hard
<doug16k>
you might get far enough ahead to always be able to dispatch something
<moon-child>
you know what would be cool? Speculative prefetch
<doug16k>
it does already. prefetch queue right? they always had that
<moon-child>
cpu looks 100-1000 instructions ahead. Doesn't actually try to execute it, just looks for memory accesses (and maybe ret/jmp) and prefetch them
<doug16k>
now it is smart as hell, it knows which way to go
<doug16k>
my hero, professor mutlu is one of the authors
<doug16k>
afaik he deserves a lot of the credit
<doug16k>
in a lecture he said that both the simple way that discards the results, and the complex way that tries to keep the runahead results, have been implemented
<doug16k>
I guess some dependency chains can be tainted as guesses and aren't eligible to be kept
<klange>
< graphitemaster> He's gonna violate some patents! ← The only relevant patents are on subpixel antialiasing, which I despise! And the last ones expired not too long ago.
<klange>
I can say that one of my actual career accomplishments was contributing to the elimination of subpixel antialiasing in macOS.
<klange>
I was actually told by my internship supervisor at Apple in 2011 that the key reason we were pushing for high-DPI displays on desktops was to get rid of subpixel anti-aliasing for text, and while it took nearly a decade to actually deliver on that promise, it did eventually happen.
<doug16k>
subpixel is such a hack
<moon-child>
eh, pixels are a hack. They work pretty well though :)
<klange>
I will admit it's a hack that makes a lot of sense and worked really well in isolation, but we're beyond it.
<graphitemaster>
Sort of beyond it for fonts, but not anything else.
<doug16k>
it does create weird color artifacts
<moon-child>
but yeah, subpixels should die. Regular antialiasing is cool though
<graphitemaster>
Subpixel AA /w jitters really important to deal with aliasing in games :(
<doug16k>
I mean the cheat where you use the separate rgb pixels within one pixel to get more pixels
<moon-child>
yeah, I don't think any game uses subpixel aa
<moon-child>
too expensive, and it would mess up their colours anyway
<graphitemaster>
Every temporal AA algorithm is a subpixel AA.
<graphitemaster>
You jitter the frames by half a pixel each frame to collect subpixel details
<graphitemaster>
It's one of the reasons all TAA impls have massive ghosting.
<graphitemaster>
Which is why you need reproject.
<moon-child>
oh, heh
<doug16k>
what's TAA?
GeDaMo has joined #osdev
<graphitemaster>
temporal anti-aliasing, also, MSAA buffers assign multiple samples per pixel and your resolve pass is meant to consider subpixels.
<klange>
I have literally never seen subpixel AA in a game, but then I also play a lot of Nintendo shit and they have a tendency to not do AA _at all_.
<klange>
Subixel anti-aliasing doesn't make a lot of sense in color graphics at all? Like the whole idea is to ignore the fact that subpixels are made of red/green/blue and just pretend they're made of _bright_.
<klange>
And even LCD TVs have wacky unpredictable subpixel layouts.
<doug16k>
so even if the person had subpixel stuff off, because their display is 4k or something, it stil does it?
<moon-child>
oh, I see. TAA blends two adjacent pixels, it doesn't actually shift the components?
<moon-child>
like you wouldn't shift the r component into the g component
<graphitemaster>
Note that subpixel AA in the game case does not mean the contents are rendered to (ab)use subpixel rendering of the display, it just means contents that have subpixel details are articially made to be a whole pixel over multiple frames so that the AA can pick them up and clean them up
<klange>
But that's the only thing "subpixel" means?
<klange>
Pretending a pixel is made of multiple pixels is _supersampling_.
Arthuria has quit [Read error: Connection reset by peer]
<bslsk05>
en.wikipedia.org: Subpixel rendering - Wikipedia
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
<doug16k>
subpixel rendering can also mean that your screen coordinates aren't truncated to integers, in some contexts
fconti has quit [Remote host closed the connection]
fconti has joined #osdev
<graphitemaster>
It's all quite complicated, there's like 100 different ways to get more samples, either accumulating it over frames (temporal), using multi-sample buffers (still the same # of pixels but the edges of geometry get assigned more samples, this is uses less memory than ...), actual super sampling (using a larger output pixel buffer, then downsampling it to display it), the problem with almost all of them is actual small subpixel detailed stuff
<graphitemaster>
(like the edge of geometry lands on a subpixel) is rarely picked up (or often lost), e.g a wire fence or the wires of a telephone pole under perspective far away, so subpixel AAs are meant to actually reconstruct the edge of subpixel details by finding clever ways to get more samples to anti-alias it.
<graphitemaster>
And they also try to preserve subpixel details where it's already the case, by being applied as subpixel passes.
<graphitemaster>
Which means applying it slightly off (literally the SMAA pass runs 0.5 over to the right and up on even frames, and down -0.4 to the left on odd frames)
Burgundy has joined #osdev
<graphitemaster>
s/0.4/0.5
<graphitemaster>
MSAA 2x, 4x, 8x, etc, are all becoming less useful these days because most aliasing is not caused by geometry anymore, it's caused by textures and shaders. And with stuff like micropoly (see UE5's Nanite), every triangle is a pixel, at that detail scale, MSAA is effectively useless because that's just not how those buffers are designed to be used.
<klange>
The technique used in MSAA is called _multisampling_ and it's literally right there in the name.
<graphitemaster>
Yes, I'm pointing out how MSAA is not used anymore.
<klange>
And its replacement is full-scene supersampling...
<doug16k>
to me, AA is the thing I crank up to see if I can get it to have a bad framerate on purpose\
<klange>
None of these approaches involve display subpixels, I'm not even sure why you're going on about them.
<klange>
Anyway, I just want to draw some damn glyphs, so back to work with me. I spent the day doing other things... like sleeping until 1pm for some reason.
<graphitemaster>
It's because you're conflating subpixel rendering with subpixel anti-aliasing, and they're orthogonal.
<graphitemaster>
Rendering subpixel correct glyphs avoids the aliasing completely.
<graphitemaster>
But if you've already rendered a mess of aliased shit and just want a pass to go over it to fix it, that's at least in the graphics circles I'm in, called subpixel anti-aliasing.
<graphitemaster>
Specifically if the aliasing is caused by subpixels itself.
<graphitemaster>
So subpixel details.
<doug16k>
this reminds me of OpenTyrian. I profiled it and it spends about 98.5% of cpu time in the upscaler
<bslsk05>
github.com: opentyrian/video_scale_hqNx.c at master · opentyrian/opentyrian · GitHub
f11 has joined #osdev
<moon-child>
eh, for some definition of good
<doug16k>
yeah, compared to the obvious big squares the pixels would be
<doug16k>
it doesn't do the weird stuff that some blending based ones often do
<doug16k>
tyrian is actually really fun
<doug16k>
it's one of the ones where you get unreasonably good weapons, but so much stuff coming at you, it is hardly enough
<moon-child>
yeah, nearest-neighbor upscaling for pixelart is just a travesty
<moon-child>
ftl does it and--ugh
sortie has quit [Ping timeout: 268 seconds]
sortie has joined #osdev
<FireFly>
I prefer the blocky look of nearest-neighbour at integer multiples (so not really "nearest neighbour" as much as representing a pixel by a 2x2 or 3x3 or whatever block) over blurry bilinear interpolation any day at least
<pony>
I remember tyrian :)
<pony>
haven't tried opentyrian yet
netbsduser` has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
bonafideosdever has joined #osdev
sortie has quit [Ping timeout: 268 seconds]
bonafideosdever has quit [Client Quit]
bonafideosdever has joined #osdev
<bonafideosdever>
Jak sie masz. I am wondering how the people of #osdev are structuring their kernel memory allocation subsystems. I describe my!
mctpyt has quit [Ping timeout: 252 seconds]
<bonafideosdever>
I have linked list of bitmaps of physical memories space. There is fanction to allocate memory from these if given size, and the function returns physical address of start and end region. This is lowest layer.
<bonafideosdever>
Next layer up. I have the basic allocator of kernel space. It ask for physical region from physical allocator, and then finds a good place in the kernel virtual memory space to allocating that memory. It only deal in 1page-or-greater sized allocations
<bonafideosdever>
That we can call "Layer 2" memory management. Then there are several "Layer 3" memory managers which are each clients of layer 2, asking for big blocks of memory from the basic allocator.. There a SLaB allocator which implements the algorithm described by Bonvik in his book, which is a famous book of OS theory in my country. That allocator is used for the most things. There is a dlmalloc also.
<klange>
Dzień dobry!
<bonafideosdever>
I must declare that layer 2 can also be GIVEN a physical region, which it is then asked to map into the kernel virtual memory space. So you see,, there is one single "point of entry" by which all mappings of physical regions into the virtual address space of kernel happen.
<Griwes>
klange: I have not looked up before seeing your message, and you really startled me with that :V
<bonafideosdever>
I derive my architecture from a study of the Unix operating system (both the System and the BSD versions: Solaris and FreeBSD). I do not try to make the best system ever conceived, but I will that my system is wise in architecture enough that the systems architect of the 1980s would respect it. Is my memory management systems respectable?
<klange>
which i traced from the image in the window behind it
<klange>
now to add some grayscale antialiasing, then write a curve tesselator, then clean all of that up for a general polygon drawing API... then I can start parsing some ttfs, ay?
Arthuria has quit [Ping timeout: 250 seconds]
ElectronApps has joined #osdev
bonafideosdever has quit [Quit: CGI:IRC]
tacco has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
mahmutov has quit [Ping timeout: 250 seconds]
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
netbsduser` has quit [Ping timeout: 252 seconds]
gog has joined #osdev
mahmutov has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
vdamewood has joined #osdev
netbsduser` has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3-dev]
pretty_dumm_guy has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
<sortie>
klange: Awesome! Now add some texture support
<sortie>
Badabing badadoom
<sortie>
Wobbly windows
<sortie>
I would love to read some good tutorial on rasterization with textures and transformations
<klange>
curve tesselation tomorrow, and hopefully a start on ttf parsing... but for now, it's 11:30pm
<sortie>
Thinking about antialiasing?
<sortie>
GeDaMo: Damn that second demo is impressive
<klange>
Anti-aliasing is a definite requirement for anything I build here, especially when text rendering is the target.
<GeDaMo>
What, the ray tracing on a business card? Yeah
<clever>
klange: my rough understanding of AA, is to just render at 2x the normal res then blend each 2x2 pixel block back down to 1 pixel, is that right?
<NieDzejkob>
that's one of the ways to do it
<clever>
the texture lookup unit on the RPI's gpu, does something else, for zoom and mis-alignment of textures
<clever>
basically, when doing a lookup into a texture, the XY coords can be a float, and it will do a weighted average of 4 pixels in a 2x2 grouping, based on the sub-pixel half of the float
Arthuria has quit [Read error: Connection reset by peer]
<clever>
but that trick, doesnt work at the edge of a poly, where AA would smooth things out better
Arthuria has joined #osdev
gmacd has quit [Read error: Connection reset by peer]
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
Mikaku has quit [Quit: server maintenance ...]
scaleww has quit [Quit: Leaving]
Mikaku has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
heat has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
srjek_ has joined #osdev
IRCMonkey has joined #osdev
heat has quit [Remote host closed the connection]
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
IRCMonkey has quit [Quit: . o O (bbl tc folks~!)]
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 258 seconds]
rdr has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
isaacwoods has joined #osdev
solar_sea has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #osdev
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
Oli has quit [Ping timeout: 265 seconds]
Oli has joined #osdev
tenshi has quit [Quit: WeeChat 3.2]
gmacd has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dennis95 has quit [Quit: Leaving]
gmacd has quit [Read error: Connection reset by peer]
mctpyt has joined #osdev
f11 has quit [Ping timeout: 250 seconds]
f11 has joined #osdev
<geist>
huh. the business card raytracer is neat
<geist>
also didn't know about pp
<geist>
ppm
Arthuria has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
Oli has quit [Read error: Connection reset by peer]
f11 has quit [Quit: WeeChat 3.2]
johnjay has quit [Ping timeout: 258 seconds]
vdamewood has joined #osdev
johnjay has joined #osdev
Arthuria has quit [Ping timeout: 265 seconds]
<geist>
huh randomly decided to look into what the Su Type 5 keyboard protocol was (looks like a mini din, but is different from PC and apple ADB)
<geist>
turns out it's super dumb: 1200 baud TTL serial
<geist>
make/break codes and an extremely simple handful of one byte commands to send it to set its state
<geist>
s/Su/Sun
<clever>
i think thats the one that has a 2nd serial line for the mouse?
<clever>
and the keyboard is just passing the mouse serial and power clean thru
<geist>
yah one of the pins seems to be dedicated to the mouse. though it appears to be a single line, so that must e some other protocol
<clever>
i think its also serial, but a second bus
<clever>
the keyboard then just passes it clean thru to the mouse port on the underside
<clever>
so you dont have to deal with 2 long cables like ps2
<geist>
it must not be exactly the same because it's a single line
<geist>
whereas the keyboard stuff is a TX and RX
<clever>
the keyboard cable carries the mouse to the desk, so the mouse can use a shorter wire
<clever>
yeah, i think the keyboard rx/tx are keystrokes and led control, while mouse-tx is movement and zero control
<geist>
i long since tossed my sun type 5, but i do have a USB sun type 6 i think? i use it every once in a while ironically but it's really not that good
<clever>
i have 2 usb sun keyboards
<clever>
the a/w keys got mushy on the 1st one, so i swapped to the 2nd, but its caplock led is dim
<geist>
yah and they so huge. lots of excees space
<geist>
but... where else are you gonna get the blank key right?
<clever>
ive found the extra keys to various things
<clever>
the again key, pulls up the run dialog in xfce
<clever>
who needs modifiers, when you have a whole bank of keys nobody else has eaten in various hotkeys
<bslsk05>
en.wikipedia.org: Space-cadet keyboard - Wikipedia
<gog>
ahhh ok
netbsduser` has joined #osdev
rdr has quit [Quit: rdr]
<geist>
clever: but yeah that usb one is unnecessarily mushy
<geist>
from about 2000, i think i got it with my blade 100 that i bought about then
<clever>
geist: it was better, but the heavily used keys get mushy with age
<clever>
i think i need to swap some rubber domes around
<geist>
which i long since got rid of, though i've been using the mouse pad that came with it for like 20 years. literally right here next to my laptop
<clever>
i'm also using the internal usb hub for my yubikey
<geist>
oh wow so you're actively typing on it?
<clever>
yep
<geist>
daaaaang
<clever>
let me snap a photo...
<GeDaMo>
I bought the keyboard I'm typing on in 1992 :P