Uso de HTML5 WebGL Shaders para Computación

Question

Me parece que en teoría se podría usar WebGL para el cálculo, como calcular números primos o π o algo similar. Sin embargo, por lo poco que he visto, el sombreado en sí no está escrito en Javascript, así que tengo un par de preguntas:

1. ¿Qué idioma se los shaders escritos en?
2. ¿Valdría la pena intentar hacer algo así, teniendo en cuenta cómo funcionan los sombreadores?
3. ¿Cómo se pasan variables hacia adelante y hacia atrás durante el tiempo de ejecución? O si no es posible, ¿cómo se pasa información una vez que el sombreador termina de ejecutarse?
4. Dado que no es Javascript, ¿cómo se manejarían enteros muy grandes (BigInteger en Java o una versión portada en Javascript)?
5. Supongo que esto compila automáticamente el script para que se ejecute en todos los núcleos de la tarjeta gráfica, ¿puedo obtener una confirmación?

Si es relevante, en este caso específico, estoy tratando de factorizar números bastante grandes como parte de un proyecto compsci [muy] extendido.

EDIT:

1. shaders WebGL están escritos en GLSL.

Answer 1

Actualmente se está trabajando en un proyecto para hacer exactamente lo mismo que usted: WebCL. Sin embargo, todavía no creo que esté en vivo en ningún navegador.

para responder a sus preguntas:

1. ya ha respondido supongo!
2. Probablemente no vale la pena hacerlo en WebGL. Si quieres jugar con el cálculo de GPU, es probable que tengas más suerte al hacerlo fuera del navegador, ya que las cadenas de herramientas son mucho más maduras allí.
3. Si tiene problemas con WebGL, un enfoque podría ser escribir sus resultados en una textura y leerlos de nuevo.
4. Con dificultad. Al igual que las CPU, las GPU solo pueden funcionar con determinados valores de tamaño de forma nativa, y todo lo demás tiene que ser emulado.
5. Sí.

Answer 2

He utilizado sombreadores de cálculo de JavaScript en Chrome usando WebGL para resolver el problema del vendedor ambulante como un conjunto distribuido de pequeños problemas de optimización resueltos en el sombreador de fragmentos y en algunos otros problemas de optimización genética.

Problemas:

1. Se puede poner en flotadores (r: 1,00, g: 234.24234, b: -22.0), pero sólo se puede obtener números enteros OUT (R: 255, G: 255, B: 0). Esto se puede superar codificando un solo flotador en 4 enteros como salida por fragmento. Esta es una operación tan pesada que casi derrota el propósito para el 99% de los problemas. Es mejor que resuelva problemas con enteros simples o sub-soluciones booleanas.

2. La depuración es una pesadilla de proporciones épicas y la comunidad está en el momento de escribir esto activamente.

3. Inyectando datos en el sombreado ya que los datos de píxeles son MUY lentos, leerlos es aún más lento. Para dar un ejemplo, leer y escribir los datos para resolver un problema TSP lleva 200 y 400 ms, respectivamente, el tiempo real de "extracción" o "cálculo" de esos datos es de 14 ms. Para ser utilizable, su conjunto de datos debe ser lo suficientemente grande y correcto.

4. JavaScript está débilmente tipeado (en la superficie ...), mientras que OpenGL ES está fuertemente tipado. Para poder interoperar, tenemos que usar cosas como Int32Array o Float32Array en JavaScript, lo cual se siente incómodo y restrictivo en un lenguaje normalmente promocionado por sus libertades.

5. El soporte de números grandes se reduce a utilizar 5 o 6 texturas de datos de entrada, combinando todos los datos de píxeles en una única estructura de números (de alguna manera ...), y luego operando en ese gran número de una manera significativa. Muy hacky, nada recomendable.

Answer 3

anduve por aquí con este tipo de cosas una vez. En respuesta a su tercera pregunta, pasé vars atrás n adelante con 'uniformes'

* edit - mirando hacia atrás ahora también usé vectores 'atributos' para pasar datos desde afuera.

que necesita para funcionar MAMP o algo para que esto funcione localmente ... https://github.com/byteface/GTP/tree/master/play/simplified

que utilizan píxeles para representar las letras del alfabeto y la búsqueda de cadenas hicieron con shaders. Fue increíblemente rápido. más rápido que los programas nativos de búsqueda basados ​​en CPU. es decir, buscar un libro completo para las instancias de una sola palabra es más rápido en el navegador en la GPU que en un programa ligero como textedit. y solo estaba usando una sola textura.