Homebrew What is GPUREG_ATTRIBBUFFERi_CONFIG0?

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
31
XP
446
Country
France
I've been looking at the portal3ds source code, and can't figure out what the GPUREG_ATTRIBBUFFERi_CONFIG0 register is for, as I can't find it in the internal registers page of 3dbrew. That being said, I suspect it to be an early define for GPUREG_ATTRIBBUFFERi_OFFSET.
But then, what's the difference between it
and GPUREG_VERTEX_OFFSET?

Any help is appreciated!!
 
Last edited by cal64,

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
31
XP
446
Country
France

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
31
XP
446
Country
France
From my current understanding, I got that GPUREG_ATTRIBBUFFERi_OFFSET is essentially an equivalent for the offset in vertexattribformat in opengl, defining where each vertex attribute is, while GPUREG_VERTEX_OFFSET sets where the first vertex to draw is.

Is that it, or am I completely wrong? Sorry to keep insisting but that would really help!
 

elhobbs

Well-Known Member
Member
Joined
Jul 28, 2008
Messages
1,044
Trophies
1
XP
3,035
Country
United States
Thank you so much for clearing that up!
And, would you happen to know what the difference between it and GPUREG_VERTEX_OFFSET is?
There is a base address used by all attribute buffers at GPUREG_ATTRIBBUFFERS_LOC. When you configure each of the individual attribute buffers the data is specified as an offset from the shared base using GPUREG_ATTRIBBUFFERSi_OFFSET.
GPUREG_VERTEX_OFFSET is generally left at 0 in homebrew. I suspect it has something to do with offsetting values referenced in GPUREG_INDEXBUFFER_CONFIG or possibly GPUREG_DRAWARRAYS or GPUREG_DRAWELEMENTS - not really sure though as I have not seen it used.
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
31
XP
446
Country
France
There is a base address used by all attribute buffers at GPUREG_ATTRIBBUFFERS_LOC. When you configure each of the individual attribute buffers the data is specified as an offset from the shared base using GPUREG_ATTRIBBUFFERSi_OFFSET.
GPUREG_VERTEX_OFFSET is generally left at 0 in homebrew. I suspect it has something to do with offsetting values referenced in GPUREG_INDEXBUFFER_CONFIG or possibly GPUREG_DRAWARRAYS or GPUREG_DRAWELEMENTS - not really sure though as I have not seen it used.
Thank you so much for all of this, this is really helping out! As for VERTEX_OFFSET being left to 0, it appears, in the case of portal3ds, that GPUREG_ATTRIBBUFFERSi_OFFSET is set the first vertex of whatever there is to draw everytime there's something to draw, thus defeating the purpose of the VERTEX_OFFSET register, I suppose.
That's what I got from the source regarding what you said, althought I'm probably wrong :) . The whole point of this for me is to learn this kind of thing, so if you have any thoughts regarding what I said here, feel free to share them, as talking about this kind of stuff really makes it easier to understand and learn! (Again, thanks a lot for your help, and sorry for my potentially broken english!)
 

elhobbs

Well-Known Member
Member
Joined
Jul 28, 2008
Messages
1,044
Trophies
1
XP
3,035
Country
United States
Thank you so much for all of this, this is really helping out! As for VERTEX_OFFSET being left to 0, it appears, in the case of portal3ds, that GPUREG_ATTRIBBUFFERSi_OFFSET is set the first vertex of whatever there is to draw everytime there's something to draw, thus defeating the purpose of the VERTEX_OFFSET register, I suppose.
That's what I got from the source regarding what you said, althought I'm probably wrong :) . The whole point of this for me is to learn this kind of thing, so if you have any thoughts regarding what I said here, feel free to share them, as talking about this kind of stuff really makes it easier to understand and learn! (Again, thanks a lot for your help, and sorry for my potentially broken english!)
GPUREG_ATTRIBBUFFERSi_OFFSET points to a buffer with vertex data. GPUREG_INDEXBUFFER_CONFIG is used to generate primitives based on the order in the index buffer. the index buffer format only allows bytes or shorts for the index values. in theory GPUREG_VERTEX_OFFSET could be used to start further along in the buffer. I suspect it is something along the lines of glDrawElements vs glDrawElementsBaseVertex, but I am not really sure.
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
31
XP
446
Country
France
GPUREG_ATTRIBBUFFERSi_OFFSET points to a buffer with vertex data. GPUREG_INDEXBUFFER_CONFIG is used to generate primitives based on the order in the index buffer. the index buffer format only allows bytes or shorts for the index values. in theory GPUREG_VERTEX_OFFSET could be used to start further along in the buffer. I suspect it is something along the lines of glDrawElements vs glDrawElementsBaseVertex, but I am not really sure.
While I didn't quite get the last part with the OpenGL correlation you made, I meant by "defeating the purpose" that while using the VERTEX_OFFSET register was possible, it would only cause the models to not be drawn fully. The only proper use of it I can think of would be to draw each model without adjusting GPUREG_ATTRIBBUFFERSi_OFFSET every time, and instead use the VERTEX_OFFSET register to separate the models from one another, however that does not seem feasible to me because of the way things are layed out in memory (the structs would prevent being able to keep the synchronisation between GPUREG_ATTRIBBUFFERSi_OFFSET and the vertex attributes from one model to the next, but then again maybe I'm not visualizing things right here. Would that be correct?) Also the VERTEX_OFFSET register is also left at 0 when using drawarray calls.

Thanks again, and by the way please tell me if I'm getting annoying with this :).
 
Last edited by cal64,

elhobbs

Well-Known Member
Member
Joined
Jul 28, 2008
Messages
1,044
Trophies
1
XP
3,035
Country
United States
While I didn't quite get the last part with the OpenGL correlation you made, I meant by "defeating the purpose" that while using the VERTEX_OFFSET register was possible, it would only cause the models to not be drawn fully. The only proper use of it I can think of would be to draw each model without adjusting GPUREG_ATTRIBBUFFERSi_OFFSET every time, and instead use the VERTEX_OFFSET register to separate the models from one another, however that does not seem feasible to me because of the way things are layed out in memory (the structs would prevent being able to keep the synchronisation between GPUREG_ATTRIBBUFFERSi_OFFSET and the vertex attributes from one model to the next, but then again maybe I'm not visualizing things right here. Would that be correct?) Also the VERTEX_OFFSET register is also left at 0 when using drawarray calls.

Thanks again, and by the way please tell me if I'm getting annoying with this :).
If that did not make sense then I recommend that you ignore the vertex offset register and leave it at 0.
 

cal64

Well-Known Member
OP
Newcomer
Joined
Oct 31, 2016
Messages
65
Trophies
0
Age
31
XP
446
Country
France
I just didn't get what you meant by that (I'm assuming you're talking about the OpenGL part...?). I didn't mean to sound rude, I'm sorry if I did.

EDIT: Ooh, Got it. Well, thanks to you I've got all the info I needed. Thank you, you're the best!
 
Last edited by cal64,

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • RedColoredStars @ RedColoredStars:
    Guy doesnt know wtf hes talking about half the time
  • realtimesave @ realtimesave:
    @SylverReZ that reminds me that my friend sells CRTs he gets cheap or free for hundreds of dollars. people are dumb
    +1
  • RedColoredStars @ RedColoredStars:
    And is incredibly annoying.
  • realtimesave @ realtimesave:
    man I just washed my shoes and they look exactly the same as before I washed them :|
  • realtimesave @ realtimesave:
    luckily they didn't fall apart
  • RedColoredStars @ RedColoredStars:
    Some CRTs are very much worth the price
  • RedColoredStars @ RedColoredStars:
    i used to go out to the recycling center every couple weeks and look at the crts and other electronics people would drop off. Usually screens were broken or severely scratched from being tossed around. Did find a good one here and there, but never anything like a 1080i widescreen crt.
  • RedColoredStars @ RedColoredStars:
    Or a good contition 40" Sony Trini that weighs 300 lbs. lol
  • RedColoredStars @ RedColoredStars:
    Literally 300 lbs. lolol
  • BigOnYa @ BigOnYa:
    I have a few of those boat anchors in my basement I tried giving away but no one wanted them, So anyone close to Columbus, Ohio area that wants them, (26", 2x 19") please come get, for free.
  • RedColoredStars @ RedColoredStars:
    Dont know anyone wants those smaller ones. Most are after larger sizes and the kinda top of the line models
  • RedColoredStars @ RedColoredStars:
    Motion handling and input lag on those things destroy plasmas, led, oled
  • realtimesave @ realtimesave:
    I had some really nice CRTs I should've kept
  • realtimesave @ realtimesave:
    now I have all lcd
  • realtimesave @ realtimesave:
    one in particular I regret getting rid of oh well :|
  • realtimesave @ realtimesave:
    the Sonys and stuff I don't care about
  • realtimesave @ realtimesave:
    and used LCD are hard to sell I can imagine.. not worth much
  • realtimesave @ realtimesave:
    @SylverReZ where do u lurk
  • a_username_that_isnt_cool @ a_username_that_isnt_cool:
    Is it piracy if it was released for free? Not in my opinion, but I also think it's not piracy if buying it isn't owning it, and it's not piracy if you can't buy it from the original creators anymore.
  • K3Nv2 @ K3Nv2:
    Free release can have loopholes where they still make money through ads
    +1
  • Xdqwerty @ Xdqwerty:
    sigh
  • Xdqwerty @ Xdqwerty:
    @a_username_that_isnt_cool, could you change your username?
  • Xdqwerty @ Xdqwerty:
    i guess not...
    Xdqwerty @ Xdqwerty: i guess not...