|
Truga posted:i think it's worth pointing out that the last 2 generations of nvidia, all the consumer gpus actually don't have double precision hardware and whatnot, to be able to cram more frames into less die size/power. amd is not doing this, probably because they can't afford to design what is basically two archs, and the difference in power draw in games for similar cards can be up to like 30%. nah amd haven't had proper double precision for a while either. hawaii was their last arch with 1/2 fp64, everything since then is 1/16 even on the pro versions. vega20 is supposed to be 1/2 though
|
#
?
Oct 7, 2017 20:52
|
|
|
|
| # ? Apr 27, 2024 04:42 |
|
|
blowfish posted:People who want to miniaturise hand soldered parts (ie three dozen hobbyists)? you can hand-solder surface mount parts, it looks really hard but once you do it a few times it's actually pretty easy 
|
|
#
?
Oct 7, 2017 21:53
|
|
|
ate all the Oreos posted:you can hand-solder surface mount parts, it looks really hard but once you do it a few times it's actually pretty easy i learned over the summer on some tricolor leds and yeah it's not too bad
|
|
#
?
Oct 7, 2017 21:58
|
|
|
ate all the Oreos posted:you can hand-solder surface mount parts, it looks really hard but once you do it a few times it's actually pretty easy  but you can't put them on standard stripboard easily
|
|
#
?
Oct 8, 2017 01:40
|
|
I CANNOT EJACULATE WITHOUT SEEING NATIVE AMERICANS BRUTALISED!
|
ate all the Oreos posted:you can hand-solder surface mount parts, it looks really hard but once you do it a few times it's actually pretty easy agreed but qfn can gently caress right off
|
|
#
?
Oct 9, 2017 00:13
|
|
|
get back to me when you can hand solder bga, blind folded, with no reflow oven upside down
|
|
#
?
Oct 9, 2017 20:55
|
|
|
the answer is always "use more flux" unless its one of those packages where the pads are under the component. that poo poo can gently caress right off
|
|
#
?
Oct 9, 2017 20:58
|
|
|
NEED MORE MILK posted:the answer is always "use more flux" thats qfns you can make qfns work jankily if you modify your board patterns to provide lil landing spots for an iron from the side but lol @ thermal pads on the bottom and double lol @ bgas
|
|
#
?
Oct 9, 2017 21:10
|
|
|
QFNs aren't as bad as BGAs for manual soldering at least, small packages with low layer count boards are fairly feasible to solder with a hot air gun for 8 pin DFNs I've sometimes just put down a big blob of solder and pressed the part down onto the pads after melting it with hot air. with enough flux and precise solder mask the extra solder pops out like a little bubble that can be cleaned up with tweezers. it's me, the idiot that's too cheap to buy stencils
|
|
#
?
Oct 9, 2017 22:27
|
|
|
i have nothing to contribute to this thread despite spending a good chunk of my time writing gpu code because i am garbage, but i wanted to say i appreciate this thread regardless ok back to the shader hellmines for me
|
|
#
?
Oct 10, 2017 02:54
|
|
|
hi. let's talk about gpu's. today i want to talk about what's easily one of the hardest open research problems in graphics: 2d graphics. that might seem like a strange idea: gpu's can already crunch through 3d graphics, so why is the extra dimension super hard? the answer is because here's what a circle looks like in 3d  and here's what a circle looks like in 2d  when you have lots of camera angles and shifting perspectives and fancy shots in motion and fancy motion blur, the limitations of 3d and the polygons can be forgiven. when you have text on a screen that needs to be perfectly rendered to the point of using the subpixels so you exploit all of the space you can out of your low-dpi lovely monitor, that stays constant on a screen, can't jitter due to scrolling or when zooming in by dragging your grubby fingers, you need perfection. and this comes down to the heart of the matter. gpu's crave triangles. they excel when given a ton of triangles stacked on top of each other with some dirt and rock textures. in 3d the problem space is complicated enough so we train artists for years in Maya asking them to make their stuff as triangles and subdivide stuff into triangles and UV wrap in triangles. but anybody and their mother can go to a piece of paper and draw a circle, so they need to be able to go to a line of code and drawCircle(), so we can't really ask them to triangle up their circle. and that sucks. the tool of the 2d trade is the bezier curve, and one that we can't ask people to give up without much of a fight. here's what the state of the 2d art looks like in 2017: * make it all in photoshop and put it in the game as textures. this is what 50% of games do. * gently caress you, make your poo poo out of triangles. a lot of fancy games now just do their ui in triangles. they make it all in 3d because it looks prettier. this is what the other 50% of games do. ok, wait, you actually need to render poo poo in 2d??? are you implementing a web browser or 2d ui library? god bless your soul, let's talk about actual approaches: * do all the hard 2d rendering on the cpu anyway and upload to the gpu as a texture. this is basically used for a lot of renderers, as soon as poo poo gets rough they fall back to the cpu. guess how fonts work???? literally everyone just jams in freetype rendering to a font atlas and presses play. * but you want gpu, right? so you try valve's sdf trick which everybody and their mother knows by heart these days. it requires a slow brute force search on the cpu (doesn't stop google from doing it in chrome) and heavily distorts the shape since merging both x and y distance into one field makes sharp angles into circles, but valve didn't care since tf2 was particularly cartoon-y and it fit their artstyle. * ok, let's try something a bit more low-tech. we can do the typical red book stencil trick. the idea is that you draw to a 1-bit buffer which flips bits whenever you draw to it, basically emulating the winding buffer. on top of that you usually add in loop-blinn for curves. the big issue with this approach is twofold: 1. the stencil trick is really bad in practice, and since you can't save the stencil buffer to a texture and load it back in for unknown reasons, you basically have to repeat that every time you want to draw the shape. it ends up being a huge pain. it also knocks out what's known as "early z", which is writing to the depth buffer based on the triangle rather than the computed shape past pixel processing. this means it really only works well for fonts, because they don't have a lot of overlapping paths and shapes. if you have a real fancy 2d svg image with strokes and styles and a lot of different stuff going on, you're going to have pixels drawing over each other, meaning you have "wasted pixels" -- this is overdraw, which is expensive. * compute the actual bezier on the gphahahahahahahaha oh man, don't do this. i mean, you can do this -- instead of doing triangulation / loop-blinn or stencil / loop-blinn as above, you just draw a rectangle ("quad") and figure out a way to sneak the path data onto the gpu. unfortunately, cubic beziers are cubic which mean they have three roots and that's just fun to make numerically stable while the user is slamming their greasy chubs scrolling through the page. you can get clever, approximate the cubic bezier with a quadratic bezier, but you still have some instability, so you throw the Citarduq Formula at it. but it's still slow because these roots are stable per scanline but you're computing them per pixel -- per 2x2 pixel, in fact. so you throw in a compute shader to compute the roots per scanline and now you have a ton of latency because starting up a compute pipeline is fast but boy does it take a lot of time to warm up. * let's try something else. if quadratic beziers are still too complicated, then url=https://github.com/behdad/glyphy]glyphy[/url] which tries to reduce bezier curves to arc segments, something a lot easier to math out. or slug which applies a dumb math trick known as "counting" to fix the issue of bezier intersections per-pixel. but as above, this doesn't support early z. and you still have the problem of just doing too much work per-pixel. * say gently caress it and just turn the 2d shapes into a lot of tiny triangles. there are a lot of approaches to this problem, and it's very much open research. Constrained Delaunay, ear clipping, trapezoidization wrt. Lorenzetto et al. despite being cpu-intensive, this is the most practical and best way to handle large shapes. oh, and now that you've solved curves, you realize that everybody also uses alpha anyway and gpu's are bad at overdraw and alpha in general, so the whole idea was worthless to begin with...
|
|
#
?
Oct 18, 2017 09:20
|
|
|
i dont understand but I do appreciate
|
|
#
?
Oct 18, 2017 09:26
|
|
|
gpu facts - my r7 290 is no longer supported in belnder open cl so now I have no gpu pathways in cucles at all now I render everything by cpu whoares
|
|
#
?
Oct 18, 2017 09:27
|
|
|
Suspicious Dish posted:* but you want gpu, right? so you try valve's sdf trick which everybody and their mother knows by heart these days. it requires a slow brute force search on the cpu (doesn't stop google from doing it in chrome) and heavily distorts the shape since merging both x and y distance into one field makes sharp angles into circles, but valve didn't care since tf2 was particularly cartoon-y and it fit their artstyle. (edit: to explain what is talked about without forcing everyone in the thread to read the paper: what valve does is get sharp-edged 1-bit textures by actually computing a low-resolution 8-bit texture where the texels are the *distance* to the true shape, such that the value 127 is on the edge of the shape, 126 is next to the edge on the outside, 128 just on the inside, etc, and then renders the thing by clamping >=127 to render solid color and <127 to be fully transparent. the result is that the simple bilinear filtering of the distances gives a nice smooth line where it considers 127 to be the "true" value) small nitpick: the preprocessing for this certainly does not *need* to be very brute-force. it may be expensive if in a situation where the texture needs to be rebuilt over and over on the fly, but only in that doing such things on cpu is pretty expensive even if very little computation per pixel is needed. all one really needs to do is really to calculate the distance from each point on the texture to each geometric shape, so linear time if you have e.g. lines and circles, and while it may get a bit pricier for exotic curves it really is nicely behaved (in that you can reasonably expect that the curve will be very smooth at the resolution you are sampling, so e.g. bounding boxing and newton-stepping on the curve using the starting position from an adjacent sample should get it very quick) valve took the easy but slow way out by sampling a huge 1-bit texture as an approximation of the true shape and then sampling that down to the distance texture, which you certainly wouldn't want to do on the fly
|
|
#
?
Oct 18, 2017 10:53
|
|
|
sorry, could you also explain what the hell a 1-bit texture is or how that's useful? is it just for like, masking?
|
|
#
?
Oct 18, 2017 13:27
|
|
|
fun fact: approximating bezier by arcs and lines is how you get fancy vector shapes on printed circuit boards and some photo plotters since the Gerber files can't handle real bezier curves
|
|
#
?
Oct 18, 2017 13:42
|
|
|
echinopsis posted:gpu facts - my r7 290 is no longer supported in belnder open cl so now I have no gpu pathways in cucles at all weird, what changed? ate all the Oreos posted:sorry, could you also explain what the hell a 1-bit texture is or how that's useful? is it just for like, masking? in the valve paper they're drawing a 2D vector shape (the text "no trespassing") with no built-in texturing onto a 3D object, so the 1-bit texture is a high-res mask of the vector shape. the point is to draw a crisp vector image at any distance, but only using a raster texture on the gpu.
|
|
#
?
Oct 18, 2017 13:51
|
|
|
josh04 posted:weird, what changed? ah ok, that's kinda what i was thinking, thanks
|
|
#
?
Oct 18, 2017 14:30
|
|
|
Suspicious Dish posted:* but you want gpu, right? so you try valve's sdf trick which everybody and their mother knows by heart these days. it requires a slow brute force search on the cpu (doesn't stop google from doing it in chrome) and heavily distorts the shape since merging both x and y distance into one field makes sharp angles into circles, but valve didn't care since tf2 was particularly cartoon-y and it fit their artstyle. multi-channel sdf is a thing and gives you text with sharp corners, but it still requires that slow preprocessing step and increases memory requirements since it needs an rgba texture (technically just rgb, but outside of mobile and newer intel igpus non-padded 24 bpp textures aren't supported)
|
|
#
?
Oct 18, 2017 15:19
|
|
|
assume the generated textures are more difficult to compress, too. dunno how limiting that is for how many you'd use.
|
|
#
?
Oct 18, 2017 15:29
|
|
|
when it comes to corners getting rounded one does wonder whether anyone ever got around to trying to modify the distance map to sharpen corners, since you know it will be bilinearly filtered you could basically just run an off the shelf optimizer to find the best values for getting the correct shape (i guess there'd be some scale dependence, but nothing too dramatic) e.g., when using distance (the scale 0..9 where 6 is on the edge, 7 inside, 5 outside, so the clamping point is >=6) you'd map something like this (note how the downscaling has the edge of the shape straddling between two distance samples, so there is no literal 6, but the bilinear filtering will place it right in between 5 and 7 on the straight bits) code:code:
|
|
#
?
Oct 18, 2017 15:34
|
|
|
yeah, my description of sdf wasn't great. but sdf in general doesn't work well for fully featured images like what you want with SVG and dynamic graphics at 60fps, e.g. HTML5 canvas, since it's a precomputed system. my understanding of the multichannel sdf stuff is poor, but i thought that you generated three different fields and tried to combine them with some brute force trying to solve for concave vs. convex intersections. but that approach seems to be outdated compared to Viktor Chlumsky's 2016 thesis which, 1. is pretty drat readable for a thesis and goes over the basics of SDF in general with cool diagrams, 2. seems to have a much more tractable approach for the multichannel sdf. also apparently doing some fancy math lets you trace contours with a single-channel sdf more carefully. found the shader here: https://www.shadertoy.com/view/ltXSDB that last approach actually looks pretty good. apparently he has it working for SVGs: https://twitter.com/adamjsimmons/status/822564326619881472 and apparently he's going to release a "pure GPU WebKit port" soon https://twitter.com/adamjsimmons/status/918598344708100097 . huh, that escalated quickly
|
|
#
?
Oct 18, 2017 16:56
|
|
|
this is probably the part where he cheerfully announces that he has been granted a patent on the technique and then turns around and sells an exclusive license to Apple for a cool 10 million
|
|
#
?
Oct 18, 2017 17:23
|
|
|
Sapozhnik posted:this is probably the part where he cheerfully announces that he has been granted a patent on the technique and then turns around and sells an exclusive license to Apple for a cool 10 million works for my machine 
|
|
#
?
Oct 18, 2017 20:18
|
|
|
if you sell apple something like that for less than 1% of their market cap, you just got screwed over son
|
|
#
?
Oct 18, 2017 20:35
|
|
|
graphics cards that need 2D acceleration should include a TMS34010 or TMS34020 on their card, they implement QuickDraw in hardware
|
|
#
?
Oct 18, 2017 21:41
|
|
|
what happened with 2d acceleration anyway, is it still mostly present in modern hardware? i know gpus had dedicated 2d hardware at least into the early agp days if not even later, and it's extremely efficient compared to just running everything in 3d, to the point where i run my laptop desktop without 3d compositor as it can easily save me over an hour of battery (so like, 10-15%) on an intel gpu, and for fat gpus it just gets worse. it also doesn't seem to suffer from various bugs that 3d drivers inevitably suffer from
|
|
#
?
Oct 18, 2017 21:59
|
|
|
If by 2D acceleration you mean fast blits, resizes, and alpha, it moved from the GPU into the display controller. Intel GPUs actually still have fast 2D engines ( see https://01.org/sites/default/files/documentation/intel_os_gfx_prm_vol9_-_blitter_0.pdf ) but I'm not sure if anything uses them. Android's "layer" system is an attempt at allowing display controllers, not GPUs and software, to do compositing. APIs are generally pretty poor at this, is the big thing.
|
|
#
?
Oct 18, 2017 22:09
|
|
|
Suspicious Dish posted:If by 2D acceleration you mean fast blits, resizes, and alpha, it moved from the GPU into the display controller. Intel GPUs actually still have fast 2D engines ( see https://01.org/sites/default/files/documentation/intel_os_gfx_prm_vol9_-_blitter_0.pdf ) but I'm not sure if anything uses them. Android's "layer" system is an attempt at allowing display controllers, not GPUs and software, to do compositing. APIs are generally pretty poor at this, is the big thing. is there any actual advantage to using the blitter hardware vs just drawing quads with the 3d hardware? the only thing i can think of that would make it attractive is if the power consumption is lower than drawing with the 3d rasterizer. The_Franz fucked around with this message at 22:28 on Oct 18, 2017 |
|
#
?
Oct 18, 2017 22:20
|
|
|
didn't most of the stuff that was used for Windows GDI acceleration, scale/stretch, on 90s hardware get sent back to software or moved onto 3d hardware that mimics fully 2d rendering? like that's what a lot of the old 2d acceleration cards were you can probably get some old windows 98 benchmarks for testing that sort of 2d acceleration on the explicit support back in the day versus early 2000s mass market graphics card versus modern stuff
|
|
#
?
Oct 18, 2017 22:24
|
|
|
The_Franz posted:is there any actual advantage to using the blitter hardware vs just drawing quads with the 3d hardware? the only thing i can think of that would make it attractive is if the lower power consumption is lower than drawing with the 3d rasterizer. That's basically it. Power is a really big concern on mobile, and GPUs are basically a giant steamroller that you try not to use if you want to just hammer a few nails into the floor. fishmech posted:didn't most of the stuff that was used for Windows GDI acceleration, scale/stretch, on 90s hardware get sent back to software or moved onto 3d hardware that mimics fully 2d rendering? like that's what a lot of the old 2d acceleration cards were Yeah, and then we brought it back for low-power scenarios because mobile, and then GPUs became powerful and not-power-intensive enough to put real GPUs in mobile devices, and then we started putting fancy GPUs in phones, so we brought back the 2D thing but put in the display controller because we still want to show YUV videos without spinning up the GPU for power reasons, and soon enough, the display controller will have 16 configurable planes and we'll try to use it less because it's power intensive. It's the cycle that never ends.
|
|
#
?
Oct 18, 2017 22:29
|
|
|
josh04 posted:weird, what changed? they took opencl up to feature parity with cuda and in doing so elminayed older ati cards
|
|
#
?
Oct 18, 2017 22:33
|
|
|
Suspicious Dish posted:If by 2D acceleration you mean fast blits, resizes, and alpha, it moved from the GPU into the display controller. yeah, that's what i meant, and that makes sense, thanks. i guess can easily and cheaply cram all sort of poo poo into a display controller that used to be separate and relatively expensive parts in the 90s. Suspicious Dish posted:That's basically it. Power is a really big concern on mobile, and GPUs are basically a giant steamroller that you try not to use if you want to just hammer a few nails into the floor. this is my main annoyance with desktop environments being all 3d, yeah. don't really care or notice it on a desktop, but on a laptop it'll both get hotter, which gets uncomfortable for using it on a lap, and drain battery faster. when it's hot in summers i like to go for a walk into a nearby forest/park and then sit down and work from there since it's nice and cool and quiet, unlike the office, and the difference on battery power between a 2d desktop and a 3d desktop is easily more than an hour these days, at least with kde.
|
|
#
?
Oct 18, 2017 22:57
|
|
|
yo how does web render do this cheaply then fwiw just rendering text and lines and boxes and circular arcs nice on the GPU would be fine for the web and doing 1000fps on gpu is great since it can then spend most of its time powered down waiting for vsync performance = battery life on mobile
|
|
#
?
Oct 18, 2017 23:35
|
|
|
well, the 1000 fps figure on its own means nothing. it could be 1000 fps while drawing 300 amps of current. scale that down to 60 fps and that's still 18 amps.Malcolm XML posted:performance = battery life on mobile performance per watt = battery life on mobile.
|
|
#
?
Oct 18, 2017 23:50
|
|
|
Truga posted:this is my main annoyance with desktop environments being all 3d, yeah. don't really care or notice it on a desktop, in 2013 or so I had a cheap PC from early 2005 sitting in a corner, and I thought “hey, I could run Linux on this and get more use out of it!” so I installed Ubuntu it was loving awful, it felt slower to use than Windows 2000 in Virtual PC on my beige G3, but the same system had been just fine under Windows XP and also Haiku it was all because the FX5200 GPU it included wasn’t supported, and all the world had switched to GPU-based compositing; once I got the one AGP video card that was still supported, it felt fine again I probably should’ve just installed NetBSD and used a regular X11 environment instead of the wannabe-Windows environment of Ubuntu (or Fedora, or any of the rest) but I eventually just replaced that system with an i7 4790K with gobs of RAM and SSD so I had someplace fast to run things that really demand a “supported” Linux
|
|
#
?
Oct 19, 2017 00:14
|
|
|
a lot of the concerns about proper rendering of 2d shapes on 3d hardware map very well to concerns about proper automatic toolpathing for 3d printers. for reference this post is about fused deposition modeling, aka glue stick on a gantry, which is what I’m familiar with. the biggest point of comparison is traditional machining: traditional machining is frequently done by a trained cam engineer running a cam tool on a model and then tuning the outputs, or (more likely) getting drawings - you know, the way engineers have been doing it for centuries: 2d plans with shapes and dimensions called out - and making their own CAM projects. 3d printing doesn’t really have trained people and the problem is much bigger because each layer (in an FDM print) requires its own toolpath. so what’s the big problem? the problem is that there are two kinds of inputs. the first kind (and at this point by convention, the most frequent kind) is 3d artistic models, as made in e.g. maya, which are, as suspicious dish talked about, composed of polygons. these are really convenient because if you take a 3d model made of polygons, pick what you want to be your z axis, and take isoclines at a given z offset, you get well defined paths made out of straight line segments. cool. the second kind, which are not as prominent yet because they’re harder, are the kind that are actually useful for engineers: cad models. cad models are fundamentally composed of bounded b-splines. these are an extension of bezier splines to 2d; those 2 dimensions are typically a bounded plane in a 3d space that is your model. the boundedness means you can have straight edges, which exist at the boundary between to splines; and smooth 2d curves, inside a splines area of influence. the nice thing about the second kind is that if you define a z axis and then take an isocline at a z axis, you actually can get a collection of bounded 2d splines. the problem is that a) this is way harder b) it’s all good to generate a CAM plan of bezier splines but a slightly harder thing to control a set of stepper motors along that path c) it’s very VERY different than the line segment method, which is what everybody is used to doing because nothing under $1,000,000 supports direct STEP pathing so everybody exports to STL. and while theoretically a collection of bounded 2d splines decays exactly to a collection of line segments if everything is strictly polygonal, there’s a lot of numerical stability issues involved. let me know if you want more info dumps on 3d printer toolpathing as I know it after leaving a large prosumer 3d printing manufacturer after like 4 years in firmware.
|
|
#
?
Oct 19, 2017 00:35
|
|
|
Malcolm XML posted:yo how does web render do this cheaply then You can cheat somewhat because CSS doesn't have bezier curves -- its drawing model is all elliptic arcs (border-radius). So instead of solving hard quadratic formula intersection problems, you just do sin/cos in the vertex shader and bam, there you go.
|
|
#
?
Oct 19, 2017 01:58
|
|
|
ate all the Oreos posted:sorry, could you also explain what the hell a 1-bit texture is or how that's useful? is it just for like, masking? 
|
|
#
?
Oct 19, 2017 02:05
|
|
|
|
| # ? Apr 27, 2024 04:42 |
|
|
Phobeste posted:let me know if you want more info dumps on 3d printer toolpathing as I know it after leaving a large prosumer 3d printing manufacturer after like 4 years in firmware. please post lots more about this because it's extraordinarily cool to me and also relevant to what i'm teaching the kids i've wondered about the direct-NURBS path before but it doesn't seem to have much of a benefit in most 3d printing cases? like, as you pointed out, your theoretical minimum resolution on an FDM is going to be whatever your stepper and belt system can hold, which on a consumer printer is maybe a few thousandths of an inch, but the machines aren't even rigid enough to get that repeatably and the extrusion is rarely that accurate either. certainly when i'm printing something on the desktop and i need a genuinely circular hole or w/e i just undersize it and drill it out. this seems like a seriously useful thing in SLA printing, though, since you can easily hit a resolution that shows faceting in the model, and because a galvanometer beam director with the proper DAC can be effectively stepless. you just need to pick a subdivision resolution that's suitable for the quality you're trying to hit. is there something particularly challenging about going NURBS -> 2D splines -> arbitrary-resolution segmentation -> beam director?
|
|
#
?
Oct 19, 2017 02:14
|
|
