tnl trouble, how can you do hw state changes depending on the primitive being rendered
So, when trying to implement ARB_point_parameters and ARB_point_sprite, I came across some problem (this tnl stuff is hard to follow). The problem is, I need to set some hardware state dependant on the primitive being renderered (in particular, r200 needs perspective correction disabled for point sprites, as otherwise the tex coord interpolator will wreak havoc with the (hw-generated) point sprite texture coordinates). Obviously, this should only be disabled when actually rendering points. However, if there are no state changes between a glEnd and glBegin command, no usual state validation will happen. Am I missing something, or is it more or less impossible to emit state depending on the primitive? Same problem also exists for sw tcl - additionally there we'd want to change the vertex format (for point parameters attenuation), as it's highly inefficient to submit per-vertex point size if we aren't drawing points... Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: So, when trying to implement ARB_point_parameters and ARB_point_sprite, I came across some problem (this tnl stuff is hard to follow). The problem is, I need to set some hardware state dependant on the primitive being renderered (in particular, r200 needs perspective correction disabled for point sprites, as otherwise the tex coord interpolator will wreak havoc with the (hw-generated) point sprite texture coordinates). Obviously, this should only be disabled when actually rendering points. However, if there are no state changes between a glEnd and glBegin command, no usual state validation will happen. Am I missing something, or is it more or less impossible to emit state depending on the primitive? I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Same problem also exists for sw tcl - additionally there we'd want to change the vertex format (for point parameters attenuation), as it's highly inefficient to submit per-vertex point size if we aren't drawing points... You might be able to do this in the begin-notify routine also. Alternately, you could add an extra pipeline stage that does the required tweaking. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFFC2vX1gOwKyEAw8RAuyxAJ937gF4uksm7dDcJaTmhXh2b3ZtCQCgkO5P Kz/wpcTwV3CLT+zRj1pgImw= =KlCv -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: So, when trying to implement ARB_point_parameters and ARB_point_sprite, I came across some problem (this tnl stuff is hard to follow). The problem is, I need to set some hardware state dependant on the primitive being renderered (in particular, r200 needs perspective correction disabled for point sprites, as otherwise the tex coord interpolator will wreak havoc with the (hw-generated) point sprite texture coordinates). Obviously, this should only be disabled when actually rendering points. However, if there are no state changes between a glEnd and glBegin command, no usual state validation will happen. Am I missing something, or is it more or less impossible to emit state depending on the primitive? I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Ah, sounds like a plan. I thought the NotifyBegin would only be useful for vtxfmt-replace like things. I'll look into that. Same problem also exists for sw tcl - additionally there we'd want to change the vertex format (for point parameters attenuation), as it's highly inefficient to submit per-vertex point size if we aren't drawing points... You might be able to do this in the begin-notify routine also. Alternately, you could add an extra pipeline stage that does the required tweaking. I hope the NotifyBegin should be enough. Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
Roland Scheidegger wrote: I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Ah, sounds like a plan. I thought the NotifyBegin would only be useful for vtxfmt-replace like things. I'll look into that. That was too fast. The NotifyBegin will only be called if there is actually new state, otherwise the tnl module will simply keep adding new primitives. Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: Roland Scheidegger wrote: I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Ah, sounds like a plan. I thought the NotifyBegin would only be useful for vtxfmt-replace like things. I'll look into that. That was too fast. The NotifyBegin will only be called if there is actually new state, otherwise the tnl module will simply keep adding new primitives. I think the core should be modified to call NotifyBegin if there is new state *or* the primitive type changes. Perhaps there should be a flag to request it being called in that case. Brian, do you have an opinion on this? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFFEzLX1gOwKyEAw8RAjdVAJ90XNQuasCUxld6vn3xuJFhtmFffACffbJv UVg1wMAiJCTS4PxVIKVo6jo= =SA9U -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: Roland Scheidegger wrote: I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Ah, sounds like a plan. I thought the NotifyBegin would only be useful for vtxfmt-replace like things. I'll look into that. That was too fast. The NotifyBegin will only be called if there is actually new state, otherwise the tnl module will simply keep adding new primitives. I think the core should be modified to call NotifyBegin if there is new state *or* the primitive type changes. Perhaps there should be a flag to request it being called in that case. Brian, do you have an opinion on this? The tnl module is pretty much Keith's domain. One thing to keep in mind is glPolygonMode. Depending on whether a triangle is front or back-facing, it may either be rendered as a filled triangle, lines, or the vertices rendered as GL_POINTS (which may be sprites!). I think cases like that might be a fallback. Anyway, even if glBegin(GL_TRIANGLES) is called, you may wind up rendering lines, points or sprites instead of triangles. Off-hand I don't know how this is currently handled in the DRI drivers. Keith would know. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: Roland Scheidegger wrote: I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Ah, sounds like a plan. I thought the NotifyBegin would only be useful for vtxfmt-replace like things. I'll look into that. That was too fast. The NotifyBegin will only be called if there is actually new state, otherwise the tnl module will simply keep adding new primitives. I think the core should be modified to call NotifyBegin if there is new state *or* the primitive type changes. Perhaps there should be a flag to request it being called in that case. Basically for the hwtnl case you need to look at where you're emitting the drawing commands and inject the state right at that point. For r200 and ignoring the vtxfmt stuff, that means you need to modify the loop in r200_run_tcl_render to emit the right state at the right time, depending on what primitive is about to be emitted. The i965 driver is quite involved at this level as it has to change all sorts of stuff based on the primitive - the clipping algorithm obviously changes between points, lines and triangles, and so on. Regular swtnl drivers also turn stuff on/off based on primtive, there is quite a bit of mechanism in place for this already - have a look at eg. r128ChooseRenderState and r128RenderPrimitive/r128RasterPrimitive for details. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
Brian Paul wrote: Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: Roland Scheidegger wrote: I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Ah, sounds like a plan. I thought the NotifyBegin would only be useful for vtxfmt-replace like things. I'll look into that. That was too fast. The NotifyBegin will only be called if there is actually new state, otherwise the tnl module will simply keep adding new primitives. I think the core should be modified to call NotifyBegin if there is new state *or* the primitive type changes. Perhaps there should be a flag to request it being called in that case. Brian, do you have an opinion on this? The tnl module is pretty much Keith's domain. One thing to keep in mind is glPolygonMode. Depending on whether a triangle is front or back-facing, it may either be rendered as a filled triangle, lines, or the vertices rendered as GL_POINTS (which may be sprites!). I think cases like that might be a fallback. Anyway, even if glBegin(GL_TRIANGLES) is called, you may wind up rendering lines, points or sprites instead of triangles. Off-hand I don't know how this is currently handled in the DRI drivers. Keith would know. The i965 handles polygonmode in hardware by uploading programs that deal with all the possibilities. It's tempting to say it just works, but the reality is that it is pretty intricately coded. The r200 falls back to software tnl for unfilled triangles, and uses the same mechanisms as swtnl drivers for this. Regular swtnl drivers handle unfilled polygons by using the templates in tnl_dd/ to generate triangle functions which provide all the necessary logic for selecting the right sort of primitive and notifying the driver of transitions between the different primitive types. This is the RenderPrimitive/RasterPrimitive callbacks that exist in most of the swtnl drivers. Keith - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
