Bonsoir. Je n’ai pas vraiment besoin d’aide, j’aurais juste besoin d’avis sur une question. Que pensez-vous d’un langage de shaders orienté objet ? Pensez-vous que ça serait une bonne chose ou que cela serait plutôt inutile ?
Je pense que ça risque de poser des problèmes d’interopérabilité, la plupart des langages existants ne fonctionnent que pour une plateforme donnée.
Ou alors il faudrait que ce soit un langage transpilé, pour bénéficier du support hardware des autres langages.
Et un des soucis que je pense qui risque de se produire, c’est que la POO n’est pas très optimisée pour les gros calculs à faire rapidement, donc le langage devrait convertir les process objets en process fonctionnels, pour correspondre au modèle de calcul des GPU.
Je pense que ça risque de poser des problèmes d’interopérabilité, la plupart des langages existants ne fonctionnent que pour une plateforme donnée.
Ou alors il faudrait que ce soit un langage transpilé, pour bénéficier du support hardware des autres langages.
Et un des soucis que je pense qui risque de se produire, c’est que la POO n’est pas très optimisée pour les gros calculs à faire rapidement, donc le langage devrait convertir les process objets en process fonctionnels, pour correspondre au modèle de calcul des GPU.
Ouais donc ça poserait plus de soucis que ça n’apporterait de choses utiles.
Salut,
Ça existe déjà, même si en l’occurrence ce projet n’a pas l’air très actif.
Et un des soucis que je pense qui risque de se produire, c’est que la POO n’est pas très optimisée pour les gros calculs à faire rapidement, donc le langage devrait convertir les process objets en process fonctionnels, pour correspondre au modèle de calcul des GPU.
Cet argument me parait plutôt faible. Le niveau d’abstraction que permet de manipuler un langage donné ne détermine pas les performances au runtime. Les performances sont une question d’écrire un compilateur (que ce soit vers le langage machine, du bytecode pour une VM, ou un autre langage) qui optimise correctement en passant du niveau d’abstraction du langage à celui de la cible. Dit autrement, choisir un langage OO est une question de design du langage alors que les performances sont une question d’implémentation. Certes, on sait mieux optimiser certains paradigmes que d’autres, mais en l’occurrence avoir un langage OO qui soit rapide au runtime, on sait faire. C++ est l’exemple évident ; Rust peut aussi se qualifier selon la définition d’OO sur laquelle on s’accorde. Clairement, on ne peut donc pas dire que "la POO n’est pas optimisée pour les gros calculs".
J’ai un peu de mal à imaginer ce que ça donnerait, tu pourrais illustrer par un exemple ?
J’ai un peu de mal à imaginer ce que ça donnerait, tu pourrais illustrer par un exemple ?
J’avais comme idée quelque chose dans ce style
// Global part
var pos: vec3 = location(0); // location is equivalent to layout in GLSL
var color: vec4 = location(1);
@entry vert // vertex shader
uniform var view: mat4;
uniform var proj: mat4;
uniform var model: mat4;
fn main() -> vec4
{
pos = vec3(model * vec4(pos, 1.0));
return proj * view * vec4(pos, 1.0);
}
@entry frag // fragment shader
class Light
{
public:
fn Light(var pos: vec3, var color: vec3, var radius: float) -> Light
{
_pos = pos;
_color = color;
_radius = radius;
}
mtd get_result() -> vec3
{
/* Some lights calculations */
return light;
}
private:
var _pos: vec3;
var _color: vec3;
var _radius: float;
}
fn main() -> vec4
{
obj light = Light((0, 10, 5), (255, 255, 255), 15.7);
var frag_color: vec4 = color * vec4(light.get_result(), 1.0);
return frag_color;
}
L’orienté objet dans ce cas-ci n’a pas grand intérêt mais cela peut en avoir dans d’autres situations
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte