When writing acceleration into drivers, it's common practice for some devs to drop down to a single xterm and twm, since it's largely unaccelerated and thus won't fuck up your screen or card while you're testing things.
They've advertised Linux support too, but I haven't heard anything from these guys. Unless they're like nVidia and sit around killing kittens all day, it would be a good idea for them to actually do some research and figure out how GLX and DRI work. Even the ATI closed-source drivers still respect the GLX way of life.
(nVidia replaces the entire DRI stack. DDX, GLX, DRI, DRM, all custom. fglrx doesn't replace GLX. Just in case you were wondering.)
As far as I know, the RV790 will be in the R600/R700 family and will work almost perfectly with existing R600/R700 code. While I have no guarantees on this, current talks with AMD employees haven't given off any indication that this chipset will be radically different from its cousins.
Actually, as the above reply demonstrated, this could be accelerated using a video overlay or any equivalent 3D hardware, so yes, it could be done with OGL.
And I'm just used to seeing 3D creations constructed with rasterizers, because the only alternative that actually seems feasible is ray-tracing, and everything else falls into one of those two categories. Voxels are rasterized, 2.5D is rasterized, and this is rasterized as well.
Who says you need 3D rendering to create a two dimensional image of mathermatical data and a databass filled with coordinates and images with RGB data?
Good point. We'd never be able to have fishing games without databass.
Seriously, I meant that if it's not rendered using 3D->2D polygon rasterization, how much hardware acceleration would it be able to use? Can it still be translated into OGL/DX expressions, or must it all be done in software?
This actually sounds like they are generating polygon-composed scenes from photographs. Cool, yes, but not actually without the traditional rendering method.
Of course, yes, it's possible to do this entirely with photos and without any kind of 3D rendering at all, but in that case, can it be accelerated? Will it move at a decent speed?
Re:looks like it still loses history
on
BASH 4.0 Released
·
· Score: 1
Hm, yeah, not exactly sure what motivated that particularly bad choice of words. I think I was referring to stockholders' right to move against upper management in the face of apparent fiscally poor decisions, but at this point I may have to write it off as just early-morning drivel.
I stand behind "shareholders need to go fuck themselves," though.
This is the entire problem with incorporation. If Microsoft were to dissolve their Windows branch and focus entirely on cool things (Zune, Xbox, Silverlight) then the world would be a much better place all around, but instead, they're forced, by legal obligation, to work on making stock prices as high as possible.
GEM (Graphics Execution Manager) is only working for Intel because they have more people working on it. There's only around four or five people working on Radeon stuff, and of those, only two of us are dedicated to ATI work, and we're both students.
If you grab development snapshots, you can see Radeons working with DRI2, GEM, KMS, and all that fancy stuff.
Not really all that surprising. I predict there will be many posts saying, "Ha, so when do the open-source drivers get this support?" so let me say it here, first.
OpenGL 3.0 support will be added to Gallium3D as it becomes supported, and Radeons will gain that support when they are added to Gallium3D. There is no timetable for this support.
Then let me be the first (but not the last) to say that I was already driven away from Wikipedia by the lack of respect for the community exhibited by certain unnamed administrators.
On another note, nouveau provides EXA, which makes it faster than nvidia for 2D on all the cards it supports. Just FYI. (They're working on 3D, too, but it'll take a bit since nVidia's still firmly in kitten-killing territory.)
Well, it's because these are usually CUDA (nVidia only) or CTM (ATI/AMD only). Onboard chips are almost always Intel or VIA, although both nV and ATI chips are occasionally put onto boards as well.
The good answer is that nobody's written CUDA/CTM/Brook+/OpenCL/etc. support for Gallium yet.
My guess is that it was written in GLSL or HLSL, as those are the only shading languages that are high-level and that work on both ATI/AMD and nVidia offerings. (For now.)
By no mean coincidence, this is *exactly* what I do whenever I need a tech to open up the cable box and tighten the screws. (Here in Oregon, sometimes the cable people forget to protect the boxes from rain, and when that happens, the cables slowly dislodge and rot and rust away. I'd be sad, except it's fucking Comcast.)
Broadcom, like many other manufacturers in this field, claim that FCC regulations forbid them from allowing modifications to the radio controls, specifically the access to channels below 1 and above 11. (I say "claim" because the FCC doesn't really care, as Atheros has already shown.) Microsoft has nothing to do with it.
Also, really, if you're going to blame an evil corporation, perhaps Apple would be more appropriate, as they have a propensity for shipping Broadcom wireless devices.
Take a page out of Freedesktop.org's process. Any user can create and maintain user repositories in their own space. For example, http://cgit.freedesktop.org/~csimpson/mesa is my personal Mesa repo. Then, anybody that wants can pull from there. Very rarely do FD.O people pull and push directly to each other, and I doubt that it happens that way in larger organizations, either.
There's only a few algorithms used in WDE, and of those, only AES and CAST have had any chance to be altered by governments. In particular, Blowfish and Serpent are, according to quite a few people, very reliable.
I personally find it very telling that the US government turned down Blowfish despite larger keysize, longer keyspace initialization, non-fixed S-boxes, and better performance, compared to AES.
At any rate, almost none of the current algorithms out there can be brute-forced, period. They're just too big.
Slashdot Mirror
Indeed. I really liked the part where the KDE devs seem to exclusively use nVidia cards with closed-source drivers. :3
When writing acceleration into drivers, it's common practice for some devs to drop down to a single xterm and twm, since it's largely unaccelerated and thus won't fuck up your screen or card while you're testing things.
They've advertised Linux support too, but I haven't heard anything from these guys. Unless they're like nVidia and sit around killing kittens all day, it would be a good idea for them to actually do some research and figure out how GLX and DRI work. Even the ATI closed-source drivers still respect the GLX way of life.
(nVidia replaces the entire DRI stack. DDX, GLX, DRI, DRM, all custom. fglrx doesn't replace GLX. Just in case you were wondering.)
As far as I know, the RV790 will be in the R600/R700 family and will work almost perfectly with existing R600/R700 code. While I have no guarantees on this, current talks with AMD employees haven't given off any indication that this chipset will be radically different from its cousins.
Actually, as the above reply demonstrated, this could be accelerated using a video overlay or any equivalent 3D hardware, so yes, it could be done with OGL.
And I'm just used to seeing 3D creations constructed with rasterizers, because the only alternative that actually seems feasible is ray-tracing, and everything else falls into one of those two categories. Voxels are rasterized, 2.5D is rasterized, and this is rasterized as well.
Who says you need 3D rendering to create a two dimensional image of mathermatical data and a databass filled with coordinates and images with RGB data?
Good point. We'd never be able to have fishing games without databass.
Seriously, I meant that if it's not rendered using 3D->2D polygon rasterization, how much hardware acceleration would it be able to use? Can it still be translated into OGL/DX expressions, or must it all be done in software?
This actually sounds like they are generating polygon-composed scenes from photographs. Cool, yes, but not actually without the traditional rendering method.
Of course, yes, it's possible to do this entirely with photos and without any kind of 3D rendering at all, but in that case, can it be accelerated? Will it move at a decent speed?
^R (Ctrl+R) is reverse-i-search. HTH. ~
Hm, yeah, not exactly sure what motivated that particularly bad choice of words. I think I was referring to stockholders' right to move against upper management in the face of apparent fiscally poor decisions, but at this point I may have to write it off as just early-morning drivel.
I stand behind "shareholders need to go fuck themselves," though.
This is the entire problem with incorporation. If Microsoft were to dissolve their Windows branch and focus entirely on cool things (Zune, Xbox, Silverlight) then the world would be a much better place all around, but instead, they're forced, by legal obligation, to work on making stock prices as high as possible.
Shareholders need to go fuck themselves.
I for one have a completely different opinion of Songsmith now.
You got modded up, so I get to correct you.
GEM (Graphics Execution Manager) is only working for Intel because they have more people working on it. There's only around four or five people working on Radeon stuff, and of those, only two of us are dedicated to ATI work, and we're both students.
If you grab development snapshots, you can see Radeons working with DRI2, GEM, KMS, and all that fancy stuff.
Currently there are zero (0) devs working on OGL 3.0 support in Gallium, and one (1) dev working on Radeons in Gallium.
"Months" is what we'd all like, yes.
Not really all that surprising. I predict there will be many posts saying, "Ha, so when do the open-source drivers get this support?" so let me say it here, first.
OpenGL 3.0 support will be added to Gallium3D as it becomes supported, and Radeons will gain that support when they are added to Gallium3D. There is no timetable for this support.
Then let me be the first (but not the last) to say that I was already driven away from Wikipedia by the lack of respect for the community exhibited by certain unnamed administrators.
Gonna be awfully hard to drive out to that remote place without a road. Just sayin'.
Real nerds contribute to X. *hint, hint*
On another note, nouveau provides EXA, which makes it faster than nvidia for 2D on all the cards it supports. Just FYI. (They're working on 3D, too, but it'll take a bit since nVidia's still firmly in kitten-killing territory.)
Well, it's because these are usually CUDA (nVidia only) or CTM (ATI/AMD only). Onboard chips are almost always Intel or VIA, although both nV and ATI chips are occasionally put onto boards as well.
The good answer is that nobody's written CUDA/CTM/Brook+/OpenCL/etc. support for Gallium yet.
My guess is that it was written in GLSL or HLSL, as those are the only shading languages that are high-level and that work on both ATI/AMD and nVidia offerings. (For now.)
By no mean coincidence, this is *exactly* what I do whenever I need a tech to open up the cable box and tighten the screws. (Here in Oregon, sometimes the cable people forget to protect the boxes from rain, and when that happens, the cables slowly dislodge and rot and rust away. I'd be sad, except it's fucking Comcast.)
Broadcom, like many other manufacturers in this field, claim that FCC regulations forbid them from allowing modifications to the radio controls, specifically the access to channels below 1 and above 11. (I say "claim" because the FCC doesn't really care, as Atheros has already shown.) Microsoft has nothing to do with it.
Also, really, if you're going to blame an evil corporation, perhaps Apple would be more appropriate, as they have a propensity for shipping Broadcom wireless devices.
Take a page out of Freedesktop.org's process. Any user can create and maintain user repositories in their own space. For example, http://cgit.freedesktop.org/~csimpson/mesa is my personal Mesa repo. Then, anybody that wants can pull from there. Very rarely do FD.O people pull and push directly to each other, and I doubt that it happens that way in larger organizations, either.
There's only a few algorithms used in WDE, and of those, only AES and CAST have had any chance to be altered by governments. In particular, Blowfish and Serpent are, according to quite a few people, very reliable.
I personally find it very telling that the US government turned down Blowfish despite larger keysize, longer keyspace initialization, non-fixed S-boxes, and better performance, compared to AES.
At any rate, almost none of the current algorithms out there can be brute-forced, period. They're just too big.
$ sudo -i
Password:
#
But how can I be the youngest X.org member if I don't act cute?
Or, on a more serious note, why complain? I'm the only X.org member to actually comment here, and with a nice, big, juicy, informative FAQ, no less.