World: r3wp

Steeve Matrix are costly in computations only if you do it with a 
CPU not designed on purpose to do those kind of tasks.... But with 
a GPU it's EASY CAKE ...Question is can we be hardware ignorant or 
not ?

Grahma hum ... getoff the didguise you pervert !!!

(the font is so small i don't see what i'm writing and my glass are 
just renewed ... the Font 6px SUX ....

You can print to html and then enlarge it there

graham i can use a software grow lens  too  .... BUT the better way 
is to have the font in 14 px like in any civilised software :)

problem is i'm not sure rebol 2.3.2.15  from decembre 2005 is the 
best rebol VM for altme ...  2005 ....  TWO  THOUSAND AND FIVE !!!

since then a lot have been done altme could use a agg rendering method 
insteas of a VID face concatenation etc...

the thing i love in  viva-rebol.r is that you can grow and skrink 
the texts at light speed

viva-rebol.r is a R2 project isn't it?

when you have a rebol 2005 below alte me the message is  ---> ALTME 
wasn't enhanced since at least 5 years i'm a very buzy man and anyway 
i don't give a damn if people use it or not ...

graham yes but viva-rebol would be such a nice kid with his brand 
new open CL powers :)

Altme has been enhanced a few times recently

Are you using an old version??

no ... but it's still microcopic font size  good if you have 10/10 
 on both eyes bad if you have -7,25 /10 an -6,75/10 on both eyes

CARL what about -12.244x-12.21 matrix don't negative floating  numbers 
deserves their own pair! too ? ( if we are loosin time in stupidity 
why not playing to game to the core ?)

i see what a pixel is  i don't see what half a pixel could be ... 
and the reason is be able to see  those half pixels i would need 
a screen that can display when and eyes that can render them to my 
brain wich will never ever be the case in this life ... So personnally 
Carl i wouldn't be sad is matrix are rounded.

CPU are not feated with matrix computations because the industry 
decided that matrix area was such a big thing that they needed a 
spécific library and a specific hadware extensivly optimised to perform 
those computations. and so the GPU accellerated enhanced for opengl 
and DirectX is born.... Now in day the industry use most likely the 
DirectX because  well 90% of the personal computers are windows and 
that 100% of them support DX so 100% of the sold PC games are done 
that way... And that allow to cut cost when another company like 
unreal tech for example make a game engine you buy it and you save 
alot of time and monney the only thing you will have to do then is 
to create the specific IHM for your game and all the visual /audio 
content. then your project  time spent is shorted by 2 or 3 years...

since unreal shows you can do blasting High definition photorealistic 
close to the perfection 3d real time rendering engine with DirectX 
then the other will say ok we need our own DX engine cause DX is 
the only one able to do this ... Then you have the GPU founders that 
will say ok since the game industry wants and need DX then we will 
enclose in our harware GPU alot of  optimisations for DX ... or even 
the next DX version noone use now in day .. buuuuut we will be ready 
!

AGG is not the best place to put OpenCL support. OpenCL is not very 
useful for accelerating graphics, and that is what AGG would need. 
A standalone OpenCL dialect would be more useful. Graphics acceleration 
uses other APIs, like OpenGL or Direct2D. AGG isn't 3D, so using 
OpenGL or Direct3D would be equivalent to reimplementing Direct2D 
on platforms that don't support it.

If the standalone OpenCL dialect was also translatable to CUDA it 
would be even better :)

Or maybe DirectCompute on Win7/Vista.

Brianh hum actually when i we display things using agg the cu is 
used only and if we want to do extensive computing visual effects 
like zoom spining things etc ... hten the cpu will be extensively 
used ... and since rebol doesn"t take advantage of  multi CPU  or 
CPU <- to ->GPU communication then the extensive computation loops 
are not enhanced. Problem is now in day NVIDIA is so expensiv no 
one buy it  10 ATi cards are sold for 1 nvidia card and in a very 
near future AMD CPU will be mixed with ATI GPU  into a single chip 
(APU fusion). This is the tendency of the computing area so if you 
have to support 1 paralelle design i would go for the AMD /ATI  couple 
instead of  betting on a close to death horse...

As for seeing a partial pixel, the writer of AGG demonstrated (in 
an unrelated post) using anti-aliasing to do 1/256 horizontal pixel 
positioning.

but yes brianh you got the point when you relay on hardware then 
you have to choose what technology you support i know rebol main 
target is to be hardware / OS / driver abstracted .. but then you 
have a toy language anyone laught about that  can't bring anyway 
the same thing on every OS computer a part some very basic features 
like networking, encryption etc...

The semantics for a GPGPU dialect in REBOL would likely be pretty 
high-level, and could be translatable to different GPUs by using 
different compiler backends. It's not necessarily a good idea to 
bet it all on one horse when you can support them all just by being 
a bit general. We wouldn't have to do major tweaking for a specific 
GPU architecture, since the level of speedup would be great for even 
a half-assed translation.

It's not a toy language, it's a high-level language. The compiler 
would handle the details. That is like calling C a toy language.

BrianH probleme is  rebol doesn"t tends to relay on a spécific thing 
or another it's phylosophy is to be an easy way to do easyly easy 
things ... when you want to get your self out of that scope you are 
 facing hella difficulties  why should i code 99% of a project in 
C and then do a  dialect to do the last 1% of rebol action code

Um, you must not be working on the same things I am. I do tough stuff 
in pure REBOL quite often. The only C I see is there to implement 
low-level dialects used by REBOL, but those aren't as often needed 
as DO or PARSE dialect code.

that's only usefull if your are sure this extension will be extensively 
used. What interrest me is doing rebol and ways to bring into rebol 
the now in day possibilities .. remember that rebol was designed 
around 1998 at that time processors where mono cores GPU  where a 
joke.(GPU 100MHz with 64Mo do GRAM and CPU 433Mhz SDRAM 133 MHz)

we are 10  years after that design ... can rebol continue to say 
ok the harward evolved but i refuse to use it ?

One of the things that the modern multi-core language research has 
discovered is that shared-memory multithreading is often a bad idea, 
and that multiprocessing with asynchronous IPC is more reliable and 
scales better. And cooincidently enough, multiprocessing is the method 
REBOL uses. Now all we have to do is get the processes smaller and 
the IPC (/Services) more efficient.

i think now in day hardware capabilities are introducing alot of 
 problems in software parallelisation strategies (wich had been always 
the case) that's a field i think rebol should explore and propose 
it's originality  to solve that increasing difficulty.

hum yeah but that  solution apears to the rest of the world like 
a joke .. face it ... we are less than a thousand people really caring 
about rebol's futur ...

The strength that REBOL has is that it is relatively easy to create 
a dialect with different semantics, because we have so many good 
tools to help with the implementation, more all the time. So REBOL 
becomes a good platform on which to do those experiments. And we 
always have the old-school single-process DO dialect to fall back 
on.

try to talk asynchronous processing with a guy doing java threads 
programing all day long that's interesting ...

Yeah, we could probably boost all view stuffs by isolating the rendering 
engine in a distinct process.

asynchronous have a weak point the data flow processed should not 
be to much ..  so for example if you want to put cheyenne on his 
needs you make it relay a webradio streaming for example

Threads was considered to be the solution last decade. And that is 
why we have a multi-core crisis now, because threads are not a good 
solution. That is why the main research not is in active objects 
and green processes.

on his needs  = on it's knees ...

not -> now

BrianH ok but who promote that way of thinking and multicore crisis 
is mainly do to the shared memory and to the weak memory controller 
completly saturated with date flow from CPU and from GPU

that's why intel/ nvidia  APPLE (in a lower extends all smartphone) 
and AMD/ATI are doing or announcing he merge of the Memory controller 
the CPU and the GPU  into a single unit

Um, that is not the multi-core crisis. The real crisis is that it 
is very difficult to break a program into threads, and even more 
difficult to manage shared state. This is why there are so many issues 
with locking and such.

It's a programming problem, not a hardware problem.

the A1 chip in the ipad for example already is a allin one chip  
and the preformances are better because the software is better too 
but because the hardware is specificly designed to feat it

that's a thing only a closed disgn 100% controled  like the apple 
one can offer

Chips in handheld and embedded systems aren't that multicore yet, 
so they can still be programmed in the old ways (like Java).

brianH that's why before the multi core processor you had multi single 
cores dedicated memory architecture and you still have that design 
in the MEGA ULTRA COMPUTERS

and yes writing programs on those computers means a specific knowledge 
.... Problem is the industry said to the code continu to code the 
way you did so fare the hardware will optimise it

wich obviously isn't the case