javascript - Usando Shaders WebGL de HTML5 para Computación
(3)
Actualmente hay un proyecto en el que se está trabajando para hacer exactamente lo que estás haciendo: WebCL . Sin embargo, no creo que esté en vivo en ningún navegador.
Para responder tu pregunta:
- Ya respondí que supongo!
- 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 por ahora, ya que las cadenas de herramientas son mucho más maduras allí.
- Si estás atascado con WebGL, un enfoque podría ser escribir tus resultados en una textura y leer eso.
- Con dificultad. Al igual que las CPU, las GPU solo pueden trabajar con ciertos valores de tamaño de forma nativa, y todo lo demás tiene que ser emulado.
- Sí.
Me parece que uno podría, en teoría, utilizar WebGL para el cálculo, como el cálculo de números primos o π o algo parecido. Sin embargo, por lo poco que he visto, el shader en sí no está escrito en Javascript, así que tengo algunas preguntas:
-
¿En qué idioma están escritos los shaders? - ¿Valdría la pena intentar hacer eso, teniendo en cuenta cómo funcionan los shaders?
- ¿Cómo se pasan las variables de un lado a otro durante el tiempo de ejecución? O si no es posible, ¿cómo se devuelve la información una vez que el sombreador termina de ejecutarse?
- Dado que no es Javascript, ¿cómo se manejan los enteros muy grandes (BigInteger en Java o una versión portada en Javascript)?
- 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.
EDITAR:
- Los sombreadores WebGL están escritos en GLSL.
He usado computar shaders desde JavaScript en Chrome usando WebGL para resolver el problema del vendedor ambulante como un conjunto distribuido de problemas de optimización más pequeños resueltos en el sombreado de fragmentos, y en algunos otros problemas de optimización genética.
Problemas:
Puede poner flotantes en (r: 1.00, g: 234.24234, b: -22.0) pero solo puede sacar números enteros (r: 255, g: 255, b: 0). Esto se puede superar mediante la codificación de un solo flotante en 4 enteros como una salida por fragmento. En realidad, esta es una operación tan pesada que casi anula el propósito del 99% de los problemas. Eres mejor para resolver problemas con soluciones integrales simples o booleanas.
La depuración es una pesadilla de proporciones épicas y la comunidad está en el momento de escribir esto activamente.
Inyectar datos en el sombreador ya que los datos de píxeles son MUY lentos, leerlos es aún más lento. Para darle un ejemplo, leer y escribir los datos para resolver un problema de TSP toma 200 y 400 ms respectivamente, el tiempo real de ''dibujar'' o ''calcular'' de esos datos es de 14 ms. Para poder utilizar su conjunto de datos tiene que ser lo suficientemente grande de la manera correcta.
JavaScript está mal escrito (en la superficie ...), mientras que OpenGL ES está fuertemente tipado. Para interoperar, tenemos que usar cosas como Int32Array o Float32Array en JavaScript, que se siente incómodo y restringido en un lenguaje que normalmente se promociona por sus libertades.
La compatibilidad con los números grandes se reduce al uso de 5 o 6 texturas de datos de entrada, combinando todos esos datos de píxeles en una estructura numérica única (de alguna manera ...), y luego operando ese número grande de manera significativa. Muy hacky, nada recomendado.
Mucked alrededor con este tipo de cosas una vez. En respuesta a su tercera pregunta, pasé las respuestas con "uniformes".
* editar: al mirar hacia atrás ahora también se usan ''atributos'' del vector para pasar datos desde el exterior.
deberá ejecutar mamp o algo para que esto funcione localmente ... https://github.com/byteface/GTP/tree/master/play/simplified
Utilicé píxeles para representar las letras del alfabeto e hice búsquedas de cadenas con sombreadores. Fue increíblemente rápido. Más rápido que los programas de búsqueda nativos basados en CPU. es decir, buscar en un libro entero 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.