Homebrew How does the GPU know what kind of data is inside the output registers?

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
30
XP
436
Country
France
I couldn't find any way of defining what kind of data they would contain. I mean, I know about the registers that define their semantic, but what about the different kinds of data From the input buffer? Is the GPU just always expecting floats?
Thanks for the Help!
 
Last edited by cal64,

migles

All my gbatemp friends are now mods, except for me
Member
Joined
Sep 19, 2013
Messages
8,033
Trophies
0
Location
Earth-chan
XP
5,299
Country
China
you're not very helpful
hey hey hye, the guy was just trying to help, at least you didnt get a "go look in google" answer or some dumb shit like "if you don't know, you should write gaemz in gamemaker"
don't need to be so salty :(
anyway, are you taking a class or trying to build something? or is just curiosity?
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
30
XP
436
Country
France
hey hey hye, the guy was just trying to help, at least you didnt get a "go look in google" answer or some dumb shit like "if you don't know, you should write gaemz in gamemaker"
don't need to be so salty :(
anyway, are you taking a class or trying to build something? or is just curiosity?
Hey, thanks for all the replies!
Well, it's a bit of the last two. I'm making homebrew games for the system, and while I can do without This info, I'd like to fully understand the system out of curiosity :).
 
  • Like
Reactions: migles

catlover007

Developer
Developer
Joined
Oct 23, 2015
Messages
714
Trophies
1
XP
3,836
Country
Germany
I couldn't find any way of defining what kind of data they would contain. I mean, I know about the registers that define their semantic, but what about the different kinds of data From the input buffer? Is the GPU just always expecting floats?
Thanks for the Help!
The the GPU reads the data from the the linear heap and converts it into it's own internal format, which is probably some weired fix point format(so neighter a plain integer nor an floating point number). When you play with the data within a shader, it's already converted into the GPU unique format, so it doesn't matter in which format the orginal data was.
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
30
XP
436
Country
France
The the GPU reads the data from the the linear heap and converts it into it's own internal format, which is probably some weired fix point format(so neighter a plain integer nor an floating point number). When you play with the data within a shader, it's already converted into the GPU unique format, so it doesn't matter in which format the orginal data was.
Oh, ok! That makes a whole lot of sense, what a relief! Thank you soooooo much! If you don't mind me asking, where did you get that information? Again, thanks a lot for your help!
 
  • Like
Reactions: migles

catlover007

Developer
Developer
Joined
Oct 23, 2015
Messages
714
Trophies
1
XP
3,836
Country
Germany
Oh, ok! That makes a whole lot of sense, what a relief! Thank you soooooo much! If you don't mind me asking, where did you get that information? Again, thanks a lot for your help!
I don't have a specific source for this, it's mostly combined knowledge from different sources(Wikipedia, programming for other GPUs using OpenGL, 3dbrew).

But I when it comes to the 3DS I can recommend looking it up on 3brew(https://www.3dbrew.org), although it is more about the low level functionalities, it can be very helpfull.
 
Last edited by catlover007,

JayFoxRox

Well-Known Member
Member
Joined
May 16, 2016
Messages
143
Trophies
0
Age
34
XP
257
Country
Gambia, The
If you are talking about the shader output registers those will map to fields which have a type given by the semantics [so colors will likely be reduced to 32bpp etc].
As long as you are calculating in the shader the data type will be a wider one.
Check the Citra source code for what we assume (?) those types are.

It shouldn't really matter though.
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
30
XP
436
Country
France
I don't have a specific source for this, it's mostly combined knowledge from different sources(Wikipedia, programming for other GPUs using OpenGL, 3dbrew).

But I when it comes to the 3DS I can recommend looking it up on 3brew(https://www.3dbrew.org), although it is more about the low level functionalities, it can be very helpfull.
Well that's where I was looking, but it didn't mention the conversion thing. I had no idea that was a thing among openGL enabled GPUs! This one was really giving me a hard time, you really helped me there!
 

elhobbs

Well-Known Member
Member
Joined
Jul 28, 2008
Messages
1,044
Trophies
1
XP
3,029
Country
United States
Well that's where I was looking, but it didn't mention the conversion thing. I had no idea that was a thing among openGL enabled GPUs! This one was really giving me a hard time, you really helped me there!
Just out of curiosity- why not just use citro3d? It handles all of this information. It is open source. If you want to see how the hardware works then look at the source for citro3d. If it does not do what you want then modify it. You are asking a lot of half formed questions - that do not really make much sense on the whole.
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
30
XP
436
Country
France
Just out of curiosity- why not just use citro3d? It handles all of this information. It is open source. If you want to see how the hardware works then look at the source for citro3d. If it does not do what you want then modify it. You are asking a lot of half formed questions - that do not really make much sense on the whole.
Well I'm new to this whole kind of thing, I'd just like to know how the hardware works and how to manipulate it, so using a wrapper that takes care of the low level stuff kind of defeats the purpose. Also, I'm really sorry if I don't phrase my questions quite well, again I'm new to this while kind of thing. Also, for instance for questions like this one I could not find the answer in the citro3d source as it's something the GPU does by default (converting to fixed point).
 

bubble2k16

Well-Known Member
Member
Joined
Jul 25, 2016
Messages
467
Trophies
0
XP
2,118
Country
Senegal
I have some experience in the 3DS hardware in my work of Snes9x that I can share with you. I think I covered in my previous post to you. But let me put in more detail:

1. Your C++ code constructs the vertex attribute buffers, and sends it to the GPU via GPU_SetAttributeBuffers.
For e.g., you may construct a set to contain 2 vectors, 1st made up of 2 INTs, the 2nd made up of 3 BYTEs. Let's say our first vertex contains this set of 2 vectors: [(1,2), (255,255,0)]. Your 1st vector is really what you intended to be the on-screen position, the 2nd vector - the color.

2. These set of vectors then get passed into the GPU's Vertex Shader (a program coded by you).
The vertex vectors gets passed into your Vertex Shader through v0 - v(n-1). I suppose the GPU takes care of actually conversion of data types from the source attribute buffers into floats. Now, based on the above example:
v0 is now (1.0, 2.0, ??, ??)
v1 is now (255, 255, 0, ??)

3. Then your Vertex Shader program then takes v0/v1 and processes them.
For eg., you tell the GPU to do this:
r0 <= v0 * 10
r1 <= v1 / 255
As a result the final result of the registers:
r0 is now (10.0, 20.0, ??, ??)
r1 is now (1.0, 1.0, 0.0, ??)

4. Finally, your Vertex Shader program then sets the output registers accordingly.
position <= r0
color <= r1
Now the texcoord0 and the color are important registers. Whatever value you assign to 'position' directly determines where the point will be on the target screen, and whatever value you assign to 'color' will determine the color output (there's a catch here, that you must configure TextureEnv properly before the color will take effect)

---------------------

Citro3D is the best choice if you don't require anything special. In Snes9x, in order to maximise the power of a Vertex Shader that can be run in parallel, I pushed quite a bit of work that could have been done in my C++ code into the Vertex Shader.

You can think of Vertex Shaders like another function that takes inputs v0-v(n-1), processes them, and outputs the final source texcoord0, on-screen position, and output color.
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
30
XP
436
Country
France
I suppose the GPU takes care of actually conversion of data types from the source attribute buffers into floats.
Oh man, first off thank you so Much for your answer! My only question is, catlover007 mentionned the GPU converts attribute data into fixed-point data, but according to You it's into floating point data.
So which actually happening then?
 
Last edited by cal64,

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    K3Nv2 @ K3Nv2: Ah see that's were you're wrong it's the shitbox everything has to be very serious